Saturday, 17 April 2010

"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


Thanks -Ant

Thursday, 1 April 2010

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