Stuggling with structure for tracking all game items
Yes I'm writing a console text game and yes I know that the console is bad for games. No graphics and won't ever be distributed (probably). I'm also learning SFML.
So, I've got a few classes like Game, Character, Map, Room.
I have Weapon, Armour and Consumable classes that inherit from an Item class.
I can create a vectors of all the Items and I can work out how to set an Item's location, but I'm struggling with how to tie it all together so that Items can be moved around the map in the way you'd expect. If the player picks up an Item, what's it's location then?
I'm guessing that most people would use x, y coords of everything, but I was going to use up and down on the map and thought that giving every room a unique identifier would make it so I could make any room lead to any other room, not just the adjacent ones. Items may not always only move to adjacent rooms either so I need to be able to just set an Item's location.
Any advice welcome
So, I've got a few classes like Game, Character, Map, Room.
I have Weapon, Armour and Consumable classes that inherit from an Item class.
I can create a vectors of all the Items and I can work out how to set an Item's location, but I'm struggling with how to tie it all together so that Items can be moved around the map in the way you'd expect. If the player picks up an Item, what's it's location then?
I'm guessing that most people would use x, y coords of everything, but I was going to use up and down on the map and thought that giving every room a unique identifier would make it so I could make any room lead to any other room, not just the adjacent ones. Items may not always only move to adjacent rooms either so I need to be able to just set an Item's location.
Any advice welcome
A Room could have a collection of Items(probably std::vector). In this way you can easily remove an Item from a Room and add it to another Room. Also Character should have a collection of Items.
I don't think that console games are bad. Playing this kind of text adventure games can be fun. I also think that as a beginner you should not try to learn to many things at once.
I don't think that console games are bad. Playing this kind of text adventure games can be fun. I also think that as a beginner you should not try to learn to many things at once.
If you are writing a console game, and you are using Windows 10 (v1511 and above) then consider using VT100 terminal codes (or other OS that supports VT100) for display (colour, cursor movement, text modification etc).
See
https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
See
https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
Last edited on
@thmm
That’s a good idea. Each room can have its own “Inventory”. I have an Inventory class anyway, makes perfect sense and so simple.
Part of the trick with code is taking a literal idea, turning it into something abstract that when run looks real again. Can’t see the wood for the trees sometimes.
@seeplus
Ok I’ll check it out. I’m mostly using the console because I want to focus on logic and following data etc. I had a go with SFML and still came unstuck with working out the non gfx stuff. I’ve always wanted to write an old fashioned text adventure since I had A 48K ZX Spectrum.
That’s a good idea. Each room can have its own “Inventory”. I have an Inventory class anyway, makes perfect sense and so simple.
Part of the trick with code is taking a literal idea, turning it into something abstract that when run looks real again. Can’t see the wood for the trees sometimes.
@seeplus
Ok I’ll check it out. I’m mostly using the console because I want to focus on logic and following data etc. I had a go with SFML and still came unstuck with working out the non gfx stuff. I’ve always wanted to write an old fashioned text adventure since I had A 48K ZX Spectrum.
at some point you may need all the items in hand. Perhaps to save your game, (the rooms are fixed, but the items and character not?). A container of pointers forms a shortcut so you don't have to iterate rooms+character(s?) to iterate items. May or may not be useful depending on the size of the lists, but just looking at what you are working with and what-iffing.
That sort of thing is less useful (you can make it work but constant updates burn up what you saved in a volatile system) with dynamic data, but when you have a fixed set of objects, it can work wonders.
I have found that if you think about your file format for the program early on, it is an oddly good indicator of the strength of your design. If saving the file is immediately a convoluted mess, ... its a red flag.
That sort of thing is less useful (you can make it work but constant updates burn up what you saved in a volatile system) with dynamic data, but when you have a fixed set of objects, it can work wonders.
I have found that if you think about your file format for the program early on, it is an oddly good indicator of the strength of your design. If saving the file is immediately a convoluted mess, ... its a red flag.
Since Weapon, Armour and Consumable derive from Item, all of these collections should be collections of pointers (or unique_ptrs?) to Items, not Items themselves. Otherwise you'll lose the derived info.
@jonnin
I think for now I’m just going to create all Items that will exist. If I’m understanding this right I will have separate containers (Inventories) of Items, some will be in the world, some on the player. But then I have a container of pointers to all the items. I feel like I’m going to hit problems moving items between containers. Or have I got this wrong?
I think for now I’m just going to create all Items that will exist. If I’m understanding this right I will have separate containers (Inventories) of Items, some will be in the world, some on the player. But then I have a container of pointers to all the items. I feel like I’m going to hit problems moving items between containers. Or have I got this wrong?
no, that sounds right.
if you use a vector for the inventories, you can use the index instead of a pointer.
-what that gets you: you can save the inventories easier, so room X has items [11] and [852], player Y has items [42][314][12], .... (its harder to save a list of pointers, because the value changes every time you run the program).
-what that costs you: the item list needs to be accessible to many things, like a global, but preferably passed around or something (though, if it is all constant, global static data is OK the bad problems come with variable global data, not constant). Pointers go right to it, without needing the original list variable in scope to get there.
things to think about:
what do you do if there are 10 "swords" in your game?
what do you do if you allow the player to make items via crafting?
if you use a vector for the inventories, you can use the index instead of a pointer.
-what that gets you: you can save the inventories easier, so room X has items [11] and [852], player Y has items [42][314][12], .... (its harder to save a list of pointers, because the value changes every time you run the program).
-what that costs you: the item list needs to be accessible to many things, like a global, but preferably passed around or something (though, if it is all constant, global static data is OK the bad problems come with variable global data, not constant). Pointers go right to it, without needing the original list variable in scope to get there.
things to think about:
what do you do if there are 10 "swords" in your game?
what do you do if you allow the player to make items via crafting?
Last edited on
Seeing as I already have plenty to chew on, I’m gonna keep every item unique, but yeah crafting adds a lot of complexity.
Thanks for the help!
Thanks for the help!
This depends upon how many base items you have. If you have no more than 64 (32), then have a 64 (32)-bit unsigned with each bit representing one base item. Then crafted items are a combination of the base items and can be fairly easily determined, added to, removed etc by bit twiddling.
and, I did not ask those for you to support it now, so much as 'what if next month' ... if you think about what may come early, you can avoid a design now that prohibits growth later. Just ... back of your mind kind of stuff, as you tinker.
Topic archived. No new replies allowed.