Print

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

[deadlycairn]

I wish to make more than one small room - I want several on each map, connected by paths (think NetHack). However my current room class has the player character as an attribute, so if I make more than one, I end up with more than one character. I could just make a global player character variable, but apparently thats a no-no. Should I rename my current ASCIIRoom class to some thing else (for example, Game), and have a different class for the sub-rooms? Or is there an easier way of doing things?

I (was) using the ASCII Dungeon tutorial, if that helps any.

[Sowelu]

Say you've got a program in multiple classes, each of which is in its own file. 
You distribute this program to some malevolent, too-smart-for-his-own-good, pimply teenager, like myself. 
  This hypothetical person, using whatever means, figures out what methods are being used, then writes and compiles a replacement for one of the class files.

This is actually, very specifically NOT what public and private are for.  That's a very common misconception.  If anyone has any of your program files, they can muck with them freely regardless of 'public' or 'private', because those things clearly have nothing to do with encryption or network security or anything like that.

"Public" and "private" are to save those pimply teenagers from themselves.  Here's a more realistic example:  Let's say you have a SortedList class.  That SortedList presumably has some 'InternalSetData(location, newData)' method.  But in normal operation, it only calls that as part of a much larger sorting operation...you say "add a new value", it makes sure everything is sorted.  If you called that InternalSetData thingy by yourself, it might skip the whole 'sorting the list' thing...and then either you, or whoever is forced to use your class, might call that function and wind up with a list that isn't sorted.

It's very important for contractual programming that you use public and private stuff.  You can make a guarantee of "As long as you only call public methods, this list will always stay sorted".  Your private methods, there's no guarantee--but since you're the only one in control there, well, when someone calls a public method, you can then call as many private ones as you want, and make sure that list is sorted again once you're done doing your job, before the next time someone can call a public one!

Try to disabuse yourself of the notion that "public" and "private" are for security.  They're just there to make your life easier.  If they aren't making your life any easier, don't use them--and in a tiny little roguelike, well, they might not have THAT much use at all.

[Fenrir]

I'm all about logical layers in a program design.  If you can abstract an item out as a functional view item, it makes touching it less confusing.  viewport.setCamera(x, y, z);  viewport.setWidth(50), etc ... graphicsEngine.render(viewport.getView())

What would getView() return?

[Sowelu]

I wish to make more than one small room - I want several on each map, connected by paths (think NetHack). However my current room class has the player character as an attribute, so if I make more than one, I end up with more than one character. I could just make a global player character variable, but apparently thats a no-no. Should I rename my current ASCIIRoom class to some thing else (for example, Game), and have a different class for the sub-rooms? Or is there an easier way of doing things?

I (was) using the ASCII Dungeon tutorial, if that helps any.

Actually, the player is probably the best candidate for "global variable" that you'll ever find.  Not a no-no at all.  Someday, you might want a "Game" class that contains several "Map" classes with their own "Room" classes.  Then you might want to put Player in "Game" instead of as a global.  But until then, go wild.

I don't have great advice for going from a room to multiple rooms.  You can either say "Okay, I want to make a Map class, which contains Room classes connected by Corridor classes", or you can say "I think I'll throw away the concept of a room, and just generate a map with some other algorithms when the level starts and store it in an array, and slowly expand the Room class into Level".  Do whatever seems best.  But either way you're going to want some class that represents the whole level.  If you want multiple levels, and you want to see any given level more than once, your Level class shouldn't be the same as your Game class.

I will warn you ahead of time:  Nethack's corridors are *HARD* to get right.  Do whatever you can to avoid connecting diagonal rooms with a horizontal+vertical (bendy) corridor.  I tripped over that last time I tried to make a roguelike...maybe you can create straight corridors of arbitrary angle, maybe you can just place rooms in such a way that they are in a grid and you can only use horizontal or vertical ones.  But bendy ones that connect intelligently and notice when they connect other corridors are tough.

[Andir]

getView() could simply return an array containing the character/icon representation of the screen viewport to be drawn.  It could also be a 2D reference array of the size of the viewport that points to the tiles in the world array for the tiles being drawn so that the render loop can figure out what goes in that space.

That all depends on where you're storing your items... If you are keeping a global array or a container class of items, you'd have to step through each and every item to do what you're asking.  If that were the case, it would be "cleaner" to do an override render where one render function takes an array (consisting of world tiles returned from the viewport.getView()) and an override function that accepts an "vector"  container type (like  vector<constructions>, vector<creatures>...)  but that might be getting into some more "advanced" C++.  I don't know your level.

You can do it how you are, but I'd request and store the extents of the viewport (viewport.getViewX1, getViewY1, getViewX2, getViewY2  or getBounds() to return a vector<> if you're feeling adventurous) and save those to local variables and compare against those to decide which ones to render.  It would save the overhead of going into the viewport for every item and calculating the result.  Just make sure to "cache" the viewport coordinates before running through all your items.

I think I read earlier that someone suggested putting references to placed items/creatures in the tiles.  That's also an option.  Then you wouldn't have to loop through all the items and decide which ones are on screen.  The viewport.render could look at the tile contents and return the item icon during the viewport.getView() saving a loop and removing a render step.  This would only matter if you had TONS of items and memory wasn't a concern.  Saving references to all items in a tile is a quick and efficient way to do it, but you incur overhead by keeping a container object in the tile.  You also have to make sure that if you remove an item from the tile "virtual" inventory that it goes to another inventory (like a creature, or a box) so you don't mis a step and the items vanishes into nothingness.

[Rhodan]

I think the player should definitely be of the monster class.  This way it is much easier to enable monsters to interact with the environment and each other the same way the player does.
The only different would be when the monster calls his AI routine, the player should call the input routine.
You should still keep an eye out for additional input, though, so the player can press 'Q' should he bug into a coma and keep missing his turn.

[Fenrir]

getView() could simply return an array containing the character/icon representation of the screen viewport to be drawn.  It could also be a 2D reference array of the size of the viewport that points to the tiles in the world array for the tiles being drawn so that the render loop can figure out what goes in that space.

That all depends on where you're storing your items... If you are keeping a global array or a container class of items, you'd have to step through each and every item to do what you're asking.  If that were the case, it would be "cleaner" to do an override render where one render function takes an array (consisting of world tiles returned from the viewport.getView()) and an override function that accepts an "vector"  container type (like  vector<constructions>, vector<creatures>...)  but that might be getting into some more "advanced" C++.  I don't know your level.

You can do it how you are, but I'd request and store the extents of the viewport (viewport.getViewX1, getViewY1, getViewX2, getViewY2  or getBounds() to return a vector<> if you're feeling adventurous) and save those to local variables and compare against those to decide which ones to render.  It would save the overhead of going into the viewport for every item and calculating the result.  Just make sure to "cache" the viewport coordinates before running through all your items.

Woah. All right, I think I can do this...

[Andir]

I wish to make more than one small room - I want several on each map, connected by paths (think NetHack). However my current room class has the player character as an attribute, so if I make more than one, I end up with more than one character. I could just make a global player character variable, but apparently thats a no-no. Should I rename my current ASCIIRoom class to some thing else (for example, Game), and have a different class for the sub-rooms? Or is there an easier way of doing things?

I (was) using the ASCII Dungeon tutorial, if that helps any.

Actually, the player is probably the best candidate for "global variable" that you'll ever find.  Not a no-no at all.  Someday, you might want a "Game" class that contains several "Map" classes with their own "Room" classes.  Then you might want to put Player in "Game" instead of as a global.  But until then, go wild.

I don't have great advice for going from a room to multiple rooms.  You can either say "Okay, I want to make a Map class, which contains Room classes connected by Corridor classes", or you can say "I think I'll throw away the concept of a room, and just generate a map with some other algorithms when the level starts and store it in an array, and slowly expand the Room class into Level".  Do whatever seems best.  But either way you're going to want some class that represents the whole level.  If you want multiple levels, and you want to see any given level more than once, your Level class shouldn't be the same as your Game class.

I will warn you ahead of time:  Nethack's corridors are *HARD* to get right.  Do whatever you can to avoid connecting diagonal rooms with a horizontal+vertical (bendy) corridor.  I tripped over that last time I tried to make a roguelike...maybe you can create straight corridors of arbitrary angle, maybe you can just place rooms in such a way that they are in a grid and you can only use horizontal or vertical ones.  But bendy ones that connect intelligently and notice when they connect other corridors are tough.

^ what he said... Also, the tutorial you went through was a pretty good one.

the ASCIIRoom object can remain.  It should remain using that type of system.  You will want to have a Level object as stated above and that level will generate the rooms.  This way, if you ever decide to add stairs, you just send the player to another Level.  World you should reserve for things you think are relative to a planet in real life.  You wouldn't put all the people in the world into a large table.  You'd subdivide all the population into Continents (Levels) and Rooms (Countries.)  Try to think of the smallest manageable divisor so that you don't have to search through the population of the entire world to find one person with black hair, a tatoo, and a red shirt.  You'd only want to look within the area you are in.

[Mondark]

...stuff...

Ahh, that does make more sense.  Thanks for clearing that up.

[Fenrir]

getView() would return a multidimentional vector, right? Otherwise, I wouldn't see how the render function would know where to put stuff.

[Andir]

Woah. All right, I think I can do this...

Don't go overboard.  I'm not a good teacher by any means, and I sometimes go too far.  Try it however you thikn it will work, then try it another way.  Programming isn't a "one size fits all" solution to everything.  My method is one that you may or may not understand.  First start off by creating an "graphicsEngine" of sorts that holds all your tiles and draws your items.  Use it however you like.  If you want to call it to draw every single tile, do it.  Expand that to accept a 2D array of tiles and see how that works.  Then pass it a 2D array that contains references to the world array.

You can build up over time.  I do not recommend you try that all at once.

[Andir]

getView() would return a multidimentional vector, right? Otherwise, I wouldn't see how the render function would know where to put stuff.

Right.  Think of it like a psuedo screen.  You'd return a 2D array the same size as the viewport.  This way, the renderer just has to concern itself with the array in question... not the whole world.

edit: sorry, I keep saying array.  A Vector will do.

[Fenrir]

Awesome. Thanks, Andir.

edit: sorry, I keep saying array.  A Vector will do.

I assumed that a vector would be my only option. If I returned a multidimensional array, the render function wouldn't have a way of knowing how big it was and wouldn't be able to access the elements safely. Of course, it's entirely likely that I'm wrong.

[Sowelu]

I think the player should definitely be of the monster class.  This way it is much easier to enable monsters to interact with the environment and each other the same way the player does.
The only different would be when the monster calls his AI routine, the player should call the input routine.
You should still keep an eye out for additional input, though, so the player can press 'Q' should he bug into a coma and keep missing his turn.

I'd recommend that "player" and "monster" both descend from "creature" in a simple roguelike, myself.  There's enough differences there.  They're controlled by different routines on their turn, they do different things when they get hit or die (like making different messages), different things want to chase/kill them, etc.

[Dasleah]

It's so convenient that you guys always seem to be discussing exactly what I'm pondering at any given time 

Anyway, an announcement: The date for the 7DRL Challenge has been announced!

The week for the Seven Day Roguelike Challenge has been chosen!

Within the week of March 7th to March 15th, you are hereby challenged to write a roguelike in 168 hours!

To participate, follow these simple steps:
1) Any time on March 7th or March 8th (as measured in your time zone), post to rec.games.roguelike.development that you have started work on your Seven Day Roguelike.

2) Write a roguelike.

3) After 168 hours, if you have completed a playable roguelike, post your success to rec.games.roguelike.announce!  If not, post your lack of results to rec.games.roguelike.development, where we will all commiserate and agree that given a few scant more hours, it could have been great.

Huzzah!