"Coders Block" : The Bain Of My Existance.

Anyone who has ever done any professional or freelance programming will know this.

Just like yesterday, you boot up the build pc, get the latest source code, check your todo list, rebuild the source code, figure out which task to take on first, and "STALL!!", you hit a mental wall and your head stops you going any further, it has to be the most frustrating things in the world, there is a job there to do yet you cant seem to get your mind to play allong.

I have spoken to plenty of programmers in the past about how they deal with the issue of coders block, and have had many differant answers, I have a freind who practices Iado, another who spends the entire day at the gym with a punchbag.

Coders block, just like writers block is the human brain's own way of saying stop and take a break.

The main difficulty is that usually the coders block kicks in when" taking a break" simply isnt an option, when there is a strict deadline rapidly coming up for example.

My own methods of dealing with coders-block are quite simple, I have no idea why they work but basically they seem to help.

First of all, I close down my code, afterall there is no point in sitting here staring at it.


Then I usually grab a book, put some music on and read until the block lifts, by doing this I actually read Stephen King's "The Shining" in a single evening.

 I have also discovered more recently that writing seems to help,(hence this post).
I take a few steps back and write up a postmortem on a recent project or write a progress report on an active project.

This obviously is great, since it is something to refer to as soon as my head kicks back in.

I also have found that just turning the computer off and going to the woods for a run really helps.

However the best thing I have ever found, is watching a really good and/or really rediculous horror film. Anyone who has been in my office now knows why I have the entire box set of Knightmare on Elm Street on my shelf right next to "Frank Luna's DirectX Book" and "AI by Example", and why I have all of the Saw films saved on my hard drive.

Hopefully writing this post, will both help my coders-block and help some other peoples coders-block at the same time.

Im going off to read my freind "Matt"s latest on the slasher story he is working on.

If you have any suggestions of your own please feel free to comment

edit:

http://skindeep.logankoester.com/overcoming-coders-block

Thanks -Ant

Engineering SoulBear -Anthony Littlewood Developer's Blog - 4

I just finished off a new build earlier today, so I decided it was time for me to post a Devblog update.

firstly, I have added some more levels into the game, after letting my dedicated test team(family/freinds) playtest the game, it became quite obvious that I am expecting people to use a mechanic I have failed to tech them. This makes progression through the game impossible, until the player learns the mechanic. 

Most players are quite impatiant, and will soon just exit the game if they get stuck at an early hurdle,and never play again, the solution to this is to provide a very gradual progression of challenges, these should start at the very basics, left right up down etc, and then progress to gradually teach the more complex mechanics of the game later. By providing the player with a reward for each progression I keep the player in the game, and at the same time teach them the mechanics they need to advance further, this means that as soon as the levels start getting  truly challenging, I can assume the player has learned the lessons they will need to complete the challenge, while keeping them engaged.

I think the best example of this is in "Braid", presenting the player with a simple Pit-Key-Door type problem, forces the player to solve a simple problem with a mechanic that can be expanded on later.

I am now at the stage of game development where I am trying to think up fun and interesting challenges, that arent going to infuriate the player. Chris as a more platformer oriented gamer, will be capable of providing platformer based levels, with jump and run based problems. I however am more puzzle oriented so I would like to create levels with more "Lemmings" type problems, ideally we can create a clean blend of the two.

This build also marks a key landmark in development,  It marks the point at which the game is now a completed prototype, all of my tasks are ticked off, and we are therefore in the end stages of pre-production.

We now need to tidy the prototype up, replace the art assets and finalise a feature list for the final game.

Once this is done we need to assemble a collaborative task list then, its basically a steady jog to the production finish line.

As part of finishing the Pre-Production Prototype, Chris has created the Bear-Dummy, this is the in-progress character model, the proportions,scale and size of the Dummy represent those of the final character, since we have the full pipeline working, and have managed to take the dummy and place it ingame, we know the final character will work:

 Obviously the Dummy looks absolutely great, and Chris really went to town on it, its quite hard to see in the screenshot, and obviously I havent taken the time to set the lighting up yet for the level, but in a modelling app you can really see the attention to detail.


The Dummy is also there to help with conceptualisation, since from this point there could be many directions the game could go in, in terms of art and style, its better to take a screenshot, and change it in photoshop to look the way the final version of the game could look, if we create a number of these concept images, we can decide on the features we like from each, instead of spending all our time re-designing set pieces.

I think a good idea for people when making a game especially for a portfolio, is to have a definite game mechanic, idea or feature before I start implementing it, then design it on paper before going anyware near any code. 

If it is not absolutely clear what I am trying to accomplish or what the core feature actually is then I scrap it, since it can only harm development and waste my time.

Another thing I use constantly is to-do lists, I make sure I have a number of tasks to tick off every day, no matter how small the jobs are, this ensures the jobs are kept small, and therefore stops me being overwelmed while at the same time keeps me moving.

I also prioritise trivial things over fixing bugs, and prioritise bug fixing over new features/implementations. Since most programmers enjoy adding the cool new things but hate the little things, it is a good way to weigh up the bug fixing and the trivial, if I can tick off 5 or more bugs from a list I can add a feature, then tick that off.

The most important thing though is to work with someone else, even if they arent a programmer, having someone, to send a build to, enforces a deadline, and forces me to keep working, it also provides someone I can bounce ideas off, and ofcourse, as soon as you see the other persons artwork inside the game you developed, its worth all of the late nights it took to get it there.

I still need to get some video capture software together for some video's so im sorry for not having one. I am intending to come back and add some more screenshots etc.

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


Thanks -Ant

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

Welcome To My New Blog

Hello, welcome to the first post of my new project blog, I have decided to use this instead of my in-page news feed for a number of reasons, partly because the process of updating was a massive pain, but mainly because I had a cap on post size, and couldnt embed media.  Now I can have video's and screenshots which will be fantastic.

Thanks -Ant