Yesterday, I learned how to use LeanTween’s spline-following functions, and attempted to create an interface using Unity’s UI. It went horribly wrong and mucked up my input, so I’ve ditched it for… rolling my own buttons.
Today, work has begun anew on the radial menu. And I have the radial menu spawning on command at the location of my choosing, with as many buttons as I like, and gracefully disappearing on command as well.
Cool beans. Now I need to tie it to actions and teach it to accept input.
I have to say I love the sheer amount of math involved that A) I don’t have to do, and B) I don’t even have to understand. How do you move an object along a spline? Hell if I know; Lean Tween will handle it for me. How do you rotate a spline around an arbitrary axis point so that multiple icons will follow the same path, except rotated? Hell if I know; Unity will handle it for me.
Input’s going to be a tad bit tricky. Mouse and touch will be easy, but the point of a radial menu is that you press a direction with the stick or D-Pad and get the button in that direction. I’m going to have to figure out a general solution that works on every number of buttons. But first, I guess I better do some plumbing.
We are going to tinker for the remainder of February. At this point, I am 90% sure I want to launch a Kickstarter for Awesome Moments on March 15th, and spend March 1st throught he 15th building up to that.
In the mean time, today’s task is to implement radial menus in my RPG/Adventure game unity framework.
I spent yesterday relaxing, trying to avoid working on the game, even in my head, but I could not avoid the conclusion that I still hate adventure games, and unless I am suddenly struck by lightning and come up with a new way of approaching them, I’m just going to go ahead and start implementing battles as soon as my radial menu is up and running.
Let me try and give you a quick idea of my damage.
Suppose in your game, you have a puzzle. Collect the 7 shards of the Pearl of McGuffin. One of the shards is in a vending machine. It costs 25 cents.
You can see a quarter in a drain. So you stick a piece of chewing gum on a stick, and use it to fish the quarter out.
The glory and the failing of adventure games is this: That is a cool, clever way to solve the problem. But it is also highly specific. Most games won’t allow you to do that, because it cannot be generalized to the game’s built in mechanics. But adventure games have the opposite problem: they will allow you to do that, and nothing else.
My favorite thing about videogames is player expression. Adventure games have, by nature, zero player expression. Every puzzle solution is not the player applying his creativity and skill to the problem before him, but rather, the player thinking the game designer’s thoughts after him. I would rather there be a set of consistent mechanics, from which the player can derive the intended solution, but also create his own solutions.
One of the reasons I seldom discuss Candy Raid, a game I worked on as the artist, is it is a puzzle game. There is one and only one intended solution to each problem. I hate that in games. I hate games that do that. They are a legitimate genre, and some people love them, but not me.
My favorite game these days is Breath of the Wild, and the reason is simply this: The game has puzzles. The puzzles have intended solutions. But the game not only doesn’t prevent you from thinking outside the box and applying your own solutions, the designers kind of wink and nod and hint that they approve of you breaking out of their boxes.
The point and click adventure genre is a celebration of the box. Therefore, I cannot in good conscious make one unless I figure out a way to change that. Therefore, even though I could stop building my RPG framework a third of way in, and produce an adventure game with that third, and even though I should, simply because doing so will force me to find the fun in the non-battle parts of the engine and because it will mean I have more games to my name, at this present moment the plan is to not do that very thing.
I do not serve my customers well by trying to produce a game I will hate. Although…
Here’s a notion. I’m not committing to it. But let’s throw it out there and let if vibrate in the aether. If I make a stealth game with an RPG/adventure game interface, then I will go into my RPG with sneaking baked in.
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.
This represents a framework for basic navigation and dialogue that works equally well with keyboard and mouse, gamepad, and touch screen.
I’ve said it before, but the JRPG genre is well suited to touchscreens. People make JRPGs that use arrow keys or gamepads or wasd, and then port them to phones with virtual dpads that clutter up the screen, instead of just using “poke to go there; prod to open chest, touch to talk,” etc.
I know why. In a game engine, you get one input system out of the box; to make the others play nice, you have to do stuff yourself. Well, my JRPG design takes enough cues from outliers like Mario RPG, etcetera, that I can’t use RPGMaker anyway. So, as I’m rolling my own framework, I’m rolling my own input system (more or less). May as well make it work both sides of the aisle.
It was harder than I thought, though not super hard. Basically, there’s two cursors on screen at all times. One jumps to the location of your mouse/touch, the other floats in front of the player character’s eyes. You click/tap and the mouse cursor triggers stuff. You press A, and the eye cursor triggers stuff.
Movement has to be handled different. There’s an invisible DPad on your character, sending the ground the same events that the mouse would. At the edges of the screen are zones that count as both ground and interactables, ushering you to the next screen.
Badda bing, badda boom. Special thanks to my cockatiel, who served tirelessly in the role of rubber duck.
Technically this bit of animation is a fine piece of work for yesterday. Technically It’s less animation than it appears to be. My timeline says 41 frames, but that’s a lie. Many of them are duplicates…
Works out to be about 25 frames when you remove the dups.
The whole point of doing monochrome, low-res graphics is to sharply limit the scope of a project. One of the rules I’ve stuck to when doing platformer stuff in this format is a hard limit of three frames per animation. It’s fairly easy to see that the walk cycle is, indeed, 3 frames.. and almost nothing else is.
(It’s not as bad as it looks. Here’s the independent frames per animation:)
(So, there’s only two animations that break the rules at the moment. The sword draw, and the second cut from the critical hit).
Right now, I cannot accomplish what I want with the animations and cut the offenders down. This is not to say the task is impossible. If I separate the sword and the character out into different layers, I might be able, by staggering frames, to get more than three frames of animation out of three frames per object — and later on, I can do weapon swaps and independent weapon/character color palette swaps when I add that functionality to the engine.
That’s how John Michael Jones’s sprite works. He gets three frames per animation, and so does his sword, but they don’t always happen at the same time, with the result of a sword swing will look like it has more than three frames of motion.
That will probably be my go-to for Last Legend II, the Final Fantasy sendup. But for Last Legend 1, the Dragon Warrior spoof (if Dragon Warrior was possible to spoof, as the games frankly poke enough fun at themselves), I’m just going to push forward as-is. The Dragon Piqha is clearly a Sentinel, so he’s not going to swap out his Conduit.
Just need to add ‘jumping back after attacking’, ‘taking a hit’, and ‘blocking a hit’, and I’m good to go to start coding.