Print

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

[Granite26]

For combat complexity, I'm going to minimize what the player has available by a very strict changeable 3 tier class system (so a player will have a limited set of move options available at a time.  XP will be by class so it encourages you to change play styles as you level up.)

You're dead right on the weapon classes.  I'm using a string list for all weapon modifiers and move requirements.

I think I'm going to shoot for a 5% to 30% optimization benefit.  100% is just running into the monster, but with everything tweaked, you can get up to 30% extra power at high levels.

As far as the 3 tier, I've got about 100 classes I'd like to use, pick 3, change them as you level up, with classes becoming available by character level(Actually, this is a lie), class level(Knight reqs Squire), stat level(Strong Man reqs str), skill level(Blademaster), and quest(7ish martial arts classes each with a master to find).  Some of them are crazy specific (there's 5ish boat classes giving big bonuses on shipboard.)  I see it playing something like the DoomRL, only instead of skills, you unlock classes (which are really just lists of bonuses).

Example Class:
Flurry
1: +6 Attacks 2: +3 Attacks, 3: +1 Attacks : Buyables : +1 Attack X3

This looks powerful (+10 attacks in tier 1!) until you realize that you don't get any weapon skills, armor skills, special attacks, or other stat bonuses.  (What's scarier, a child slapping you 10 times, or a knight slashing you once)

Too many classes will be impossible to balance, but that's not critical in a 1p game.

[deadlycairn]

I'm a fan of 'personal weapon' skills in roguelikes. To discourage people swapping out their weapons whenever they find a slightly better one, have the player slowly get better with a weapon over time. Encourages the player to keep and look after his weapons - plus in my game, enchantments are harder to come by - you may be better off keeping your beginning weapon until you find something REALLY worth it.

[Alexhans]

I'm a fan of 'personal weapon' skills in roguelikes. To discourage people swapping out their weapons whenever they find a slightly better one, have the player slowly get better with a weapon over time. Encourages the player to keep and look after his weapons - plus in my game, enchantments are harder to come by - you may be better off keeping your beginning weapon until you find something REALLY worth it.

Yeah... like ADOM.  It makes it a much better experience.  Because otherwise it doesnt really matter wich weapon you have, but that you have one.  Its also more realistic.

[Sowelu]

I think deadlycairn didn't just mean "swords skill" but "this particular sword".  If you swap out your short sword for another short sword of the same material, you'd still lose some skill in the old one.  I'm lukewarm of the idea--It's kind of fun but it seems kind of limiting, and makes most of the equipment you see look like a waste of time.  Essentially, if you swing a weapon you don't plan to keep, you just wasted the skill points you COULD have gotten in a better weapon.

In ADOM, if you pick up a (+0,+0) random two handed club to use, well, heck, maybe someday you'll use another two handed weapon and get the bonuses from that.  But with personal skills, it's a total loss.

[deadlycairn]

Sowelu's right. Having a particular weapon (lets say a long sword), would train your blades skill, your large weapon skill, your sword skill and also your skill with that particular sword. Switch to, say, a small club, and all your training would be wasted. A battleaxe would get about half your bonuses, and a different long sword would get almost all your bonuses. You'd still be best however, with the long sword you'd been using for a while. (If anything ever sparks my brain into coding nirvana, I'm adding weapon damage/repair to encourage looking after your weapons even more. No more dipping your sword in unidentified substances!

[Rhodan]

Your "specific weapon" skill should train very, very rapidly.  After only a few battles you should be fully attuned to your new sword.
This makes the player try to hang on to the weapon he has while he's in a dangerous area, and when it's safe can consider picking up a new one that'll eventually be better than his current one.  Once he gets used to it.

This could also be translated into a "I just switched weapons" penalty, though players always prefer to have a seeminly positive bonus.

Weapon-based classes could then be better at switching weapons and stuff.  In the Middle Ages, knights went into battle with a variety of weapons each for specific circumstances, like stabbing through armor joints or in kidneys.
A similar penalty could be used for other classes, like switching elements while using magic, although switching arrows shouldn't make a difference.  This would give ranger classes interesting advantages.

[Darkone]

Just like to note to the python crew that rabbyt DOES support zoom functions Even a roguelike could benefit from this, as it isn't too hard to zoom out in map view.

[Granite26]

I'm going more into a 'encourage the player to use different weapons/skills because each one maxes out.' kind of feel.  To where playing as the knight for a few levels is good, but eventually you'll get to the point where switching to a barbarian (and using an axe) will give you new skills to buy that will be useful when you go back to knight. (or some other sword fighter class).  (say, the barbarian has a few +1 str skills you can get)

[Sowelu]

I REALLY, REALLY like the "train in multiple classes to get a bunch of stacking modifiers" mode of gameplay.  I don't know how to balance it, but I'm fully behind anyone who wants to try and make that fun. 

[The Moonlit Knight]

Well damn, this looks like an interesting thread.

I'm having a shot at developing a roguelike of my own, something along the lines of a little open-ended adventure centered around a small town in a post-apocalyptic world. I'm just barely learning how to use Python at the moment but I've at least reached the point where I know, in theory, how to do everything I intend to do; I just need to work on actually coding everything properly. I've got some interesting ideas for my game's design, at least. I think. I do have to work out some kind of end-game, though, which is sort of uh, important.

On the subject of combat skills, I like the idea of combining multiple fighting styles/classes into a more efficient whole, but the realistic part of me sort of nitpicks it. I can't imagine that a jack-of-all-trades of fighting would be equivalent to someone who's spent all their life training with one particular weapon in one particular style; what the general-use fighter gains in well-roundedness and perhaps in combining diverse methods, (s)he would lose the benefit of pure talent and skill in one field. But maybe on a game design level that doesn't matter; if it's fun to be a weaponmaster, then I sure as hell wouldn't stop it. I've always preferred the thematic feel of particular weapons, though. I love the point at which a weapon starts seeming to be an extension of a character, an icon, maybe with a name and identity all on its own. Of course, the weapon can only have that kind of significance if the character has significance, so I guess that'd be more suited for a game with the potential for story or character growth at the very least; less so for a dungeon crawl.

[deadlycairn]

There'll only be about three classes in mine, and they'll all be prett vague. More of a guideline than anything else. One is a weapon based one, one a magic based one and the other centres around the unique functions in the game (a venomist/alchemisty kinda thing). I DO NOT like games where wizards are forced to walk around with a staff with pale skin and low HP. Wizards can use swords too, you know!

[Sergius]

Ok, this is a programming question so I don't know if this is the right thread, but it's about making a roguelike.

I'm considering making a Rogue-like game, but I intend to separate the game-logic from the "rendering" part. Now, I think I'm a fairly good programmer but I have never done anything like this, so I don't know where to start.

One way I could approach this is to make it client-server and run both a server and a client in the same machine (even have the server pause the world until input is received to make it turn based), this would work ok if it ever becomes "multiplayer", except for the turn-based part... but let's ignore that for the moment as it may never happen and would need a lot of work to make it playable.

But from what I've seen this may be overkill. Just having a way to swap a tile-based and a Curses-based rendering engine would be fine, were it a DLL or whatever, or even recompiling the whole thing together. Later I'd toy with the idea to make a 3D frontend, but again that's not important now.

So, from all the stuff posted, sample code, open-source stuff you've seen, are there any good samples/tutorials/guides to do this? I'd probably want to program this thing in Java but the samples themselves could be in C# or C++ or something that's easy to read and well structured.

What I'm looking for is to know how I should organize my project, how a game loop would be for said project, etc, taking into account just that: how to make separate game logic (engine) and display logic (renderer).

[Sowelu]

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...

[qwertyuiopas]

Classes? we don't need no classes.

But if you go without classes, then you end up working with global functions, or more likely, two separate file groups, one for the game, and one for the drawing. The only shared #include files would contain the functions that need to be shared.

I personally keep a global array of what should show up on a particular part of the screen separate from the map itself, and have a function that translates a map tile into an update to the screen, and then I feed the screen stuff through openGL...

But then again, I am using C, and C does NOT have classes to begin with.

[Soulwynd]

C has structs which are similar to classes to a certain extend. They probably inspired the whole class idea. I prefer using a mix of both, there are things which global functions do better than silly classes. In my opinion of course.

I should upload the source code for my pathfinding algorithm, I'm sure you guys could make use of it.