Last Legend Devlog: What Next?

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.

Which is why I made a big deal of it here.

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.

And… done.

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.

Captain’s Log 0210219.142: Now Let Them Fight…

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.

So what’s the plan, stan?

I tried the Series 7 again..

I love the extra life and the shadow depth that a brush lends my work, but with that life comes a sensitivity to the faintest tremors in my hands that don’t even seem to exist when I’m using the tombows.

Here’s the same pencils, inked with the tombows, and then given a hurried color job.

My Series 7 has a split tip, which Mr. Jesse White, who extolled to me the virtues of the brush, has recently complained is increasingly a problem. So it may be I have a defective product. It may also be that I simply need a lot of practice to master the tool.

But! There is something else.

Continue reading “I tried the Series 7 again..”

Last Legend 1: Dragon Piqha

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.

That’ll do.