Inventory System

Started by
10 comments, last by Phil123 11 years, 9 months ago
Let me just add that you don't need to justify your reasoning for working on this project. Often times 'reinventing the wheel' is the best way to learn, and this is the right place for that. Also, although I agree that you should have your requirements pretty much fleshed out before starting the development phase of a project, in my opinion it is often times impossible to know exactly how you're going to do everything--especially for large projects. The key is iteration. Start somewhere, and as you discover things that you need or approaches that don't work, take a step back and refactor. Unless you've written half a dozen inventory systems before, I would expect that kind of process.

EDIT: After reading a bit closer, it sounds like you were referring to not perfecting a piece of code that you're not sure is even what you want, which is good.

I recently wrote a resource manager for my game engine. I probably rewrote it three times until I found a design that I liked. It wasn't that I didn't figure out everything beforehand, it was mostly that my naive ideas of what I thought would work ended up being rather mediocre in the end, and I found better ways to do it only because I messed up the first two times.

Just saying.
Advertisement

why do you have c and temp objects?


c objects are for the player's equipped gear. When I determine the player's battle stats, the values stored in c will be added to this amount. (so... cBattleStats.Offense = cPlayer.Offense + cWeapon.Offense_Increase, etc etc). The reason why I can't just add this value to cPlayer is strictly because monster strength is partially based on cPlayer stats (and I only want enemies to get stronger based on your stats/level, rather than how good your gear is - to reward exploring more areas and fighting tougher enemies to get better gear rather than grinding the same area).

Temp objects are for storing temporary data that is used to display specific item stats (say, an item in the player's inventory). It opens the item data.txt file and reads in the values into the corresponding temp object.

I suppose I could skip the whole "temp" object and just display the info to the screen while I get the data from a file, but in this situation (doing something new) I decided to split everything up so if I end up with a nasty bug, it's much easier to pinpoint where it is.


What I'm asking is wont you have like 3 different swords with various stats?


Sure, but the player can only equip one. I could change my program so when the player wants the items in his inventory listed it'll display the stats for each item, but that'd be a mess when playing the game.


The way you have set this up it seems like you can't expand it, the user can't have 5 differente unique weapons or clothing, only 1 of each.


They indeed can. The item name of said weapons or clothing is stored in Inv_List, and the player can easily get the game to display the stats of said item through file input (item data.txt or whatever I called it).


Your item hierarchy is fine, its just your c and temp globals that make this very unusual.


Yeah, I know, I'm always open to ideas, just because I've implemented something and posted the general outline doesn't mean I'm not willing to change it up or completely redesign it.


Like i said if your layout is working fine and your game is behaving how you want, you can just ignore me. I just want to help


It's working great, but I'm always looking for new ideas to do things so please post away. And ignoring you would be extremely disrespectful as there's alot to learn from the people on these forums. And thanks - for wanting to help, it's appreciated.


Start somewhere, and as you discover things that you need or approaches that don't work, take a step back and refactor.


Yeah, this happened a few times. I'd say to myself "wait a second... ... ...this won't work, I have to change this because of this."


I probably rewrote it three times until I found a design that I liked. It wasn't that I didn't figure out everything beforehand, it was mostly that my naive ideas of what I thought would work ended up being rather mediocre in the end, and I found better ways to do it only because I messed up the first two times.


Yup, that's exactly why I keep an open mind to new ideas/ways of doing things.

This topic is closed to new replies.

Advertisement