Time for another update. In recent weeks a lot of focus has been placed on testing and fine tuning the first zone of the game (roughly 20 to 30 minutes of game play). A lot of this has been cosmetic, but there has also been a lot of work linked to player movement ... making sure collision boxes are set up correctly, ensuring that the player can get out of any place they can get into (for instance if the player falls off a bridge ... can he/she get back onto the bridge) and so on. Linked to this has been a number of code changes aimed at making everything a bit more robust. For instance, I have been working on the player respawning code (as it was very fragile up until now), switch handling (the player can now activate switches by moving across them, activating them manually and through the use of keys) and creature AI (for instance one type of creature had a habit of jumping off tall buildings ... without Superman's ability to fly ... while others would try very hard to drown themselves on occasion).
Beyond this I've added a dialogue system so characters in the game can share information and story details with the player. It's a simple system (as shown in the screenshot above), but effective. Finally, as hinted at in the last blog post, it is now possible to fly thanks to the introduction of the gyrobot. After a bit of trial and error the movement feels right and most of the existing collision detection code seems to be working well (the exception is that for the moment it is possible to fly up through buildings - a few simple changes should sort that out). Linked to this is the need to control when and how far players can fly (so there can be 'walking' zones and 'flying' zones with puzzles and creatures to match. This has resulted in the introduction of fuel pumps at various points in the game which give varying amounts of fuel (normally about 30 seconds worth of fuel). Will see how this works out once I have a properly dedicated flying zone mapped out ... the biggest question is how to handle fuel availability at each pump (only reset the pumps if the player respawns, gradually refill over time, rapid refill but the player can only take so much fuel at any time - need to see which feels best when playing).
Hopefully with a bit more work the game will be in a good enough state to allow for the creation of a new video showing off a bit more of the world.
Not a lot of time this week, but managed to work on two elements of the game. First off I've been busy creating a few more friendly robots including Gyro, shown below.
This will be one of the robots controllable by the player capable of flying for short distances. With islands and tall towers featuring heavily in the level design this will open up the possibility to have a variety of puzzles where the player will need to swap around from robot to robot to advance - Gyro will be able to, as long as there is enough fuel left, fly from tower to tower or to other islands to collect items normally out of reach. In addition I've nearly completed another robot, this time with a few interchangeable elements so the robot can appear several times as villagers and so on.
The second area I worked on was adding additional sections to the game map - nothing too exciting as it mainly involved adding scenery between puzzle / action zones. However I have also started on a multi step puzzle linking the start zone to more advanced zones.
It's been a while as I had to take some time off from development due to illness. However, now back at work at last.
So what's happened since the last entry? Perhaps the most noticeable change is that I have been ... again ... working on the character models. The screenshots below (taken in game) show the new main character (the thinner of the two robots) and another friendly robot who the player will be able to interact with throughout the game (basically the robot will act as a sort of narrator at various points in the story). As can be seen when comparing with older characters, the models are more complex and the texturing a bit better. Next step is to finish rigging and animating these characters.
Other than this I have been adding new zones to the game with the map now roughly double its earlier size. The new zones show a ramp up in difficulty ... the first part of the map is intended to allow the player to get used to moving around and get familiar with basic actions (activating switches, using lifts and cable cars, completing simple puzzles and dealing with weak enemies). Now the puzzles are getting more complex (several switches to open a single door, etc) and enemies are more dangerous (chasing the player over longer distances and happy to fire off projectiles if they feel like it).
However, the concern was that I might ramp up the difficulty too fast leading to an anticlimax later on. In the end this isn't too much of an issue - having relative peaks and troughs feels right. However, most importantly, the dynamic map loading code (where map chunks are loaded as needed) means that it is relatively easy to move around different parts of the map - if a certain area is much more difficult that originally planned it is possible to lift and shift it to a later part of the game map replacing it with a less challenging area. All that is needed is a few file name changes and a bit of in editor tidying up of the height maps between the chunks that have been moved around.
It's been a while since the last update so time for a bit of news.
Looking first at the game engine changes have been made to improve player movement with it now being possible to run or walk - when dodging traps running usually helps, but the player can reduce movement down to a crawl when trying to avoid falling off narrow walkways.
Next up was the introduction of more content into the game. The map is constantly expanding in size with the general approach being to have one 'story path' across the map with frequent branches allowing the player to discover additional puzzles and rewards. In addition I've been creating additional building components to add a bit of variety to the different zones around the map. Of most note is the creation of a set of modular components that can be combined to create 'Donkey Kong' towers (several towers linked together by walkways, lifts and so on). Finally, I've reintroduced creatures into the game - with the final game map taking shape it's been possible to add creatures to each zone and really test them as part of the proper game (rather than in a sandbox environment). As a result of this I'm currently fine-tuning the AI to improve navigation and ensure that creatures do not chase the player endlessly across the map (this either ends up with long streams of creatures all chasing the player or Lemming like behaviour where the AI can't cope with certain areas and the creatures take suicidal jumps off bits of scenery)
However, most attention has been placed on creating the character models. First step was creating the models themselves and for a while whatever I did just didn't seem right for the game. Eventually I came to the conclusion that the models were all too thin and tall - it was difficult to see the models clearly without zooming in too much and zooming in changed the feel of playing the game. Consequently I tried removing the knees/lower legs and wrists from models while bulking out the rest of the mesh a bit. Result is that the models are much more visible and to scale with the rest the game world.
Next step was the texturing ... as mentioned in a previous post this is not a strong point for me, but I've finally (and painfully) managed to get to a point where the textures are good enough and I can move onto other stuff ... for the moment.
Finally I've been working on the character animation. As the overall objective is to have a light and fun atmosphere to the game I'm over exaggerating the animation a bit with movement being slightly 'bouncy' ... at least compared to the more 'serious' games I've worked on in the past.
To give a couple of examples the screenshots above are of the main character (COG) and a Gardener (a low level creature the player will encounter in the early part of the game). The idea isn't to create Steampunk robots but slightly worn out robots that have built the Steampunk world around them. Both images are taken from in game - an additional problem I had when working on the texturing is that what looked okay in a 3D modelling app (typically something with 'busy' texturing) wouldn't look at all the same in game (where simpler texturing as shown here actually works better).
Feedback obviously welcome.
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!