I've been learning how to use Unity as I mentioned in the previous post and so to test my fairly basic skills in the program I decided to write a simple invaders clone (it's a very easy game to write, I did it in under 2K of BBC BASIC once)
Unity has a very jumbled way of doing things it seems to me. I'm not used to having so little control over how things operate and this was the biggest challenge. Putting together the game was pretty easy, sorting out interconnections between objects and various other things was the main problem.
Unity has a variety of languages you can use to write code for. The tutorial I was using suggested Javascript, but I'm far more comfortable with C#, which is another offering, so I went with that. Overall the language use was pretty standard. Unity uses an external editor to modify the code, then recompiles it on returning to Unity, this system isn't wonderful and sometimes when editing multiple scripts Unity will only recompile one of them, also the editor isn't wonderful, lacking some of the modern amenities I'm used to, but overall this works pretty well and I get the impression you're never supposed to be editing more than a few hundred lines of code for each object and expected to do the majority of things in Unity itself.
Unity comes with its own 3D physics engine and hull colliders for a set of primitives. These are fun to play with at first, but trying to do anything constructive with them in a simple game isn't the best bet. I completely discarded the engine for my invaders game as it simply wasn't necessary and having seen some other 'physics invaders' games, it's not really a wonderful new dynamic.
I originally intended on using the collision detection from the physics engine for hit detection, but that proved more difficult than I anticipated. I suspect it is possible, but I wasn't able to get it to work as intended. As a result I do all the collision detection manually. This probably works better anyway as the Unity hit detection will do all objects against all other objects whereas mine just does bullets against aliens and bombs against the player.
So, I actually finished pretty much all this game, save the bombs, last weekend sometime, with just the bombs left which I added this evening since my last post.
My overall feelings are that Unity is a very nice bit of kit, very useful and very easy to use. I'm not sure how much I'll use it in the future at the moment, I've got an idea for a game that would work well with it and I've only just started to uncover what it's capable of (there's model importing, animation and a ton of other stuff I've yet to look at).
Without further ado, here's a link to my Unity game. It requires the Unity web plugin be installed, which should work on sane browsers under Windows and OS X. Not sure about Linux.
I might clean it up and release it as a separate executable, since Unity allows that easily. Will see.
What initially got me to take another look at Unity is this blog post by Sophie Houlden. I've recently started using Twitter a lot more and started following a number of indie devs and she was one of them. Currently she's working on a game using Unity called Lottie's Dungeon. So far there's not a huge amount of content, but it is fun to run around in and right now it costs practically nothing. Her intention is to raise the price as she adds more content, in small increments.
It's an interesting development idea and it's similar to the one that Markus Persson (aka Notch) has done with Minecraft, although he's charging half price until he's decided it's not an alpha any more. It's working for Notch anyway who's made a huge amount of cash and sold over 600,000 copies as of today.
As mentioned earlier, I'm releasing these two games as part of my game-a-month project now. Still leaves me miles behind schedule, but ah well. Maybe "occasional game release project" might be a better name? ;o)
This is project a anyway.
Showing posts with label gameamonth. Show all posts
Showing posts with label gameamonth. Show all posts
2010-11-14
Flash, Unity and other things
So I've been busy coding, just not on my games again. :o/
Well, that's not technically true, I've been writing games, just not exactly for my game-a-month project.
What I've found is Unity and Flixel.
I knew about Unity before I started this project, but for some reason I'd got it into my head that it was pay-only and there was only a free trial. That's not the case. For PC, Mac and Web development it's completely free (save some more advanced libraries like realistic water effects).
It's astoundingly easy to use and I've created a small invaders re-make that I'll release shortly. It's almost finished, just needs 'bombs' adding.
Flixel is a flash library. Normally I steer clear of Flash because performance under it is absolutely terrible for games. Really terrible. How much this matters depends on your perspective and I'll write a piece on that another time.
Flixel allows quick and easy development of Flash games. It uses completely free tools (Adobe's Flex SDK is free and there's a very handy IDE called FlashDevelop). Which just leaves learning ActionScript 3.
If you've any experience with other modern languages, that's not really an issue, but it has some peculiarities in it and seems overly verbose in places to me, but still, it's easy enough. Following the 'hello world' tutorial on the Flixel site gives a reasonable introduction to the basics, but doesn't explain a lot of things.
So, 48 hours after picking up Flixel I have a full game written in it. Yes, it is that easy to use.
I could embed it directly in the page, but I've always kinda been against that, so here's a link instead.
Space to shoot, cursors to move.
You'll have to excuse my pretty dreadful graphics, I was mostly just experimenting and seeing what I could manage. The backgrounds took less than 2 minutes each and the clouds were about the same. The ship is from a while back. The ghosts were just me yesterday morning going "what's an easy enemy to draw?"
Most of the code is taken from this tutorial, which I don't think anyone who doesn't know about resource allocation should follow. If you follow that tutorial to the letter, you'll end up with some nasty memory leaks because it doesn't reuse resources properly, it just leaves them hanging around in the background. Most notably are the bullets (which aren't destroyed, so any that miss enemies and fly off into the ether to the right of the screen will just go on forever), enemies (same issue going off the left of the screen) and explosions (creates and doesn't dispose 10 sprites every time something dies).
So, I changed it slightly so that my game destroys bullets off the right of the screen, enemies off the left and re-uses the same 10 explosions, seems to work well.
I also extended the tutorial to include my parallax background effect and moving clouds. There's nothing particularly spectacular in there, but it was something I was interested in working out.
Flixel is pretty well known in the Flash community, the main author is Adam "Atomic" Saltsman who wrote the game Canabalt (google it, you've almost certainly played it before).
So that was this weekend's Flash adventure. Was interesting and I've an idea for a Flash game I want to put into practice at some point using Flixel. Although it's a platformer so will require me learning a fair bit more about how it all works.
Because I've not been keeping to my game a month schedule, I'm going to mark this minor game as part of the project but not give it a number, I'll label it 'b'. 'a' will be the Unity game which I'll finish off and post shortly.
Well, that's not technically true, I've been writing games, just not exactly for my game-a-month project.
What I've found is Unity and Flixel.
I knew about Unity before I started this project, but for some reason I'd got it into my head that it was pay-only and there was only a free trial. That's not the case. For PC, Mac and Web development it's completely free (save some more advanced libraries like realistic water effects).
It's astoundingly easy to use and I've created a small invaders re-make that I'll release shortly. It's almost finished, just needs 'bombs' adding.
Flixel is a flash library. Normally I steer clear of Flash because performance under it is absolutely terrible for games. Really terrible. How much this matters depends on your perspective and I'll write a piece on that another time.
Flixel allows quick and easy development of Flash games. It uses completely free tools (Adobe's Flex SDK is free and there's a very handy IDE called FlashDevelop). Which just leaves learning ActionScript 3.
If you've any experience with other modern languages, that's not really an issue, but it has some peculiarities in it and seems overly verbose in places to me, but still, it's easy enough. Following the 'hello world' tutorial on the Flixel site gives a reasonable introduction to the basics, but doesn't explain a lot of things.
So, 48 hours after picking up Flixel I have a full game written in it. Yes, it is that easy to use.
I could embed it directly in the page, but I've always kinda been against that, so here's a link instead.
Space to shoot, cursors to move.
You'll have to excuse my pretty dreadful graphics, I was mostly just experimenting and seeing what I could manage. The backgrounds took less than 2 minutes each and the clouds were about the same. The ship is from a while back. The ghosts were just me yesterday morning going "what's an easy enemy to draw?"
Most of the code is taken from this tutorial, which I don't think anyone who doesn't know about resource allocation should follow. If you follow that tutorial to the letter, you'll end up with some nasty memory leaks because it doesn't reuse resources properly, it just leaves them hanging around in the background. Most notably are the bullets (which aren't destroyed, so any that miss enemies and fly off into the ether to the right of the screen will just go on forever), enemies (same issue going off the left of the screen) and explosions (creates and doesn't dispose 10 sprites every time something dies).
So, I changed it slightly so that my game destroys bullets off the right of the screen, enemies off the left and re-uses the same 10 explosions, seems to work well.
I also extended the tutorial to include my parallax background effect and moving clouds. There's nothing particularly spectacular in there, but it was something I was interested in working out.
Flixel is pretty well known in the Flash community, the main author is Adam "Atomic" Saltsman who wrote the game Canabalt (google it, you've almost certainly played it before).
So that was this weekend's Flash adventure. Was interesting and I've an idea for a Flash game I want to put into practice at some point using Flixel. Although it's a platformer so will require me learning a fair bit more about how it all works.
Because I've not been keeping to my game a month schedule, I'm going to mark this minor game as part of the project but not give it a number, I'll label it 'b'. 'a' will be the Unity game which I'll finish off and post shortly.
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-28
General update
I've been lazy this week and not done any work on Whirligig. Hence the lack of updates here.
What I have been doing is playing Merentha again. Which is a MUD (an early multiplayer RPG, generally with far more involved systems than more modern MMORPGs).
Used to play it all the time, but it gets a bit of a grind so I play on and off since it's free.
No pretty graphics, it's all text-based, but the base gameplay is unrivalled by MMORPGs imo.
Err, that's pretty much it. I won't get any work done this weekend since I'm in Scotland for a stag do (not mine!)
The only real bit of news on Whirligig I guess I've for is that I started the shop on Monday then thought I had a serious UI problem, so I played Merentha whilst I thought it over and realised I didn't have a problem. :oP
Just need to put UI components together, but as I've stated before I don't enjoy that aspect of coding at all.
What I have been doing is playing Merentha again. Which is a MUD (an early multiplayer RPG, generally with far more involved systems than more modern MMORPGs).
Used to play it all the time, but it gets a bit of a grind so I play on and off since it's free.
No pretty graphics, it's all text-based, but the base gameplay is unrivalled by MMORPGs imo.
Err, that's pretty much it. I won't get any work done this weekend since I'm in Scotland for a stag do (not mine!)
The only real bit of news on Whirligig I guess I've for is that I started the shop on Monday then thought I had a serious UI problem, so I played Merentha whilst I thought it over and realised I didn't have a problem. :oP
Just need to put UI components together, but as I've stated before I don't enjoy that aspect of coding at all.
2010-05-20
Quick UI taster
This is how far Whirligig has moved along:
As you can see, everything is labelled, the 'projectile', 'shell' and 'shot' types all have icons (although pretty crappy ones ;o)) Clicking on them opens a window like the shell type one shown, which is showing 'normal', 'bounce', 'double bounce', 'double split', 'triple split' and 'clusterbomb'.
A 'split time' counter has been added so you can see how that works.
Oh, and there's 3 players, which (as I think I stated) was possible back as far as the tech demo, I just used 2 players back then.
The window is busier than I'd like. I need to fit the number of shots/shells/projectiles on there yet, which will require some reshuffling. Also I've not implemented that part to the weapon-choice windows either. And still not started on the shop. Still, getting there slowly.
As you can see, everything is labelled, the 'projectile', 'shell' and 'shot' types all have icons (although pretty crappy ones ;o)) Clicking on them opens a window like the shell type one shown, which is showing 'normal', 'bounce', 'double bounce', 'double split', 'triple split' and 'clusterbomb'.
A 'split time' counter has been added so you can see how that works.
Oh, and there's 3 players, which (as I think I stated) was possible back as far as the tech demo, I just used 2 players back then.
The window is busier than I'd like. I need to fit the number of shots/shells/projectiles on there yet, which will require some reshuffling. Also I've not implemented that part to the weapon-choice windows either. And still not started on the shop. Still, getting there slowly.
Minor update
Not a lot to report really, all current work is pulling together UI parts. It's pretty boring stuff.
Have I mentioned I hate UI work? ;o)
Unfortunately most of the rest of this project is UI work now. The only bit that isn't really is the AI and level generator.
The level generator will just create 3 (or half the number of players, whichever is lower) planets and make sure they're spaced far enough apart then randomly locate the players making sure they're never closer than 90 degrees on a planet.
There may be some occasions on small planets where players get placed close together, but these should be rare(ish).
The AI I'm unsure how to do... I think I'll just have the projectile report back how close to an enemy the shot was and have the AI adjust from there. I could probably write in a load of simulation code that would make the AI dead smart, but I think a simple "how near am I?" setup will work well enough for the level of game I'm aiming at this. Were it a commercial product I'd bung in several AI levels, including a genius one that never missed. ;o)
Have I mentioned I hate UI work? ;o)
Unfortunately most of the rest of this project is UI work now. The only bit that isn't really is the AI and level generator.
The level generator will just create 3 (or half the number of players, whichever is lower) planets and make sure they're spaced far enough apart then randomly locate the players making sure they're never closer than 90 degrees on a planet.
There may be some occasions on small planets where players get placed close together, but these should be rare(ish).
The AI I'm unsure how to do... I think I'll just have the projectile report back how close to an enemy the shot was and have the AI adjust from there. I could probably write in a load of simulation code that would make the AI dead smart, but I think a simple "how near am I?" setup will work well enough for the level of game I'm aiming at this. Were it a commercial product I'd bung in several AI levels, including a genius one that never missed. ;o)
2010-05-18
Whirligig Update
Well I did write a fairly long post about this yesterday, but lost it, somehow.
Anyway, I took a small break over the weekend since I finished Hoshi early and yesterday I resumed Whirligig.
First thing I implemented was a shell type window to go along with the shot type window.
I should probably explain the shell/shot/projectile types at this point.
Projectile types determine the size of destruction (there's 4 sizes).
Shot types determine whether the projectile will split after it's fired and into how many subsequent projectiles (1-5). The length of time before splitting can also be set.
Shell types determine what the projectile does on impact. This is the most complex and consists of bouncing (once or twice) or splitting (2 or 3 times) or a clusterbomb which explodes at the impact point and fires 4 other shots off.
I now need to finish building the GUI for these (timing for split shots and projectile type need implementing) then put together a shop.
The shop is needed because you will start with a limited number of each projectile. The only thing you'll have inifinite of is normal/normal/normal. Although this can all be changed in the options.
Basic gameplay will consist of a series of rounds (1-20). The shop can be set to be available mid-round or only at the end of each round.
After the rounds various stats will be shown with a 'score' winner, a 'kills' winner and a 'rounds' winner.
I don't think that's as clear as my original post about all this, unfortunately. If you've any questions, leave them in the comments and I'll try and clarify. Or you can wait a few days and I'll post some screenshots hopefully. ;o)
Anyway, I took a small break over the weekend since I finished Hoshi early and yesterday I resumed Whirligig.
First thing I implemented was a shell type window to go along with the shot type window.
I should probably explain the shell/shot/projectile types at this point.
Projectile types determine the size of destruction (there's 4 sizes).
Shot types determine whether the projectile will split after it's fired and into how many subsequent projectiles (1-5). The length of time before splitting can also be set.
Shell types determine what the projectile does on impact. This is the most complex and consists of bouncing (once or twice) or splitting (2 or 3 times) or a clusterbomb which explodes at the impact point and fires 4 other shots off.
I now need to finish building the GUI for these (timing for split shots and projectile type need implementing) then put together a shop.
The shop is needed because you will start with a limited number of each projectile. The only thing you'll have inifinite of is normal/normal/normal. Although this can all be changed in the options.
Basic gameplay will consist of a series of rounds (1-20). The shop can be set to be available mid-round or only at the end of each round.
After the rounds various stats will be shown with a 'score' winner, a 'kills' winner and a 'rounds' winner.
I don't think that's as clear as my original post about all this, unfortunately. If you've any questions, leave them in the comments and I'll try and clarify. Or you can wait a few days and I'll post some screenshots hopefully. ;o)
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.
Discussion on future projects
Since I've effectively finished Hoshi now, which is effectively project 2 but will be the first released, I thought I'd better start looking at ideas for future projects.
I do have a fairly large accumulation of game ideas, but most are too big for a month project and are more in the 6 month to 2 year time frame which I'm best staying away from for now.
So, what will fit in a month? Well, I have a ideas for 2 platformers, but I lack the graphics and level design experience to manage these properly in a month. Both would (ideally) need level editors which would be a project in and of itself.
So, I'll be leaving these for now, but I'll come back to them.
So I've decided on two relatively boring concepts for projects three and four and I'll give you the reasoning for them:
Project three will be an arena shooter (player in the middle of a single room with a gun that can shoot in 8 directions with enemies approaching from every direction). I estimate this will take around 2 weeks to write the code, but the sprites will take a long while as I'm hopeless at pixel art, but the entire point of this project is to improve that aspect.
Project Four will be a single-room-platformer. Classic examples being Manic Miner or Jet Set Willy from the 8-bit era. Again I'm not expecting more than around 2 weeks to write the main code and another week for a level editor. Some artwork will be re-used from project 3 (I may make this a sequel of sorts). The primary goal of this project is to experiment in level design and see what I can learn.
So, there you have it, projects three and four. Estimated (but not solid) release dates will be mid-July for 3 and mid-August for 4.
I do have a fairly large accumulation of game ideas, but most are too big for a month project and are more in the 6 month to 2 year time frame which I'm best staying away from for now.
So, what will fit in a month? Well, I have a ideas for 2 platformers, but I lack the graphics and level design experience to manage these properly in a month. Both would (ideally) need level editors which would be a project in and of itself.
So, I'll be leaving these for now, but I'll come back to them.
So I've decided on two relatively boring concepts for projects three and four and I'll give you the reasoning for them:
Project three will be an arena shooter (player in the middle of a single room with a gun that can shoot in 8 directions with enemies approaching from every direction). I estimate this will take around 2 weeks to write the code, but the sprites will take a long while as I'm hopeless at pixel art, but the entire point of this project is to improve that aspect.
Project Four will be a single-room-platformer. Classic examples being Manic Miner or Jet Set Willy from the 8-bit era. Again I'm not expecting more than around 2 weeks to write the main code and another week for a level editor. Some artwork will be re-used from project 3 (I may make this a sequel of sorts). The primary goal of this project is to experiment in level design and see what I can learn.
So, there you have it, projects three and four. Estimated (but not solid) release dates will be mid-July for 3 and mid-August for 4.
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.
Subscribe to:
Posts (Atom)
