All posts by OneDollar

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.

general

Signed in

1 Comment

I just spent the last 10 minutes trying to sign into the Rockstar Social Club in order to play GTA:IV, getting increasingly frustrated that not only did the series of logins and passwords I tried not work, but Rockstar was unable to email me password reminders. I finally figured out that because I’ve never played online I never created an account.

Once upon a time all you had to remember was your computer password and email account. Now I’ve got logins for websites, games, game distribution platforms, consoles (that I don’t even own) and several games publishers. With all the possible combinations of logins and passwords anything that gets shelved for a couple of months is doomed to have a password guessing/resetting session when it gets picked up again. A simple bout of amnesia would kill an entire online life.

MAGS

MAGS: March 2010

Leave a comment

Another month, another MAGS competition! This month’s rules are…

Something in the game should be drastically changed in the middle of the game.
Examples:
* The genre of the game should change from horror to comedy
* The music for the game should change from rock to classical
* The character of the game should change from a boy to a girl
* The interface of the game should change completely
* etc etc, anything goes!

The only limitation here is, there has to be a clear justification in the plot for the change. If the user will ask himself “Why???” then you have failed…

For bonus points, you can change more than one thing  Wink

I keep saying I won’t do another of these, but this ruleset is really interesting…. anyone want to collaborate?

general, site updates

Moving from Blogger to WordPress

Leave a comment

So far everything seems to be working with the new blog, so I thought I’d do a post about some of the issues I had moving everything over from Blogger to WordPress. Be forewarned that the steps I took below came from a mixture of skim reading websites, asking friends and trial and error, and should not be taken as me knowing what I’m doing. Enjoy!

1. Installing WordPress
WordPress has a “famous 5-minute installation” guide, though I’m not sure what it counts as installing because uploading 7-8 MB of files over FTP takes up quite a lot of that time. Anyway, putting WordPress onto the site was pretty straight forward – the one minor problem I had was I originally missed the security keys section of the WordPress configuration file, probably because the instructions that tell you to do so are written after a long list of options you are told to leave alone.

Once the blog was up I started looking for options to tweak. I tried changing the permalinks to be categorised by year then date, but WordPress didn’t have the access rights to the .htaccess file. I think this is because I uploaded all the files through ftp, and therefore all the rights to the WordPress files and folders were assigned the FTP user. This wasn’t too much of a problem at this stage because WordPress helpfully gave me the code it wanted to put in my .htaccess file, so I could do that myself.

2. Importing Blogger posts
The next step was to get all my old posts imported in. This was much less straightforward. There’s a handy import tool, but in order to use it WordPress wanted to create some new folders and ran into the same access rights issues as before.

What I did:

  • Tried to upload a picture using WordPress (which failed due to the access rights issue). Noted down the location of the folder it was trying to make.
  • Created that folder using FTP and granted full access for everyone to it (777 access). Uploaded the picture again – successful this time because everyone could now write to this folder (which would be a security risk if I had left it like this).
  • Connected to the actual web server (which fortunately I can get access to). Noted down the user that owned the picture I had just uploaded (this is the user that WordPress is using to interface with the server).
  • Removed the picture upload folders.
  • Created the folders WordPress needed for the import. On the web server changed the ownership and rights to give the WordPress user enough access over the folder.
  • Performed the rest of the import.

What I now think I could have done:

  • Manually create the folders WordPress wanted to write to using FTP.
  • Use FTP to grant full access rights to everyone (777 rights) on the lowest subfolder created.
  • Perform the import.
  • Use FTP to change access rights on the folder back to how they used to be and/or delete the new folders

WordPress doesn’t seem to put anything in the folders (blog posts are stored in a database rather than as physical webpages), so I’m not entirely sure why it needs the folders creating. My guess is it’s some kind of staging area to temporarily store the blog posts before converting them and putting them into the database. Anyway, the point is as far as I can tell WordPress needs access to the folder to perform the import, but doesn’t need access afterwards, so you can open up a security hole then close it later. I’d have to put a bit more thought into permissions if I wanted to use WordPress to upload files (e.g. pictures), but I’m happy doing that through FTP so it’s not a problem.

Now that I had folders WordPress could write to all I had to do was run the import tool. There’s a built in Blogger import option, so I ran that. It seemed to go fine, asking for my Blogger details then giving my website access to my Blogger account, but when it actually came to pulling data back it seemed to think I had three blogs with no posts in. Instead I went to Blogger and exported my posts from there, used this online tool to convert them to WordPress export format and imported them as WordPress posts. This worked fine for me, but something must have gone wrong when a friend of mine did the same thing as he somehow ended up with half of his blog and half a blog about baby care products. Moral of the story is check (at least skim read) through your posts to check that everything’s there.

3. Redirecting pages
Wanting to do things properly I decided I needed page redirection, so that anyone clicking a link to my old blog would be taken to the correct post in the new blog. I thought this was going to be reasonably easy because old Blogger posts were “/blog/year/month/postname” and new WordPress posts are “/news/year/month/postname”, so I thought all we had to do was take a request for /blog/blah and redirect it to /news/blah. Unfortunately there are a couple of differences in the way Blogger and WordPress post. For starters all Blogger posts have .html on the end of them, whereas WordPress doesn’t, which means a simple folder redirect doesn’t cut it. The following lines in an .htaccess file fixed this (thanks go to my friend Steve for writing this code)

RewriteEngine On
RewriteBase /
RewriteRule ^blog/([0-9]+)/([0-9]+)/([A-Za-z0-9_-]+).html$ news/$1/$2/$3/ [R]
RewriteRule ^blog/blog.htm$ news/ [R]
RewriteRule ^blog/$ news/ [R]

Second problem is that when you post to Blogger it cuts out short words such as “the”, “a” and “an” from your post permalinks (so my post “The cat, the player and the cupboard” was given the Yorkshire sounding permalink “cat-player-and-cupboard.html”). WordPress’ converted posts had the full title (“the-cat-the-player-the-cupboard”). I’m sure there’s some clever script you could write to go through all your posts removing these short words and their extra hyphens from blog links, but seen as I only had 30-odd posts I just changed the links on the affected ones manually to match the original Blogger links (minus the .html of course).

4. Making the final move
So I have a working WordPress install with all my previous posts imported in and redirects in place so that anyone trying to get to an old post will find the new version instead. As soon as I put the redirects in place visitors to my website should no longer be able to get to any of the pages of my old blog, but it’s probably a good idea to change all the links in the rest of the website to point to the new addresses.

The final issue is the RSS feed of the old blog. I don’t think you can redirect RSS feeds, so anyone reading posts solely through the old RSS will stop getting updates and therefore stop reading. So, the last thing to do is make a new post on Blogger informing people that the blog has moved and asking them to update their RSS feeds. Remember that people won’t be able get to the actual Blogger post because of the redirects, but their RSS readers will still pick up the post from Blogger’s feed. I also made a post on the new blog with a matching permalink so that if they click to view the post the RSS came from they’ll be redirected to a welcoming page on the new blog.

What I should have done from the start was use Feedburner to ‘burn’ my RSS feeds, then offer the Feedburner feed for people to subscribe to instead of the actual website feed. In other words, people subscribe to Feedburner, which then fetches the actual feed generated by my blog for them. If I had done that I’d have been able to point Feedburner at the new RSS feed and wouldn’t have lost any subscribers. I didn’t know about Feedburner when I started my blog, but that’s what I’m doing this time around.

* * *

Whew, that was a long post. I don’t know if any of that was useful, but hopefully someone will find it interesting. Now that I’ve got WordPress up and running I intend to blog a bit more often (which blogger hasn’t said that?) so we’ll see how that goes.

general, maintenance, site updates

We have moved!

Leave a comment

Welcome to my shiny new WordPress powered blog! Hopefully everything has moved and should be in the correct place, but if you notice any problems drop me an email.

If you subscribed to the RSS feed for my Blogger powered blog then unfortunately that feed will no longer work, but you can sign up to the new feed by clicking this link. If you didn’t subscribe to the old blog, please consider subscribing to the new one anyway!

general, maintenance, site updates

Blogger stops FTP, I’m off to WordPress

3 Comments

Blogger announced on the 22nd of January (though I don’t read their blog so only found out by email today) that they’re discontinuing FTP and SFTP publishing services after March 26th. Unfortunately I rely on FTP to publish here because I don’t want to host my blog on Google’s servers.

I’ve not been overly happy with Blogger’s service, so this is probably going to be the catalyst for me moving to WordPress. I’m going to have to do some reading to see how that’s going to work/happen but it’s likely webpages, RSS feeds and so on are going to change so if you’re still interested in what I have to say watch this space for news.