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.
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-11-27
Rss, Feedburner, etc.
I think I had an RSS feed already, but I'm adding feedburner as well, this is mostly a test post to check it.
I've also added a "Subscribe To" gadget thing to make the feeds easier to find (assuming they were there at all before).
Anyway: as to coding, I've moved to a new computer and I'm still setting it up exactly how I want and testing all my old games out on the new(er) card in there. So not been up to much code as a result. :oD
I've also added a "Subscribe To" gadget thing to make the feeds easier to find (assuming they were there at all before).
Anyway: as to coding, I've moved to a new computer and I'm still setting it up exactly how I want and testing all my old games out on the new(er) card in there. So not been up to much code as a result. :oD
2010-11-19
More Flash stuff
Been mucking about with Flixel more. As I stated in my last post talking about Flash and Flixel, I have a game idea that involves platforming that will work well in Flash. So I've set about learning how to write a platformer in Flixel.
Most of this I've taught myself, although I've pulled segments from this tutorial. Unfortunately the FlxCamera class seems to have gone missing, but I cheated my way around that. I'll go looking for it properly at some point.
I've drawn a complete set of tiled sprites myself for level building (they're very basic and just for mucking about with really, not pretty) and a short 4-frame animation for a guy running.
I used mappy for drawing the maps. It's fairly easy to use as I had problems using the editor suggested in the tutorial above. However mappy doesn't output map files suitable for Flixel (it has its own simplistic format for reading map tiles) but it does output in csv (comma separated values) format, which is very easy to read and port to Flixel's format. So I quickly wrote a C# application to do that.
Putting all this together resulted in a pretty basic platformer. I added a second 'layer' over the level that is used for checking for collectables, placing the entrance and checking for the exit. I have a feeling the way I'm doing this isn't very efficient in terms of Flash as I seem to be getting some minor framedrop, but it's a method that would perform fantastically under pretty much any other platform. There's a few ways around it. Thankfully it won't be an issue with the game idea I'm thinking of as the levels will be randomly generated.
Anyway, feel free to play around with Project C
I've not put any start or end stuff into this game. All it does when you complete it is shake the screen whilst you're stood over the exit. The idea is to pick up all 3 gems then head to the exit. The exit remains with a red light over it until all 3 are picked up. Simple stuff but as I say, it's all a test so not really 'complete'.
Most of this I've taught myself, although I've pulled segments from this tutorial. Unfortunately the FlxCamera class seems to have gone missing, but I cheated my way around that. I'll go looking for it properly at some point.
I've drawn a complete set of tiled sprites myself for level building (they're very basic and just for mucking about with really, not pretty) and a short 4-frame animation for a guy running.
I used mappy for drawing the maps. It's fairly easy to use as I had problems using the editor suggested in the tutorial above. However mappy doesn't output map files suitable for Flixel (it has its own simplistic format for reading map tiles) but it does output in csv (comma separated values) format, which is very easy to read and port to Flixel's format. So I quickly wrote a C# application to do that.
Putting all this together resulted in a pretty basic platformer. I added a second 'layer' over the level that is used for checking for collectables, placing the entrance and checking for the exit. I have a feeling the way I'm doing this isn't very efficient in terms of Flash as I seem to be getting some minor framedrop, but it's a method that would perform fantastically under pretty much any other platform. There's a few ways around it. Thankfully it won't be an issue with the game idea I'm thinking of as the levels will be randomly generated.
Anyway, feel free to play around with Project C
I've not put any start or end stuff into this game. All it does when you complete it is shake the screen whilst you're stood over the exit. The idea is to pick up all 3 gems then head to the exit. The exit remains with a red light over it until all 3 are picked up. Simple stuff but as I say, it's all a test so not really 'complete'.
2010-11-14
And moving on to Unity.
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.
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.
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-09-25
Voxels
Yeah, yeah, I know, not really getting anywhere with the games. S'bad, but I'll get back to it.
I've been writing a voxel editor recently.
Voxel's aren't an easily concept to explain, although they're a simple concept to understand. In essence a voxel is a 3D pixel. That is a standard bitmap you create in paint is made up of pixels along the x and y dimensions, voxels add a z dimension allowing for easy 3D rendering.
So, I've written a (currently) simple editor for building voxel art with the intention of using it in my future games.
Right now the editor isn't much use for more than simple voxelart. I've been test-driving the editor for most of today and know there's about half a dozen features that need adding to its toolbox.
So, without further ado, this is what I managed yesterday:
For those not in the know, it's called a Menger Sponge which is a fairly basic cube fractal. This is taken to the 3rd iteration and contains 8000 cubes of which I clicked every bloody one (and don't I know it!)
So, will be adding some basic things like copy and paste, colour fill and keyboard shortcuts.
Also need to compress the voxel save files as a 27x27x27 image such as this one clocks in at 9.5MB.
At that point I'll make a simple video explaining more about the editor and if people are very lucky I might release it.
So what is the point in all this? Well it's to develop an art style for projects 3 and 4. Hoping having some artwork to play with will motivate me to make a move on them.
I also might have a try at doing some simple pure-animation using some voxels, will see how the games go first though.
I've been writing a voxel editor recently.
Voxel's aren't an easily concept to explain, although they're a simple concept to understand. In essence a voxel is a 3D pixel. That is a standard bitmap you create in paint is made up of pixels along the x and y dimensions, voxels add a z dimension allowing for easy 3D rendering.
So, I've written a (currently) simple editor for building voxel art with the intention of using it in my future games.
Right now the editor isn't much use for more than simple voxelart. I've been test-driving the editor for most of today and know there's about half a dozen features that need adding to its toolbox.
So, without further ado, this is what I managed yesterday:
For those not in the know, it's called a Menger Sponge which is a fairly basic cube fractal. This is taken to the 3rd iteration and contains 8000 cubes of which I clicked every bloody one (and don't I know it!)
So, will be adding some basic things like copy and paste, colour fill and keyboard shortcuts.
Also need to compress the voxel save files as a 27x27x27 image such as this one clocks in at 9.5MB.
At that point I'll make a simple video explaining more about the editor and if people are very lucky I might release it.
So what is the point in all this? Well it's to develop an art style for projects 3 and 4. Hoping having some artwork to play with will motivate me to make a move on them.
I also might have a try at doing some simple pure-animation using some voxels, will see how the games go first though.
2010-08-22
Err, yeah, hi
I do still exist. The Game-a-month project is still on my list of things to do, I'm just having a bit of a hiatus.
This is, of course, not particularly good, but it's where I'm at for the moment so it's happening.
I've spent most of the last two months not coding, so, not a lot to say here.
However recently I've picked up an idea for comparing track rollercoasters on Audiosurf that someone was interested in a while back.
The original thread is on the Audiosurf forums here and is basically asking for an easy way to sort tracks by the amount of traffic they have.
Retrieving traffic information involves digging through a .ash file locally or asking the servers for it. I've not done any experimenting in pulling that data from the Audiosurf servers yet, however I already had the code for retrieving the track shape, which is a good indication of the traffic a track will have and the speed it will run at.
So, in a few hours I put together a very quick program to pull the track shape (and global scores) for a named track. Very easy to do, and the result is posted in the thread mentioned.
But that doesn't technically compare the tracks, or order them or anything, it just allows for quickly viewing multiple songs outside of Audiosurf. Useful, but not ideal.
For a long while I left the application there, then I picked it up again a week or so ago and began work on a 'playlist' section of the application. This downloads a track shape for every song in a playlist with the eventual idea being that it will show an estimate for how 'quick' the track will be, allow sorting and re-tagging of [as-steep] to slower tracks.
It quickly became obvious once I had the "download lots of track shapes" code implemented that the Audiosurf server is struggling to stay up at the moment (indeed, whilst making the screenshots below, I had significant issues with the Audiosurf server timing out, even for single-song lookups). This is noticeable if you use the forums much and/or play the game a lot as the forum, scoreboards and logging in are often down. Obviously I don't want to make this workload any worse, so I've implemented a cache for the track shapes that stores this data locally as presumably a track shape shouldn't change unless the picked user is cheating.
To avoid accidentally pulling out cheaters, the app always goes for the last global score of the 'Elite' category, if there's no elite scores it goes for the last of the pro, then last of the casual. The assumption being that a cheater will hold the top spot and not be lower down on the scoreboard. Additionally the "single song" searcher that was initially implemented (and will be launchable from the playlist window) will allow you to store which rollercoaster you want to see locally.
Possibly will take it as far as YAAP (Yet Another Audiosurf Player) with tagging features, etc, not decided yet.
Oh, have an example image that's rather sparse. Much will be added, hopefully (click to view full size):
This is, of course, not particularly good, but it's where I'm at for the moment so it's happening.
I've spent most of the last two months not coding, so, not a lot to say here.
However recently I've picked up an idea for comparing track rollercoasters on Audiosurf that someone was interested in a while back.
The original thread is on the Audiosurf forums here and is basically asking for an easy way to sort tracks by the amount of traffic they have.
Retrieving traffic information involves digging through a .ash file locally or asking the servers for it. I've not done any experimenting in pulling that data from the Audiosurf servers yet, however I already had the code for retrieving the track shape, which is a good indication of the traffic a track will have and the speed it will run at.
So, in a few hours I put together a very quick program to pull the track shape (and global scores) for a named track. Very easy to do, and the result is posted in the thread mentioned.
But that doesn't technically compare the tracks, or order them or anything, it just allows for quickly viewing multiple songs outside of Audiosurf. Useful, but not ideal.
For a long while I left the application there, then I picked it up again a week or so ago and began work on a 'playlist' section of the application. This downloads a track shape for every song in a playlist with the eventual idea being that it will show an estimate for how 'quick' the track will be, allow sorting and re-tagging of [as-steep] to slower tracks.
It quickly became obvious once I had the "download lots of track shapes" code implemented that the Audiosurf server is struggling to stay up at the moment (indeed, whilst making the screenshots below, I had significant issues with the Audiosurf server timing out, even for single-song lookups). This is noticeable if you use the forums much and/or play the game a lot as the forum, scoreboards and logging in are often down. Obviously I don't want to make this workload any worse, so I've implemented a cache for the track shapes that stores this data locally as presumably a track shape shouldn't change unless the picked user is cheating.
To avoid accidentally pulling out cheaters, the app always goes for the last global score of the 'Elite' category, if there's no elite scores it goes for the last of the pro, then last of the casual. The assumption being that a cheater will hold the top spot and not be lower down on the scoreboard. Additionally the "single song" searcher that was initially implemented (and will be launchable from the playlist window) will allow you to store which rollercoaster you want to see locally.
Possibly will take it as far as YAAP (Yet Another Audiosurf Player) with tagging features, etc, not decided yet.
Oh, have an example image that's rather sparse. Much will be added, hopefully (click to view full size):
Subscribe to:
Posts (Atom)
