Inventory and pop-ups: Who calls what?

[phlip45]

So I'm endeavoring to write a rogue-like game in javascript to learn the language a bit. I'm using the Rot.js library as a base and so far everything works pretty good. I keep wavering back and forth on how to implement the inventory screen though.

The way things are in my current implementation is that all key-presses start off handled by an event handling function. If the inventory button is pressed then a flag is set that the player is in the inventory and future key presses should be directed to an inventory object until that flag is no longer true. The key code is then handled there. So right now the Inventory object is handling outputting text to the screen and such.

What I think I might want to do however is have a Menu object that acts as an inbetween to handle all the outputting of text to the screen and receiving input and then calling on the inventory object to provide the data to display. I think this would help later on when I have more menus to work with, but I'm unsure which is going to be easier to maintain, having the menu object draw everything and take info from other objects or have objects handle their own menus.

There is probably another way of doing it that I do not know as I'm new to programming, so which of these methods do you use, or what methods are there of handling menus beside these two.

//sorry if this is not the correct place for this topic but I'm also new to this site

[reaver]

What's a "Menu" and how is it different to the "Inventory"? If your game is ASCII, then it sounds like the menu could be used for pretty much everything, and as such I find the description a bit vague.

I found it helpful to have several game states, e.g. "main menu", "main game", "targeting mode", "inventory", all of which process input and render stuff to screen differently. E.g. pressing "i" while in "main game" makes a transition to "inventory", where you have other key shortcuts, and "Esc" sends you back to the "main game" mode. Each state can also track what windows (if you have a GUI) are rendered and take that into account while processing input. Your game can maintain a stack of game states, and start with e.g. "main menu". Then, when you make state transitions, you can push/pop the stack. Hitting the inventory key pushes the inventory state to the stack, and when you're done with the inventory, you pop it off the stack. Etc.

[phlip45]

Sorry if the description was vague.

Right now my player has an inventory object that holds his inventory and the functions that add/remove/ or manipulate items in his inventory. I have it as its own separate object in case I want other actors like monsters or npcs to have their own inventories. Currently the functions that handle displaying the inventory window and item information is contained inside this inventory object.

What I'm thinking of doing is removing the display inventory and item information functions and placing them in a menu object that would later house all the functions that display all non-map windows. This way I can consolidate functions that would be useful for drawing and updating these screens.

I never thought of using an array to track where the user had come from and pushing/popping that information into/out of that array. It seems like a neat way to do it.

[AgingMinotaur]

Displaying inventory and menus will probably not be the hardest part to get working satisfactorily, so I'd just say go with something that feels intuitive to you. I have a "generic menu" function, which is called with a list of strings to print as well as instructions on where to print it, and which returns the player's choice (if applicable). I find it more practical, because stuff like scrolling and cursorcontrolled inventory/menus just has to be implemented once, and it gets quite trivial to add UI for similar functionalities, such as dialogue or character creation.

As always,
Minotauros

[phlip45]

Thanks Minotauros. I realize that it probably just seems difficult for me right now because it is the thing I'm working on currently. Things always tend to seem more difficult while you are working on them or just before. I still would be interested in what methods people have chosen to tackle this particular problem, as I'd just like to see the different ways people attack a problem which to me seems open to several solutions. Something described here may end up being more intuitive to me then my own line of thinking (which happens a lot to me).

[mcouk]

I'm new to game/roguelike development but I've also gone down the route that reaver mentions; I have a MenuState, PlayState, InventoryState, etc. It's still early stages but so far my main loop consists of just update/draw/input, so if I change to InventoryState the loop works only on that state. Once the state is over it passes back to PlayState; I return false from the (i)nventory input command so that PlayState knows the player hasn't yet taken their turn.

If each Actor has their own inventory then I guess you would need to pass that information into the InventoryState when you switch to it (switching is handled by the parent GameState). You could also implement enter/leave methods for each state if required.

[phlip45]

That makes sense mcouk. I don't think my game has boiled down to a game state with just input, draw and render yet. It could be because Javascript is a bit weird in that it is asynchronous  so multiple functions could be executing at the same time instead of one thing has to finish before the next one begins. Right now timing is handled by a scheduling engine that just lets different actors take their turn. Each actor is responsible for updating its position on the game map and drawing itself when it is created. Currently it is the player objects responsibility to keep track of the inventory interface and other such windows because these things are only going to happen on the players turn.

It could also be because I'm dumb =P.

[mcouk]

I was looking over the code for PugnaciousWizards2 (https://github.com/trystan/PugnaciousWizards2) the other day, I don't know much about ActionScript, and my JS is only for basic webpage DOM stuff, but it looks like it could be similar enough for you to get some ideas from. It uses screens, (MenuScreen, PlayScreen, etc.) but that to me looks the same idea as states.