A few people (hi, /r/roguelikes!) have asked if I'd share my roguelike source code, or at least some of it. As a Flash dev I know I'd be really excited to see how other Flash devs are handling roguelike development, so I figured it's only fair to get mine out there. I'm hoping some gurus out there will tell me if I'm doing this wrong, and point me in the right direction, it's all a learning process!
OK, so anyway, the first thing I'm posting is a highly simplified version of my room generation code, that shows a random single room being built, and a character dropped on to a valid random square. I've also stuck it on an external Pastebin link rather than an embedded one, as this code has long descriptive comments on that freak out a bit when they're stuffed into a thin blog format.
Feedback would be appreciated!
http://pastebin.com/BBPpGPBz
Tuesday, 29 June 2010
Thursday, 10 June 2010
The Google analytics Flash API and me
OK, so I'm a little late to the party with this one (about two years too late), but whatever: the Google analytics API for Flash is completely awesome.
Actually, there's not much more I can add. It's a breeze to use, well-documented, and basically saves the world (like pretty much everything the folks at Google magically conjure). I particularly like the fact that the API can be used in such a way that no external Javascript is needed, so tracking Flash that's placed on third-party sites still works like a charm. Of course, you can still old-school it and use ga.js if you've already got it set up on your page.
It comes in component form for both Flash and Flex, or a straight-up bunch of classes wrapped in a .swc file for those of us who'd rather get stuck into coding (and have a seething hatred of unnecessary components!). The built-in debug panel is a lifesaver too, when enabled it blocks all traffic to the analytics servers so any testing won't affect the stats. Mega useful.
At the moment it's only for online stuff (which is perfectly reasonable) but there's talk of it being adapted for none-browser use too, which will be handy for tracking AIR applications and offline project distributions.
Google certainly covered all the bases anyway. Get it here, and read about it here. I'd post a code sample, but it's so easy to use I think the documentation will suffice in this case.
Thanks again, Google nerds! Where would we be without you?
Actually, there's not much more I can add. It's a breeze to use, well-documented, and basically saves the world (like pretty much everything the folks at Google magically conjure). I particularly like the fact that the API can be used in such a way that no external Javascript is needed, so tracking Flash that's placed on third-party sites still works like a charm. Of course, you can still old-school it and use ga.js if you've already got it set up on your page.
It comes in component form for both Flash and Flex, or a straight-up bunch of classes wrapped in a .swc file for those of us who'd rather get stuck into coding (and have a seething hatred of unnecessary components!). The built-in debug panel is a lifesaver too, when enabled it blocks all traffic to the analytics servers so any testing won't affect the stats. Mega useful.
At the moment it's only for online stuff (which is perfectly reasonable) but there's talk of it being adapted for none-browser use too, which will be handy for tracking AIR applications and offline project distributions.
Google certainly covered all the bases anyway. Get it here, and read about it here. I'd post a code sample, but it's so easy to use I think the documentation will suffice in this case.
Thanks again, Google nerds! Where would we be without you?
Sunday, 6 June 2010
Portfolio progress
Well, my new portfolio is taking shape finally (it's only taken me a year or so to get going on it, you can't rush these things!)
It's a PV3D-powered extravaganza, or at least it will be when I start going nuts with it. Currently it looks like this, early days yet though:
The full version can be viewed here, but it might behave strangely if I'm still screwing with it, so don't judge the quality of it just yet!
Anyway, the 3D panels are looking good, the next stage is to get some information popping over the top of each panel when the mouse rolls over. The idea is to have two coloured panels floating just in front of the one you've rolled over, so you'll be able to see the project title and the category of work (I'm going to be including none-project work on here too, stuff like any experiments or cool stuff I've been screwing with).
When you click a panel, the rest will drop/animate off the screen, and some additional images and text will pop up. I think I'll tone down the rotation on the whole thing so I can have the text in 3D space, so it stays readable.
There'll also be Twitter and blog representations on the site too, which will hopefully pull in live feeds and do something snappy with them visually (while of course linking to the actual pages in case people don't want to be forced to read stuff on my site).
Anyway, that's where I'm at. All I need now is some time to work on the damn thing! :D
It's a PV3D-powered extravaganza, or at least it will be when I start going nuts with it. Currently it looks like this, early days yet though:
The full version can be viewed here, but it might behave strangely if I'm still screwing with it, so don't judge the quality of it just yet!
Anyway, the 3D panels are looking good, the next stage is to get some information popping over the top of each panel when the mouse rolls over. The idea is to have two coloured panels floating just in front of the one you've rolled over, so you'll be able to see the project title and the category of work (I'm going to be including none-project work on here too, stuff like any experiments or cool stuff I've been screwing with).
When you click a panel, the rest will drop/animate off the screen, and some additional images and text will pop up. I think I'll tone down the rotation on the whole thing so I can have the text in 3D space, so it stays readable.
There'll also be Twitter and blog representations on the site too, which will hopefully pull in live feeds and do something snappy with them visually (while of course linking to the actual pages in case people don't want to be forced to read stuff on my site).
Anyway, that's where I'm at. All I need now is some time to work on the damn thing! :D
Wednesday, 2 June 2010
Roguelike, part 2: Random rooms
OK, so things are taking shape! I figured that a great starting point for this would be getting single room instances working first, which is what I've managed to get done.
I went for an array-based grid idea, based on this tutorial. Getting a hard-coded room was easy enough to do, all I needed to do was loop through each row vertically and then sub loop horizontally, testing for the numbers that apply to each tile type (currently only "wall", "floor" and blank tiles for use in gaps). This hard-coded approach (combined with Nethack tiles) gave me this:
This looks great and all, but it wouldn't be a rougelike without some serious randomness at work. Luckily it was pretty simple to create a suitable array. In fact, generating the level was more challenging in terms of me visualising it in my head, than actually coding it. I'd originally thought along the lines of randomly generating the top-left and bottom-right tiles, then drawing the room between them, but this was really difficult straight away. Not only that, but it would have meant that I would have much less control over individual tiles (more on why this is important later). Anyway, as with most things, the best answer (that I know of so far) was the simplest one: generate a random room width and height, and go from there.
That makes it sound so simple, in reality it's *slightly* more complicated but still not too scary:
- Create a whole row of wall tiles for the top row (set to our random width)
- Create a bunch of middle rows (going downwards vertically), each with a wall tile at either end
- Create another whole row of wall tiles and add it to the bottom of the stack, to close the room
Like so:
Once this was done, the array could be passed into my tiling system and whammo: one random room.
Looking at the code, I think I could automate it even further, but as it stands at the moment this double-loop system means I have access to every single tile in order as it's created. Why is this important? Because the next stage is to add doors/stairs/obstacles to my rooms, and for that I need to know exactly where I can and can't add stuff.
Oh, and the player avatar is randomly placed too, and is added on the basis of what tile type it's been spawned above (for example, the player will never spawn on a wall tile). However I don't think I'm doing it entirely correctly, and need a much more robust system of creating and spawning objects, which is a whole different post entirely (not to mention a long way off from where I'm at now!)
I'm sure that any hardcore roguelike devs reading this will be laughing at the simplicity of what I've achieved so far, but at the moment these concepts are all pretty new to me, so personally I'm glad it's taking shape so quickly... I'm sure I'll be tearing my hair out further down the line, but at the moment it's looking good.
The next step will be to create entire dungeon floors: first I want a couple of non-overlapping rooms spawned each time, and then a corridor system to link the rooms up (which I'm sure will be a nightmare to write, or so I've been told). After that will be basic character movement, then I'll add stairs so the basic structure of the dungeon will be complete before I start going completely mental with monsters and items and stuff.
If anyone has anything to add (i.e. if I'm doing it all wrong) then I would love to hear it, next time I'll be posting actual code too.
The quest continues!
I went for an array-based grid idea, based on this tutorial. Getting a hard-coded room was easy enough to do, all I needed to do was loop through each row vertically and then sub loop horizontally, testing for the numbers that apply to each tile type (currently only "wall", "floor" and blank tiles for use in gaps). This hard-coded approach (combined with Nethack tiles) gave me this:
This looks great and all, but it wouldn't be a rougelike without some serious randomness at work. Luckily it was pretty simple to create a suitable array. In fact, generating the level was more challenging in terms of me visualising it in my head, than actually coding it. I'd originally thought along the lines of randomly generating the top-left and bottom-right tiles, then drawing the room between them, but this was really difficult straight away. Not only that, but it would have meant that I would have much less control over individual tiles (more on why this is important later). Anyway, as with most things, the best answer (that I know of so far) was the simplest one: generate a random room width and height, and go from there.
That makes it sound so simple, in reality it's *slightly* more complicated but still not too scary:
- Create a whole row of wall tiles for the top row (set to our random width)
- Create a bunch of middle rows (going downwards vertically), each with a wall tile at either end
- Create another whole row of wall tiles and add it to the bottom of the stack, to close the room
Like so:
Once this was done, the array could be passed into my tiling system and whammo: one random room.
Looking at the code, I think I could automate it even further, but as it stands at the moment this double-loop system means I have access to every single tile in order as it's created. Why is this important? Because the next stage is to add doors/stairs/obstacles to my rooms, and for that I need to know exactly where I can and can't add stuff.
Oh, and the player avatar is randomly placed too, and is added on the basis of what tile type it's been spawned above (for example, the player will never spawn on a wall tile). However I don't think I'm doing it entirely correctly, and need a much more robust system of creating and spawning objects, which is a whole different post entirely (not to mention a long way off from where I'm at now!)
I'm sure that any hardcore roguelike devs reading this will be laughing at the simplicity of what I've achieved so far, but at the moment these concepts are all pretty new to me, so personally I'm glad it's taking shape so quickly... I'm sure I'll be tearing my hair out further down the line, but at the moment it's looking good.
The next step will be to create entire dungeon floors: first I want a couple of non-overlapping rooms spawned each time, and then a corridor system to link the rooms up (which I'm sure will be a nightmare to write, or so I've been told). After that will be basic character movement, then I'll add stairs so the basic structure of the dungeon will be complete before I start going completely mental with monsters and items and stuff.
If anyone has anything to add (i.e. if I'm doing it all wrong) then I would love to hear it, next time I'll be posting actual code too.
The quest continues!
Tuesday, 1 June 2010
Making a roguelike, Part 1
I read a great thread on Reddit the other day, asking what exercises an amateur programmer can do to get better at whatever language they're trying to learn. There were some great suggestions (notably Coding Kata, but that's another blog post entirely), but interestingly the highest voted one was "make a rougelike". If you're not familiar with what a roguelike is, check this explanation out before continuing... these games are as geeky as they come, but are some of my favourite games ever (look Mum, no graphics!)
My inital reaction to the suggestion was dismissive, given that roguelike games are usually so mind-bogglingly complicated most players (myself included) haven't even gotten close to the end of one despite years of play. However, I thought some more about it and realised that it's actually a brilliant idea. Think about it for a second, the features of an average roguelike are:
- Mimimal graphics, or no graphics at all (mine will use graphical tiles)
- Randomly generated levels
- Randomly generated monsters/items etc
- Stats, lots of stats.
The structure of a roguelike lends itself perfectly to an OOP project; creating lots and lots of small elements to form a huge, randomly-generated game. So, I'm having a crack at it. I must say at this point that I am using this purely as a learning exercise: I don't intend to try and produce a finished game, nor do I intend to write any stories or any of that crap (leave it to the professionals, I say). What I do want to do is get my head around all of the ideas and concepts that make up a great rougelike, and try and build them.
Who knows, if it works well enough then I might throw it out to someone else to populate it with characters and stuff, but at the moment I'm looking at it purely from a 'technical challenge' standpoint.
The big thing I'm finding interesting right now is getting randomly generated levels working, which is the first thing I've got stuck into. I'm going to put together a proper detailed post about each element I build, as well as how the whole project is taking shape.
For now, here's some of the stuff I've been checking out:
- Brilliant and detailed tile tutorial, slightly outdated (AS2) but super useful
- Tilesets archive from some of the more popular roguelikes
- Nethack, my favourite roguelike ever. It's for research, honest.
Basically, this project is about learning some new stuff (and it's working already!), in the most fun and geeky way possible. Much more later! :D
My inital reaction to the suggestion was dismissive, given that roguelike games are usually so mind-bogglingly complicated most players (myself included) haven't even gotten close to the end of one despite years of play. However, I thought some more about it and realised that it's actually a brilliant idea. Think about it for a second, the features of an average roguelike are:
- Mimimal graphics, or no graphics at all (mine will use graphical tiles)
- Randomly generated levels
- Randomly generated monsters/items etc
- Stats, lots of stats.
The structure of a roguelike lends itself perfectly to an OOP project; creating lots and lots of small elements to form a huge, randomly-generated game. So, I'm having a crack at it. I must say at this point that I am using this purely as a learning exercise: I don't intend to try and produce a finished game, nor do I intend to write any stories or any of that crap (leave it to the professionals, I say). What I do want to do is get my head around all of the ideas and concepts that make up a great rougelike, and try and build them.
Who knows, if it works well enough then I might throw it out to someone else to populate it with characters and stuff, but at the moment I'm looking at it purely from a 'technical challenge' standpoint.
The big thing I'm finding interesting right now is getting randomly generated levels working, which is the first thing I've got stuck into. I'm going to put together a proper detailed post about each element I build, as well as how the whole project is taking shape.
For now, here's some of the stuff I've been checking out:
- Brilliant and detailed tile tutorial, slightly outdated (AS2) but super useful
- Tilesets archive from some of the more popular roguelikes
- Nethack, my favourite roguelike ever. It's for research, honest.
Basically, this project is about learning some new stuff (and it's working already!), in the most fun and geeky way possible. Much more later! :D
Subscribe to:
Posts (Atom)