Normally, I would put off the Captain’s Log post for Friday, but I’ve only got three workdays left in this month, and that means I have to make a decision as to what I’m doing next month. And I’m almost 100% sure I’m going to Kickstart Awesome Moments starting halfway through the month. Which means I need to swiftly decide whether I’m retooling the art style, and I need to produce some good art for the Kickstarter itself, including the first draft of the PDF, and a couple of pages of finished illustrations.
The Last Legend engine has basic movement, dialogue, and context-sensitive radial menus:
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.
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.
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.
Put together a forest tileset in one day, added a couple of refinements to the platforming controller. Candy Raid: Side Story is still in the tinkering phase. However, I decided to stick to one shot type (the star), and one small “world” (Just the forest). When I switch to “draft” mode, the goal is to create a series of puzzles that reward you with candy, and a victory condition that requires some (but not all) of the candy. I feel like I’m done tinkering with this for now, though.
Yesterday, I had a small epiphany.
When I make a ‘screen’ for my Dragon Egg graphics, it consists of two parts: a background that I just draw full size, and a foreground I assemble from tiles. You can kind of see how it works in this gallery:
Making “fullscreen” backgrounds in 160×90 with only four colors is… very doable. I get a lot of fun out of coming up with interesting forms and arrangements, ‘Seussian’ proportions, etcetera. And this reduced level of details keeps me from getting bogged down.
Which got me thinking. I made static, painted backgrounds for my JRPG demo a while back…
What if I made my JRPG as a dragon egg game? What if the reason I never got anywhere with the prototype was I got too bogged down in the graphics, both the creation of HD graphics, and the busywork of making them behave in Unity?
Today, I tried recreating my RPG background in 160×90 with the Rainboy palette, and dropped some Cache Miss/Crossover Arcade characters on it to see if it would work as a comic backdrop, and…
You know what? I think I’m going to make Cache Miss settings just like this, unless I specifically need a tileset for a platformer like Candy Raid: Side Story. And I think this week’s objective is to tinker a prototype of a Dragon Egg JRPG.
I’m also gonna scope back. We’ll make the first Last Legend not a Final Fantasy sendup, but a Dragon Quest sendup, with only one protagonist, the Dragon Warrior.
If the engine works and is fun, we’ll do an Itch release, and then think about Kickstarting HD editions with hand-drawn art.
This week, my main objective is to push towards getting a day job. My secondary objective is to tinker, presumably with a Dragon Egg RPG, and my tertiary objective is to build up Cache Miss backgrounds, sprites, and strips, so that I can launch the comic in the next few months.
Today, I’m updating more of the placeholder art to HD. Sadly, I’m not keeping the proportions precise with the 3D models. But that’s almost necessary. To get the project done, I have to abandon speed bumps and do the absolute best I can within the following constraint: only the best I can do and still actually finish the project. “Second best and finished” is better than “first best but only in my head.”
Anyway, I need to get my momentum back. As an artist, there’s two kinds of work I can do: creative work, and busy work. Updating the art to the HD is busy work: all the creative decisions have been made, I merely need to execute on them.
When my momentum is dead, busy work is the best way to get it back. I can do it in the evening when I’m tired. I can do it when my brain has stopped working. I get a peak of maybe one or two hours a day of creativity, but once the creativity has happened, I can spend hours and hours executing on it if necessary. One of the reasons I avoid commissions is I resent selling my single hour of creativity for someone else’s use. I’m no Tolkien or even Lewis. My creative genius is nothing to write home about. But it’s mine, dammit.
My priority is to get an orc up and running, as I have now all the animations needed for the dwarf. I’m hoping to hit the ground running on that Thursday. Any time I have left today for Vargenstone, though is going to be making HD versions of placeholder art, because I can do that.
This last week I did what I wanted, when I wanted, and nothing else (except what was required to keep my family and their animals alive, of course). And what I wanted turned out to be the basis of a platforming sequel to my hit game Candy Raid: the factory.
This gif has a lot of little things worth talking about, but let’s get back to it.
I need to either search for a day job, or else gear up to pay my bills with my projects quickly. Option 2 means running a successful crowdfund ASAP. The only project I have that is close to ready for that is Awesome Moments, my Bible Story book.
Because of my social media fast, the earliest I can run the Kickstarter in question effectively is March. If I choose to work my butt off on Hat Trick, or my bestiary, or on this little Candy Raid platformer, I can hypothetically have either of these projects Kickstarter ready by then. But I have to be 100% committed to the project. And my history of underestimating time to completion on projects leads me to believe I’d need at least two months to get either of those ready. And even a successful Kickstarter wouldn’t disburse funds until April.
Which means I need to hunt for a day job.
Sucks to be me, but I’ve been employed at dead-end day jobs for 15 years, and I’ve done the starving artist thing for 6 months. Being jobless definitely helps my projects, but not by giving me more time, but rather by giving me consistent time. If I can get something with regular hours, I should be able to keep my productivity close to the same.
If not, such is life. So let’s talk about how we are going to change our approaches to Vargenstone and Everything Else as a result.