Listing out some ideas I have for what I'm thinking of making. These are in no particular order right now.
1. Arena / Twin-stick shooter: Going with a typical player in the middle (either a man or a ship, ship is easier to animate) who can shoot in a full 360 degrees using either mouse aiming or the classic 2 sticks on a joypad. Enemies would attack in various patterns. I've prototyped this playstyle in C++ with OpenGL in the past (image of prototype)so using that as a reference along with using my existing C#/OpenTK library means this should be easy to get up and running and so would make a good first month project.
2. Single room platformer: This would consist of a simple platforming engine in which each level is a single room on the screen (no scrolling). The original point of this idea was to allow me to experiment and learn about level design. Exact specifics about each level are unclear right now, whether there are collectibles/puzzles/enemies/all of these and the number of levels depends on time constraints.
3. Scrolling jumping platformer: The two more well known examples of this genre are Canabalt and Robot Unicorn Attack. Adding multiple levels you drop down to with the higher ones being quicker might be an interesting twist to this. Building the levels randomly (and consistently) will be an interesting challenge.
4. Ship management: Something similar to FTL, but much simpler. This would be more a prototype and I think it's one of those genres that a lot of devs would like to experiment with.
5. Side-scrolling shooter: This is a genre I've made a couple of simple Flash games of and I experimented with it using music to generate enemies, but I've never put a lot of thought into a comprehensive game in this genre. Several levels with various weapon/ship upgrades and limited lives. Not bullet-hell, more casual.
6. Survival: Something similar but simpler than Don't Starve. Mouse controlled movement, simple crafting. Again more a prototype but something to experiment with.
7. Hoshi 2: I love this game but I feel it's missing something and I'm only sure of parts of that. I would like to update the UI and sound effects especially. Some sort of online score system would be nice. At a stretch I'd like to add multi-player but I'm unsure how easy that would be to do in a month. I want to add more game elements as well and update the AI. It's extremely simplistic atm and overwhelms in a horde-style instead of actively hunting you. I'll write more about what I want to add/change if I decide to pick this up as a game.
8. Fixing Whirligig: A lot of Whirligig's problems are a result of some questionable design decisions when I first started it. Sometimes player rotation goes out of whack and there are pauses as the new planet bitmaps are produced after every impact. Additionally the physics (especially in bouncing) are a little odd at times. The amount of refactoring and fixing required would mean this would take as much time as a new project.
9. RTS/TD hybrid: This would consist of a small group of 'units' that you move around a map, gathering resources, defending yourself and building more units whilst being attacked constantly. I'm unsure how well this will work and may require a lot of tweaking.
10. Procedurally generated exploration: Not exactly a game, but it would create a landscape you could explore procedurally (that is, on the fly, computationally and consistently). The reasoning is that the Survival and RTS/TD hybrid ideas above would require such code before implementing the gameplay specifics for those games. Whilst I doubt this would be a huge amount of fun, with enough thought behind the landscape generation it should create some interesting scenery. Separating it out like this means I'm more likely to spend time fixing issues with the generation before moving on to gameplay elements which should produce a more robust system I can then use for more games.
11. 3D puzzle style game: Something akin to Marble Madness although I'm thinking closer to Arcturus (an old RISC OS game) with varying obstacles, different surface types, slopes and enemies to navigate.
12. Fixing/finishing Five Point Five: Five Point Five was a game I started for a TIG competition regarding multi-player only. Technically it works, although there's no input set up for all 5 ships and it's local only (looks something like this as I left it). The base gameplay is to destroy the other players, however you can't damage them until all the asteroids are destroyed. You can however push them around with your bullets. The asteroids drop power-ups like rapid-fire, power-shots, faster shield recharge. Once the asteroids are destroyed you can damage each other and whoever is left at the end wins. Has plenty of particle effects and you can see the heavy influence from Spheres of Chaos. Fixing and finishing it would require adding net play (which would be the biggest challenge) and a proper menu with rebindable controls. If you plug in enough joysticks it will work fine locally but having a couple of computers for it would make more sense. The levels are set up internally in such a way to reduce lag issues - they're based on a single number and procedurally generated from that, with all the sub-asteroids based from that original number, meaning that clients only need a location and time for a split and not all the individual asteroid information. Moving the game on from the original spec to include AI players would also make things interesting.
So those are 12 ideas. I don't know whether I'll use all of these as doubtless I'll have more and some aren't hugely interesting. There's also various puzzle games like Tetris or Puzzle Bobble that I'd like to clone and would be pretty easy to do.
Showing posts with label hoshi. Show all posts
Showing posts with label hoshi. Show all posts
2012-12-16
2012-12-13
A return
Resurrecting this blog as I'm taking part in 2013's One Game A Month project (http://http://www.onegameamonth.com/) and my original game-a-month project back in 2010 was one of the reasons I started this blog.
I'm on the site as 'phillmwebster' as that's my Twitter handle (http://www.twitter.com/phillmwebster/)
Not really sure which game ideas I'll be using for the projects. I may start off small with the 2 ideas I had for my old game-a-month project (simple arena-style and single-room platformer) and see where I go from there.
I will be re-using my C#/OpenTK library that I used for Hoshi and Whirligig in the past. At least for the first two projects. This is mostly because it's tried and tested and very easy to throw sprites around with.
I may drop into Flash and/or Unity for some of the later ones. Using Python is another possibility, but I'd be learning the language from scratch so would have to see.
Talking of Whirligig I have done some small additional work on it, but it still lacks the viability of a release as there's no real UI outside of a game so all the player names, amounts, etc are still hardcoded. I'll poke around with it some more during December to re-acquaint myself, probably film a video of it and perhaps release a hard-coded version with working random levels and the ability to re-start the level without quitting/restarting the game.
I'm on the site as 'phillmwebster' as that's my Twitter handle (http://www.twitter.com/phillmwebster/)
Not really sure which game ideas I'll be using for the projects. I may start off small with the 2 ideas I had for my old game-a-month project (simple arena-style and single-room platformer) and see where I go from there.
I will be re-using my C#/OpenTK library that I used for Hoshi and Whirligig in the past. At least for the first two projects. This is mostly because it's tried and tested and very easy to throw sprites around with.
I may drop into Flash and/or Unity for some of the later ones. Using Python is another possibility, but I'd be learning the language from scratch so would have to see.
Talking of Whirligig I have done some small additional work on it, but it still lacks the viability of a release as there's no real UI outside of a game so all the player names, amounts, etc are still hardcoded. I'll poke around with it some more during December to re-acquaint myself, probably film a video of it and perhaps release a hard-coded version with working random levels and the ability to re-start the level without quitting/restarting the game.
2010-10-25
A note on sound
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.
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.
Hoshi bug fixes
I'm making an effort to get Whirligig released (hopefully this week, maybe even today, I'm not sure how long it will take to do what I want with it).
In doing so, one of the things that needs implementing is sound. I have all the sounds I need ready and I had Hoshi's sound engine. So, no problem, yes?
Well, Hoshi's sound engine isn't perfect. It actually causes the game to crash randomly when OpenAL isn't installed. This is a fairly major issue, so I decided to go back and fix this on Hoshi before moving the engine across to Whirligig.
Whilst I was working on the engine I quickly added a simple substitute for the sound when OpenAL isn't installed. This uses .NET's or Mono's System.Media.SoundPlayer. This isn't ideal because it will only play one sound at a time with no mixing and Hoshi requires many sounds to be playing at once to sound correct. But it's a good substitute for those who don't want to go searching for OpenAL.
So, now Hoshi will work out of the box with sound, although you'll get a much better experience with OpenAL installed. There's also an additional option in the hoshioptions.xml file in AppData that allows changing the sound engine. So you can set it off, set it to the Media.SoundPlayer option or set it to OpenAL. There's also a ForceOpenAL option which skips any checks for OpenAL and is not really recommended as it will cause the same crashing issues as before if used on a system without OpenAL.
Anyway, new release is here.
These are purely bugfixes, if the version of Hoshi you have already doesn't have issues you won't gain anything from this new version.
And now I can do some work on Whirligig.
In doing so, one of the things that needs implementing is sound. I have all the sounds I need ready and I had Hoshi's sound engine. So, no problem, yes?
Well, Hoshi's sound engine isn't perfect. It actually causes the game to crash randomly when OpenAL isn't installed. This is a fairly major issue, so I decided to go back and fix this on Hoshi before moving the engine across to Whirligig.
Whilst I was working on the engine I quickly added a simple substitute for the sound when OpenAL isn't installed. This uses .NET's or Mono's System.Media.SoundPlayer. This isn't ideal because it will only play one sound at a time with no mixing and Hoshi requires many sounds to be playing at once to sound correct. But it's a good substitute for those who don't want to go searching for OpenAL.
So, now Hoshi will work out of the box with sound, although you'll get a much better experience with OpenAL installed. There's also an additional option in the hoshioptions.xml file in AppData that allows changing the sound engine. So you can set it off, set it to the Media.SoundPlayer option or set it to OpenAL. There's also a ForceOpenAL option which skips any checks for OpenAL and is not really recommended as it will cause the same crashing issues as before if used on a system without OpenAL.
Anyway, new release is here.
These are purely bugfixes, if the version of Hoshi you have already doesn't have issues you won't gain anything from this new version.
And now I can do some work on Whirligig.
2010-06-17
2010-06-11
Quick post
Just a quick note to say I've finally tested Hoshi in Linux.
Good news is that it works.
Bad news is that I messed up the sound paths. I'll push out an update for that tomorrow.
What is interesting is that it runs considerably better full-screen than on Windows. I guess that isn't particularly surprising though since Windows is bloated and not a particularly good OS choice from a gaming technical perspective.
Good news is that it works.
Bad news is that I messed up the sound paths. I'll push out an update for that tomorrow.
What is interesting is that it runs considerably better full-screen than on Windows. I guess that isn't particularly surprising though since Windows is bloated and not a particularly good OS choice from a gaming technical perspective.
2010-05-14
Hoshi release!
I'm releasing Hoshi today, earlier than I originally planned because, well, it's done.
Without further ado, you can download it from here (~800KB).
And a picture of the final version:
I'm uploading a video of it running at the moment, will take some time because my connection is broken horribly right now, but will add a link to that when it's done.
Edit: Video is here.
On with Whirligig now, with a release date looking around June 15th, but that's not set in stone.
Feel free to comment with any bugs. AFAIK there aren't any, but if there's anything large enough I'll fix it and re-release.
I haven't done all the fiddling about with OpenAL that I intended to. There are some checks in there but I've no idea if they're enough, so you may need to install OpenAL as well. Downloads are available from creative here. Linux users should have it in their repo somewhere, but I'm not 100% on that.
Without further ado, you can download it from here (~800KB).
And a picture of the final version:
I'm uploading a video of it running at the moment, will take some time because my connection is broken horribly right now, but will add a link to that when it's done.
Edit: Video is here.
On with Whirligig now, with a release date looking around June 15th, but that's not set in stone.
Feel free to comment with any bugs. AFAIK there aren't any, but if there's anything large enough I'll fix it and re-release.
I haven't done all the fiddling about with OpenAL that I intended to. There are some checks in there but I've no idea if they're enough, so you may need to install OpenAL as well. Downloads are available from creative here. Linux users should have it in their repo somewhere, but I'm not 100% on that.
2010-05-13
That was easy
It's, err, sorted.
Sound is working.
I haven't tested for systems without OpenAL yet. I think I have enough checks to stop an outright crash but I need to be sure.
I also haven't added the "sound effects on/off" line in the options, which needs doing as not everyone likes retro beeps and whistles. Might add a volume control to that as well, will see.
But yeah, the game is pretty much finished. I'll make a video later demonstrating the sounds and um, guess I'll release it once I've checked the OpenAL stuff and added that line to the options screen.
Sound is working.
I haven't tested for systems without OpenAL yet. I think I have enough checks to stop an outright crash but I need to be sure.
I also haven't added the "sound effects on/off" line in the options, which needs doing as not everyone likes retro beeps and whistles. Might add a volume control to that as well, will see.
But yeah, the game is pretty much finished. I'll make a video later demonstrating the sounds and um, guess I'll release it once I've checked the OpenAL stuff and added that line to the options screen.
It's done!
That is, everything but the sound is.
I may not finish the sound by Sunday (should do, but I can't be 100%), in which case I'll release this version on Sunday instead.
Also, things may go terribly wrong with the sound on various systems, so I'm going to have to abstract it away and try and check for errors at runtime then run with a "null" sound driver if things go wrong.
Doing the additional checks is probably what will take up most of the time.
I'll be using sfxr to make the effects, which is exceedingly good at making retro noises, which fits in with the whole theme Hoshi goes for.
I'm going to try and recreate the original sound effects as closely as possible, but that may not work 100%, will have to see.
I may not finish the sound by Sunday (should do, but I can't be 100%), in which case I'll release this version on Sunday instead.
Also, things may go terribly wrong with the sound on various systems, so I'm going to have to abstract it away and try and check for errors at runtime then run with a "null" sound driver if things go wrong.
Doing the additional checks is probably what will take up most of the time.
I'll be using sfxr to make the effects, which is exceedingly good at making retro noises, which fits in with the whole theme Hoshi goes for.
I'm going to try and recreate the original sound effects as closely as possible, but that may not work 100%, will have to see.
2010-05-12
Progress
Had a busy evening.
Most of the options menu now works. It's klunky horrible, horrible code, but it works.
It's completely centred on Hoshi, which means I can't re-use this menu code. Something I realised late today. Given the choice I'd do the entire thing differently, but it's close enough to completion now to not be worth redoing. Next time I make a non-mouse menu I know what to do at least.
So what works?
- Resolution changes (only 2 resolutions are supported, but you can change these to whatever you want in the options, initially they're set as 800x600 and 1280x800).
- Moving to/from fullscreen. It's not ideal, OpenTK doesn't do this particularly well and I seem to lose a fair whack of performance (which I believe is actually Windows' fault), but it's there.
- Changing between keysets and joystick.
- Resetting the high score.
What's to implement?
- Custom key changes.
- Sound effects on/off (implementing sound first is a bit of a must for this one. ;o))
Additionally I added a refreshrate variable to the options file, so this can be changed by hand. It's set to 60 by default, which will be fine for TFTs but is generally unpleasant on CRTs.
Also: Options are saved on exit, not on change. So if you change some options then manage to crash the game (I've not managed it yet) then they won't be saved and neither will your highscore.
I know highscore editing is simple, but really, who benefits? ;o)
Also found and squashed a bug earlier where it was possible to spawn a bazillion enemies on level 1 and so use that to significantly boost your score. Whoops.
Still looking good for a Sunday release anyway. I worked out earlier that I'll have written the entire game in 26 days (started it on the 20th of April). Pretty sure that's a good achievement. :o)
Just a quick teaser, image of the options screen:
Most of the options menu now works. It's klunky horrible, horrible code, but it works.
It's completely centred on Hoshi, which means I can't re-use this menu code. Something I realised late today. Given the choice I'd do the entire thing differently, but it's close enough to completion now to not be worth redoing. Next time I make a non-mouse menu I know what to do at least.
So what works?
- Resolution changes (only 2 resolutions are supported, but you can change these to whatever you want in the options, initially they're set as 800x600 and 1280x800).
- Moving to/from fullscreen. It's not ideal, OpenTK doesn't do this particularly well and I seem to lose a fair whack of performance (which I believe is actually Windows' fault), but it's there.
- Changing between keysets and joystick.
- Resetting the high score.
What's to implement?
- Custom key changes.
- Sound effects on/off (implementing sound first is a bit of a must for this one. ;o))
Additionally I added a refreshrate variable to the options file, so this can be changed by hand. It's set to 60 by default, which will be fine for TFTs but is generally unpleasant on CRTs.
Also: Options are saved on exit, not on change. So if you change some options then manage to crash the game (I've not managed it yet) then they won't be saved and neither will your highscore.
I know highscore editing is simple, but really, who benefits? ;o)
Also found and squashed a bug earlier where it was possible to spawn a bazillion enemies on level 1 and so use that to significantly boost your score. Whoops.
Still looking good for a Sunday release anyway. I worked out earlier that I'll have written the entire game in 26 days (started it on the 20th of April). Pretty sure that's a good achievement. :o)
Just a quick teaser, image of the options screen:
More on Joysticks
Slowly working through the Options menu. I really hate UI design.
The good news is the UK election is sorted. I'm not convinced it will last more than a couple of years, and things aren't exactly how I'd like them, but they'll do. We shouldn't be running off invading any more countries illegally for the time being anyway. :oP
Anyway, Joysticks.
I have Joystick support implemented and working. It feels fine to me, but I don't like joystick controls on this sort of game personally.
I edited the OpenTK source to implement it in the end with a semi-clumsy hack.
I'm fairly certain it's badly optimised, but it work for now. I'm not looking to break any optimisation records with Hoshi. ;o)
I'm not extensively testing it. Random unplugs etc are undefined. It's mostly there as a testbed for future projects among which will probably be platformers, for which joystick support is a must.
The good news is the UK election is sorted. I'm not convinced it will last more than a couple of years, and things aren't exactly how I'd like them, but they'll do. We shouldn't be running off invading any more countries illegally for the time being anyway. :oP
Anyway, Joysticks.
I have Joystick support implemented and working. It feels fine to me, but I don't like joystick controls on this sort of game personally.
I edited the OpenTK source to implement it in the end with a semi-clumsy hack.
I'm fairly certain it's badly optimised, but it work for now. I'm not looking to break any optimisation records with Hoshi. ;o)
I'm not extensively testing it. Random unplugs etc are undefined. It's mostly there as a testbed for future projects among which will probably be platformers, for which joystick support is a must.
2010-05-11
Another update
I've spent the afternoon avoiding the Options menu. I really hate UI coding, it's so full of potentially tricksy pieces.
Instead I've fixed all the niggly bugs and added explosions to ship deaths, including the player, with a seconds worth of delay after dying so you can watch the remains of your ship fly into the unknown.
So yes, everything is now drawn correctly at the edges of the Arena and I've removed those horrible red lines. Passage between one edge and another should be unnoticeable.
I've made some minor changes to balance.
Enemy ships now have a variable amount of shield power depending on the wave. Up to wave 5 you'll always insta-kill them. At wave 6 they'll take 2 shots, at wave 11 they'll take 3, 16 they'll take 4, etc.
I don't think there's anything else to add at all to the game itself now. Balancing tests still need to be done, but I think that should be fair enough. Getting past Wave 11 will require considerable skill I suspect, but that was true on the original Foray as well. I think the furthest I ever got on that was around wave 15.
Instead I've fixed all the niggly bugs and added explosions to ship deaths, including the player, with a seconds worth of delay after dying so you can watch the remains of your ship fly into the unknown.
So yes, everything is now drawn correctly at the edges of the Arena and I've removed those horrible red lines. Passage between one edge and another should be unnoticeable.
I've made some minor changes to balance.
Enemy ships now have a variable amount of shield power depending on the wave. Up to wave 5 you'll always insta-kill them. At wave 6 they'll take 2 shots, at wave 11 they'll take 3, 16 they'll take 4, etc.
I don't think there's anything else to add at all to the game itself now. Balancing tests still need to be done, but I think that should be fair enough. Getting past Wave 11 will require considerable skill I suspect, but that was true on the original Foray as well. I think the furthest I ever got on that was around wave 15.
Hoshi video
Managed to finally take a video of Hoshi.
As I said before, this is near finished game-play. There's still cleaning up to do and I'm still having performance issues in full-screen for some reason, which is why this is an 800x600 recording, not a 1280x800 as I'd like, but it still gives a good example of what the final game will look like.
I die rather suddenly at the end and accidentally start a new game immediately. Will have to look at that.
As I said before, this is near finished game-play. There's still cleaning up to do and I'm still having performance issues in full-screen for some reason, which is why this is an 800x600 recording, not a 1280x800 as I'd like, but it still gives a good example of what the final game will look like.
I die rather suddenly at the end and accidentally start a new game immediately. Will have to look at that.
Nearly done!
Hoshi is finished for all intents and purposes. With the exception of the Options menu.
All other bugs are niggling:
- Boss AI currently gets confused and sometimes lost due to lacking position-correction. This only happens whilst escort ships are still around, once they're dead the AI works. The position correction is easy to fix, hopefully the AI is as well.
- Stars are still somewhat confused from my X axis mix-up, this is easy to fix.
- Enemy AI does still get confused with arena borders. This should be easily fixable.
Additionally I'm having second thoughts about the 3-shots-to-kill enemies. It shows off the shield animation better, but they're a bit of a pain to kill.
I may drop it to two shots and make it so only 3 need to crash into you in rapid succession to kill you instead of the current 4.
So, I should have an RC tech demo by the end of the day.
All other bugs are niggling:
- Boss AI currently gets confused and sometimes lost due to lacking position-correction. This only happens whilst escort ships are still around, once they're dead the AI works. The position correction is easy to fix, hopefully the AI is as well.
- Stars are still somewhat confused from my X axis mix-up, this is easy to fix.
- Enemy AI does still get confused with arena borders. This should be easily fixable.
Additionally I'm having second thoughts about the 3-shots-to-kill enemies. It shows off the shield animation better, but they're a bit of a pain to kill.
I may drop it to two shots and make it so only 3 need to crash into you in rapid succession to kill you instead of the current 4.
So, I should have an RC tech demo by the end of the day.
2010-05-10
Quick Hoshi update
Obviously the election stuff has dragged on a lot longer than I thought it had and in between a friend's birthday party and the Spanish Grand Prix I got near enough no code done this weekend.
However, today I've had quite a productive afternoon, so I'll outline what now works in addition to before.
Firstly there's a menu:
Which is fairly basic, but will do for now.
Options still doesn't work, but most of the basic framework is in there, just needs fully implementing.
I've finished adding the final few pieces of game code, which means the game actually plays now as it will when finished, that means all AI (including boss), special bullets and wave re-plays are implemented.
However there's no indication what wave you're on, nor score indicator (although both are stored internally).
I'm expecting to have everything implemented either tomorrow afternoon or Wednesday at which point I'll have a choice.
First, I could just release it at that point, however there will be no sound implemented. Sound is a bit of a funny area with OpenTK. It uses OpenAL, which is a separate download on Windows and may require the player to go do download and ./configure things on Linux, which is less than ideal.
Also, OpenAL breaks 64-bit support on Windows, which means telling the application to run in 32-bit mode. There's no 64-bit version of OpenAL for Windows as of this moment and it's possible there won't be in the foreseeable future.
I may be able to get round these at some point in the future but right now it's a bit of a show stopper for sound effects.
I do have a solution, but it's not ideal.
Distribute multiple binaries.
It's fairly easy for me to create a non-sound binary alongside one with sound. I just don't call OpenAL in the no sound one and so it will run with most compatibility.
There's a further solution to all this, and that is compiling and distributing an OpenAL DLL and linux shared object alongside the executable. I'd rather not go this route just yet though as compiling OpenAL soft under Windows is somewhat daunting, but it would fix the 32/64-bit issue.
Another word on Joystick support. If you followed the link I made in my last post you'll not that Fiddler said the issue was fixed in OpenTK's svn. I've downloaded and compiled that and I'm still having the same issue at the moment. This is unfortunate but not seriously threatening. I still have my full keyboard support which will be fine on any keyboard that allows 3 keys to be used at once (all, else ctrl-alt-del wouldn't be usable ;o))
So that's where I stand. I'll go get Score and Wave notifications implemented so I can work on the Options screen tomorrow.
However, today I've had quite a productive afternoon, so I'll outline what now works in addition to before.
Firstly there's a menu:
Which is fairly basic, but will do for now.
Options still doesn't work, but most of the basic framework is in there, just needs fully implementing.
I've finished adding the final few pieces of game code, which means the game actually plays now as it will when finished, that means all AI (including boss), special bullets and wave re-plays are implemented.
However there's no indication what wave you're on, nor score indicator (although both are stored internally).
I'm expecting to have everything implemented either tomorrow afternoon or Wednesday at which point I'll have a choice.
First, I could just release it at that point, however there will be no sound implemented. Sound is a bit of a funny area with OpenTK. It uses OpenAL, which is a separate download on Windows and may require the player to go do download and ./configure things on Linux, which is less than ideal.
Also, OpenAL breaks 64-bit support on Windows, which means telling the application to run in 32-bit mode. There's no 64-bit version of OpenAL for Windows as of this moment and it's possible there won't be in the foreseeable future.
I may be able to get round these at some point in the future but right now it's a bit of a show stopper for sound effects.
I do have a solution, but it's not ideal.
Distribute multiple binaries.
It's fairly easy for me to create a non-sound binary alongside one with sound. I just don't call OpenAL in the no sound one and so it will run with most compatibility.
There's a further solution to all this, and that is compiling and distributing an OpenAL DLL and linux shared object alongside the executable. I'd rather not go this route just yet though as compiling OpenAL soft under Windows is somewhat daunting, but it would fix the 32/64-bit issue.
Another word on Joystick support. If you followed the link I made in my last post you'll not that Fiddler said the issue was fixed in OpenTK's svn. I've downloaded and compiled that and I'm still having the same issue at the moment. This is unfortunate but not seriously threatening. I still have my full keyboard support which will be fine on any keyboard that allows 3 keys to be used at once (all, else ctrl-alt-del wouldn't be usable ;o))
So that's where I stand. I'll go get Score and Wave notifications implemented so I can work on the Options screen tomorrow.
2010-05-06
Well that explains a lot.
All my X co-ordinates have been oddly reversed in Hoshi. Just worked out my camera wasn't orientated properly... Having text backwards isn't conducive to the user experience.
Bleh.
Bleh.
2010-05-05
Joysticks
OpenTK pulled the old joystick code near the end of last year without me noticing. This essentially means Hoshi won't have joystick support like I wanted unless I cobble together a custom version of OpenTK.
This isn't a disaster, but it's annoying as I wanted to introduce Joystick support for some of the other games I have planned as well.
This is the exact post detailing the new input methods. You'll note the last post is "this won't be ready for v1.0."
Unfortunately the old code was pulled as part of the process of implementing the new, so whilst OpenTK will wave a flag and say "look! I has a stick!" it won't let you actually read any useful information from the joystick.
So that's about half a day wasted on that. :o(
Arse. And I drew a joystick icon as well.
This isn't a disaster, but it's annoying as I wanted to introduce Joystick support for some of the other games I have planned as well.
This is the exact post detailing the new input methods. You'll note the last post is "this won't be ready for v1.0."
Unfortunately the old code was pulled as part of the process of implementing the new, so whilst OpenTK will wave a flag and say "look! I has a stick!" it won't let you actually read any useful information from the joystick.
So that's about half a day wasted on that. :o(
Arse. And I drew a joystick icon as well.
2010-05-04
Work on Hoshi
Been busy watching election stuff again. :oP
That'll all be over on Thursday.
Anyway, I'm having a minor crisis with control mechanisms.
Essentially I wanted things to be as simple as possible. In the old versions there were a singular set of keys: Z, X, right shift and enter (for left, right, thrust and fire respectively). These are generally not considered "nice" keys under todays standards (although personally I still think they work fantastically for pretty much any game when you use ' and / for up/down as well, but anyway), so there's another keyset that in the tech demo is configured as left and right cursor, Z and X (I think). The fire/thrust aren't ideal really, but good enough for the tech demo.
So, what's the problem exactly? Well, I have a left, right and enter key, and even a potential "back", but no up/down.
Because I want an options screen, I need a basic menu. A basic menu ideally needs an up/down and definitely needs clear keys.
Initially I just thought "oh, I'll add an up/down", but that could confuse matters when the user goes "what do up/down in the game?" The answer would be "nothing, they're purely for menu navigation"... Seems a little silly.
Next thought was "I could do a left/right menu with cool slanty text", which would work but involves coding up another UI element and drawing the text sideways which will all take time which I'm running out of.
So, I've decided on this:
Menu navigation will all be done through the cursor keys. Game play will have custom keys definable in the options.
Oh, also I'm adding basic joystick support.
On the main menu they'll be a notice in the top-left of the screen with pictures of cursor keys, enter, escape and a joystick to indicate that's how you navigate the menu. Heading to the options screen will let you redefine the in-game keys.
The tech demo actually has the ability to redefine the keys in its options file, but that's not a lot of use unless you know the OpenTK keycodes. There's a few other options I forgot to mention that I'll go through now:
If you open the file that is in AppData (C:\Users\\AppData\Local on Vista/Win7, C:\Documents and Settings\\Application Data on XP I think) then you can change these options.
First off is 'fullscreen'. Changing this to 'true' will attempt a fullscreen mode.
Next you have an X and Y resolution, changing these will do the obvious.
Arenasize changes the size of the arena. Making it very, very small is untested, I don't suggest doing so. Making it very large will just mean it takes longer to catch up with the enemy ships. Again this is untested. The radars should still work, but again, untested. :oD
StarsInTheSky and Layers changes the number of stars on each of the parallax star layers and obviously the number of those layers.
StarSize is a value passed directly to OpenGL to change the size of points. I've not stuck to this everywhere in the code so changing it might not make a difference. Large values will look silly, 1 will make the stars hard to see and anything smaller than 1 will default to 1.
UseKeySet determines which set of keys to use. Currently 0 is the standard cursors with Z and X, 1 is the Z/X/enter/shift layout I mentioned previously that I prefer. 2 will default to the cursors with Z and X again and will become the 'custom' key set when implemented.
Once joystick support is implemented, this value will also support -1 for the joystick.
Back and pause will always be Escape and 'P'... Pause works but has a bug in that you can still rotate and fire in the tech demo.
That'll all be over on Thursday.
Anyway, I'm having a minor crisis with control mechanisms.
Essentially I wanted things to be as simple as possible. In the old versions there were a singular set of keys: Z, X, right shift and enter (for left, right, thrust and fire respectively). These are generally not considered "nice" keys under todays standards (although personally I still think they work fantastically for pretty much any game when you use ' and / for up/down as well, but anyway), so there's another keyset that in the tech demo is configured as left and right cursor, Z and X (I think). The fire/thrust aren't ideal really, but good enough for the tech demo.
So, what's the problem exactly? Well, I have a left, right and enter key, and even a potential "back", but no up/down.
Because I want an options screen, I need a basic menu. A basic menu ideally needs an up/down and definitely needs clear keys.
Initially I just thought "oh, I'll add an up/down", but that could confuse matters when the user goes "what do up/down in the game?" The answer would be "nothing, they're purely for menu navigation"... Seems a little silly.
Next thought was "I could do a left/right menu with cool slanty text", which would work but involves coding up another UI element and drawing the text sideways which will all take time which I'm running out of.
So, I've decided on this:
Menu navigation will all be done through the cursor keys. Game play will have custom keys definable in the options.
Oh, also I'm adding basic joystick support.
On the main menu they'll be a notice in the top-left of the screen with pictures of cursor keys, enter, escape and a joystick to indicate that's how you navigate the menu. Heading to the options screen will let you redefine the in-game keys.
The tech demo actually has the ability to redefine the keys in its options file, but that's not a lot of use unless you know the OpenTK keycodes. There's a few other options I forgot to mention that I'll go through now:
If you open the file that is in AppData (C:\Users\
First off is 'fullscreen'. Changing this to 'true' will attempt a fullscreen mode.
Next you have an X and Y resolution, changing these will do the obvious.
Arenasize changes the size of the arena. Making it very, very small is untested, I don't suggest doing so. Making it very large will just mean it takes longer to catch up with the enemy ships. Again this is untested. The radars should still work, but again, untested. :oD
StarsInTheSky and Layers changes the number of stars on each of the parallax star layers and obviously the number of those layers.
StarSize is a value passed directly to OpenGL to change the size of points. I've not stuck to this everywhere in the code so changing it might not make a difference. Large values will look silly, 1 will make the stars hard to see and anything smaller than 1 will default to 1.
UseKeySet determines which set of keys to use. Currently 0 is the standard cursors with Z and X, 1 is the Z/X/enter/shift layout I mentioned previously that I prefer. 2 will default to the cursors with Z and X again and will become the 'custom' key set when implemented.
Once joystick support is implemented, this value will also support -1 for the joystick.
Back and pause will always be Escape and 'P'... Pause works but has a bug in that you can still rotate and fire in the tech demo.
2010-05-02
Design decisions
I said I'd talk about why I'd decided to use C# and OpenTK, so I'll do that here. Along with why I'm developing reusable code, which is something of a two-edged sword if you're not careful.
Why C#?
To be blunt, because I can get from clicking "start project" to a working OpenGL window in under 2 minutes. With OpenTK installed on the system there's minimal messing around with dependencies etc, etc.
On top of that, .NET has a very, very rich network of libraries. VB also has access, but it's not as flexible a language. There are other options for adding useful libraries to C/C++ but you have to take time to set things up, which can take a long time and there's also issues with linking things so they'll "just work" on other people's machines. C# with always "just work" on a Windows box and with mono installed will most likely "just work" on both Linux and OS X as well without requiring me to release 3 copies of the game.
Why OpenTK?
Once C# was decided on, there were several things I could use for games programming. The most obvious is XNA, which is Microsoft's release and is easily portable to the X-Box 360. However, it's Windows only and is based on DirectX, which I've never particularly liked.
SDL.NET was another possiblity, but this works in 2D and seems to be abandoned in recent years. It was more active around .NET 1.1 than any other time and much of the coding harks back to that era, C# and .NET have moved on since then.
Tao is another possibility and would be a solid choice, but again it looks abandoned.
So that brings me to OpenTK, which has almost direct calls to OpenGL, contains a very quick and easy class called "GameWindow" (which allows that 2 minute setup I spoke about), contains maths classes that are almost (but not quite) directly portable with XNA, has support for sound playback and has extensive input support for keyboards, mice and joysticks. It also supports these features across both Windows and Linux, with most supported on OS X (I think sound playback and joysticks are a bit iffy, but I have no Mac to test them on).
Also note, I'm discounting anything that isn't free here.
Reusable code
Working out how much of a game to make reusable is more complex than it first appears.
For example: You could build an entire game engine that could be used for multiple games, but it should be pointed out that this is a large project in and of itself and if you just want to write a game then it's advisable to write a game-specific engine which will be much less flexible, but you're more likely to complete.
For my Game-A-Month project I've hit somewhere in the middle ground. Certain parts of my games will be reusable, but the game itself will be built largely from scratch each time.
The main part that is reusable is are the user interface components. Specifically this is a lump of code that contains the decision making for what is happening in the game at the moment, making sure things that are supposed to be rendered are so and those that aren't, aren't, making sure when a key is pushed the game takes the right action, etc, etc.
In Whirligig it deals with where and what the mouse has clicked on, who's turn it is and what to display on the screen at any moment. It will also deal with the main menu and shop when those are implemented.
In Hoshi it just deals with the basic rendering right now and not a lot else, although it also knows when the player dies and deals with ending the game; this bit of user interface is particularly clever as internally user interfaces lie on a stack, the first on the stack is the 'main menu' then you stack whatever else the user visits as you need it. When the user finishes with the user interface it just pops the stack and the user is automatically returned to the previous interface. If the stack is empty the game ends.
This allows me to very quickly knock together a group of components I want rendering into a user interface, chuck it on the stack and have a game prototype. This is the stage both Hoshi and Whirligig are currently at. When I want to add a main menu, I just create the menu as a separate interface and when the user selects "play game" just push my 'prototype' interface onto the stack. When the game ends, the stack is popped and control drops back through to the main menu.
Other components are designed to work with this interface and mostly consist of fairly mundane things like windows, labels, buttons and progress bars (all showcased in Whirligig) which inherit an interface called IUIElement. This interface allows me to create and add a new element to a user interface very quickly. For example, the radars took ~30 minutes to knock up in the end and the energy bar not a lot longer, then I just use an AddControl() call on the interface and they're rendered the same as anything else.
This is all very useful, but I take some performance hits for it. Interfaces suffer some nasty performance problems and once I start developing more complex objects I will certainly start using less of them (right now every render object uses one for it's main render cycle, this is VERY BAD as it generates unnecessary allocation and therefore garbage collection calls for every object in every render cycle -- 60+ times a second -- which severely impacts performance and may be the reason I'm having issues recording a video). Hopefully project #3 (which I'm looking at a plaformer idea I have for) will have less of these.
There are other small elements that I'm making reusable, small things like the OpenGL texture upload code, which I'm just doing quick'n'dirty right now, text drawing is done through the .NET image subsystem to a texture then uploaded with a transparent mask, this isn't perfect (rapidly changing text would be bad for this method) but works for what I have right now.
When I write a simple audio subsystem (which I'll be doing in the next couple of weeks for Hoshi), that will be reusable as well.
Hoshi tech demo
Hoshi is moving rapidly, I've now got a tech demo ready which you can download here (557KB).The aim is simply to kill all 20 ships. The AI is fully implemented but not properly balanced yet and they sometimes shoot in mysterious directions. However they do usually target your direction and despite having no swarm mechanics do tend to act in a swarm-like behaviour.
I've mostly been playing against 50 ships when doing testing and that can prove quite difficult. You shouldn't reach 50 ships for a long while in the main game though.
Tips are to just keep moving as much as possible, but not TOO fast or you'll outrun your bullets and run the risk of smashing into ships. If you die (energy bar is at the bottom) the demo will exit. You only get one life. ;o)
Currently things go a bit weird at the edges of the level. For one the AI will get confused and start flying in the opposite direction, ships on the opposite side won't be drawn and bullets don't have "move to correct side" parts attached. So, if you see a big red line, I suggest flying away from it, although nothing will go spectacularly wrong if you don't.
In other news, I did a fair bit of yesterday and today's development under Linux, where the game just runs. I'll write a post about my reasons for choosing C# and OpenTK (this being a main one) at some point. For now, you can see what it looks like here, ignore the tearing, that's just a vsync issue. I'd not quite got the radar implemented there, so no red spots.
I tried to take a video of the tech demo earlier but ran into some issues unfortunately. I'll try again later though.
Subscribe to:
Posts (Atom)
