Category Archives: my games

behind the scenes, game updates, games, my games, programming

The Search for Oceanspirit Dennis – source code and resource pack released

1 Comment

The Search for Oceanspirit Dennis

Want to see just how messy my code gets when I have too much to do and a fast approaching deadline? Well good news, because you can now download the source code in all its sparsely-commented glory!

Want to make your own Oceanspirit Dennis game, but need some resources to get you started? Don’t want to have to extract them from someone else’s project? Well then grab the resource pack instead, and you’ll get all the art in nice friendly .png files. Some of the backgrounds even have the original Photoshop file, so you can mess around with layers and things. There’s even a few sound effects in there!

The source code can be downloaded here.
The resource pack can be downloaded here.
If you never quite got around to playing The Search for Oceanspirit Dennis, you can download it for free from this page.

behind the scenes, game updates, my games

Teaser

1 Comment

I’ve been procrastinating a lot recently both with this blog and a couple of AGS projects I should be working on. Had a computer death to deal with then a couple of weeks and several hundred pounds later I discovered I was somewhat lacking in motivation. So I started another short project instead. Oh well, I’m sure both will be finished eventually.

Here’s a slightly-cropped screen shot to make up. Click for zoom.

Ooooh... teaser-y

In other news I increased my year count yesterday. It didn’t hurt.

behind the scenes, demos, my games, programming

Flying features

1 Comment

Here’s a little bit of commentary for some of the features in the demo I posted yesterday:

Each game loop goes something like this:
1) Introduce any new enemies that are needed.
Currently the idea is to have a simple function CallEnemy(optional int enemy, optional int x, optional int y) which creates the specified enemy type at the specified location. If no location is specified, a random x value is chosen and y is set a bit above the top of the screen. If no enemy type is specified the function should choose a random enemy from a list of low-level enemies. At the moment there is only one enemy type, and the CallEnemy works by seeing if the number of enemies drawn (ie still alive) in the last game loop is less than a certain value, and calling another enemy if it is.

2) Calculate the desired horizontal movement of the player ship
This is based on what arrow keys are/aren’t pressed, and uses acceleration and maximum speed values. In other words, if a player continues to hold down an arrow key the ship’s speed will change by a higher and higher amount each time, until it reaches a maximum value. This gives a more realistic simulation, but I’m not sure how well it works in the context of this game where control is important. Might be useful for special instances (a specific level or section where the ship is hard to control?).

3) Calculate the desired vertical movement of the player ship.
Pretty much the same as above, but in the y direction.

4) If the player is firing, introduce a new bullet.
A single bullet is an instance of a Bullet structure, which is basically a container for values such as the x and y positions, the graphic to use for the bullet, the x and y speed of the bullet, the animation view to use for its explosion and how much damage it deals. It also contains a ‘life’ value that says how long the bullet has been around. The player has an array of (50?) bullets. This means there can be up to 50 player-fired bullets on-screen at any one time. In order to create a new bullet we have to go through this list of player bullets to try and find one that isn’t in use (its life = 0). If we succeed we can set this array slot up to be the new bullet. If not then… well… the player doesn’t fire anything. At the moment this can’t happen because the rate of fire combined with the speed of the bullets means bullets are disappearing off the top of the screen (and being ‘killed’ by setting life back to 0) before 50 have been shot.

5) Calculate the player’s horizontal position
This is a combination of the results of step 2 and any additional environmental effects such as drag. E.g. setting a drag value at a certain part of a stage could be used to simulate gravity or wind that would move the player in a certain direction unless they flew against it.

6) Calculate the player’s vertical position.
As above. Re-reading the code it’s possible that step 4 should actually happen after this, but at 40 frames a second I don’t think anyone would notice the difference.

7) Calculate the enemy movement, including them firing bullets.
I’m trying to implement some form of artificial intelligence for the enemies. Currently it works like this:
a) Each enemy has a variable pointing at an AI Routine, and a variable pointing at an AI Step.
b) When it needs to work out an enemy’s next movements, the script calls an AI function.
c) The AI function goes to the enemy’s routine, and then looks at the step they are currently on.
d) This step may modify one or more of the enemy’s values such as its speed. Enemies also have a target destination that they are moved towards, so the step may change this. The step may also check values, such as the enemy’s position, and make decisions based on this. Finally the step can call for the enemy to fire, by setting a boolean to true.
e) The step may alter the enemy’s AI Step value, so that a different step is run the next time. It could also potentially alter the AI Routine value, so that a completely different routine is run next time.
f) The script then leaves the AI function and moves the enemy according to the enemy’s values, whether or not they have been changed. Enemies are moved towards their target destinations (in both the x and y axis).
g) If called to fire the enemy creates a bullet similarly to the player in step 4. Enemies use the same Bullet structure as the player, but they have their own array to create bullets in. Each enemy has values telling the script where to create the bullet, what graphic to use, how much damage the bullet does etc. In other words each enemy can have different weapons, but the bullets for all weapons are stored in one array.

The current enemies show a very simple version of this. Their AI routine looks something like this:
Step 1) Set the target destination to be the left of the screen. Set the next step to be step 2.
Step 2) If the enemy has reached the target destination, set the next step to be step 3. Otherwise randomise a number and fire a bullet if that number is a certain value.
Step 3) Set the target destination to be the right of the screen. Set the next step to be step 4.
Step 4) If the enemy has reached the target destination, set the next step to be step 3. Otherwise randomise a number and fire a bullet if that number is a certain value.

Hopefully further down the line this can be used to program reasonably complex behaviour on an individual basis. A huge plus to this system is most of the code will be reused. There’s also the advantage that it’s in its separate global script, so it can grow without making the rest of the game’s code hard to read. I may add a AI Counter variable to the enemy type, so that for example a routine could be run a number of times, then changed to a different one.

8) Calculate movement of all player’s bullets, including whether they hit an enemy, and if so remove the bullet, damage/kill the enemy and create relevant explosions.
This is the major number cruncher, as every bullet has to be checked to see if it’s colliding with every enemy, which is potentially a lot of checking. Obviously this needs optimising. I don’t know how the professionals do it, but I’m using a series of if statements, called in the order that I think they’re most likely to be failed. In other words…
a) Is the bullet ‘alive’. If not, stop checking anything as it doesn’t exist on the game screen, and move on to the next bullet.
b) Is the enemy actually ‘alive’? If not, move on to checking the next enemy.
c) Is the bullet too far to the right of the enemy to hit them? If so, next enemy.
d) Is the bullet too far below the enemy to hit them? If so, next enemy.
e) Is the bullet too far to the left of the enemy? If so, next enemy.
f) Is the bullet too far to the right of the enemy? If so, next enemy.
If all of these checks pass the bullet has hit the enemy and we can move onto checking the next bullet (after destroying this one, causing the enemy to take damage/die and making an explosion).

9) Calculate movement of all enemy bullets, causing the player to take damage and create explosions if hit.
Less of a number cruncher because although there are potentially more enemy bullets, there’s only one area to check within. The player and enemies currently use hit-boxes as they are being drawn at real-time.

10) Calculate background movement.
This is actually the first bit of the project I made. The game has two backgrounds (which could potentially share the same graphic) and works on the assumption that each background graphic is at least as big as the game resolution. It starts by moving background 1, then checks to see if the top of background 1 is below the top of the screen. If it is, it draws background 2 above it to make sure there’s no gap. This continues, with both backgrounds moving down the screen. Eventually background 1 will fall completely off the bottom of the screen. When this happens, background 2 becomes the new background 1, transferring it’s current location and graphic. The game then picks a new background 2 image (at the moment this is from a random list of 3 or 4 graphics) and continues. As soon as background 1 starts coming off the top of the screen background 2 appears above it… and so on.

11) Draw player ship.

12) Draw enemy ships.

13) Draw player bullets.

14) Draw enemy bullets.

15) Draw special effects (currently means explosions).

16) Draw background.

All game graphics are drawn to the screen every frame using AGS’s drawing functions. There are no objects and only one invisible character who’s sole purpose is to sit in the one room so that AGS knows to show it. Graphics are drawn onto the backgrounds of one of 6 full-screen GUIs because:
a) I need something to draw onto.
b) Using GUIs is an easy way of doing layering – so the background is drawn behind the ship while bullets are drawn in front, regardless of when I actually draw them in the loop.
Maybe in the future I’ll convert it to use even less resources, and just draw on the room background.

17) Update status bar.

At the moment this GUI is just a health bar, but later it’ll probably contain other things (ammo, smart bombs?). The health bar is a button, and I’m clearing it to a red colour then using the draw rectangle function to drawn a green rectangle on top with the width determined by the player’s health.

And…?

Hopefully the above is the start of a good framework for producing a progressive, level based shoot-em-up game. I’ve tried to create it in such a way that lots of different elements of the game can be changed very easily, so that when it comes to actually programming a level it should be relatively simple and code light.

But whatever I end up doing with the project, the main point is it’s a fun programming challenge. I keep pushing AGS, and I keep being surprised by what it can do. All of the above takes place 40 times a second, yet I’m not seeing any drop in frame-rate at all. It’s truly an awesome tool.

P.S. If anyone wants a copy of the source code email me or PM me over at the AGS forums. It’s far from complete, and I can’t guarantee that the latest version is stable, but I’ve tried to keep it well commented as I’m going along.

behind the scenes, games, MAGS, my games

Robbing the Princess facts

1 Comment

WARNING: THE BELOW DEFINITELY CONTAIN SPOILERS! IF YOU’VE NOT PLAYED ROBBING THE PRINCESS PLEASE DO SO BEFORE READING!

For those interested, here’s a few facts about Robbing the Princess:

  • All of the final game script (finished by about the 5th day) got put into the game. There was nothing I was trying to get in that didn’t make it.
  • Like Breakdown I did have a few extra ideas on a strict “if I have time” plan. I didn’t, as expected, so I didn’t do any work towards them.
  • One of the ideas was an introductory  sequence that would teach the player the controls and fill in a bit of the backstory. The player would control Alec only who would be on a train. The player would be walked through a simple puzzle with text prompts teaching them commands such as picking up and using items, then would have a confrontation with the unnamed bad guy on the roof of a carriage. The bad guy would escape by being airlifted by a convenient helicopter – see why I didn’t have time to implement this? – leaving behind his coat (intentionally as it later turns out). The packing slip Alec mentions in the intro of the game would be found in one of the pockets, and Alec would radio Suzy telling her to meet him at the docks.
  • The ending is a bit of a cliffhanger, but I would have liked to make it more so. The end credits show The Princess sailing off into the sunset, and I’d have liked to have a submarine surface behind them at the very end.
  • If I was going to continue the story (and I have no desire or intention to) I’d pick up with The Princess being torpedoed and the player having to solve a puzzle to get Alec and Suzy out of the sinking ship. They’d then escape to a nearby island and probably have to work out how to get back to the mainland.
  • I have no idea what was supposed to be in the crate. Stolen property and/or something that could be used for great evil probably. I never came up with any of that backstory. Hey, Mission Impossible 3 got away with it, why shouldn’t I?
  • I wrote initials are hidden in the otherwise pretty random pebble-dashing on the front of the pub. I then put the ladder and fire escape in front of them, so you can’t actually see them. I did a similar thing with the grass in Erk.
  • I tried to use a particle effect for the gas but I couldn’t get it to work with alpha channels or transparency, so I just hand animated it instead.
game updates, games, MAGS, my games

Robbing the Princess updated (again)

Leave a comment

Last week I finally got around to fixing a bug in Robbing the Princess that I’ve known about since the end of December. Was it a major bug? Yes, it made the game crash and could be performed quite easily. Was it easy to fix? Yes, once I’d figured out that AGS returns ‘true’ for the query ‘is a character standing on region x’ when the character isn’t in the current room (sounds a bit like a bug to me). So why did it take over two months to fix?

Well part of the reason is that with Christmas coming I didn’t immediately have the spare time (or desire to spend the spare time I had) to fix it, and with MAGS well and truly over and the game starting to slip off the first page of the completed games thread the peak of people playing the game was also gone. The other reason is, to be honest, I don’t really like the game. I said a while back I was going to write some kind of analysis on the game so I guess this is it.

WARNING: THE FOLLOWING MAY CONTAIN MINOR SPOILERS.

I don’t think Robbing the Princess is a *bad* game as such, and I really don’t want to discourage you from playing it (please do and leave me some feedback!). In fact there’s a lot of things in it I’m really pleased with. For one thing I always used to struggle with room design creating sprawling (well, relatively speaking) adventure worlds where each room had maybe one or two purposes. Not only does this mean the player has to trek back and forth a lot but more importantly as the game designer working to the MAGS time limit of 25-26 days it means I have to spend huge amounts of that time on drawing backgrounds. I dislike drawing backgrounds. Interestingly Alan Saves Christmas (my first game) had eleven playable rooms, Erk: Adventures in Stone Age Real Estate (second) had nine,  Breakdown (third) had four and now Robbing the Princess has squeezed a fair bit of gameplay into just two playable rooms. I think I’ve got that aspect of room design sorted.

The graphics are also pretty decent in my opinion (and also in the opinion of the AGS review panel). I tried a completely different style and I think it came off quite well. I’m definitely not up to the level of some of the artists on the AGS forums, but I don’t think many people will be put off from playing the game based on graphics.

The animation is also something I’m fairly happy with. A lot of it is missing (up and down walkcycles would have been nice if I’d had the time) and still more is copied mercilessly (all the characters share the same rough body and therefore the same animations), but in places I think it shines. Everybody hates doing walkcycles, but I’d like to think the ones in Princess are fairly smooth and realistic. Also I went overboard on the guard sailor inside the ship – there’s smooth transitions and animation for pretty much everything he does. Very pleased with how his cutscenes and idle animations turned out.

There’s also a lot of complicated programming in there, not least because the rules demanded two playable characters which makes everything at least 1.5 times as hard. Performing the same action with different characters results in different actions. Some actions can be done with only one character. The door code is randomly generated at the start of the game yet it can still be figured out (you’ll know what I mean if you’ve finished the game). It’s also my first released game that contains conversations which I personally find very awkward to implement.

So what’s the problem? What motivates me tends to be a balance of work to fun. I’ve mentioned in the past that I have no problem spending hours working on an overly complicated bit of code that will probably go unnoticed by most players but will, for example, give some randomisation, provide customised feedback for lots of obscure situations or just look clever. Did I really need a automatic door in Breakdown that would open whenever the player or another character walked in front of it? No. Was I thrilled when I finally got it working? Oh yes. The main problem I have with Princess is that it took a LOT of effort. I’d just become full time at work and I was spending every spare evening, lunchbreak and most of my weekends working on it.  For all that work I just don’t think the end experience is very fun.

While creating and playing the game it was painfully obvious to me that the writing in the game is, well, functional at best and boring at worst. Both characters may have different responses to every action, but what’s the point when they just say the same sentence worded differently? There’s pretty much no characterisation and no story. Combine that with the lack of sound and music and you’re left with a rather bland gaming experience. In the past I’ve used humour to give characters personality, assigning a feature or flaw to them then exploiting it for jokes. I’ve also always gone for a more tongue-in-cheek approach – none of the characters takes the game seriously. In Princess I didn’t want to make another comedy game, and I succeeded in striping out most of the personality.

I also focus very hard on trying to make my games as stable and bug free as possible. I spend a lot of time testing every combination of the section I’ve just programmed, even if I’m pretty sure the code is solid, and I’ll sacrifice features to fix something that doesn’t work right. So having anxiously compiled and uploaded your game, written it a database entry and submitted it to the MAGS thread after a month’s worth of very hard work, it’s a bit of a kicker when the first response back is a major bug that causes the game to be rendered unwinnable (note this was fixed, or at least worked around soon after it was raised, and at the risk of suggesting bugs in AGS twice in one post I still can’t see any fault in my programming).

The whole experience left me pretty burned out with making adventure games. In the past I’ve worked really hard on a game for a month, then I’ve got the chance to sit back and get (usually positive) feedback from people who’ve played it. Even when most people have stopped playing I can still think “I made that game. That was a good game”. This time it feels like all I’ve walked away with is a sense of my inability to write good stories and characters.

I’m probably being over dramatic and overly critical, but making Princess wasn’t a particularly positive experience and it’s left me unsure about where to go with any more games I might want to do. I do want to make more games, especially moving away from MAGS and its time limits, but while I have plot ideas I get very stuck on working on the details so nothing’s happened yet. I suppose I should either work on my writing or find a team mate. Anyway, there’s always Mystery Project to work on. That *is* still alive (even though I’ve only put in a few hours this year). We’ll see.