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





No comments:

Post a comment