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