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!
Showing posts with label Nethack. Show all posts
Showing posts with label Nethack. Show all posts
Wednesday, 2 June 2010
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)

