Engineering SoulBear -Anthony Littlewood Developer's Blog - 3

First of all, my apologies for not posting sooner, ive been spending most of my time getting a number of early builds shifted out, the idea here is to work on bugs before features, once I get to the point where the bugs are sorted, I add some polish, assemble a build, then start adding some things from my feature list.

This way the problems in the build never stack up beyond my ability to controll them, and thus far the build is feeling pretty solid.

While I am still using placeholders for the time being, I have got the jumping to a point I am happy with and the dragging/lifting mechanics are working very well, the build can actually be considered as a full game now, with animation, mechanics and goals.

I also have support for multiple levels now, although I have not developed any more than one level. 

My editor is also suitablaly developed to fit the build.

I have made a number of significant improvements to the editor, this has been developed as a seperate game state, therefore allowing me to engineer a level, save then play the level, then go back to editor and make changes within a few seconds of one another, this maximises turnaround time and means that everything just becomes easier. 

My more recent improvements, are to the "stacking" mechanic, this allows players to lift objects onto each other in order to solve problems:

As you can see here its basically good enough, it will never be absolutely perfect because of its implementation, for efficiancy and speed and also to give maximum flexibility, the collisionmeshes used for the body's on these crates is actually made up of small spheres, since spheres are so easy to perform collision detection and physics on, unfortunately this also means the crates do not represent a physically accurate model of the visual representation so there will allways be innacuracys, but for the ammount of freedom this provides Chris and I as developers its worth the trade off.

You can see the character there, getting all of the animation blending to work properly was quite a challenge, and I intend to write an article on how I did it in the future, its comically simple once you figure out the trick.

Also the same with my new implementation of jumping; the hard thing is getting the jump to appropriately work with the physics engine, in a 2d game with simple collision detection and responce, the world state is far more robust, but with a physics engine, nothing should ever have its state changed directly, i.e. position, it causes the future state of the world to be inherantly unpredictable, and thus unstable. 


I will hopefully get chance to create a video of the lifting and stacking aswell as a video of the editor. as soon as I do I will put them on here.


As allways if you have any questions or comments feel free to email me.


Thanks -Ant

Engineering SoulBear -Anthony Littlewood Developer's Blog - 2

Anyone who read my previous developer's blog will know I have been working intesively on a new project over the last few days, and have been trying to use rapid prototyping and refactoring techniques to get things working first, then update them to be more flexible and extensible later. I have found this approach to yeild fantastic results when working in smaller groups, in software development terms this technique is often refered to as "sprinting".

After spending the last two evenings, adding some more things in I deceided id add a new blog post to document my progress.

firstly menus and sound are working:

As you can see, its a menu and it works, its not exactly pretty or very interesting, but its clean simple and therefore good enough for now, and we can allways replace it with something better in the future.

I intend to write a technical blog on how I develop my menus at a later date as it is something a lot of people seem to have problems understanding when they first work on games, I have also put in a developer mode toggle so the game will bypass all of the menu's and go straight into a level, while it mabee only takes a few seconds to go though a menu all of that time adds up, considering how many times the game is closed and re-run during development, just that simple switch can save a few minuites every day.

I have also added resource archive support, this makes builds tidy at the very least.

 I have also improved the camera system, this is more of a development feature than anything else, but the camera can be decoupled from the central character and panned arround the level, obviously if there is something in the level intended for testing to have to walk to the location with the avatar is quite time consuming.

But the main tasks I have been taking on over the last few days have been focussed on refactoring my entity creation code, I have used an abstract builder, design patern as my entity manager, this basically means I register entities with the builder as "templates", then any entities I need to create, I can do simply by instancing from the templates.

Approaching entity creation this way, has meant that after a one line registration function, I can then spawn new entities from a one line creation function, or a single event(the event can be used to spawn new entities as the system is running) and all of the physics callbacks and event registration is handled automatically by the entity manager. This is another area I will cover in a future blog post.  

I hope you have enjoyed the second update following the progress of "SoulBear", I appologise for not having any nice screenys for this post but all of the work over the last few days has been code focussed, most of the groundwork is now done however so I can move my focuss back to tools and the game its self, I am also aiming at having an internal build ready by Thursday, so I should have some nice screenshots ready quite soon.


As allways if you have any questions or comments feel free to email me.


Thanks -Ant

Resource Management : A Package Based Approach

Hello And welcome to my new post on Resource Management in games.

I decided to write this as all games require various resouces,
yet there are supprisingly few articles
or tutorials on good approaches to the problem of managing them.

firstly a resource can be defined as any exteral asset that can be loaded into the game, for instance sounds, 3d art, textures, and to a certain degree even game scripts can all be considered as resources.

Unfortunately all of these assets take up a lot of storage space and memory, they also have an irritating tendancy to stay in memory after the game has closed down, and most programmers will put a great deal of time into reducing the memory overhead and leaks caused by these resources.

A naïve way to approach resource management, is to not see it as a problem at all, since finding a watertight approach can become quite complex, if a person is just starting and has limited programming knoledge, this approach is perfectly acceptable,

But for an actuall game, these resources must be tracked and released again. 

Any C++ programmer know's and fully understands the usage of the "new" and "delete" operators:

Type * variablename = new Type(); //allocate memory and assign it to a pointer

this method of allocating memory has many advantages to the standard one but has the disadvantage of not being automatically freed when the variable goes out of scope, basically the programmer needs to take controll and delete it again manually:

if(variablename ) 

{

 delete(variablename ); //clear the allocated memory

 variablename =NULL //ensure the pointer is not pointing to arbitary memory

}

when a texture or other resource is loaded in this way it also must be released.

and chasing after every allocation, even in a game the size of tetris can quickly turn into a massive headache.

A better method of getting around this is to create a linked list, of an abstract "resource" type, then create a manager for this list.

any resource type, for instance "texture" will then inherit from the abstract type and define a custom Release method:

 now, I create an instance of the resource manager:

Resource-Manager* resource_mgr = new Resource-Manager();

then I can simply add the resource on creation:

resource_mgr->Add_Resource(new Sound_Resource("beep.wav"));

resource_mgr->Add_Resource(new Texture_Resource("face.bmp")); 

and then on release I simply call the resource managers Release_all() function:

Resource-Manager->Release_All();

and the manager will then call the Release for every resource in the list.

Personally I take this further, and use an xml document to script the resource loading:

 Note: I usually add an xml parser to my projects just because it has so many potential uses, this could just as easily be a simple association list

and add a "name" parameter to the base resource type, now when the xml is parsed the resource manager can be populated, automatically.

since traversing a linked-list is trivial I can create a simple "GetResource()" function that takes in a name string, searches the linked-list for a match and returns a Resource pointer to that node now all I need to do is:

 face_texture = (*Texture_Resource)resource_mgr->GetResource("Face");

 

whenever I need the texture. The massive advantage to all of this is that any new resources can be added without requiring the game to be rebuilt. 

My own system also includes an abstraction over zlib, meaning that all the resources can be loaded from an archive automatically, this archive can then be compressed, password protected, and even encrypted.

Obviously for a tetris clone most of this is overkill but for a project with more than one developer I would strongly suggest looking into this more intellegent system.

In a later post I will go into more detail about the zlib integration (since I found very little on it) and explain some of the other features I have added to my own system.

note: I chose to add zlib since it met my own requirements, this is however not strictly neccisary, if you wish to simply package all of your resources together, a far simpler implementation would be to load all of the resource data into a "flat-file" or an xml file as raw data and then just store the offsets in the linked list, if you do this however it would probably be best to write a tool to make things easier.

As allways, if you have any questions, feedback or comments, please feel free to email me. I also have source code if anyone would like to see it.

Thanks -Ant

Engineering SoulBear -Anthony Littlewood Developer's Blog

As my first set of blog posts I'd like to document the development of a new collaborative project a freind and I have decided to take on.

Chris Nichols, is a fantastic artist, and good freind and I am honored to have the opportunity to work with him again.

This is a brand new project, of Chris's imagining, and as such Chris is taking the lead design role.

I am heading the Engineering and Technical side of developent while Chris is also taking care of the Artistic Side.

we have both spent quite some time going over the idea on paper and discussing priority features, recently I felt it was time to actually get started, while I dont want to go into too much detail about the core story of the game, we do have some great ideas, and are allready making good progress.

The game is a 3d platformer with a 2d side view perspective.

The game has a heavy focuss on puzzle solving through lifting and carrying, for this I designed a "telekinesis" system, in function it behaves a lot like the gravity gun in half-life 2 allthough it is designed to be a lot more tempremental, the unusual ability will force the player to learn, in order to solve problems that are otherwise impossible.

We are not long into development but we allready have some fantastic features, and after looking at some of Chris's design work the game will look fantastic aswell.

I would like to post some screenshots showing how things have developed so far (note: all current art is made with placeholders):

 This image is from the point where we had the absolute minimal system requirements inplace:

1. An animated character
2. A character controller
3. Keyboard input
4. Collision with a static body

Once we had these foundation features in-place we could begin prioritising certain more complex features over others.

After discussing certain gameplay mechanics with Chris, I had an idea for a "push-ball", as you can see from the size of the ball, the player cannot get over it and on a 2d plane cannot walk around it, forcing the player to deal with the obstacle, this provides a perfect means of teaching the "push mechanic", in a simple and stable environment.

After getting the minimal application working, I started adding some more intuitive code, mainly taken from my previous games.

I also developed a new event manager, this was neccisary since the game will feature some quite complex options, only realistically possible with a more advanced event manager.

The massive advantage of developing a game with an event driven focuss is that all problems essentially boil down to structure and event modeling. Once key objects have been designed their interactions tend to repeat themselves. it does however have the drawback of requiring specific conditions to be explained, where other approaches could make autonomous assumptions. 

 This screenshot represents the current stage of development, the "test-crate" behaves as one would expect it to, while the actual game would probably force the player to push an object this size, for testing and because its fun, I have allowed the telekinises to effect objects of this size also.

here the player is presented with the problem of a pit, the sides of which are angular, while the player can jump over the pit, the suggestion is made that they could push the crate into the pit neutralising the problem at the cost of the crate. 

This could be chained with the ball rolling mechanic to present the player with the problem of rolling the ball over the pit to accomplish an objective.




I hope you have enjoyed the first of what will hopefully be many updates following the progress of "SoulBear", as much as I have enjoyed development so far.


As allways if you have any questions or comments feel free to email me.


Thanks -Ant