Print

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

[Alexhans]

I'd recommend a good OOP programming book

[Rhodan]

Roguelikes can get very, very complicated when it comes to classes.  Since roguelikes are all about interacting with objects in various way, setting up a solid system for this is Hardcore OOP to the X-Treme.

I suggest keeping it simple, with a class for cells, levels, monsters, items and the player.
Then the world would be an array of levels, each level containing a list of monsters, items and cells.
Each monster, item and cell contains a list of items.  Now you can move the items between lists and have stuff interact.  Once your character can move down 10 levels, up 10 levels and get killed in between, you can begin to worry about more advanced code.

Stuff like monster types, cell types and item types is not really necessary to  be put in their own child classes, your first roguelike should be simple and functional.  You can worry about fun and streamlined programming on your next attempt.

I think it's important to have as much fun as possible when programming your first game, so don't set up extensive frameworks where you'll debug for hours without seeing any result.  Program quick, program dirty, get fast results that you can see and test immediately.  Once you get familiar with programming, you can begin to learn writing cleaner code.

[Alexhans]

yep... but you must have a general design because quick and dirty may make your code hard to understand if you leave it untouched for a while...

adding traits as you go is fun... but having a general idea of the features you'll implement makes it easier when you finally do because you'll have the tools and space to do so...

[Singularity]

Sorry, guess I should have been more specific.  Where I am right now, I currently have 3 "entities": the player, a blank floor, and a wall.  Currently only the player is an actual class.  The floor and wall are just simple '#' or '.' chars in my Level's char array.  I'm looking to clean that up and add a Tile class in soon enough.  However, first I would like to come up with a more concrete class structure.  Here are some plans I had in mind:

1. I want all my entities like creatures, items and so on to inherit from Entity because there are some characteristics that they can all share -- currently name, x and y positions, and even HP, if I decide to make terrain destructible.

2. I also want them all derived from Entity to make it easier to cycle through them all for rendering, updating, etc.

3. I definitely DON'T want things like a new subclass for each type of enemy.  No Dog, Gnome, or Lizard classes if at all possible.

4. However I DO want to be able to give entities different capabilities on an instance-basis.  (e.g. the player will be an entity like all the rest, however his Update() method will check for keyboard input instead of using AI.)  But how exactly would I go about doing this? I considered function pointers, but really I'm rather new to pointers in general, coming from C#.  A little help would be nice.

5. Finally, I'm looking for some sort of way to easily store the hard data I'll need to build my entities.  I'll eventually move it out to data files, but for now I'm going to hardcode it.  I'm currently looking into structs to hold the data, but again I'm not quite sure how to use them properly.

Thanks again for all your help so far, I really appreciate it.

[Andir]

You're halfway there... just decide what each level of inheritance does what.

(this is not concrete, just a brainstorm)

Entity
---------
x, y, z, hp, inventory (yes, even a tile can hold something...like the player, a tree, etc.)

Mover : Entity
---------
pathing?, move(Vector(x,y,z))? (Vector could be a simple (x, y, z) offset passed by the input or AI method [thread safe?])

Creature : Mover
---------
body Parts?  (things common to the player and enemy)

Player : Creature
---------
keyboard scanning, line of sight (maybe on creature?  depends on game)

There are literally a hundred ways these could be re-arranged and laid out, you just have to sit down and think about what each level of "identification" you need in the hierarchy.  If you remember anything from science classes about species classification, this is kind of the same thing.  Find a common reference between all the objects in your game and break them out.  List all the things you can think of (no matter how crazy) then list out what each of them can do.  When you have commonality (like moving, coordinates, hitpoints, etc.) between two objects, make that into a parent class.  Draw out a tree if you need to.  Keep inheritance and parent/child relationships separate ideas.  I know I always manage to intermix these at times and I don't know why.   

As far as data, keep it internal for now, but plan for future export if you know you might do that.  Create a class to handle data... Come up with a standard method to get your data from the store.  A simple get(category, key) or set(category, key, value) will work.  Create a datastore "interface" (Interfaces are a C++ construct, this isn't what I'm talking about) class and use it to save the data.  If you feel daring, this "interface" could even be setup like a template class (C# Generics.)  When you declare/define the datastore, tell it what type it is [new DataStore(new FileStore(filename))].  Let it handle files/containers/arrays and expose a common interface to your program that you defined above (get/set).  This way if you ever want to change from a file to a remote store or internal data, you just pass it a different class that emulates the FileStore when it's defined.  The rest of the program doesn't need to know that you changed it then.

You can handle data in structs, but I'd actually tell you to do it with serialization like method of sorts, but this is in no means the best, easiest, or only way to do it.  Plan on each savable object to return a dataset in a standardized form so you can call that method when you save (like xml/json/self defined binary format/etc.)  Imagine being able to save() and load() your world with one line... mydata::save(myWorld.serialize()); myWorld.deserialize(mydata::load()); and having your world create a collection of data that represents itself in a storage format.  During it's data compilation it will loop through it's inventory (all the tiles) and request that they serialize their data and children.  It should recurs up the tree and return you a single entity of data to save.  Keep this to a bare minimum of data needed to load the world to a point where the player will recognize it.  For instance, if you can regen a region with a random seed, store that instead of the raw data.  Then just regenerate it when it's reloaded (given that it doesn't change.)

Some of these ideas will work, some of them will be horrible for your plan.  It's just so hard to give someone direction in programming because there are a million ways to do it.  Any way you look at it, if you want this to be a success, you'll most likely want to spend some time with a pen and paper before you start coding and end up throwing it all out.  If you haven't read a book on proper OO techniques (separation of data, etc.) you should probably look into it.  You can get a lot of free books online.  One I remember being pretty good was "Code Complete" and I think you can find it for free (or in a library?) or you can buy it from any bookstore.  It's fairly language agnostic so there aren't a lot of samples but it covered concepts well.

[Mondark]

4. However I DO want to be able to give entities different capabilities on an instance-basis.  (e.g. the player will be an entity like all the rest, however his Update() method will check for keyboard input instead of using AI.)  But how exactly would I go about doing this? I considered function pointers, but really I'm rather new to pointers in general, coming from C#.  A little help would be nice.

Not being a C/C++ programmer, I can't help you with all that function pointer weirdness, but I do recall a 'design pattern' that may be of some use in your situation.

It's called the 'Strategy Pattern', IIRC, and basically you give each Entity an object called something like 'UpdateStrategy', which has the method that does the actual updating of the object.  So Entity's update method delegates all the work to its strategy object.  Then you just subclass UpdateStrategy into something that looks for keyboard input and give that 'customized' UpdateStrategy to your players object.  Other Entities can be given their own UpdateStrategies as necessary.

That makes it easy to swap out different behaviors for different objects/entities on the run.  I've not actually done this yet, but thought it might be kind of cool to use that kind of system to implement some kind of 'mind-swapping/control' in a roguelike sometime.

[Andir]

4. However I DO want to be able to give entities different capabilities on an instance-basis.  (e.g. the player will be an entity like all the rest, however his Update() method will check for keyboard input instead of using AI.)  But how exactly would I go about doing this? I considered function pointers, but really I'm rather new to pointers in general, coming from C#.  A little help would be nice.

Not being a C/C++ programmer, I can't help you with all that function pointer weirdness, but I do recall a 'design pattern' that may be of some use in your situation.

It's called the 'Strategy Pattern', IIRC, and basically you give each Entity an object called something like 'UpdateStrategy', which has the method that does the actual updating of the object.  So Entity's update method delegates all the work to its strategy object.  Then you just subclass UpdateStrategy into something that looks for keyboard input and give that 'customized' UpdateStrategy to your players object.  Other Entities can be given their own UpdateStrategies as necessary.

That makes it easy to swap out different behaviors for different objects/entities on the run.  I've not actually done this yet, but thought it might be kind of cool to use that kind of system to implement some kind of 'mind-swapping/control' in a roguelike sometime.

That's a possibility.  I think one of the groups here at work has implemented something similar for accounting/payroll purposes having to deal with business logic and dealing with different state/union regulations.  I could see creating a strategy for AI and one for keyboard input.  Maybe even fluid movement/weather/... I think to be truly successful though, you'd want to template these strategies so they all conformed to a set of standard calls and methods.

Here's a good site for the patterns
 - Strategy Pattern

[Singularity]

Hmm... all interesting reading.  However I don't learn so great through theory...  I'll just go find some sample c++ roguelike code to look at for now, see if I can't find a suitable example of class structure.

I'll leave you with this question though:  Right now I'm setting up the barebones of a RenderEngine class.  Now, I do eventually want most of my code to go though my Game class at some point or another.  It is the hub, you could say.  But somehow it doesn't seem right for Game to "own" the RenderEngine.  How do you guys interface your rendering engine with the rest of your code?

[qwertyuiopas]

Although it is in C, my code calls the render() from inside the program loop, but render() reads data out of a "shared" array.

You could put a screen definition inside of the game, but isolate the renderer itself, though give the screen a link to both the renderer and the game object. The screen would not own either but it could trigger the render for the game object.

[deadlycairn]

Well, after a long dry spell, I've decided on a new game. Basically a spaceship tactical game, inspired by Battleships Forever. I have a nice design plan, but four questions to ask those of you who actually know what you're doing.

1. The ships will be multi-tile (of course) and the component parts will have individual properties. I'm not quite sure how to handle this, as a ship class with a child object for every part of the ship seems difficult, plus there's the whole how to get the computer to put all the pieces in the right place. I'm thinking linked lists, but I'm not sure how they work. An array MIGHT work, but I'm not sure. Can you guys please tell me a solution, and then give a bit of advice on how to implement them?

2.Saving. How do I write the stuff to a file, and then read it, so that players can save their ship designs?

3.I've heard about #defines, but I don't know what they are. What are they, and how do I use them? I need all the syntax I can find.

Thanks in advance. And I'm using Dev-C++, cannibalising bits and pieces from everywhere (mainly the ASCII dungeon tutorial) to get things up and running. Once I get past these problems I should be good to go.

[justinhoffman]

Hey I stumbled across this thread as I am making my own roguelike at the moment.

It's in java, and I hope to have it browser based.   I just started it around the end of june, but am making good progress.

It's called Forge of the Elements.  So far the item gen, map gen, targeting, messages, UI, spell effects, melee combat, spell combat are all in place.  Well I'm about a little over 1/2 through the spells and haven't determined mana costs yet.

Spell targeting and ranged combat is in for the AI right now too.  Here are some pics.

Ratling monk with acid mastery punching a fire ant releasing an explosion of toxic energy.



Summoned hell fiend taking on a fire ant.

[JoshuaFH]

That looks really interesting Hoffman! Do you have a website or something?

[justinhoffman]

That looks really interesting Hoffman! Do you have a website or something?

  Nope not yet, but I will.  You can follow progress here if you want.  Roguetemple is a small but active community there I just discovered, and it seems like a great place to go for roguelike fans.  I just started spaming a thread there on my development.

  http://www.roguetemple.com/forums/index.php?topic=433.0

  It's not quite a game yet.  I'm trying to build all the parts and game mechanics and then throw levels on top of it.  Basically, I'm designing the combat/spell/skill system first with the UI.

  I'll at first have distributable .jar's and currently have it running in an applet wrapped in a JFrame.  And plan to release a stand alone game.  But eventually I want it to run in a browser.

  Anyway, about the game.  Both the player and enemies are 'monsters' and the AI is reflexive, meaning I can make a mob friendly and it behaves as a companion.  There is a spell in game that dominates an enemy (highest level mind spell).

   Spell targeting is used by both the player and mobs, and is handled by a function that returns the spaces affected.  Spells can be balls (AE), single target, PBAE, rays, bolts (can be blocked), and self targeting.  The AI will choose debuffs, buffs (I might not do this at first), and heal using information on player status, mana, and who they'd hit if they'd cast.

  The game is based on elemental focuses.  Any character can chose an elemental path (or not), and it will add additional bonuses to melee and ranged combat and make high level spells of that element available.  There are 4 spell schools.   The spells will be very 'crowd control' heavy offering a variety of effects to mitigate damage offensively.  Meaning you can blind enemies to prevent them from targeting you with spells, or confuse enemies and they will throw fireballs at each other.  There are a wide array of status effects currently in game from confusion, burning, poison, slow, frozen, stop, corroded, diseased, stunned, paralyzed, lull, dominate, daze and weaken.  Casters will be very fragile, but have a variety off tools to use to prevent them from taking damage.  Melee champs will be very tough on the other hand.

  Right now I'm putting in all the spells.  Basically trying to add a bit of symmetry to all the different class paths.  My goal is have all the parts in place and have an alpha to release by the end of summer.  Basically I'm going to implement all the cool spells and abilities I want in the game first.

  I'm missing so far... wands, scrolls, potions, spell books, food, item identification, stealth, and magic item skills, and about half the spells.

 I'm going to kept the thread updated, if anyone wants to read it.  Maybe you'll find it helpful in developing your own roguelike.

  Anyway, I don't expect it to be a great game anytime soon.  But, I want it to get it to a point where I am thinking more about game balance, food clock, level progression, side dungeons and other stuff that will make it a complete game.

  Oh and anyone who wants to develop a roguelike without doing a lick of programing.  Start following some of the actively developing ones and start testing them.  Test and give feed back.  There are a ton of really cool projects that could use the attention.

[qwertyuiopas]

Well, after a long dry spell, I've decided on a new game. Basically a spaceship tactical game, inspired by Battleships Forever. I have a nice design plan, but four questions to ask those of you who actually know what you're doing.

1. The ships will be multi-tile (of course) and the component parts will have individual properties. I'm not quite sure how to handle this, as a ship class with a child object for every part of the ship seems difficult, plus there's the whole how to get the computer to put all the pieces in the right place. I'm thinking linked lists, but I'm not sure how they work. An array MIGHT work, but I'm not sure. Can you guys please tell me a solution, and then give a bit of advice on how to implement them?

2.Saving. How do I write the stuff to a file, and then read it, so that players can save their ship designs?

3.I've heard about #defines, but I don't know what they are. What are they, and how do I use them? I need all the syntax I can find.

Thanks in advance. And I'm using Dev-C++, cannibalising bits and pieces from everywhere (mainly the ASCII dungeon tutorial) to get things up and running. Once I get past these problems I should be good to go.

I actually had something like that once, though all it was was just the parts sticking together.

#defines are used to replace text with other text. so #define STUFF 5 replces every occurance of STUFF with 5 at compile-time. Macros are more complex, closer to functions, but I don't know all the details.

As for the ships, I made each part part of a doubly linked list with a pointer to it's parent. That way, each ship was both part of a list of ships, and each part linked to the first part that linked to the rest. This worked for me, though there is almost certainly a better way, but without hit-testing it worked wonders as the tree it emulated was the easiest way to render it all in OpenGL, for proper rotation-transformation inheritance(so each part could rotate freely rotating it's children along with it)

Edit:
Of course, it was in C, but it should work in C++ too, right?

[deadlycairn]

I have no real interest in fully rotating ships, and I'm deliberately choosing tiles that have a counterpart for the four different directions, or look the same from all directions. Might look slightly funky, but oh well. Looks like I'm gonna have to see what a linked list IS though, although one (more time-consuming) method I came up with was an array of part objects. That would work right. Please say yes.