Using archetypes in Unreal Engine 3 (UDK)

March 6th, 2010

Special thanks

Before I start talking about archetypes, I wish to thank Jeremy Stieglitz from Trendy Entertainment for further explaining to me why I should be using archetypes.

Introduction

Archetypes are similar to Prefabs in that we use them to create instances of an object. The nice thing about using instances is that when you change the archetype that is stored within the package, it will update all instances in a map. On top of that, if you change the instance of an archetype then the value remains and it won’t be updated.

For those of you who come from an Unreal Engine 2 or Unreal Engine 1 background, archetypes is almost equivalent to creating many subclasses of a parent class and altering the class’s default properties. I say that it’s almost equivalent because while it does a somewhat similar job, it isn’t as easy to use as archetypes.

So now that we know what they are, you may wonder how they’re useful to your project. Here are some cases where they do become very useful.

  • When many variations of an object or actor is required (common examples are inventory variants of the same type)
  • When in editor tweaking would be easier, or if the programmer is implementing options that are outside of his or her responsibility (common examples would be allows colour options)
  • Reduce load time and or compile time (if you reference any content through script Unreal Engine 3 will load the content both in game and during compilation)

When many variations of an object or actor is required

It is usually common practise in programming to group things together based on the common functionality. For example, weaponry in Unreal is usually sub classed from Weapon. Inventory items in Unreal is usually sub classed from Inventory.

Back in Unreal Engine 2 or 1 we would add in the differences through subclasses. That is to say a Flak Cannon would be a subclass of Weapon, and that subclass would contain the differences that make the Weapon into a Flak Cannon.

When the differences are data or content driven then using archetypes is usually the best solution (I am sure that there will be some edge cases where using archetypes isn’t a good idea). So a good example of this, is when you have variations of something; let’s say five variations of the shock rifle where each one has a different material and different weapon damages. Archetyping the shock rifle would be the best solution here.

Using archetypes in code is simple. When spawning, you insert the archetype reference in the spawn function (for example, Spawn(class’Actor’, SpawnOwner, SpawnTag, SpawnLocation, SpawnRotation, ArchetypeReference, bNoCollisionFail). When creating an object, you insert the archetype reference in brackets after the class declaration (for example, new () class’Object’(ObjectArchetype)).

When in editor tweaking would be easier, or if the programmer is implementing options that are outside of his or her responsibility

Often when I’m told to implement a feature without the required content available, I’m often told to put in a place holder art. This is because the man hours it takes for a programmer to program a quick prototype the feature is often much less than the man hours it will take for artists to create the content (especially in this day and age!).

However, during the prototyping phase lots of tweaks may be required to know whether the prototype is actually a success or not. Often, a lot of these tweaks are for things that are outside the programmers realm of responsibility (it is often the game designers responsibility). Having to constantly tweak these values inside code and recompiling is tedious and a waste of time.

It’s far quicker to open up Unreal Editor, open the test level, open up the archetype properties, play in the view port and tweak from there.

Reduce load time and or compile time

One of the things that annoys me a little bit is that compilation times have gone up when using Unreal Engine 3. From memory, I don’t think Unreal Engine 2 bothers loading anything until it’s actually needed. However, it’s a double edged sword we’re having to deal with here. (Some of this information is hear say and a little bit of logic extending… so hopefully I’m right about this information!)

In the case of Unreal Engine 2, while it’s great that it doesn’t load anything till its needed; it also causes lots of pauses and hitches during game play. In the case of Unreal Engine 3, while it’s great that nothing really pauses and hitches during game play; it can take ages to compile code if you reference too much content.

One way around it was to use dynamic load object to force loading of an object during run time without having to pay the compilation penalty. But this is quite brittle and there’s no reference checking available either.

If you’re needing to keep reference of a lot of content, and then load it in one go, what you can do is to store all of that in an object archetype and load the archetype when you need to load all the other content as well. Make sure you don’t reference the archetype in code, or it will also slow down the compilation times as well.

You also get the chance to be able to seamlessly load things in by making the archetype as an actor archetype, putting content references in there and then seamlessly travelling to that level.

Conclusion

Well, I hope that makes it clearer as to why you may want to use archetypes. They’re a really useful tool that can help resolve many issues with game development and also help to speed up development as well. They can be a bit annoying sometimes, as you sometimes have to remember if you’re reading from a saved archetype that exists in a package, or if you’re reading from an instanced archetype. But overall, they’re very, very, very useful.

Extra reading

Posted in James Tan | No Comments »

Procedural level generation rant

January 23rd, 2010

Procedural level generation in Unreal Engine had been something I had experimented with since Unreal Engine 2. It wasn’t really possible to do well in Unreal Engine 1 since you could not generate new geometry during runtime. Well, to clarify, it wasn’t possible without an engine license.

It became a possibility with Unreal Engine 2 because of the introduction of Static Meshes. For those who haven’t been told what static meshes are, static meshes is about instancing lots of the same mesh everywhere. This technique adds a lot of extra polygons into a scene without having to store more than a single copy within video memory. While you can change the meshes scale, rotation and location you aren’t able to alter individual vertices.

However there were problems with doing procedural level generation in Unreal Engine 2. The first issue had to do with UV coordinates. Because you weren’t able to alter the vertex data with static meshes, if you were to scale and stretch any meshes then that would cause problems. As I recall, I got around this by making textures smaller, but that lead to other problems such as resolution issues (if the textures were enlarged). However, the major issue is that Unreal Engine 2 was predominantly vertex lit. A basic form of shadow mapping was present, but it wasn’t really powerful enough to use and it didn’t always work that well. Light mapping could only be done during compile time. So while it was possible, it didn’t look very good at all.

Unreal Engine 3’s main focus seemed to be about increasing the flexibility of the engine by introducing shaders into most aspects of rendering. Instead of using the fixed hardware pipeline, everything used the shader pipeline. With this improved visual acuity, a lot of the problems with procedural level generation that occured in Unreal Engine 2 simply vanished. The only problem I came across however, occurs when I scaled static meshes.

Both images in this scene have wall meshes that are partitioned up to form a complete wall. The difference is, is that the wall on the left image has one wall partition that has been scaled to have a width of 2x. This seems to lighten the mesh by a factor. The right image has perfect lighting. When I scale the mesh to say 0.5x, it darkens the mesh. The only reason why I can think this may be happening is that when the surface normals have been generated for a mesh, they’re unit length. Thus when used for calculating light, they don’t affect the ‘brightness’ of the end result. When a mesh is scaled, it must scale everything … including the surface normals which then does affects the brightness of the end result!

Thus unfortunately, the only way to really ‘fix’ the issue for now is to simply create every single variation of wall in a modeling program and import them all into Unreal Engine 3. I suppose you could argue that I should report this bug to Epic, and while I can … it doesn’t really help me in actually fixing the bug.

Posted in Derelict 9 | Comments Off

Choices and decisions

January 1st, 2010

When the Unreal Development Kit (UDK) was released back in November, 2009 I had a hard a choice to make. I could either continue to develop my platformer  exploration project that I had talked about earlier or I could develop something using the UDK. Unfortunately, I do not have the time to do too many projects.

The pros for continuing development on the platformer exploration project were:

  • Lightweight engine designed to run on low specification computers.
  • Written with C++ and cross platform libraries.
  • Work pipeline and tools were developed specifically for the game.

The cons for continuing development on the platformer exploration project were:

  • Time and cost of development was unknown. This is due to the fact that I was no longer a full time developer.
  • There were many aspects of engine design and development that I still did not understand or know how to do. Asynchronous multiplayer is an example.
  • Resources to handle software quality assurance. Because I was writing a lot of my own technology, it is doubtful that I would have enough of resources to fix bugs on systems that I did not know or understand.

The pros for starting new development using the UDK were:

  • Unreal Engine 3 has proven, war tested technology.
  • I know how Unreal Engine 3 works, its quirks and limitations.
  • Non programmers (such as texture artists, modellers, sound artists etc) could start development using Unreal Editor, and preview their results earlier.

The cons for starting new development using the UDK were:

  • Unreal Engine 3 was designed for what Epic was planning to do with it. Thus there were potential idioms that would not work for my game.
  • If extra tools were required, development time of those tools would be unknown as Unreal Engine 3 formats do not have official documentation.
  • Higher expectations to the over all quality of the game.

In the end, I decided to go ahead with developing using the UDK. This was mostly because I knew that I could trust Unreal Engine 3 to be able to deliver what I wanted to do, and because I knew the engine well.

Posted in James Tan | Comments Off

Four months zooms by…

October 14th, 2009

Well, it looks like it’s been four months since I last updated my blog. So what have I been doing, other than not writing to this blog? Well, as always, I’ve been working on games.

As some of you may know, I’ve decided that Viva La Donuta was never a game that I wanted to make. Towards the end of 2008 I was more or less in a desperate situation where I needed to make something which I thought would sell. I learnt a lot about game development while developing that project and using the lessons learnt from that, I decided to rethink about my future projects.

Brute Engine at this point is on hold. Quite as

One project that I’m somewhat confident to start talking about is Contrast. Contrast is a name that I always use, and it gets restarted quite often. The concept that I have for Contrast this time around is that it will be a 2D pixel art explorational platformer.

Players take the role of an inquisitor trying to figure out why a country on the brink of internal collapse would spend the majority of its efforts into developing a dooms day device. Unfortunately for this particular country, the dooms day device incorrectly detected the enemy as itself and thus launched nuclear warheads at itself.

So what I hope to achieve for this game, is that players are given a sense of freedom to discover story lines within the major storyline above, and solve why the dooms day device triggered upon itself. So the exploration part of the game isn’t so much finding hidden secrets in the level, although that certainly is a part of it, it’s about finding the stories about people who lived / worked / served in this country.

The project has been in the works for the last few months now, and most of the development has been spent in the tools and engine area. Acknowledging my lack of artistic ability, I’ve also decided to work with an artist I met on TigSource who goes by the name Xion.

As I get more done and have more things of value to talk about, I will post back here.

Thanks for stopping by.

Posted in James Tan | Comments Off

Thinking about localization/internationalization/globalization

June 4th, 2009

Currently I have been thinking very carefully about how to handle localization / internationalization / globalization (I’ll just call it localization for the rest of this post). Nereid (from irc.enterthegame.com; #fragbu) gave me a run down on his thoughts when it comes to dealing with localization. Originally, I had only considered localizing text, but he had considered localizing everything. Everything ranging from textures to sounds. When I considered that, I also agreed that this is a logical step in the way game engines should go perhaps. With the internet getting faster in more remote areas of the world, it is inevitable that people will be able to get their hands on your game. While supporting English is an obvious choice, it shouldn’t be the only choice. Certainly in countries like Japan, games that only support English don’t get very far!

However, there are two main problems that immediately come to mind if you are trying to localize everything. First of all, data look up can be a rather lengthy process and I had to put some limitations in the ways people could look up data. Secondly, because data look up is a lengthy process, physical data seeking could also be a problem.

The way Brute Engine handles data look up is by using URI (Uniform Resource Identifier) structure. URI’s have three strings in them, a package string, a group string and a resource string.

The package string represents the file name of the zip without the extension. All packages have the same extension (currently packages are just zips at this point, so for ease of development are just zip).

The group string represents a folder within a package. At first I would have liked to have an array of groups rather than just a singular one as this would have allowed developers to sub divide packages into clearer names. However for the sake of fast data look ups, I decided that only a single group would be best for now. Perhaps this may change in future, I’m not entirely too sure at this point since I have not actually bench marked the performance between having a single group and having multiple groups.

The resource string represents the file name within the package and folder. For now, the resource string does have an extension attached to it, although this may be dropped in favour of having a integer to represent the data that the URI. But at the moment, an extension is useful for development purposes.

Resources vary a lot depending on the resource type they are. Some resources may hold binary data, while some resources may hold human readable ASCII data. Others may be a combination of the two. Typically, the rule for this engine is that anything made by the engine & tools alone will be human readable XML data uncooked which can be cooked into a binary form (for faster loading and parsing) and everything else will be binary (since the data is created by another program, developers should have these stored in another file). More importantly, some resources are composed on multiple files.

A example of a complex internationalized resource, that I can think of right now, would be a sound resource. A sound file is composed of multiple files in order to provide internationalization.

  • One file stores the raw sound data as an array of 8-bit samples.
  • One file stores the sound sample rate and other sound related numbers.
  • One file stores the localized sub title text

In order to provide good localization, when Brute Engine goes to load this sound file, it must compose a virtual representation of the sound files that best represent the localization the user has chosen. This is only difficult because, not all localized versions of those sound files will contain those files. Since English is going to be the presumed fallback language, all English localized sound files would probably contain all three files. However, a French localized version of the sound file might only contain localized sub title text data … because the developer may not have hired someone to act the dialogue in French. So let’s say the user is French, and the sound is requested by a component to be played back. Thus when loading the sound file, Brute Engine will first load the French localized version, and if any other data is missing, it will then fall back through localized versions of the same sound file! (This is because Brute Engine doesn’t rely on just dual localization, it can handle variants of a language too, thus you may have French-Canadian localization which overloads a few things from the French localization which overloads many things [but not all] from the English localization).

Phew, that’s a bit of a mouthful and certainly a lot to keep in mind. In order to support this properly, I had to build some sort of a tree like structure to organise how this all works.

Lastly, to touch base on a subject that most people aren’t even concerned about is data seeking. Obviously with this sort of localization method, there is a lot of power and flexibility behind it. However, the data for a ’single’ sound file is distributed all over the place. Thus if the game was to be run off a CD/DVD/Blu-ray disc, loading times would be atrocious since the ROM drive would spend half the time just seeking to the right portion of the disc. However, since most consoles are region specific, it might be possible to simply cook the the fully localized development version into a single language specific version of the game. I certainly don’t know the dynamics of the cost involved with distributing language specific versions of the game … but it would solve this issue rather nicely! On the PC this problem isn’t really apparent since hard drives are pretty good at seeking for random data at random points on the drive, although loading performance is often increased if the data is all aligned by defragging the drive.

Posted in James Tan | Comments Off

Protected structs idea.

June 3rd, 2009

During my phases of learning C++, I was quickly informed that the practise of passing pointers around is a relatively unsafe thing to do. No matter what constant modifiers you attach to a pointer, the programmer can always delete what the pointer is pointing to. I’m sure many other programmers would argue that passing around pointers is just as safe as any other practise and that my overall approach to that topic is rather unjustified.

“Of course you shouldn’t delete it, no one needs to delete except the person who originally newed the object into existence.”

The problem with that reasoning is that, what happens if you branch out into a group project or if you are picking up someone else’s code. Also what happens when the rules are slightly bent, in that the ownership of the newed objects aren’t the object’s or function’s. Then the above reasoning goes out the window.

So typically, what I do is just return constant references to an object. For example,

const Object& GetObject()
{
  if (!m_object_ptr)
    Assert("m_object_ptr is null.");

  return *m_object_ptr;
}

This ensures that this object is relatively safe from being deleted by other objects or programmers. Still, this is a problem when you need to get an array of objects. Certainly if you are using std::vector or any other types of arrays that can’t handle copying constant references or structures, then the whole idea does fall apart.

I was pondering exactly how to handle this situation for quite some time, and I thought of using a protected struct. What this means is that the struct would contain pointers to the objects I want to send to another class, but the other class can only access these pointers as a constant reference because the struct would hide these pointers from the other class. For example,

struct ProtectedObject
{
  ProtectedObject::ProtectedObject(Object *object_ptr)
  :
  m_object_ptr(object_ptr)
  { };

  const Object& GetObject()
  {
    if (!m_object_ptr)
      Assert("m_object_ptr is null."); return *m_object_ptr;
  };

  private:
    Object *m_object_ptr;
}

This sort of structure hides away the pointer from the other class, but still allows itself to be copied into a std::vector, and thus you can now pass an array of pointers around with the same safety net.  It’s hard to tell if this particular idea will slow things down tremendously because I have to create these structures, but hopefully it won’t and still allow me to keep everything within all my C++ projects safe. The ultimate benefit is to the users at the end of the day, as it means that my projects won’t crash and burn an unfortunate death … at least not intentionally anyways.

Posted in Brute Engine | 2 Comments »

Researching deferred rendering again…

May 22nd, 2009

Now that I am very close to finishing my latest project which was Balding’s Quest Editor, I found out that I really enjoyed developing tool sets. From what people have been telling me, this is a rather rare facet of game development to actually enjoy. Apparently most people enjoy other areas such as game design, engine design and so forth. So with that in mind, I decided that perhaps it is best if I simply develop engines … and perhaps see where that leads me. Now that I’m very comfortable working two jobs (being a pharmacist here in New Zealand and developing software for Digital Confectioners), I suppose I can afford to simple develop an engine over a reasonably long period of time.

Because I have worked with Unreal Engine 3 for such a long time, I decided that I would try to emulate and expand on many of the tools they have created for their licensees. One of the things that really impressed me about Unreal Engine 3 was that it was always trying to focus on artists to get their content into the game as easily as possible. However, I considered that perhaps I should try to focus on game designers / story writers instead of artists. Perhaps Unreal Engine 3 was designed more for them … but it does feel very artist orientated to me.

So the first tool that I would like to develop is a similar material system that they have done. This could lead to some potentially very complex materials being run. So I went forth and decided to experiment with a deferred shading system in OpenGL. As some of you may know, I experimented with this earlier in DirectX quite a few months ago. The experiment was somewhat successful but it wasn’t as flexible as I would have liked.

So after a weekend of bashing out some code, I had my OpenGL deferred rendering system going. So far the only cool thing it can do is render a mesh with some normal mapping applied to it. But none the less, it’s a renderer that will allow me to start work on a material editor.

Deferred Rendering Immediate Output

This is the four rendering targets that I am using at the moment. The data held is diffuse, normal, position and depth. Nothing terribly complicated just yet.

Deferred Rendering Output

This is what the final lit rendering looks like (using a directional light). Note that this actually uses a diffuse and normal map to produce the rock like surface. It’s not fancy, but it’s enough to start work on a material editor.

Posted in Brute Engine | Comments Off

Back to the drawing board for Hexlo’s component system

April 28th, 2009

About a week or so, I was discussing about how I was pretty happy with Hexlo’s new component system. Unfortunately, as most designs go … this design didn’t quite work out that well.

The problem came when I had to do rather complex systems such as compound meshes. A mesh contains vertex data which define position data, texture coordinate data and color data; triangle data which define which triplets of vertices form each triangle and a texture id. Compound meshes are just when you have multiple meshes together. The reason why you need compound meshes is when you have meshes that require more than a single texture.

Why this became a problem was because the amount of data that was having to be transferred between the component, then to the register became very large per frame. This reduced my frame rate to a crawl. The system works wonderfully when you have small amounts of data which was the case for components such as sprites, lines and points, but once the components became very complex it became exponentially harder.

I had already predicted that data duplication would happen with this design, but I did under estimate the magnitude of that.

The other problem with this component design had to do with caching. Because components had to stay very generic, there was no way for them to store specific data for OpenGL or DirectX. Because OpenGL and DirectX manage and store objects such as textures differently to each other, I had to write a generic system in which then both OpenGL and DirectX would then override to implement their own specific methods. While this worked reasonably well to an extent, the worst case scenario had never been simulated. Since I would need to do look ups per frame, I can imagine that once I start hitting a certain number of objects on the screen it would probably slow the game down quite considerably.

So with those in mind, it’s back to the drawing board I think. I know the component system is achievable, but perhaps I am looking at this the wrong way.

Posted in Hexlo | Comments Off

Rethinking the component system for Hexlo

April 19th, 2009

I don’t believe I have announced Hexlo on this blog yet, but never the less it is one of the games that I am writing at the moment. The important aspect about Hexlo is that it mainly serves as my highly experimental projects in which I inject a lot of my new experimental methods into. I find it a little easier to inject new methodologies into projects like this because of their scale. Anyways, in Hexlo I wanted to rethink about my component system again.

A component system is one where entities in the world has a list of components which then define how that entities looks like, sounds like, behaves like and so forth. For example, for a rocket entity you may have a mesh component which renders a rocket projectile mesh onto the screen, a sound component which plays back a “fssssssssh!” sound during the rocket’s flight and perhaps a script component which contains the logic for when the rocket contacts something. Component systems like this are designed for the end user in mind. It also helps code reusability and extending current classes rather than having to copy/paste sections of code for different classes that aren’t able to extend similar classes.

My first initial stab at a component system involved using a lot of RTTI (Run Time Type Information) which was functional at the time but certainly an unsafe method of doing things. It is unsafe to me, because you assume a few things. For example, consider:

if (component_ptr->GetType() == Enum_Mesh_Component)
  ((MeshComponent*)component_ptr)->RenderMesh();

You assume a few things with this sort of code. First, you assume that GetType() will always return the correct value for each class definition you write.

  • What happens if you forget to override the virtual function in your child class? Make it abstract you say?
  • What happens if you return a conflicting identifier to another class?
  • What happens if component_ptr is a child class of a child class of Component?

And lastly, your code will be littered with gigantic switch and if statements that may get out of control. Lastly, you simply assume that component_ptr is going to be MeshComponent. If it isn’t, then it is going to explode as you try to access a function from a class that doesn’t actually have it. There is simply no real fail-safe methods here. I suppose you may interject and suggest that I could have used dynamic_cast<> to provide fail safe methods. The main problem with using dynamic_cast<> is that it is rather slow in relative measures.

Certainly when everything is written correctly, everything would be fine. But that’s like saying that a program will never have bugs in it because everything will be written correctly.

My second attempt at a component system involved interfaces. This assumed that every component is just a component and that typing was unnecessary. The base class, Component, would essentially have a large list of virtual functions that were setters and getters for everything imaginable. While this was very fail-safe and anything error related was able to be caught during compile time, the base class became very bloated with one off virtual functions that would eventually create such a large virtual table for these classes that the amount of memory used per class would be huge. For example:

class Component
{
  virtual void Set(const unsigned int &id, const int &in)  { };
  virtual void Set(const unsigned int &id, const float &in) { };
  virtual void Set(const unsigned int &id, const short &in) { };
};

As you can imagine, not every component would require all of these virtual functions but they would still incur the penalty of having them within their virtual tables. I couldn’t make these into abstract functions because then every component would need to implement them anyways making every child class simple massive.

So with Hexlo, I wanted to avoid that sort of a setup because I knew it would be a horrible system to work with. While it was very safe, it was memory hogging and too bloated to be usable. So when I thought about it some more, I realized that most of the time it was the entities themselves that often needed to alter the properties of their own components. So with that in mind, since the owners of these class instances were the entities themselves, keeping a private pointer reference to the component would be fine. End users would also not have to care too much about the memory management of these pointers, since a pointer list would manage these class instances.

class Entity
{
public:
  void AddMesh()
  {
    m_mesh_component_ptr = new MeshComponent();
    m_components_ptr.push_back(m_mesh_component_ptr)
  };

private:
  std::vector<Component*> m_components;
  MeshComponent *m_mesh_component_ptr;
};

So, with that using m_mesh_component_ptr is used when the class itself wants to change any parameters within it, but I would suspect that the majority of the time this isn’t really required at all. So that’s nothing special just yet, but in this particular case, let’s use this within a rendering scenario.

class Viewport()
{
public:
  void Render(MeshComponent &mesh_component);
};

class Component()
{
public:
  void Render()
  {
    InternalRender();
  };

private:
  virtual void InternalRender() = 0;
};

class MeshComponent : public Component()
{
  virtual void InternalRender()
  {
    GetViewport().Render(*this);
  };
};

*GetViewport() returns the Viewport class instance as a reference

This sort of structure pretty much resolves most of the issues I came across with the top two methods. I don’t have huge banks of virtual functions that hardly ever get used by many child classes, I don’t require RTTI since C++ itself handles typing and it’s pretty darn fail safe at most areas. The only potential problem that could possible happen is that the amount of function calls that is required could be a little on the excessive side causing potential problems but I haven’t come across this yet in Hexlo. The only other ‘problem’ is that you have to write quite a lot of virtual functions within Viewport for all of the different component types you have. However, I don’t think that’s any different to having to write the actual rendering functions for handling the component anyways.

I’m feeling pretty good about this method right now. But perhaps in a few weeks, I might come up with an even better solution!

Posted in Hexlo | Comments Off

How I handled undo and redo in Balding’s Quest Editor

April 7th, 2009

Handling undo/redo sounds like a really trivial task for any application. In fact, I suppose because it is so common in all the applications we use these days that we simply just expect that every application we ever use simple have those features. However, upon further delving it actually turns out to be a rather difficult thing to implement.

The main constraint with any undo/redo systems is memory. For naive undo/redo systems they would just keep a copy of each modified object within memory. For example, if I was to do this, a copy of each state of the level prior to change would exist in memory. Since each level in Balding’s Quest is of relatively small size I could potentially get away with doing this. After all, if each level was to say only use 20 kilobytes of memory, then it would fifty one level states before I reached a megabyte of memory. While that sounds like a lot of states available, it really isn’t much to be honest.

The first problem is scalability. If Balding’s Quest level formats were going to become more complex and thus use more space in memory, even if it was another 10 kilobytes larger then the number of states I have available per megabyte then becomes thirty. This is a pretty big drop considering a small increase in the size.

The second problem is going to be assuming that most operations will encompass broad changes. But in most cases with the editor makes rather small changes to the level at each time. For example, when a user paints tiles onto the levels that is one tile at a tile that is being changed. So painting fifty one new tiles onto the map isn’t hard to do at all.

So, well with that in mind, the naive approach is obviously not going to work. So after much brain storming, I decided that a history event logger could work. The idea behind this is that each time the level changes, I would record it as an event detailing what happened there. If a tile got changed, I would write in memory that “Tile at x, y was changed from palette index 0 to 1″. To undo the event I would just interpret the event backwards and then to redo I interpret the event going forwards.

This seemed to work in the end, but the only ‘problem’ is that I have to write undo and redo functions for every action that a user can do. However, it does resolve both issues I stated above with the naive approach. Perhaps in time I’ll come up with a better method.

Latest Balding's Quest Editor screenshot

Posted in BqEd | 2 Comments »

« Older Entries