Updated 28/08/2009
As the original post is getting a bit on the long side, I'll be continuing the Chaos Caverns 2 dev diary here.
I've been taking a couple of days off to think through what direction I want to take the game in. There are still a couple of things that I'd like to add in, conveyor belts for example, but nothing that is likely to stop me from finishing the game.
I've been toying with the idea of releasing a demo of the game so far, but to be honest I'd rather release a finished (and more importantly tweaked and polished) game this time around. With that in mind I'll be putting out a call for volunteers to beta-test the game once the game is a bit further along. Interested? Then feel free to get in touch either via the comments on this blog post, the development thread on Retro Remakes or by email at dans.remakes(AT)googlemail.com.
Right, enough gabbing for now - back to coding!
28/08/2009
One of the problems with being less than artistically gifted is that doing the graphics for a game takes a lot longer than you might expect. Trying to make animated sprites takes even longer.
Rather than trying to create the sprites from scratch I'm (mainly) shinking and editing images from photographs. This is giving the game a much more "unique" look and certainly makes up for my lack of artistic talent.
Showing posts with label Programming. Show all posts
Showing posts with label Programming. Show all posts
Wednesday, 26 August 2009
Saturday, 1 August 2009
Chaos Caverns II - Dev Diary
Updated 21/08/2009
A couple of months ago there was a discussion on Retro Remakes relating to creating platform games. The discussion grew to the point that I got a bit carried away and added an early (very early in fact) version of the source code to Chaos Caverns, as well as writing some pseudo-code to demonstrate how simple it is to make a basic platform game.
The thing is that once I'd written the pseudo code I found myself wondering if it would actually work, and the only way to test this is to bloody well write it. And so, using my pseudo code as a template I wrote a basic platform game engine. It works too. In fact in some respects it works better than the code for the original Chaos Caverns.
So now I'm in a bit of a quandry as I'd already been planning an update of Chaos Caverns and was in the middle of fixing up the old code.
So on the one hand is the original Chaos Caverns, which has already been expanded to allow me to create a flip-screen arcade adventure in a similar style to Jet Set Willy and pretty much only needs the levels completing to make it into a completed game.
On the other is the new code sitting in the Testplatform2 folder. This isn't quite as complete as the other but has some important improvements:
1 - It has been upscaled to 640x480. This is double the resolution of the original and does look a lot nicer.
2 - I've written the new version using Object Oriented methodology, rather than the spaghetti code of the first one. It has taken longer trying to remove things like the level transitions from the old one than it has to write the new one from scratch. Also I've got the benefit of a couple of years experience compared to when I started writing Chaos Caverns.
3 - Even on the short test level I've created it feels rather nice to play.
4 - It should allow me to create a much better game, more in a 16bit retro style than the 8bit style of the first one.
Point 4 is the decider really. Even though I could knock out a quick game using the old code base I wouldn't be as happy with it as I think I could be with the new game engine. So I'm re-implementing the functions that are still missing, which is a slightly frustrating exercise, but the new features (such as animated tiles, and each tile being available in multiple states) already there makes up for this.
So here we are at the birth of what I'm currently calling "Chaos Caverns II".
I'll be updating this post with the development diary as time goes on, so stay tuned!
2/8/2009
Level switching code has been added to the game, so now I can start building the game proper. I've put together three screens as a test and it all works rather well. At this point it is starting to feel a bit more like a proper game.
Next step: Items and enemies.
12/8/2009
Summer time isn't the most productive time for programming, but have managed to track down and fix some bugs, including an extremely annoying one which caused the player to fall through the floor, but only when existing the screen to the left. Exiting from the right worked fine. Finally managed to fix it by re-arranging the movement code to make sure that the move down / platform checking code ran before the left / right movement and exit code.
I've also spent some time tidying the code up a tad, and starting to add in the code for the enemies.
I'm dealing with the enemies in a different way to how I did in Chaos Caverns. This time all the enemies from all the levels are read into a single array when the game initialises - rather than refreshing the list at each level change. This allows me to "kill" enemies and for them to stay "dead" between screen changes.
I'll be dealing with objects in the same way. Some objects will allow you to destroy enemies, so for example, collecting a pin will allow you to destroy the giant beach balls. More on that later...
To make the game feel a bit more like a game and less like a demo I've added a place-holder title screen.
OK, so that's a long way from brilliant, but at least it makes testing the game a whole lot easier in that once you've lost all your lives you return to the title screen rather than just quitting or jumping straight back to the first screen.
I've also added a music track for the title screen - again this will probably change before the game is finished - but for now I'm using Mozart's Rondo Alla Turca (thank God for classical music in the public domain).
As a side note - if any budding musicians are reading this and feel like donating a music track or two then please get in touch.
As of midnight I've got a moving enemy on screen (at last!) and can move onto the enemy collision detection routines tomorrow. *yawn*
13/8/2009
Oh no, Thursday the Thirteenth!
I'm not superstitious about the number thirteen, but today hasn't been a great day, work-wise.
At lunchtime we lost access to the internet, email, our advertising system AND our page transmission system - while we were half-way through transmitting a newspaper that had a 1pm deadline. It was down for a couple of hours due to an alleged power-cut in Oxford.
So we had three hours of dealing with complaints about something that we've got no control over.
Wonderful.
Follow that up with me being on call, and getting called back in twice (although as luck would have it I was able to deal with both calls remotely).
On the bright side I've got collisions with the first (and currently only) enemy in the game working. So that's nice.
15/8/2009
Motivation is often an issue when writing software for yourself. When things get tricky, I try and add "one feature a day". This at least gives some impression of the game developing rather than just lurking there waiting for me to complete it.
OK, so sometimes you miss a day - but today's feature is one that makes the game a bit more tricky - and that is allowing the player to die if they fall from too great a height. Not a difficult thing to add but something that I had deliberately left out of the original Chaos Caverns.
This time, however, if the level designs that I have in mind are going to work then this is a feature that I need - otherwise there won't really be any challenge.
Features remaining to be added (and this isn't a full list):
Other things to do:
16/08/2009
Today's new feature: Lifts. In getting the lifts working I've had a think about how I'm coding the game, and more importantly, how to reduce the amount of routines that I need whilst achieving the features that I require.
The lifts are a case in point. I'd considered making a new game object for the lifts, but then realised the obvious: "a lift is just a platform that moves." So by adding some new parameters to the platform object and creating a "move" method I've got a basic lift working with very little new code required.
I've still got to code the interactions between the player and the moving platform (ie. if the platform is moving left or right then the player's movement follows it). Easy for left to right, slightly more complex for up and down. Especially when I need to find a way of slowing down the lifts a bit as by default they are a bit nippier than I'd like.
I was also going to add another object for "traps" - basically killer objects. Thinking about it what is a killer object? In the terms of this game it is an enemy that doesn't move, so if I just use the existing enemy routines with a static enemy then job done!
18/08/2009
Still working on the lifts. As they were running a bit faster than I'd like I've added in some code to create a delay between each move - so the lift will only move every x number of frames. This works well and allows me to have fast and slow lifts as required.
Moving and jumping whilst on the lift works but... sometimes whilst jumping you fall through the lift, and I can't see why. Ah well, tracking down and squashing bugs is all part of the fun.
I've also been re-jigging the player movement code a bit so it should be a wee bit more optimised, as well as a bit smaller. For those interested, at present on a P4 2.8ghz the game uses around 4% of the CPU time.
Update: Bug fixed, so the lifts are now fully working (vertically at least). I've adapted the second screen so that it can only be traversed by using the lift - and it all seems to work nicely so far.
19/08/2009
Now that the lifts are working it is time to start expanding on the code to make this less of a demo and more of a game. With that in mind I've started adding a fairly basic score / level / lives display at the bottom of the screen.
The strange thing is that this revealed another bug: if you dropped from a height into water you'd lose two lives instead of just one.
After one hell of a lot of hunting through the code I finally realised that I was forgetting to reset the fall height, so when the water code killed you the fall counter still contained a value, and because you re-spawned on a platform it treated it as if you'd landed after a long fall, which kills you a second time.
An easy one to fix, but a bugger to track down.
20/08/2009
Today I've been expanding the code a touch (extra baddie movement types, horizontally moving platforms and some other bits).
I've also put together a short video showing the game in action. Not a lot to see so far, but you can get the general idea of the progress so far.
Tomorrow I'm planning to add the code for collectible objects into the game. Once this has been done then the game engine will be basically complete and it will be time to start adding enemies and designing some proper levels.
21/08/2009
Found and eliminated another bug - one that allowed you to pass through a solid block if you hit it precisely on the top corner whilst falling.
I've amended the second screen to add in a horizontally moving platform - which worked first time without problems. Mind you, once you've got the code working for the vertical lifts there really isn't a lot you need to change to get it working for horizontal ones.
I've also posted about this game on the Retro Remakes forum - so a big hello to anyone visiting from there.
Update: Collectible items are now working. Quite simple to add really, providing you remember to use methods rather than functions for your reading / drawing code. Why? Because functions can't access an objects fields (the variables that the object uses). This is a "it's too late at night for this shit" type bug.
22/08/2009
Today has been mainly spent "enjoying" a bout of either man-flu or hayfever. Either one gives the same result - my IQ has dropped so far that it now has a negative value, my nose and eyes are taking it in turns to drip, different parts of me are competing in the "most painful" competition (I think that my back is winning so far). Not surprisingly I've not been especially productive on the old programming front.
That said, I've started expanding the baddie routines a bit, so the beach-ball enemy now rotates as it bounces (which looks cool), I've added a balloon as another enemy, which is also semi-transparent. This also looks pretty cool in action.
I've also started tidying up some of the routines, and simplifying the code in a couple of places.
Continued in Part 2
A couple of months ago there was a discussion on Retro Remakes relating to creating platform games. The discussion grew to the point that I got a bit carried away and added an early (very early in fact) version of the source code to Chaos Caverns, as well as writing some pseudo-code to demonstrate how simple it is to make a basic platform game.
The thing is that once I'd written the pseudo code I found myself wondering if it would actually work, and the only way to test this is to bloody well write it. And so, using my pseudo code as a template I wrote a basic platform game engine. It works too. In fact in some respects it works better than the code for the original Chaos Caverns.
So now I'm in a bit of a quandry as I'd already been planning an update of Chaos Caverns and was in the middle of fixing up the old code.
So on the one hand is the original Chaos Caverns, which has already been expanded to allow me to create a flip-screen arcade adventure in a similar style to Jet Set Willy and pretty much only needs the levels completing to make it into a completed game.
On the other is the new code sitting in the Testplatform2 folder. This isn't quite as complete as the other but has some important improvements:
1 - It has been upscaled to 640x480. This is double the resolution of the original and does look a lot nicer.
2 - I've written the new version using Object Oriented methodology, rather than the spaghetti code of the first one. It has taken longer trying to remove things like the level transitions from the old one than it has to write the new one from scratch. Also I've got the benefit of a couple of years experience compared to when I started writing Chaos Caverns.
3 - Even on the short test level I've created it feels rather nice to play.
4 - It should allow me to create a much better game, more in a 16bit retro style than the 8bit style of the first one.
Point 4 is the decider really. Even though I could knock out a quick game using the old code base I wouldn't be as happy with it as I think I could be with the new game engine. So I'm re-implementing the functions that are still missing, which is a slightly frustrating exercise, but the new features (such as animated tiles, and each tile being available in multiple states) already there makes up for this.
So here we are at the birth of what I'm currently calling "Chaos Caverns II".
I'll be updating this post with the development diary as time goes on, so stay tuned!
2/8/2009
Level switching code has been added to the game, so now I can start building the game proper. I've put together three screens as a test and it all works rather well. At this point it is starting to feel a bit more like a proper game.
Next step: Items and enemies.
12/8/2009
Summer time isn't the most productive time for programming, but have managed to track down and fix some bugs, including an extremely annoying one which caused the player to fall through the floor, but only when existing the screen to the left. Exiting from the right worked fine. Finally managed to fix it by re-arranging the movement code to make sure that the move down / platform checking code ran before the left / right movement and exit code.
I've also spent some time tidying the code up a tad, and starting to add in the code for the enemies.
I'm dealing with the enemies in a different way to how I did in Chaos Caverns. This time all the enemies from all the levels are read into a single array when the game initialises - rather than refreshing the list at each level change. This allows me to "kill" enemies and for them to stay "dead" between screen changes.
I'll be dealing with objects in the same way. Some objects will allow you to destroy enemies, so for example, collecting a pin will allow you to destroy the giant beach balls. More on that later...
To make the game feel a bit more like a game and less like a demo I've added a place-holder title screen.
OK, so that's a long way from brilliant, but at least it makes testing the game a whole lot easier in that once you've lost all your lives you return to the title screen rather than just quitting or jumping straight back to the first screen.
I've also added a music track for the title screen - again this will probably change before the game is finished - but for now I'm using Mozart's Rondo Alla Turca (thank God for classical music in the public domain).
As a side note - if any budding musicians are reading this and feel like donating a music track or two then please get in touch.
As of midnight I've got a moving enemy on screen (at last!) and can move onto the enemy collision detection routines tomorrow. *yawn*
13/8/2009
Oh no, Thursday the Thirteenth!
I'm not superstitious about the number thirteen, but today hasn't been a great day, work-wise.
At lunchtime we lost access to the internet, email, our advertising system AND our page transmission system - while we were half-way through transmitting a newspaper that had a 1pm deadline. It was down for a couple of hours due to an alleged power-cut in Oxford.
So we had three hours of dealing with complaints about something that we've got no control over.
Wonderful.
Follow that up with me being on call, and getting called back in twice (although as luck would have it I was able to deal with both calls remotely).
On the bright side I've got collisions with the first (and currently only) enemy in the game working. So that's nice.
15/8/2009
Motivation is often an issue when writing software for yourself. When things get tricky, I try and add "one feature a day". This at least gives some impression of the game developing rather than just lurking there waiting for me to complete it.
OK, so sometimes you miss a day - but today's feature is one that makes the game a bit more tricky - and that is allowing the player to die if they fall from too great a height. Not a difficult thing to add but something that I had deliberately left out of the original Chaos Caverns.
This time, however, if the level designs that I have in mind are going to work then this is a feature that I need - otherwise there won't really be any challenge.
Features remaining to be added (and this isn't a full list):
- Collectible items
- Killer items
- Special items
- Lifts
- Conveyor belts
Other things to do:
- Add more levels
- Add more enemies
- Add more graphics and sounds
- Write a proper front-end to the game
- Add an end sequence
16/08/2009
Today's new feature: Lifts. In getting the lifts working I've had a think about how I'm coding the game, and more importantly, how to reduce the amount of routines that I need whilst achieving the features that I require.
The lifts are a case in point. I'd considered making a new game object for the lifts, but then realised the obvious: "a lift is just a platform that moves." So by adding some new parameters to the platform object and creating a "move" method I've got a basic lift working with very little new code required.
I've still got to code the interactions between the player and the moving platform (ie. if the platform is moving left or right then the player's movement follows it). Easy for left to right, slightly more complex for up and down. Especially when I need to find a way of slowing down the lifts a bit as by default they are a bit nippier than I'd like.
I was also going to add another object for "traps" - basically killer objects. Thinking about it what is a killer object? In the terms of this game it is an enemy that doesn't move, so if I just use the existing enemy routines with a static enemy then job done!
18/08/2009
Still working on the lifts. As they were running a bit faster than I'd like I've added in some code to create a delay between each move - so the lift will only move every x number of frames. This works well and allows me to have fast and slow lifts as required.
Moving and jumping whilst on the lift works but... sometimes whilst jumping you fall through the lift, and I can't see why. Ah well, tracking down and squashing bugs is all part of the fun.
I've also been re-jigging the player movement code a bit so it should be a wee bit more optimised, as well as a bit smaller. For those interested, at present on a P4 2.8ghz the game uses around 4% of the CPU time.
Update: Bug fixed, so the lifts are now fully working (vertically at least). I've adapted the second screen so that it can only be traversed by using the lift - and it all seems to work nicely so far.
19/08/2009
Now that the lifts are working it is time to start expanding on the code to make this less of a demo and more of a game. With that in mind I've started adding a fairly basic score / level / lives display at the bottom of the screen.
The strange thing is that this revealed another bug: if you dropped from a height into water you'd lose two lives instead of just one.
After one hell of a lot of hunting through the code I finally realised that I was forgetting to reset the fall height, so when the water code killed you the fall counter still contained a value, and because you re-spawned on a platform it treated it as if you'd landed after a long fall, which kills you a second time.
An easy one to fix, but a bugger to track down.
20/08/2009
Today I've been expanding the code a touch (extra baddie movement types, horizontally moving platforms and some other bits).
I've also put together a short video showing the game in action. Not a lot to see so far, but you can get the general idea of the progress so far.
Tomorrow I'm planning to add the code for collectible objects into the game. Once this has been done then the game engine will be basically complete and it will be time to start adding enemies and designing some proper levels.
21/08/2009
Found and eliminated another bug - one that allowed you to pass through a solid block if you hit it precisely on the top corner whilst falling.
I've amended the second screen to add in a horizontally moving platform - which worked first time without problems. Mind you, once you've got the code working for the vertical lifts there really isn't a lot you need to change to get it working for horizontal ones.
I've also posted about this game on the Retro Remakes forum - so a big hello to anyone visiting from there.
Update: Collectible items are now working. Quite simple to add really, providing you remember to use methods rather than functions for your reading / drawing code. Why? Because functions can't access an objects fields (the variables that the object uses). This is a "it's too late at night for this shit" type bug.
22/08/2009
Today has been mainly spent "enjoying" a bout of either man-flu or hayfever. Either one gives the same result - my IQ has dropped so far that it now has a negative value, my nose and eyes are taking it in turns to drip, different parts of me are competing in the "most painful" competition (I think that my back is winning so far). Not surprisingly I've not been especially productive on the old programming front.
That said, I've started expanding the baddie routines a bit, so the beach-ball enemy now rotates as it bounces (which looks cool), I've added a balloon as another enemy, which is also semi-transparent. This also looks pretty cool in action.
I've also started tidying up some of the routines, and simplifying the code in a couple of places.
Continued in Part 2
Wednesday, 19 December 2007
The Pre-Christmas Lull
Well, here we are less than a week before Christmas, and over a week since the release of the Batty Junior Christmas Demo.
I hadn't been to sure if releasing the demo was a good idea, especially as the game is at a pretty early stage, but thankfully it seems to have been rather well received by the people who have played it.
As I expected the missing power-ups has drawn some comments, but they are being added and will all be there for the next release.
The next couple of powers have been added in (Thrusters and Multi-ball) and just need a little bit of a polish before I'll be happy with them. That only leaves the Extending bat and all the original power-ups will be there.
Updating the code to allow for multiple balls on screen was something that I wasn't looking forward to. Really I should have done that much earlier on in the process (if not from the start) and so having to retrofit the code to allow for this was, shall we say, a fun experience - if your idea of fun is breaking the game entirely, fixing it, followed by an hour or so of bug-fixing.
It has been well worth it though, as even with fifteen or twenty balls on screen the CPU usage is still very low and the collision detection works a treat. Even the ball-grab power-up was a doddle to upgrade to handle multi-ball.
I'm still going to have to go through and do a code-cleanup at some point in the near future, as things are pretty unoptimised thanks to the major changes I'd put in place.
So once that is done then what remains? Well, the gravity warp thingy is something that I've been saving till last, and also I'm going to have to see about adding some variety to the baddies as I've only implemented the UFO so far (the Bird needs to be added).
If you haven't played the demo yet then head over to http://dans-remakes.sytes.net and give it a shot. As it supports Windows (XP and Vista), Linux and MacOS X most people should be able to run it.
I hadn't been to sure if releasing the demo was a good idea, especially as the game is at a pretty early stage, but thankfully it seems to have been rather well received by the people who have played it.
As I expected the missing power-ups has drawn some comments, but they are being added and will all be there for the next release.
The next couple of powers have been added in (Thrusters and Multi-ball) and just need a little bit of a polish before I'll be happy with them. That only leaves the Extending bat and all the original power-ups will be there.
Updating the code to allow for multiple balls on screen was something that I wasn't looking forward to. Really I should have done that much earlier on in the process (if not from the start) and so having to retrofit the code to allow for this was, shall we say, a fun experience - if your idea of fun is breaking the game entirely, fixing it, followed by an hour or so of bug-fixing.
It has been well worth it though, as even with fifteen or twenty balls on screen the CPU usage is still very low and the collision detection works a treat. Even the ball-grab power-up was a doddle to upgrade to handle multi-ball.
I'm still going to have to go through and do a code-cleanup at some point in the near future, as things are pretty unoptimised thanks to the major changes I'd put in place.
So once that is done then what remains? Well, the gravity warp thingy is something that I've been saving till last, and also I'm going to have to see about adding some variety to the baddies as I've only implemented the UFO so far (the Bird needs to be added).
If you haven't played the demo yet then head over to http://dans-remakes.sytes.net and give it a shot. As it supports Windows (XP and Vista), Linux and MacOS X most people should be able to run it.
Tuesday, 9 October 2007
One step closer to release
Another couple of items have been ticked off before the release. I've embedded the graphics and sound into the executable, so it should be a single 1.3 meg file which can be placed anywhere on your system regardless of whether you're using Windows or Linux.
I may be able to reduce the size of the executable a bit by ditching some of the none-required code modules, but I'll worry about that at the end.
I've changed the program to running in "strict" mode (something I should have done from the start). This is the same sort of idea as "option explicit" on QBasic / Visual Basic style programming languages in that all variables must be declared before use, and the variable types cannot change without being re-declared. This is handy for catching typos in variable or object names.
I've change the front screen to make it a bit nicer and added a basic high score feature to the game.
There are only a couple of small things that need to be done now which I should get done tomorrow. It's looking like I'll be releasing the game this weekend providing no show stopping bugs show up when I start testing the game on Windows.
Just for reference (and because I can't remember if I've mentioned this before or not), this is being coded in BlitzMax. This is down to it being relatively easy to use and cross-platform (you buy it once and can download and use it on all available operating systems).
I may be able to reduce the size of the executable a bit by ditching some of the none-required code modules, but I'll worry about that at the end.
I've changed the program to running in "strict" mode (something I should have done from the start). This is the same sort of idea as "option explicit" on QBasic / Visual Basic style programming languages in that all variables must be declared before use, and the variable types cannot change without being re-declared. This is handy for catching typos in variable or object names.
I've change the front screen to make it a bit nicer and added a basic high score feature to the game.
There are only a couple of small things that need to be done now which I should get done tomorrow. It's looking like I'll be releasing the game this weekend providing no show stopping bugs show up when I start testing the game on Windows.
Just for reference (and because I can't remember if I've mentioned this before or not), this is being coded in BlitzMax. This is down to it being relatively easy to use and cross-platform (you buy it once and can download and use it on all available operating systems).
On a Bug Hunt
One of the most labour intensive parts of game programming (and programming in general) is bug hunting and optimisation. Even if you are a programming genius like what I is bugs can still sneak in to your code when your back is turned.
The only way to track them down is to play, play and play your game again. Be your own most dedicated play tester. One of the tests that I do is create a windowed mode for the game, and play it alongside a CPU monitor. This can give you some big clues as to where there are performance bottlenecks in your game.
For example, I found that while the game was playing, the CPU usage was only 2 - 3%, but pressing fire knocked it up to 70%. Ouch! That was fixed by merging the base drawing and player shot collision code into a single run.
Another bug was down to programmer daftness. Because I'd made the enemy shots part of the enemy structure, when an enemy was destroyed their shot vanished too. D'oh! Needless to say I've created a new structure just to hold the shots and moved the enemy shot code into its own section. This involved some major restructuring of the code but was well worth it.
I've added a simple (but effective) end sequence that fits in with the retro styling of the game.
I'll have to have a run through the code and see where else it can be cleaned up before adding in the final missing features. Dull work, but necessary.
The only way to track them down is to play, play and play your game again. Be your own most dedicated play tester. One of the tests that I do is create a windowed mode for the game, and play it alongside a CPU monitor. This can give you some big clues as to where there are performance bottlenecks in your game.
For example, I found that while the game was playing, the CPU usage was only 2 - 3%, but pressing fire knocked it up to 70%. Ouch! That was fixed by merging the base drawing and player shot collision code into a single run.
Another bug was down to programmer daftness. Because I'd made the enemy shots part of the enemy structure, when an enemy was destroyed their shot vanished too. D'oh! Needless to say I've created a new structure just to hold the shots and moved the enemy shot code into its own section. This involved some major restructuring of the code but was well worth it.
I've added a simple (but effective) end sequence that fits in with the retro styling of the game.
I'll have to have a run through the code and see where else it can be cleaned up before adding in the final missing features. Dull work, but necessary.
Subscribe to:
Posts (Atom)
