Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Sowelu]

When I get home, I'll drop a link to the A* implementation I'm using for now.  It's C++, and it took me about a day to rework it to fit my game (different data structures, a Z-level, etc).  Really don't suggest anyone do that.  But it's good to look at!

(Writing your own pathfinder is always good practice, just make sure it follows a good algorithm.  And Dijkstra's algorithm is easier to get right than A*, while being exactly as good for most tasks.)

[Sergius]

Spoiler (click to show/hide)

This is absolutely the correct thread!  Programming is the main thing here, other stuff is secondary, I think.

As for splitting it up, the way that I'm doing it (and seen it done elsewhere) is, force yourself to split it up, by using abstract classes.

Create some "IO" abstract class (or interface or whatever your language has for this).  That class will call your game logic, and your game will call that IO class.  Figure out what functions need to be called.  You only need one 'Game' so you don't need to make that abstract.

Your game will probably need to expose a "What character/foreground/background colors are in this tile?" and possibly "What image is in this tile?", so the IO subclasses can choose which ones to call.  Any data that the IO is going to need, it needs to go through your Game class to obtain.

Also figure out how program flow is going to work.  In my case, my IO class actually RUNS the program...it instantiates the Game class.  I do it like that so that the IO has full control of the timer and stuff.

But in any case, for a pure roguelike, your Game is probably going to want to call functions on IO like:
- Create the window with optional height/width
- Redraw this tile (x,y)
- Redraw the whole screen
- Draw text on the header/footer/etc
- Delay for N milliseconds
- Get a key (waits for keypress, returns the key)

Keep in mind that for 'Get a key', you need to know what format to put it in.  If you use SDL, there's like three different ways that it numbers all the keys on the keyboard.  For a pure roguelike, it's probably quite enough to use a 'char' type.  For other games you need a way to encode the user pressing and releasing 'shift' and other weird stuff, but do yourself a favor and don't bother with that or the mouse yet!

ANYWAY, once that's done.  Your IO interface/abstract class/etc needs a pointer to your Game class, and your Game class needs a pointer to your IO.  Now just make a class like "SDL_IO" or "Curses_IO" that implements "IO"...and if you do it the way I did, put your 'static void main()' in Curses_IO, and have that function instantiate a Curses_IO and a Game, give them each others' pointers.  My game was kind of realtime and graphics, so I put my loop in my IO class.  You probably want to put your loop in Game.

A common flow of operations looks like:
- I'm in the Game class, looping...
- Loop just started.  Get a key from the user by calling io.GetKey()
- User pressed 'right arrow', which I've mapped to the char '6' for ease of use.
- There's no wall to the right, so move the user to the right!
- Tell the IO that it needs to redraw the player's old and new tiles.
- The IO says, "Okay, I'm drawing tile 6,6.  I'll ask the game what tile is at 6,6."
- The game responds "That's the character '@'."
- The IO draws an @ at 6,6.
- The IO does the same thing and draws an '.' at 7,6.
- The game loops!

It seems like kind of an extra step to say "Draw the tile at this location" and making the IO say "Okay, let me ask what tile that is".  But it makes a lot of sense because the game doesn't know if it wants graphics or ASCII, so IO needs to know what information to ask for.  Also, when you redraw the whole screen all at once, IO is going to have to ask for what's in every tile...

Thanks for the reply.

From what I see, in the example you're treating your data in Roguelike terms. Which is ok, I guess, but I would rather treat it in an agnostic way - like asking the "engine" (I'm not sure what you call the IO exactly, I'm assuming it's the User Interface part) what tile or character is in a tile. Shouldn't it be better to query simply for what one or more objects are in a coordinate, and let the UI decide for itself if it's going to use a '@' to draw it?

It's getting a bit more clear now... I think what I'd do, for example, is have a function in the engine that tells me what tiles are visible from my POV and probably return an array or expose said tiles to the "client" (I'm just calling the UI the 'client' and the engine the 'server' even tho it's not a networked app).

[Andir]

This is probably going off the deep end, but... The server could return just an ID for the tile type to the client, the client could interpret that ID any way it likes.  Be it a tree or statue.  (though getting wood from a statue would be a strange site so you'd have to have the server return an ID and quantity of the result and let the client figure out what it actually is...)  You could even write a client to pull assets based on the ID from a server so any time you updated a tile of model, it would query to see if it has the latest and stream it down... (I said off the deep end...)

I like brainstorming ideas and letting others pick good ideas out of them. :p

I've always liked the client server model though... and I wish DF would go to it.  Not necessarily for MP, but it would allow for many customizable clients and situations (playing remotely, etc.)  It could also be tailored to allow the server to spawn processes that connect to the server to control mobs, AI, and other things to give another method to "cluster" DF with a main server engine and sub-engines that could do multiple things or be spawned/despawned as needed.  If anyone messed with any of the old EQ Emulators, it would be kind of like the world server and zone servers, but the zone servers would be creature servers handling multiple creatures.  You could also have "zone" servers, but depending on the scale of your world, you could be talking thousands of zones.  Anyway, MMO server/clustering would definitely make for an epic roguelike way out of the scope of this thread I think.

... I warned you it was off the deep end.

[Rhodan]

I got a bit deeper into the libtcod library, and it's very impressive.
It takes most of the trickier graphics and system stuff out of your hands so you can just focus on the roguelike itself.
It has full colour support and various colourisation functions so you can do pretty lighting effects.  It also includes a pathfinding algorithm, line drawing algorithms, various LOS algorithms and plenty of noise functions.  It even has support for realtime games with framerate and everything, but you can also use this do do animations in your turn-based roguelike.  The string functions are also neat, allowing you to do automatic word-wrapping, coloured words inside a string and so on.
For some reason it also has a thingy that turns a .bmp image in a coloured ASCII rendition.  I guess that's nice for title screens and the like.

[Granite26]

The Magic of Interfaces:  When Friends fail.

What is a character?  A silly little mess of functions and variables.

So I've got a character.  The character needs to be associated with a lot of different parts of the application.  Specifically, it needs to be accessed by the game engine, the display engine(map), the display engine(character sheet), the control scheme,it's own classes, and the AI.

Each of these classes need to interact with the character in completely different ways.  The game engine needs to be able to manage attacks and moves.  The Map needs to get the current position and graphic of the character.  The character sheet needs to get a list of stats.  Etc.

I want to specify what each class is allowed to access.  This means that public access and friend access is not fine tuned enough.  What I really want is interfaces.

Declaring separate interfaces will allow me to create a character graphics interface to send to the graphics engine, a character sheet interface to the character sheet display and sub-classes, and an interaction interface to the game engine.

I do this by taking advantage of 'is-a' relationships and polymorphism.  For example, the character is-a(inherits) displayable object, and thus supports a full range of get image functionality.  (position, graphic, size, whatever).  I also say that the character is-a actor that itself inherits character sheet.  When the individual items need to get things from the character, they do it through the interfaces.  This cleans up what is available and makes sure that I don't access inappropriate bits of data.  (The display shouldn't be able to move the character, nor the character sheet deal damage)

This also innately supports different graphics modes, since a character that inherits the curses display class is functionally the same as one that inherits the sprite class, is the same that inherits the 3d class, in all ways except their display members.  This means that you can abstract the display completely in a clean way, while taking advantage of the same abstraction method for other purposes.

[Fualkner]

When it comes to classes, I really prefer freeform development. As an example, IVAN basically grows your character from your playstyle. If it were finished, with a proper magic system, it'd be a great example of this method. I figure that to balance the switching problems is to make the first few levels gain very quickly, and the stronger the enemy, the quicker the levels. That way, when you switch weapons late-game, it isn't a fantastic choice, but you should be able to get within a livable amount of skill quickly.

[Sergius]

I found an interesting article in Gamasutra about the MVC pattern and how it is applied to games (and one game in particular).

http://www.gamasutra.com/features/20050414/rouwe_01.shtml

These principles can just as well apply to a roguelike. Separation of view and (world) model is essential if you ever hope to port your game to a different user interface (let's say 3d and mouse driven). Or even if you need to switch from curses to SDL or even to a different ASCII library.

Apologies if this has been linked before.

[Rhodan]

So, like, I was thinking.  One of the defining parts of any roguelike is it's dungeon or map generator.  It shapes the world where the game will take place, and changes the way the game is played.  It's also really fun to code.
What bugs me is how most roguelikes have a pile of rooms with corridors in between.  There's no sense of structure.  Sometimes there's a spiffy vault or village or natural cave, and those always look good. 

I want my roguelike to have a dungeon that's actually a dungeon that used to be used for dungeoning.  Long corridors lined with doors, behind which are rooms filled with stuff, which might or might not be connected by secret passageways.  Perhaps a castle would be more interesting like this, wide hallways lined with various rooms, ranging from armouries to bedrooms to libraries to privvies, with locked gates blocking the hallway leaving you to search for keys or alternate exits.  The generator for such a dungeon would be pretty simple, but I think placing the challenges in the form of guards, locks and traps would make such a dungeon very interesting.

Any thoughts on this?  How would a map like this work and what would make it super-fun to play?

[Mondark]

So, like, I was thinking.  One of the defining parts of any roguelike is it's dungeon or map generator.  It shapes the world where the game will take place, and changes the way the game is played.  It's also really fun to code.
What bugs me is how most roguelikes have a pile of rooms with corridors in between.  There's no sense of structure.  Sometimes there's a spiffy vault or village or natural cave, and those always look good. 

I want my roguelike to have a dungeon that's actually a dungeon that used to be used for dungeoning.  Long corridors lined with doors, behind which are rooms filled with stuff, which might or might not be connected by secret passageways.  Perhaps a castle would be more interesting like this, wide hallways lined with various rooms, ranging from armouries to bedrooms to libraries to privvies, with locked gates blocking the hallway leaving you to search for keys or alternate exits.  The generator for such a dungeon would be pretty simple, but I think placing the challenges in the form of guards, locks and traps would make such a dungeon very interesting.

Any thoughts on this?  How would a map like this work and what would make it super-fun to play?

Hmmm, nifty.  I like this idea.  With a 'real' dungeon to work with, you could even set up the game such that, instead of trying to go down and back up, you could simply be trying to escape from the bottom of the dungeon, like in Legerdemain (I think.)

Something I've not seen in roguelikes is monsters, in this case guards, locking and unlocking doors.  (Maybe I've just not gotten far enough to meet them)  Having a guard running away from you and locking all the doors behind him could be pretty cool.  Especially if he was able to call up reinforcements to recapture you on the other side.  Instead of being killed right off, you might be thrown in another cell, retaining the stat gains you earned.  Though, after the third recapture or so, they'd probably just kill you.

[Rhodan]

I'm thinking of a quest where you explore a castle, do your stuff, and get the HFS back out.
The hallways would make for a simple layout that can still hide a lot of surprises.  Especially if some parts have been collapsed or infested or overgrown.  Hallways could also connect maps in a grid pattern, which makes more sense than just a tower made by people who haven't invented the stairwell yet.  Some larger rooms in logical spots can then break any remaining monotony. (giant ballroom, throneroom, treasury, great library, aviary with undead birds,...)

If you really want to have the player ascend or descend, just make the stairwell itself really interesting.  A big tower with a path along the inner edge, spiralling upwards.  Add some balconies or rooms stuck to the side of the tower and there ya go. A believable, interesting environment that's still plenty different each playthrough.
Now I just have to make that.  Yup, getting started anytime.

[Granite26]

Roguelike ideas that I'll never get around to making:

ParanoiaRL:  Unlike most roguelikes, this one takes place on a single large map with corridors.  You could, in theory, walk right up to the exit and win.  Unfortunately, you're a Red, and the exit is Ultra Violet, and Locked with an Ultra Violet Key.  Map making would start by drawing the UV layout, layering the Violet, Blue, etc. on top.  95% of the time, when corridors crossed, it would take the lower value (but not always).  If the random guys walking around find you with gear outside of your grade, or in a corridor or room out of your grade, they attack.  You (probably) die. 

Serving the computer will get you rank.  The computer asks you to do exceptionally random stuff.

Elemental Plane of Dungeon:  Your small town has been sucked through a rift.  It's farms and fields are gone.  People are starving.  The only answer is to descend into the cavern system to find food and supplies. 

Seriously.  Kinda like Ravenloft, only it's 'Dungeon' instead of 'Fear'.  Interesting features: 1: The metagame is that you aren't really playing the adventurer so much as the town.  Each 'adventurer' starts from scratch with low stats, but the health of the town, the training and EQ that's available to you, etc, is dependant on what previous adventurers have brought back.  2: The Dungeon : The ground under your feet is constantly shifting.  Coming back from a run, things may be different.  Alternately, you may wander back into a level that a previous character has been through (not that more monsters haven't moved back in and looted the corpse).  3: Stasis.  It may be possible to secure the first few levels, giving space for the town to grow food and open new shops and houses.  It may also be that certain subterrainian levels are stable enough to place outposts on.  4: Food.  You aren't likely to starve yourself, but the townspeople might.

[Fenrir]

Those ideas are awesome, Granite. The world needs more unique roguelikes.

[Sergius]

I like the idea of rewarding death (the permanent kind) in games such as roguelikes or MMORPGs, and I've toyed with it in a few design documents (rants) I made. Of course, death in a meaningful way or after you've collected a certain amount of skills. What you describe as "roleplaying a town" is more or less what I mean, and it could be applied to families/bloodlines for instance. The idea that you unlock new stuff, like skill cards, more creation points, but only can take advantage of said stuff as a "newborn" while retaining most of the progress of the previous character, and the possibility of recovering some of his best equipment somehow.

[JoshuaFH]

I don't know squat about programming, as I've said before, but I can't help but follow the progress of this thread.

[Rhodan]

I'm considering to make every race playable by killing it at least once.  Should be interesting to start as a rat or something; extreme dexterity, resistance to poison, sneaking bonus, intelligent, can pass grates,... Once you get your little paws on a ring of fireball you'd be in for a very interesting adventure.