There’s three different directions to go from here, each necessary, but to my mind, not one predominant:
One direction is to add music, sound, and an options menu to change the music, sound, screen, and controls. This frequently gets neglected, and I have been the artist in games that didn’t add these things, even though I consider them a bare minimum to a professional game.
The second direction is to add fights. Get those Action Points charging, and those hearts popping up. This is the most gameplay-centric option. What is an RPG without its battle system, after all!
The third option is adding radial menus and expanding the number of things we can do with our “NPC”. Here exists a slight exception to my “not one of these is predominant” statement: while, as of yesterday, I figured the Battle System was definitely the next thing to build, the fact is that both navigation on the overworld, and fighting in battles utilize radial menues!
So, in the first couple of computer RPGs, when you walked up to an NPC and pressed A, you didn’t talk to him. You got a menu, and you selected talk from that menu. You could also select other things from that menu, like “look” (presumably to examine your NPC) or “stairs” (presumably we’re not thinking too hard about that one).
I want a system that preserves the convenience of the modern convention, and the flexibility of the old. So, pressing A, or left-clicking, or tapping your NPC will still give you a default action, in this case “greet”. Pressing B, or right-clicking, or holding a finger on an NPC, on the other hand, should spawn a radial menu with other options such as “look at”, “ask about [topic],” etcetera, as makes sense for the game.
This multi-action functionality is unnecessary for Last Legend I. My intention was to leave it alone until Last Legend II at least. But! As I have said, radial menus are also used in combat, and here there is no hope of putting it off a game or two. I need them to be in this game.
If I am going to code them for the combat, I may as well code them for the overworld as well, with an eye to reusing them in combat.
Well! I think I’ve answered my question as to what I’ll code next. So, let’s add some nuance to this interaction. We will shift our Interactable code to have a long distance interact and a close-distance interaction. So if we are far from our NPC, we look at him, and if we are close, we greet him.
Prior to this, we stored the mouse icons in the interactable component. Now, we’re storing the icon in the action script, along with a highlighted version, so we can reuse the icons in the radial menu.
I want to have gameplay modes that utilize standard time, and gameplay modes that pause it. Dialogue should actually pause the underlying gameplay mode, as should the command wheel. I was thinking of having the code that handles dialogue and the code that handles the command wheel each pause and release the pause themselves, but now that seems like something we ought to handle from the mode manager itself.
Here’s another thought. When I implement my command wheel, I will be a fraction of an inch closer to making my JRPG framework, putting me at maybe a quarter of the way there (of course, the framework doesn’t account for the bulk of the game — the precise places, plotlines, people, and powers pertinent to the product). But it’ll put me more than halfway to a proper Adventure Game framework. I’ll just be missing an inventory system (which I also need for a JRPG) and a save/load system (which I also need for a JRPG). My heart rebels at the thought of making an adventure game with no combat, but… it’s meant to be a very small game. Only an hour at most. And if my JRPGs do not succeed as adventure games, they will not be the product I am trying to make however nice the combat is.
That’s not a decision I need to make today, though. I can punt it down the road. In fact, I can punt the question of whether I’m making a JRPG this iteration or next iteration until I’ve implemented all of the adventure mechanics.
And so, perhaps, I shall.