What is a practical way for an indie to create an rpg menu module?

Hey there, I've got my data saving and loading properly in xml and have my database structure set up in where it works for me in an organized and elegant manner. Now it's time to work on a menu module before I get into working on a turn-based battle system as I feel getting all of the stats and abilities done first and foremost with a working menu system will lead into creating a stable battle system.

I'm wondering how you might go about this considering that you want to be as practical as possible, as in not spend 1000 hours creating it. My rpg system could hardly be called complex, it's literally just got two or three stats, and there are no items in the game, you just collect skills and switch them out. The game is also episodic, only about 2 hours long I would say...There are simple moves like punch, kick, fire punch, fire punch II, block, throw fireball, etc...

Are there any asset store scripts that you would recommend, or tutorials on youtube or elsewhere that focus on creating menu systems? I would assume the most difficult part about using another's system is integrating my own database structure into theirs....in a way...I don't know...

 

I would suggest to watch what others have made in similar games. There's no need to reinvent the wheel most of the time.
Depending on the platform, you might want to have different menu systems too.
There are so many possibilities though.
Bottom centered menu, with all skills showed.
Circular or half-circular menu with under-menus per skill.
Buttons for every skill would also be a possibility.
Just really get inspired by examples from other games and adapt to your liking.

 

There are surely assets and a bunch of good systems, however based on already existing concerns about integration into your game, it's even harder to suggest something, because we don't even know how your code and the systems look like.

It depends what you mean by that.
To be honest, if that's going to be a programmatic difficulty then either of both is not suitable to be combined with anything that's not programmed against said system.

Anyway, you'll most-likely need a layer between your logic and the menu either way, i.e. some abstraction that does not bind your game logic directly to the menus.
Having that in mind, you should be able to even prototype the menu system on your own and exchange it later.

 

Im trying to consider what would be some of the primary challenges. Ive created readouts of data before, but a module that reads out data from a list but then you scroll down through the data adding and removing equipment seems challenging to me.

http://cdn.player.one/sites/player.one/files/styles/scale_lg/public/2017/04/27/ffviimateriamenu4.png

The game Im making is very small in comparison with a system like this...Im trying to wrap my head around some of the challenges thoigh ahead of time before it destroys me.

I think one of the challenges thats erking me the most is the implementation of a scrollbar...I would imagine the idea is that it reads out a particular amount of items (like it has "slots") and trades off one item for another in its slot when scrolling up or down.

Looking at tutorials and guides Im seeing people using ui panels. Readouts of data that dont require scrolling dont seem too difficult...Im just trying to find the fastest simplest way and not create something overly complex. To keep my game simpler I decided to take out items and only have abilities, then all I really need is to create an equip screen I would suppose. Its extremely simplistic. Maybe drag and drop panels would work better, than a traditional rpg menu...

 

creating a scrolling list is really easy.
Create a scrollview, create a prefab Button with Text and instanciate prefabs in the Content from the scrollview for each ability.
I would suggest watching this

 

The unity tutorial is actually pretty good for this!
https://unity3d.com/learn/tutorials/modules/intermediate/live-training-archive/modal-window

 

Thanks for bumping, I had forget about this thread completely.

True, the scrollbar itself is pretty simple to set up, if Unity's built-in scrollbar is enough for your needs.

The more important question is - and that's pretty unrelated to the scrollbar that you use - is where to pull the data from and how to pull the data that you want to show. I think that's also the part that you worry about the most, as far as I can understand @astracat111

You should actually split this problem into smaller parts that you may want to look at seperately. Let's split it into two major problems to solve for the sake of simplicity:

1) the architectural aspect, i.e. how does the menu know where it receives the item data from? That might just be the player's inventory, however that'd be a tightly coupled UI (you find this very often, but one can improve it)
2) the performance and efficiency part, i.e. how (much) data must be shown, how much panels to instantiate and such... That's one thing you've also touched in your post.

### 1 ###
With regards to the architecture, as already mentioned, one thing you might often see is that UI elements do exactly know where to get the information from, e.g. one tends to link the inventory, an item database etc directly to the UI elements. One may also argue that the UI is some kind of top layer in the final application and these dependencies are okay, because they wouldn't break the entire code base. And that's truely acceptable, in some way...

But in fact, there's actually quite a bit of re-usability we can sqeeze out of it.
The menu does not need to know exactly where the items or abilities are read from, i.e. no specific type of data source, it just needs a very tiny interface that allows to pull data from any data source of that kind. In other words, don't link the inventory or the ability list directly. This also reduces the access to inventory and such for UI elements, which is kind of great.

Consider this example (I'll use items, but it applies to abilities, media galeries, etc...).
- show items from an inventory
- show items in a trade window (actually a subset of inventories of the participating parties)
- show items from a merchant (merchant's "inventory")
- show items from an auction house
- show items from an IAP shop
- ...

You could actually find some sort of base-inventory implementation, but that's not necessarily needed as it may already expose too much information, i.e. methods etc.
Instead, you can link some IItemSource[Reader] (don't mind the names, I'll just make them up spontaneuosly)
which allows to read from anything that contains items ... similar to an iterator that's exposed by collections / containers. It doesn't even need to have the defintion of an "inventory", it's just a source of information (could as well be streaming from an external / remote source... it's very flexible).

You'd simply "request" a range of items instead of pulling them directly out of some specific source.

### 2 ###
That leads to the second part, which items do we need to care about?

It's certainly a valid approach to just instantiate one panel per set of data. Once that list grows huge, this is actually not efficient anymore. And as far as I can read, that's also one of your concerns, and you've already mentioned a common approach for that:

So you'd want to have some kind of panel-pool. Whenever you scroll up/down, you need to determine the range of items that you need. Render the data in some way and exchange a panel's content when you scroll, or when the list changes.
This does also combine very well with the abstraction of the interface I talked about earlier.

Of course, all of that is just some rough outlining (you can generalize and extend this greatly and seperate the task even better). It does indeed involve a bit more coding than the most trivial approach, but once you get such a system working, it'll be pretty easy and satisfying to add additional features.