Little more on Hoshi

is still gradually moving towards a tech demo (may even get one out later today).

Bullet collision is now working, which puts it squarely past my last effort in terms of game-mechanics, but there's still nothing in terms of UI.
Next plan is to add an energy bar, then the radars, possibly a score and release that as a tech demo.

Enemy bullet hitting a player and lighting their shields:

Player hitting an enemy and lighting their shields:

Not a lot else to say right now. Again progress is slower than I'd like, again mostly to do with the election, but I've also picked up a nasty cold which is making my head a bit muggy. Oh well, the show must go on or something. :o)


A word on Hoshi

The new engine currently looks like this.
There's no collision detection for bullets and their "launch point" needs moving, but overall it's coming on nicely. Once collision detection and enemy AI (for which the framework is there, just not the AI itself) are implemented the main game dynamics will be in place and most of the rest will be fixing the UI.
Work hasn't progressed as quickly over the past few days, this is mostly due to my being distracted by the current UK election, which is potentially one of the most important in the history of the country with the results determining whether our entire electoral system will be changed or not. But, this isn't a political blog, I'm just pointing out why I've not done as much work as I intended over the past few days.

Currently there's only "normal" and "boss" ships, but I've left enough room to add others if I feel the need.
I may if I have enough time left before the deadline I've set myself create several game types instead of the standard arcadey 'wave' version. The other game types would make use of these additional ships.

From there, I should outline the entire gameplay for the arcade mode:
The basic style is pretty old, even as far back as the 8-bit era; you're a lone ship on a scrolling background (which wraps) against massive odds, but your ship has a distinct advantage.
In the case of Hoshi that advantage is regenerative shielding and a larger bullet range than the enemy as well as an additional high-power bullet designed for killing bosses.
Gameplay will follow that you have to destroy a swarm of escort ships, these will take a minimum of hits (I've not decided exactly how many, Foray had single-hit kills, currently it's set ~5 shots, but this is easily changeable). The best option for killing the swarm is to shoot them, but crashing into them works since they have considerably weaker shields and yours quickly regenerate, however you'll score less for a crash than a clean kill and it obviously leaves you with a temporary reduced shield power.
Once the swarm is killed your ship automatically switches to 'boss mode' and you can shoot boss bullets. You have a very limited number of these, so it's best to save them up wherever possible. On early waves the boss can be killed with just a single bullet, but the number required will increase as you progress through the game.
If you run out of boss bullets all the escort swarm will respawn and you'll have to kill them all again at a reduced score per ship. The more times you re-do the level, the lower the score per ship, but you can always re-do it. It's important that you can always re-do it because killing a certain number of ships provides you with boss bullets (don't ask why, it just does).
Getting far enough into the game theoretically requires re-playing through waves as the bosses will require more bullets than you can carry. This is intentional as by that point the swarm will contain enough ships to be very formidable and so it increases the difficulty considerably.

There are a number of design decision I'm going to go into here:
Bullets don't gain velocity from the ship speed. This is twofold, firstly it's a design consideration in the original Foray game and it also prevents the player just running through a swarm of following enemy ships with all guns blazing. If you attempt this with bullets adding to the ship velocity then you'll kill most of the enemies and come out the other side unscathed, if you have no bullets in front of you however, you'll smash into the ships and die very quickly. This prevents players from just leading the enemies into a swarm then running through this swarm repeatedly. This worked extremely well in Foray, forcing a constant change in player tactics, often involving an engage, retreat, engage strategy to recharge shields from the enemy ships crashing into you.

Separate bullets for killing the boss and having waves repeat if you fail to kill it. Again this was an original Foray design, I do intend on making the change that on repeating a wave the score will be reduced, this is to prevent players just aiming for a high score by re-playing early levels over and over. Whether I make an online high-score table or not is another matter, if I do it will be a separate project.

Moving the UI from the right hand side to the top. This is mostly to make it easier to support multiple resolutions. As I mentioned in other posts, the last Hoshi engine had problems with internal positioning and part of this was an attempt to support all of 4:3, 5:4, 16:9 and 16:10 resolutions. Since the sidebar would be the same width in all resolutions, and the ship needed to be centred in the remaining space I made some poor positioning decisions that resulted in everything falling apart when I came to implement collision detection.
In the new engine, the camera moves, following the ship through the world instead of previously where the world moved then the ship was positioned to appear centre whilst the ship-in-world position and ship-on-screen positioning were completely separate.
The radars will be top-centre and the score probably next to this with the number of 'boss bullets' on the other side and the energy bar across the bottom of the screen.

'Swarm' ships are very stupid. I could theoretically give them some fairly awesome AI, including the ability to work in groups etc, but this would take a lot of time to tweak and also removes the possibility of accidental suicide runs from them, which created some classic moments from Foray, including many of frustration when you head towards a group swarm and suddenly 5 ships smash into you uncontrollably. It's a good mechanic that keeps you on your toes, so I'll keep it. Possibly if I do introduce other modes the AI would be upgraded on those ships and obviously the boss AI will be different.

Crashing into boss ships does nothing. Boss ships have much stronger shields is the main reasoning behind this and as such you just bounce off them with no danger. However staying close to a boss ship is a bad idea as they can shoot just like the normal swarm ships.

Enemy ships can't move and shoot at the same time. This is to allow the player to retreat from the swarm at any moment. If you feel it needs more justification, the enemy ships don't have a enough power to run both weapons and engines at the same time. ;o) They can coast for a long way though, so potentially you could get smacked with a load of bullets with an enemy ship at the end of it.

Enemy ships have a very powerful weapon and rapid fire rate. This is to even the odds a little, after all you can always run away from the enemies and regenerate your shields, you have a longer range and generally a more powerful ship.

Hope that clears a few things up on Hoshi, hoping to get a tech demo out in the next few days for people to have a shot at killing some enemies.


Last.fm RSS stuff

Not game related, but thought I'd add it.

I got briefly distracted last night when I realised the RSS reader I wrote around 3 years ago can grab last.fm RSS feeds. About 10 minutes later I had an app that displayed my last songs in an image.
I rather quickly turned this into a sig that I'm now using on the Audiosurf forums. It doesn't really do anything snazzy, it's almost identical to the ones last.fm chooses anyway, the only difference is that I have complete control over the layout etc. Which means my own choice of font... Err, that's probably the only real difference. :oD

Ah well, was a good bit of fun!
Currently looks like:


The fate of AudioGame

I lost motivation for this project somewhere around October/November last year. Things just weren't going how I wanted and I got a large swarm of bugs that caused me a lot of problems and I couldn't track down along with some nasty memory leaks springing up overnight in unchanged code. The game itself plays ok-ish for what it is (a very early example of what the engine is capable of).

Then recently I found Beat Hazard, which is pretty much exactly the 'feel' I was aiming for with my game, but works as an old arena-style shooter instead of a sideways shooter.
I read a brief interview with the author, who mentioned using beats in the music to increase counters instead of acting on them directly, which is a pretty cool idea. This made me go digging through AudioGame's code and see what happened if I implemented that technique myself. The results were pretty awesome, instead of huge waves of enemies, they appeared in spots and starts with a sort-of time to the music.

Unfortunately all the old issues are still prevalent. The memory leak I'm at a total loss for, I can't even remember what code I added just before it turned up. I have it set up so the enemies have no maximum speed as the "don't go faster than this" code is broken somehow. It's actually so broken that it has a habit of sending enemy ships shooting off at odd angles when I've only written code to have them move right to left.

This all leaves me with a bit of a conundrum. I could take this game all the way if I fixed the bugs. That tip from the Beat Hazard guy (btw, I strongly suggest buying the game, it's a lot of fun) essentially fixed the biggest problem I was having, which was how to make things work to the music. But the bugs are obscure and may take a long time to fix that isn't proportionate to the issues they cause. The memory leak for example isn't the "keep eating memory forever" sort, it's the "you didn't clean up properly when closing" sort, which is a non-issue for a user but annoying for a coder.

I may re-pick it up as part of the game-a-month stuff and make a prototype, maybe even in C# and OpenTK instead of C++. I may not and just let it rest.

Game A Month Project #1 and #2

So, I've only decided in the past couple of days to go for this game-a-month thing and I already have 2 projects currently on the go.

These consist of the earlier spoken about Whirligig and also a re-re-make of Hoshi.

Whirligig I've not worked on since the tech demo, except to do some testing. I can confirm it works with more than 2 players, but it is the bigger of these two projects so, despite starting it first it will take longer. Also I used it as the test bed for a lot of the framework I'm developing for use in my game-a-month project and I spent over a week getting this working to a satisfactory and easily reusable standard. However, when I started work on Hoshi, this meant I could just drop in a lot of this framework with very little change and now I have two games where I just had one two days ago. Perhaps I'll release some of this framework afterwards, we'll see.

A little more on Hoshi here: when I first found OpenTK one of the first things I wrote for it was a re-write of my uni game Hoshi. Again I got around 75% of the development and then discovered I'd made a huge (and I mean huge) error with how I was translating all the objects around the screen. Untangling this mess would have taken as long again as a total rewrite, so I essentially left it there. There are some videos of the engine on youtube. So, I'm once again re-making the game I put so many hours into as a kid. Right now I have a starry sky (just a quick note, the word hoshi in Japanese -- kanji 星 -- means 'star') and a ship that can fly around it. I have ship designs for the enemy ships in place and I haven't mucked up the positioning system yet. I'd say I'm around 70% of the way to a tech demo with it and around 50% of the way to a full game.

So, those are my current two dates. Hoshi I estimate will be ready sometime in May, I'm going to say provisionally the 16th, since it's my birthday and this was one of my favourite games. ;o)
Whirligig will take longer as I've more plans for it, mid to late June is probably a fair estimate.

New game plan

Ok, so things didn't go quite as planned with my AudioGame. I'll explain the specifics in another post, but this one is more about what I'm planning to do for the rest of this year.

One thing that a lot of indie developers seem to do that allows them to enjoy the scene is to publish a "game a week" or something similar. So, I'm planning on doing the same. This will be hard for me because I'm not someone who easily works to deadlines. I code because I enjoy it and I want it to remain that way, so if I find I'm trying to do more work than I'm enjoying I tend to back off.
This has resulted in a rather large accumulation of half-finished projects however as I also enjoy exploring new ideas, but rarely see them through to completion.

One such example of this is a game I originally wrote for university called Hoshi which is a re-make of an old RISC OS game called Foray that in itself took a lot of inspiration from a BBC/Acorn Electron game called Starship Command. I spent many hours playing this game and it's one of my fondest gaming memories. Single-player, you fly around shooting enemies in waves. One hit kills on them, you have a shield bar, however the enemies shoot so quickly that if you remain still in a shot of their bullets you tend to die in around a second. Unfortunately I long ago lost the original, which is where my wish to remake it originally came from. And I succeeded, sort of. Things were going great, I had ~75% of the game in place and then the deadline approached and I rushed the next 15% and introduced a LOT of bugs that effectively stalled development. I handed in a game that was near enough completion to get high marks, but it was also bugridden as a result of that rush at the end.
What does this have to do with now? Well, I want to make it clear that I won't make that sort of mistake with these games. If I start introducing bugs like that I'll slow down. My plan is to make stable, fun games on a semi-regular basis, not unstable, broken games on a strict timetable.

What this leaves me with is that I won't set an exact time for each game. I also want to put more time into some of the ideas than has been done by some developers (that's not to say their games aren't good, but you can see where corners were cut to fit deadlines). I'll also be using OpenTK and C# instead of some of the more rapid development tools available. The reason for this is simply that I like the additional "wiggle room" that using a base language gives you over something like QuestViewer. Audiosurf is a good example of this. Fantastic game, but all it's bad points ultimately point to it being developed in Quest3D.

So my timetable is this: Average a game once a month. Sometimes it might be two months between releases, sometimes it might be 2 weeks. Updates will primarily be from here, hosted on DropBox, because it's easy and free. ;o)



Whirligig is a small artillery game I'm currently working on.
The basic idea takes from an old, old game called Gravity Wars which involves two stationary ships arranged between several planets where the idea is to shoot your opponent and the planets have gravitational effect on your projectiles.
I've taken other ideas, mainly from an old RISC OS game called TANKS, although the concepts are similar to those used in Worms, that is different types of weapons.

Currently I have the game running as a short tech demo (~2.4MB) between two players with infinite "split" weapons and a video on youtube from earlier in development.

Small technical notes on the game: it uses OpenTK and is written in C#.

I'm also building as much of the internals of the game in a re-usable fashion so I can use them in other projects as well, as I'll explain in my next post.