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
2010-11-27
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):
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.
Subscribe to:
Posts (Atom)
