Category Archives: demos

Flying features

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.

Runaway – not a road adventure

A few days ago I got an email from someone who had stumbled across this post that I made on the AGS forums about an adventure game called Runaway – or Monkey Run? – by a German group called Pixel Team (not to be confused with the later Runaway adventure games by Péndulo Studios).

I’ve got a demo of this game from a CD collection and it has always intrigued me because although it’s rather buggy and has an awful interface, it also has several nice touches that seem to have had a lot of thought put into them. I spent a few free evenings recording videos and trying desperately to remember how to complete it (which I’m sure I’ve done, or nearly did).

I couldn’t figure it out, so here’s a video of the first puzzle to show a bit of the game in action instead.

Unfortunately I have not been able to find much out about this game (especially as searches for “Runaway” and “adventure game” find the Péndulo games), so I’m fairly sure it never got beyond this demo. If you have any more information I’d love to hear it.

The demo was released as shareware, so if you fancy playing it I’ve uploaded a copy here. It works fine under Windows XP using DOS-Box. If you manage to get into the keeper’s house (which I think is the next step from where I’m stuck) let me know how because I really can’t remember how I did it last time! If I manage to get much further I might put up a full playthrough.

Tip for playing:
When picking up items you can click the ‘Pick Up’ option, then the item. With the other interactions you generally have to click on the place you want to interact with, *then* click the verb…

OneDollar’s Demos – Nancy Drew: Ransom of the Seven Ships – Part 2

Continuing on from yesterday’s post

OneDollar Presents…
A biased and uncharitable review of Nancy Drew: Ransom of the Seven Ships (Part 2)


I’m sorry but this isn’t a door lock, somebody’s just fitted an electronic game to your wall. I’d call your locksmith and ask for a refund.


Success – I opened the door! Now I can dress up in a diving suit, then attempt all the other challenges while still wearing it. According to George, Nancy has “…solved mysteries in every corner of the world”. The map shows the locations of all of Nancy’s mysteries, so “every corner of the world” actually means North America and four places in Europe. How cultured.


I can deduce one of two things from this book of instructions: either Sonny stole a monkey’s brain, or Sonny stole a monkey’s hairdo.


“You look just like this bird I met in England” sounds like another way of saying “We already rendered a parrot once, lets use it again”. I assume this previous meeting explains why Nancy shows no surprise at a bird that can carry on an intelligent conversation. Seriously, a bird like that should not be left sitting in an empty lobby, it should be on TV hosting a chat show or doing the weather or something.


George told me this golf cart needed water to work, but it runs fine. This is the person we’ve got repairing our one and only satellite phone? It doesn’t work on grass (after all, why would you want a golf cart to work on grass?) but fortunately most of this ‘ecotourism’ island is covered with winding tarmac roads.


After beating the monkey at his own game I get to choose a prize from a thrilling range! Don’t get too excited about puzzle solving though, Nancy’s quick to remind me that the parrot wanted fruit. If only this were a real adventure game, just think of the puzzles you could solve with an eye patch and a goldfish keyring…


This means 7-9-2-0-4 in international signals. Now there’s a fair chance that anyone wanting a sail is going to be using it to sail a boat, and there’s an equally fair chance that said sailor will know the international flag signals so really all this does is weed out the amateurs. Changing this code must be a real pain. Do they have a stock of little flags to put on the bin?


I found this picture hidden in the lobby. It brings home a stark realisation that somewhere, somehow a real game creator made this game and was pleased enough with it to hide a photo of his wife (or daughter, or sister or next door neighbour) in the background. Kind of touching, unless of course that picture *is* the game creator in which case its just creepy.


Having ticked off everything on the task list that the game will let me, all I’ve got left to do is to look for Bess. She clearly came to this beach but the demo won’t let me go there, so I guess I’ve been abandoned to drive the golf cart in circles around the map. Anyway, leaving the demo without a proper ending seems a good enough reason for me to do the same to this post.

End.

OneDollar’s Demos – Nancy Drew: Ransom of the Seven Ships – Part 1

Time for something a little different (although I’ve done something similar before). I got bored on Sunday evening, fired up Steam and downloaded a demo of what I fully expected to be a rubbish game. What follows are my experiences.

OneDollar Presents…
A biased and uncharitable review of Nancy Drew: Ransom of the Seven Ships (Part 1)


If there’s one thing that immediately made me want to play the full game, its the promise of “Mild Violence”.


Maybe they got the monkey to count them?


I always visit the options page before starting a game. Here I’m glad to note we are given not one but two resolutions: ‘small’ and ‘would fit comfortably on the screen of my phone’. Who is this game made for, those casual gamers who never found the resolution settings on their PC?


Although it’s meant to set the scene, this introduction raises more questions than it answers.
– Shouldn’t that be George and I? If you’re going to keep a journal at least learn to use correct grammar. (If not write a blog instead).
– Who on earth holds a father-daughter banquet? As a side note, arriving a day late to one of these things is never a good plan. I can only assume everyone will be dead, missing or replaced by a robot lookalike by the time Nancy arrives.
– An ecotourism resort that you can only reach by plane? Well somebody dropped the ball there. Does the cost of your ticket include carbon offsetting?
– Floatplane is a stupid name for a kind of aircraft. Not a question, just an observation.
– I guess this is the same journal Nancy will use to record all the grisly details of whatever ‘Mild Violence’-containing mystery we come across. I’m sure the red-purple frilly borders will offset that marvellously.
– “Shark Diving Resort” is possibly the worst name for a resort I have ever come across.
– Seriously, how big is this book? Judging by the size of those poorly paper-clipped postcards… erm… 29×33 centimetres closed. I’m not going to ask where she keeps it.


I have no idea what’s going on here but AHAHAHAHAHA! I’m just disappointed the actor didn’t read the “pppp” at the end of “Stooooopppp”. Also a nice contender for ‘worst water render in a modern game’.


If I were ever to kidnap someone, I don’t think I’d do it on a tiny, inaccessible island with no planes to escape with. Okay, so the story’s wholly unoriginal and the characters look like they were made in Poser, but we’ve already got intrigue, danger…


…and a task to “Win a game against a monkey”? I assumed the introduction was supposed to make me sympathise with the characters and draw me into the game’s plot, but why bother when five seconds later you’re going to a literal list of mini-games I have to play. There are many things that drive people to crime. Need, greed and apparently an insatiable urge to create treasure hunts. We’re dealing with one seriously messed up villain here… do you reckon you actually have to go diving for number 8, or is it just an excuse for them to watch Nancy dress up? Let’s not think too hard about that one.


George demonstrates how to fix a satellite phone: glare at it and shake it up and down. Also if you make the mistake of hovering your mouse over her…


“Hey George, can I talk to… ooh okay…”

Venture back tomorrow, if ye dare, for the terrible conclusivness of part 2!