Since I've revamped the sound engine for the toolkit I've created and have interfaced it with Whirligig, I thought I'd talk a bit about the design decisions behind the sound.
Firstly, all sound is played from plain old WAV files. This is purely for practical purposes. I don't want to start mucking about with OGG and other things in C# as there isn't much in the way of good libraries for doing so and all the sound effects are small enough that keeping them uncompressed isn't an issue.
All the sounds for both Hoshi and Whirligig (and probably projects 3 and 4) has been done in sfxr, which is a very useful project that just outputs simple waves with a few parameters to play with, allowing easy retro sound effects to be created with minimal effort.
So in actual code I use OpenAL where-ever possible. This is mostly because it's a fairly comprehensive library that takes raw WAV data and works on any system with the OpenAL library installed (Windows, Linux and OS X are all supported, for instance).
However OpenAL isn't available on all systems, but .NET and Mono provide a very basic sound player in the form of System.Media.SoundPlayer. This works well for single sound effects, but is useless for playing multiple sounds together. This will be less obvious with some games over others. It's very obvious on Hoshi, but does give an idea of what is being missed. It's also somewhat buggy under Mono it seems, playing sounds unexpectedly or not at all in some cases. As this is purely a back up system I'm not too worried about it and won't be making any effort to fix the problem(s) introduced through this method.
So, when started the sound system checks the options file. If the options file says to not bother with sound, it just loads the dummy sound driver, which just says "ok" to everything, so the game thinks the sound system is all working, but the driver does nothing with any data passed to it.
If the options file says to use OpenAL, it checks that OpenAL is installed on the system then attempts to use it. If either of the checks for OpenAL or if a valid OpenAL context can be created fail then it drops back to the dummy driver.
If the options file says to use the SoundPlayer then the sound system will attempt to create a SoundPlayer class, if that works then it will assume that SoundPlayer works and so use that. If it fails it will default to the dummy sound driver.
The last two options are 'Auto' and 'ForceOpenAL' and are a bit more complicated.
'Auto' is the default and will attempt to use OpenAL followed by SoundPlayer then will drop to the dummy if both fail.
'ForceOpenAL' will skip all checks when initialising OpenAL, which will cause a crash if OpenAL isn't installed. This shouldn't ever be needed by a user and was intended by debug purposes.
So that's the new sound system. As I stated, after modifying it to this in Hoshi, I inserted it into Whirligig this morning and now Whirligig has a multitude of retro sounds that bring some extra life to the game.
Showing posts with label game design. Show all posts
Showing posts with label game design. Show all posts
2010-10-25
2010-04-28
A word on Hoshi
Posted by
Mincus
at
17:59
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.
Subscribe to:
Posts (Atom)