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.

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)