• Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

About this blog

An indie 3D action adventure game with strong platformer elements.

Entries in this blog

Update time again ... recent work has concentrated on polishing and debugging code linked to map or level streaming.  As previously mentioned instead of discrete levels the world is one continuous entity which is loaded on the fly ... basically there is a 3x3 grid of map sections loaded at any one time.  When the player moves from one section to another the game loads the sections needed and cleans up the map sections no longer in use.

Simple in theory ... but a little more complex in practice.  The first issue was linked to the player revisiting map sections.  Here the concept of persistent game objects was needed.  To give a simple example, imagine a player collecting a coin and then wandering off to explore a different part of the world.  The map section is cleaned up and the coin is forgotten.  Later the player comes back, the map section reloads and the coin is recreated - and the player gets even richer.  Making the coin persistent (where it is never forgotten) means that once it is collected it cannot reappear.

That's a low impact example - more complex examples include moving objects (if a lift moves to a certain floor and stops then it should be at the same floor when the player comes back), switches and doors (an unlocked door should remain unlocked) and finally monsters (if it's dead then it should stay dead!).  Without keeping a track of these would result in certain parts of the map becoming blocked off and inaccessible to the player.

Then to add another layer still, I needed to consider what would happen if a player does something (for example activates a lift) and then dies.  When the player respawns should an object be persistent or not?  This has involved changes to the respawn process (it now needs to be a full game reload rather than a simple move of the player back to the last respawn point).

All of this was a fairly predictable aspect of the map streaming system.  Something that was much harder to narrow down and deal with was the collision detection.  To give a bit of background every game object (wall, coin, lift, platform) may have a series of collision polygons to identify where the player and monsters can move, where they can't, where they will be moved automatically (on conveyor belts for example) and where they will trigger some kind of event (collect an object, trigger a switch or another event).  The result is as shown in the screenshot below (to the left is the normal game view, to the right the debug view with collision zones highlighted).


The tricky bit ... objects are linked to map sections and the collision detection code iterates through the different map sections to check for collisions (there are probably better ways to do this but the collision code is the bedrock of the whole game, implemented early on and not easy to change).  In general this works fine - the object is fully in a map section, the player or monster in the same map section and the collision detection works a dream.  Unfortunately there are certain objects that slightly overlap the edges of a map section - bridges are a typical example of this where effectively the bridge links one map section to another.  To deal with these cases I had the choice of always making sure objects didn't overlap ... which would lead to restrictive level design or update the code to handle overlaps.  So I updated the code and it worked fine 99.9% of the time.  Unfortunately occasionally it would break (anywhere on the map when objects overlapped in a certain way) and the collision detection would effectively switch off and the player would fall through the floor.  Eventually after a lot of debugging the source of the problem was found – the overlap checking where, for some reason, I had got distracted and forgotten to add the last two lines of code.  Two lines, probably 20 characters missing and as a result probably 2 weeks of on and off debugging … sometimes I need to be reminded why I enjoy developing games ;)


Time for an update.  

So what have I been working on in the last couple of weeks?  Firstly the lighting and particle systems are activated.  The particle system is pretty unintrusive with the most notable aspect being the chimney smoke rising from the different steampunk engines.  Alongside this there is now a bit of splashing water and a few sparks flying around.  Much more noticeable is the lighting system as demonstrated in the new screenshots.  Here there is now a day / night cycle - I spent quite a long time making sure that the night was not too dark and I already have a game setting allowing this to be turned off (while this will lose a lot of the atmosphere just having day light slightly improves performance ... no other lights need to be active ... and maximises visibility).  Introducing other lights was a bit more problematic than expected.  Firstly, it took a while to get the light fall off fine-tuned correctly and secondly I upgraded the code quite a bit.  Originally, the light manager would always choose the lights nearest to the player, meaning that a maximum of 7 lights (beyond the sunlight) could be active in any scene.  Okay, but it did mean that more distant lights would suddenly flick on.  The new logic activates lights nearest to each game object or map tile currently being drawn, allowing a much greater number of lights to be shown in any scene.  In general the list of lights to activate are pre-calculated as each map section is loaded, with only lighting for moving objects being calculated on the fly.  So far seems to be working nicely - if I overloaded a particular area with lights there could still be light pop-up, but with sensible level design this can be avoided.  I did consider pre-baking the lighting but with the day/night cycle and the desire to alter light intensity and even colour on the fly this was going to be too complex and the performance of the current solution seems to be very good.


The other task I've been working on is the introduction of two new map zones.  The objective was to introduce something distinct from what had been done so far and to this end I have been working on a wilderness and an industrial zone.  And the wilderness zone completely failed to work.  It's a beginner zone so there wasn't any intention to overload it with complex gameplay, but even so it's just empty and uninteresting - back to the drawing board on that one.  As for the industrial zone this one is going better.  There are a number of new models being used and a few more to add with a couple of objectives in mind.  First off the aim is to create a little bit the confusion of a steampunk factory - pipes, big machines, smoke and steam.  Secondly, to hint at the down side of (steampunk) industrialisation with the texturing more grimy and even the addition of waste stacks (handily blocking off the player's progression requiring them to navigate their way round more carefully).  An early draft is shown in the screenshot below - the ground texturing needs to be changed with green grass needing to be replaced by rock and sand and I will also be working on the lighting and fog - to draw in the view and create a darker scene even in the middle of the day.  The scene may be a bit too busy at the moment, but I will see how I feel once these changes are made.

Hope the update was interesting - as before any feedback most welcome.  

In hopefully the first blog of a (fairly!) regular series I would like to introduce the game I've been working on for a while now.  With a working title of COG, the game is a 3D action adventure game with a Steampunk theme and strong platformer elements.


This is very much an indie project ... the coding of the home grown engine is done by me, the 3D modeling is (largely) done by me, the level design is done by me and ... well you get the idea!  About the only support I'm getting is from my kids who are doing the 'QA' (and who are super critical when something doesn't work!).


So where am I with this project?   The game engine itself is pretty much 'feature complete' and the game playable even if there is still a lot to do in optimising and polishing the different components.  Most of the standard platformer elements (conveyor belts, lifts, moving platforms, spike traps, switches, etc, etc) are already working and available through the level editor with the 'levels' (more accurately map sections) loading on the fly to create a continuous, seamless world.  Basic monster code is already in place with it being pretty easy to add new monster types as needed for the game.  The lighting and particle systems are  currently being reintegrated into the game (the code is complete, but was deactivated while creating the first builds) so hopefully the landscape will soon be full of splashing water and rising steam and smoke (pretty important to have rising steam in a steampunk game!).  


The camera system is nearing completion - it allows the player to have full control of the angle of the camera with objects close to the camera position fading out to improve player visibility (this is the last bit being worked on here with the drawing order of semi-transparent buildings being tightened up and optimised).


Looking at the content there is currently some placeholder content being used with the worst offender being the player's character which is currently a (not very steampunk) Kiwi rather than what will eventually be a small robot.  In addition, while the 3D models are almost all self created, the textures used are a mix of those I've created myself, that I've purchased and a handful of temporary placeholder textures.  These placeholders have allowed for rapid prototyping  (especially as creating textures is a slow and painful process for me), but will obviously need to be replaced in the near future.  Fortunately this shouldn't be a huge task as I'm using texture atlases that allow for easy swapping in and out of new textures ... there should be relatively few cases where it may be necessary to tweak the texture mapping.  For information the screenshots and video contain this placeholder content.


As a result of all this there is now quite a nice library of 'Lego bricks' available including a range of basic building blocks (platforms, towers, walls, pipes, etc), more exotic props (the already mentioned spike traps, barriers, lifts and switches as wells as the mandatory barrels and movable crates), plants, rocks and other landscape elements.  Finally, there is a series of animated models including waterwheels, steam engine, pistons and so on whose clanking and whirring will helpful give the impression of a living world around the player.

So things are going pretty well at the moment (especially given the limits on the time I can devote to this) and COG seems to be getting to a stage where it is moving from a process of writing code to one where the current task is to complete the game - a pretty rare thing for me!

Please let me know you think of the screenshots and video - one of the main reasons for starting this blog is to start getting some feedback to help shape the remainder of the game ... all constructive comments would be very much appreciated.  Also if there is interest in a particular aspect of the game development process I would be happy to share more details in a later blog entry.

Thank you for your time!

Sign in to follow this  
  • Advertisement