Print

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

[Andir]

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.

Well, you would know the size if you returned a Vector(or fixed array of 4 values) of dimensions from the viewport using viewport.getDimensions().  Arrays would be more efficient, but yes, they are harder to use properly.

[qwertyuiopas]

The player is certaily easiest to work with as global.

Linked lists have the advantage of not having a size limit, so you don't end up with a nearly empty array hogging memory, running out of array space, or time consuming resizing of arrays. Also, you don't have to copy all of the data whan transfering the object, and a doubly linked list is very easy to add to or remove from.

I have heard it mentioned on the internet that a circular doubly linked list could be used to store all of the active creatures to make updating each turn very easy(all you need to remember is the current creature, allowing the loop to break often to redraw the screen on longer turns).

Finally, read what experienced people have to say: http://roguebasin.roguelikedevelopment.org/index.php?title=Articles


Also, disregard all the people who say that global variables are evil and MUST be avoided. They are just bad in excess. A handful, even upwards of 20, makes complete sense for data that is shared across many functions, or even for anything, especially while in early development.

Make your first level a global, you can change it later once you know that it works(but don't wait too long, or you will find it very hard to change). Keep the player global until it doesn't make sense(it will probably always will make sense to keep the player global to an extent, since you will almost never get so advanced on your first attempt, unless you planned it from the start)

Edit: Over 10 posts added since I started writing this.

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

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.

Nuuu, the different messages would be handled by the message system, which takes a description of what happens and then writes it out from the player's viewpoint.  Works quite well, as it allows you to focus on other things first before refining the grammar syntax.
Getting hit should work the same way for everyone.  Check all status effects, resistances, stats, equipment and skills and calculate the damage based on this.  This also makes it extremely easy to morph the player into another creature by spawning any creature, giving it the player's inventory and "AI" and remove the original player or keep in him storage (in case the spell isn't permanent).  Adding more creatures with the player AI would enable the player to control those entities as well.
I had a little bug in my 2nd roguelike where any newly hatched dragon could be controlled by the player.  It was fun but confusing to play.

Edit: I guess some player info should be kept global, but the bit that runs around chopping at stuff should really be of the same class as the monsters.  It just makes sense in my head.

[Andir]

The player is certaily easiest to work with as global.

Certainly, and as I stated earlier, programming is not set in stone.  You can do it however you like.  I prefer to instance things within their logical scope though.  I tend to use globals VERY sparingly.

Edit: Over 10 posts added since I started writing this.

You need to learn to type faster!

[Sowelu]

Nuuu, the different messages would be handled by the message system, which takes a description of what happens and then writes it out from the player's viewpoint.  Works quite well, as it allows you to focus on other things first before refining the grammar syntax.
Getting hit should work the same way for everyone.

Well, clearly SOMEwhere down the line, the game needs to know "The player hit a monster" or "A monster hit the player".  I guess it does make sense to say "Whenever someone gets hit, call WriteHitMessage(attacker, target)", and then WriteHitMessage compares to see if attacker==player or target==player.

So that actually does work quite well.  Yeah. 

[deadlycairn]

I've read through what you said and I kinda understand both sides of the argument. For now, i'm just gonna upsize. My ASCIIMan will become the attribute of a level class, and if I decide to make multiple levels, he'll become the attribute of a game class. For two reasons, mainly I need to learn how to use classes better, and secondly it will require less short term-fiddling about to make it work - just gotta update some names. As for the rooms, they aren't gonna be EXACTLY like NetHack, but thats the closest example they could think of. The paths will (hopefully) implement the same AI as my duck to reach the doors of other rooms. Thats talk for a later time though, for now I gotta work on attacking.

Also, in my roguelike my monster and player belong to the same class. It may change (if I ever figure out what the hell I'm doing), but for now it's not too difficult to keep them in the same class, and it opens up the possibility of the player controlling a monster/ monster controlling the player.

What the hell, two new replies while I was typing? This thread was barely moving this morning!

EDIT:Oh, and before I forget, is there a random function, that can be set into parameters? I don't wanna have to hard-code the size and locaton of every room.

EDIT2: According to http://roguebasin.roguelikedevelopment.org/index.php?title=How_to_Write_a_Roguelike_in_15_Steps, I'm skipping from step 4, to 6 & 7, straight through to step 12. Oh well, it's a learning experience

[qwertyuiopas]

Look for functions to seed the random number generator(srand, for example.)

[Willfor]

rand() in C and C++. If you google it, you can find ways to make the seed more random using your system's clock.

Also if you want it between certain numbers it would be something like:

Code: [Select]

int random_number;
random_number = rand() % 100 + 1;
for something between 1 and 100.

Edit: Also, no one should probably use my code right when I post it. Not because of an epeen reason, but because even my simply code tends to get typo'd. Anyway, fixed.

[Andir]

EDIT:Oh, and before I forget, is there a random function, that can be set into parameters? I don't wanna have to hard-code the size and locaton of every room.

Use rand() / srand()
http://www.cplusplus.com/reference/clibrary/cstdlib/rand.html
This site is a really good reference for C++ standard library stuff.

[Willfor]

Also, it is not a roguelike, but this thread has sparked off that little part of my brain that has always wanted to program. I think I have overcome a mental block here, finally.

Spoiler (click to show/hide)

Of course, if I had been thinking I wouldn't have tried to calculate that large of an election. It managed to go for a half hour.

[Andir]

Try this:
How many citizens does this country have? T <enter>

 

[qwertyuiopas]

Try, instead of var= --var, var--

[Willfor]

There is nothing like an infinite loop to make sure that a person puts in the right input sanitizers. *clicks 'X'*

[Fenrir]

Spoiler: EPIC FAIL (click to show/hide)

This is going to take some time.

[Granite26]

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

Actually, I would have it return a map class pointer that has all the data wrapped with 'getsize' and 'getsquare' functions and whatever else the renderer might need.