Choosing a theme is superior to making a resolution. This is because when presented with a fork in the road, it is easier to choose the branch in keeping with your theme than it is to force yourself to take the branch you resolved to take, whether it is there or not.
Consider instead of choosing a theme for a year (or a resolution for a year) choosing a theme for a season. E.g. instead of “I will do 30 pushups a day”, prefer, “this will be the Winter of pushups!” or better yet “the winter of Health!”
I take a definite interest in self-improvement as I fall short on a number of fronts. Fortunate man I, Christ has suffered and died for my many evils. But I still want to better myself for a number of reasons. First of them is: it is good to be good. But more importantly, the better a man I am, the better it is for those I claim to love.
My habit has been making monthly goals, not yearly resolutions nor seasonal themes. And the system has been fruitful, but not as fruitful as I think is possible. I don’t know whether “seasonal themes” is the answer. Right now, I have taken ill and am preparing for sleep, and lack the mental firepower to usefully analyze it. But I have a notion it is more in tune with my natural rhythms, simply because my one-month projects always manage to expand to 3 months. And I wanted to note it down so I can look into it tomorrow, or whenever I am awake and my mind is clear.
The Action Points now charge up automatically, based on the Speed of the character, which is the only stat thus far implemented. As a safety harness, the program keeps track of how fast all the combatants are and ensures that the speed at which AP bubbles charge is kept to a manageable level. I don’t like how I implemented my safety harness. But hopefully we’ll never even run into it.
Slow but steady progress on this game. I’m not a fan of how slow it is going. But we march ever onward!
Just to show that Speed does, in fact, play into the equation.
And I’m sorry, I can’t resist posting a full-color screenshot when forced for any period of time to contemplate the gif compression. Not that the gif isn’t doing its best!
So now the action point orbs reflect the player’s Action Points, and the player switches between charging and ready animations based on his AP total. I also started building the heart, but I’m probably just going to leave it sitting there for a few days while I work on other stuff.
My wife desires coffee. I think I shall appease her, and procure some for myself as well, and then take stock of where I am and what I can do next. This week’s goal is to continue tinkering on the RPG. In December, I may switch to making a kids book, switch to editing my comic book, or make a serious attempt to produce a game prototype based on my November tinkerings. We’ll burn that bridge when we get to it.
And now for something completely different!
Duck Comics, and the resulting TV shows inspire me. Not directly, as in, “oh yeah, I need to do that,” but obliquely, as in, “that’s very much in line with my goals, and I can see it is objectively of decent quality, therefore my goals have objective potential.”
I like this. I am sadly not going to watch the show due to time constraints and the fact that the Mouse is my sworn enemy, but I like this.
So you want a field in you Inspector that has sub fields. Its sole purpose is to just be a bucket of data, but you have no real need to share it between classes in Unity or have it be universal in any way.
Sounds like a good use for the C# struct, right?
Nah. Unity doesn’t roll that way. You want a plain old class. No inheriting from MonoBehavior nor ScriptableObject. Just decorate that bad boy with [System.Serializable].
Wait, Unity’s default code files don’t include System? I suppose I can see why, as I haven’t noticed ’til now, but years of working with XNA/Monogame led me to not see that coming…
I needed to make a mockup of the videogame I wanted to make. So I started with this:
I just grabbed a background off of DuckDuckGo. After all, there was no way I was gonna keep it. The actual background will be particular to the game.
Still, I wanted to stretch the grassy bit so none of the characters was floating in the air. And it would be nice if the backdrop fit the color palette I’ve been tweaking over the last three years. So I made an attempt to push it closer to my palette, and make it fit the characters. While I was at it, I smeared things around with a rough brush.
I shouldn’t’ve. It doesn’t matter after all. This will never be used in a final game. It’s wasted effort, it is.
Well, Sunday I don’t work on whatever my project o’ the month is. And since work on the background doesn’t count as work on the game, as the final game will have backgrounds made to order for the story, I decided to mess around with it a little.
I have a guy on a screen. He has a waiting, ready, and highlighted animations. I can switch between them at will. The animation system has a compatibility layer so that when I use tweens or Spriter or Spine instead of Unity’s native animation system, my logic code will never know the difference.
Criticisms: I’ve spent too much time making this look nice. I should not have painted a backdrop, but continued using a random pic off of Google DuckDuckGo. I should not have put nearly so much effort into the character animations, since they will ultimately be replaced anyhow.
Next step: actually implementing character speed and Action Points so that the character is not ready or ready at given times. Then, we can worry about whether a ready character may be selected.
Got a little Action Point interface bubble made. It’s charging as I physically drag the slider for its value around, rather than in response to any battle code. But I thought I better put it here as I’ll be away from my computer today and I like to ogle my progress when I’m unable to make more.
My goal over the next few days is to make this mockup happen. A random background stolen off the internet (later to be replaced by my own creations). A party of 4 heroes, perhaps chosen at the start. Action points that charge up. When one action point is full for a member of your party, he is ready and you can select him. Selecting him produces a menu. Choosing an action subtracts the correct amount of AP.
In fact, let’s just have all the heroes be a single Fighter. No enemies. Once we have the Action Points working, we’ll get the menu going. Once we get the menu, we’ll give him enemies to select, and comrades with different speeds so we can make sure selecting ready allies is also in place. Yeah. There’s our tack.
Let’s do this.
Youtube game tutorials have been pimping Milanote as a design tool. It’s sort of a cross between a brainstorming board and a checklist/collaboration tool like Trello. Suits me! So I started designing my RPG on Milanote and…
Looks like I can’t finish the design without paying. That’s fine. Everybody’s gotta make a buck. I get that. Though it does mean as I am currently broke, I can’t rely on Milanote. Sorry, peddle your app elsewhere, but I can’t buy from you. And then..
Turns out I can’t access or modify my design offline, even though I’m using an app rather than the web interface. The app is just a lite web browser that only goes to the web interface.
That’s not fine. I (proudly) live out in the sticks. Internet is not reliable for me. I can’t afford to have my design live solely in the cloud.
Looks like it’s back to a folder full of markdown for my design documents. Sad, though. I like the interface here.
Though, hey! That reminds me. I did get a decent amount of work done using Trello to manage my checklists. Thanks for reminding me.
We are inching ever forward. The climax is storyboarded, all that remains is the denoument. The storyboard may well be finished this week. Not sure how it’ll go after that. Probably I’ll do a print proof using the storyboard art just and, say, 10 pages of original drawings just to give room for any extra I have to add in the second draft. This way we’ll see how bad my margin error is. Then take a month or two off from this project to let it settle before working on revisions.
I continue to tinker around the edges with my Piqha RPG. If it works out well, frankly it makes more sense for me to tell future Hat Trick stories as mini RPGs. But at this precise moment it’s more me feeling an unmet need to write a little code. I think I may duplicate last year, though, and turn December into an attempt to get the prototype of the RPG up and running. We’ll see.
BIG note: one of the advantages of using e.g. LeanTween instead of the Unity Animator, according to this video, is performance. Whenever a UI element changes, the canvas gets dirtied/refreshed, which causes a performance hit. This is true regardless of whether you are using the Animator or LeanTween; the difference this video calls out is that the Animator dirties a canvas every frame whether it does anything or not!
Except not any more. This was a bug, and Unity has since fixed it. Repeat: Using a tweening library for UI animations no longer conveys a performance advantage.
However, the dirty/refresh system still leads to performance-boosting shenanigans: using multiple canvases in a single scene isolates dirty UI elements from each other, resulting in fewer objects processed per refresh.
LeanTween is still a useful tool in your kit, especially if, like me, you don’t especially like Unity’s animation tools. But there’s no easy integration between UI button state changes and LeanTween, and it’s good to know I can use the intended solutions as intended without shooting myself in the foot.
Let’s start with Wizardry/Final Fantasy as our template; later we shall diverge.
You pick a party of 4 guys from 6 classes. We’ll call the red mage a ranger, the white mage a cleric, and the black mage a sorcerer, to stay honest to the D&D roots of the game. Always regress toward the source! We’ll throw in a generic piqha to use for NPCs, and a rat piqha to use for enemies (for now).
So, your class distinctives will be a ScriptableObject. We’ll make critters and, perhaps, NPCs work the same way, in case we want to make a game where you can attack innocent bystanders.
For now, we’ll do a single ATB bubble. When your bubble fills, you are ready to attack. We’ll want to create an animation wrapper that can present our combat system with the same interface whether we’re doing Spine shenanigans (in the future) or LeanTween shenanigans (now).
I want combat moves to be things. Like, you have a list of moves your hero could use, and then you equip the ones you want to have access to in combat. Maybe a fully empowered character can have as many as 8, but a low level character tops out at 4.
Interfacewise, they should form a radial wheel around a selected character. This is optimal for touch (just press the icon), for gamepad (just pick a direction with the D-Pad or thumbstick), or computer (click and play!),
Resources for stuff like spells should be less magic points and more either Action Points (but maybe let’s skip that for this first game) and the opportunity cost of filling in one of your action slots.
Even our bruiser should have different sorts of actions he can choose from. By all means, have a generic attack that everyone can do, but give our swordsman some shenanigans he can pull!
For starters, we want to not bother overmuch with story or setting. Just make a series of combat encounters. Once the combat is fun, we can start building on top of that.
So we’ll have a character selection scene, and a battle scene. However, my plan is not to have battle scenes per se, but run all encounters on the map, like Chrono Trigger, so we need to keep in mind that the battle scene has to support non battle activities.
Awright, let’s steal code from my previous attempts to get ourselves a head start! Here’s a dialogue box.
Mostly taken from my previous RPG attempts, but I’m using LeanTween instead of an animator to animate my text boxes, etc.