next »

[TheGrandHero]

Dev Log #24
Speak Your Mind

My day job makes it difficult to set aside time to work on projects like this. I have to be careful to budget my time, or else I'll end up getting a lot of work done for awhile but then quickly burn out. Still, over the past month or so I've managed to get about thirty minutes to an hour of progress a day. It doesn't seem like much (and really, it isn't) but it does add up after awhile, so long as I'm good about where I spend those precious minutes each day.

I've been messing around with the battle system for a long time now, and that makes sense. The battle system tends to be what really engages people when they play an RPG, and it's where they're going to end up spending a lot of their time. But a video game is more than the sum of its parts. A good RPG needs more than just a battle system. It needs a story to frame the battles you're fighting and give you a reason to fight them. To that end, I've switched gears for now and am plowing ahead on changing the game's scripting engine from mere partially-programmed ideas to a reality.

Previously, I'd mentioned wanting to make a "vertical slice" to show the game off, but I've never really used that method before. Instead, I've fallen back to the same work flow I used on the first Another Star: starting at the beginning and working my way to the end. The first cut scene is scripted and plays, with characters moving to their cues and going through their dialog. After so long, it's really amazing to watch play out, especially since the last game's scenes were so simple. I'm working hard to make sure that the game's custom scripting language makes it easy to generate and tweak the content very quickly so that I can make the absolute most of my time.

One of the things that I've done during this process is move the character portraits up out of the dialog boxes. This allows room for a few more letters to be visible in each line. As you can see, the portraits aren't static. The mouths flap, and when they're not talking they even blink in sync with their sprites!

I also made the portraits bigger. Much bigger. I was inspired by looking at Shining Force II which had these huge, vibrant character portraits. I wanted the characters in this game to be able to be likewise endearing, even though there wouldn't really be quite enough room in the system's VRAM for portraits this big without sacrificing some of the area graphics. I'm not 100% committed to it yet, and the first few portraits are in need of tweaks, but I kind of like how they look so far. My only worry about the size is that they're going to obscure what's going on beyond them. The characters on screen have various actions that play out with their dialog, and I don't want their portraits to always be in the way.

I'll share more from these early areas of the game as I make progress. In the next dev blog, I plan to write about the often overlooked process of nailing things down to avoid working on them forever.

[qMopey]

really happy to see more of your posts! 

[TheGrandHero]

Glad you're enjoying them! I'm hoping to be able to make them more regularly.

I may also start posting smaller updates that aren't the main "dev log" entries. There were a lot of little things I did over the past few months that didn't really warrant a big entry, but I still could have shared a screenshot or two for them.

[velocirection]

I didn't read any of that yet because fist I wanted to say WOW looking really great :D

[Ishi]

Ooh nice to see updates on this! I just went back and relistened to the gorgeous music in your post about the FM synth system - still a huge fan of that sound.

[telltaletypist]

Having character portraits blink in sync with their sprites is such a wonderful touch. I don't know why, but I love it.

[TheGrandHero]

One of those mini-updates I promised:

Something I worked the past few days to add just to see if it's worth the trouble is 8-directional sprite facings. Only a very small handful of 8-bit and 16-bit games actually did these, so it's really stretching the aesthetic. Earthbound is the only RPG I'm aware of that used them in that era, and that's an SNES game. It's also doubling the workload right out of the gate. Not sure if it's going to stay.

But it does look pretty.



I also implemented subpixel tracking for entities. This was more common; Super Mario Bros. on the NES even used it, although tricks like dropping movement on certain frames were how it was usually handled. The subpixel movement makes it easier to deal with things like slower-than-1-pixel-per-frame entities and it really smoothed out how diagonal movement looks so it's very likely staying for sure.

[qMopey]

Breaking the old limitations as long as the underlying aesthetic remains in-tact is, in my opinion, very smart and I think you should keep doing it!

[airman4]

Awesome work there
sounds legit !

[TheGrandHero]

And here's a test with an NPC to see how it looks when they have 8-directional facings and track the player's movement.

Still like the way it looks, but it may be a bit too much for the aesthetic, and I'm extra worried about the workload creep it'd add to the project.

[Ishi]

Still like the way it looks, but it may be a bit too much for the aesthetic, and I'm extra worried about the workload creep it'd add to the project.

Is it something that could be reserved just for the player character, or for specific important NPCs, to reduce workload? The additional directions look like a really nice addition for the player character particularly.

The GBA Golden Sun games did something smart with the character directions. Player characters had a full 8-direction set of sprites. NPCs had only 6 directions to reduce the amount of variations needed.

There are some examples in this post: http://forum.goldensunhacking.net/index.php?topic=2735.0 The important bit of text refers to the compass diagrams in the image: "Generally, PCs use the red, blue, and purple directions, while NPCs use red and green".

And a screenshot here, where the NPCs are using their slightly-diagonal directions, while the two player characters (bottom middle) use their upwards and diagonal-down directions.


I think this 6-direction system for NPCs is really smart. For an old-school 4-direction NPC you'd draw three unique sprites: up, down, and side (which is mirrored to achieve left and right). A 6-direction NPC still only needs three unique sprites - diagonal up, diagonal down, and side, but all three are mirrored to create the 6 directions. So doesn't really require any more work or memory compared to 4-direction NPCs. I also think it can look more natural to have the characters angled slightly off-centre rather than looking directly up or down.

This may not fit the aesthetic you're going for, but may provide some inspiration on how to approach the problem!

[TheGrandHero]

The Golden Sun solution is one I've considered before; I've always thought it was a pretty smart approach to how they handle their NPCs. Not sure how much of a difference it would be for straight pixel art versus the pre-rendered sprites that Golden Sun used in the GBA games.

It's also not something I think I've ever really seen in another mainstream game, let alone one from the era I'm trying to emulate. No single game in the 8-bit / early 16-bit era would do everything I'm trying to do all in the same game at the same time--RAM would become a huge issue at some point. However, I'm trying to have at least one "forerunner" game I can point to for each effect I use. In part for the faux "authenticity" of it, but also so that I have something to study to see how the developers of that era tackled the issue and came up with a workable solution.

(That said, I'm not above tossing the old ways aside for the sake of the greater good.)

[qMopey]

I think it's quite smart of you to be able to selectively move beyond old technological limitations

An aesthetic is about taking inspiration and crafting a particular style according to your taste. It's not merely copying, as you've already demonstrated. Keep it up! These are very exciting to see!

[TheGrandHero]

Dev Log #25
The Perils of Indecision

Did you ever have to make up your mind? Pick up on one thing and leave the other behind? Did you ever have to finally decide? Well, that’s how the song goes, anyway.

It can be a difficult thing, though, choosing one path out of many. This indecisiveness can also delay or even kill a project. In my experience, one of the biggest sources of eternal “feature creep” is the failure to draw a line in the sand. “This much and no further.” It’s so hard because doing so means closing out so many more possibilities! So many great things that could have been will now never be!

Here’s a big case in point. This is the palette that I used for Another Star:

Each color is an 8-bit RRRGGGBB value, scaled to NTSC tolerances (so white is less than 100% and black is more than 0%). These sixteen colors went a long way, but they didn’t happen overnight. Even with just sixteen colors to decide upon, and a mere 256 possible values to select from, I went back and forth a lot during the game’s development. I didn’t add the mid-gray color until the game was nearly complete!

However, changing the palette for that game wasn’t a big deal. All the game’s graphics fit into a single image—just 128×128 pixels in the game’s initial release, raised to 512×512 with the new graphics used in the Steam release. Replaced a color? No big deal! I could just edit around it in a few minutes or so.

This game is different, though. The main player character’s sprite sheet alone is about half as big as the first game’s entire graphics set. And that’s just her area map graphics! It doesn’t count her in-battle graphics. And NPCs thus far currently have 128×256 pixel sprite sheets. Notice the plural. “Sheets”. Each one has their own, so changing a single color means I have to edit multiple files, a task that only gets more difficult as time goes on.

A minor change isn’t a big deal, mind you. If I tweak a color in the palette, the colors are stored in a special palette file and that change is applied at runtime by the game’s graphics engine. The sprite sheets themselves don’t contain the colors when they’re saved for use in the game. But if I decide to remove the purple and make a green? Yeah, that’s a big deal. I have to go back to all the characters that used that purple and decide what to replace it with, which may not even be the same for every instance it appears. It means I have to rethink everything up to that point!

Now, this game is a little different from the first. The imaginary VGS console’s graphics are largely based on the Sega Master System, and like the Master System this game actually has access to two palettes, not just one. While the first game stuck with a single sixteen color palette for everything, one of the palettes in this game changes quite regularly based on the room or battle arena and such. However, since there’s only one palette for characters, outside of the special case of their in-battle graphics everyone has to share the same sixteen colors in the second palette (and for sprites, one of those sixteen is always transparent). As much as I hated it, the time came to make up my mind. I had to choose the sixteen color palette (really fifteen, remember) for all the characters in the game to share. I expected it would only take a few days, but I ended up agonizing over it for a good two weeks.

Here is the palette for Another Star 2:

Even now I’m not 100% happy with it, but here it is. This is what I’m using going forward. There will likely be a few tweaks here and there, but only that. Tweaks. No more rehauls. I’ll never be completely happy with it anyway, especially since the limited RRRGGGBB master palette lacks the exact colors I often want to use. But it’s nice and bright and I think the colors really pop, even if they’re a slight bit more saturated than I would like.

It’s strange how I started with the first game’s palette and toyed with it over time. At one point, I actually trashed the palette and went at it anew from scratch, only to end up coming back around to pretty much the exact same colors.

It’s not far from the basic choices of the first game, however I added a hint of blue to the grays to give them a nice cool quality and eventually ended up merging the light gray with the light blue and added an extra mid-tone gray. Most of the colors ended up getting a touch of blue, which does end up somewhat extreme since, with only two bits for blue, there’s only four levels for the blues to be. I toyed with the idea of sacrificing that extra gray or the bright purple for either a richer red (the red I have now is practically a pink) or for a light yellow-green for the greens and yellow to ramp up in to.

There are a lot of browns and grays in the palette, true, but I wanted to be able to represent a wider array of skin tones than we normally see. The midtone gray is likewise used to represent an ebony-skinned character. Earlier versions of the palette lacked a good tone for him and his color ramps clashed pretty badly as you might be able to see in some of the long past videos I posted. I could have just made his skin brown, but I’d rather he get his proper character design in his sprite form.

What’s interesting though is that as I finally nailed down the color palette with one hand I was gleefully opening up a can of worms with the other. On a whim, I decided to add two new “features” to the game engine. One is a minor change, the other is a major change.

The minor change is that characters now have a subpixel resolution to their position. That is, their actual position within a room can be “between” two pixels. This is not something foreign to 8-bit consoles. In Super Mario Bros. on the Famicom and NES Mario has a 1/16 subpixel position in order to tighten his handling and smooth out his acceleration and deceleration. However, it’s a super odd choice for an “8-bit” RPG like this, which is strange enough being a non-action RPG with movement not limited to a grid. Most games of the era didn’t bother, or else they used tricks like alternating each frame which axis got an extra pixel of movement when moving diagonally. I originally was doing the latter, but I ended having to implement different solutions to different areas where it was needed (diagonal movement vs. slower movement on the overworld, for example) and there was an ever-expanding bundle of extra code to deal with edge cases.

Going to subpixel movement made the handling feel pretty slick, especially when you’re using the thumb stick instead of a d-pad. I was unsure at first, but it actually simplified the flow of the code in the end so it’s likely here to stay. Characters have a whopping 120 subpixel resolution, which as the lowest common multiple of 2, 3, 4, 5, 6, and 8 gives a lot of granularity. (Adding 7 to the mix raises the multiple to a whopping 840, which does not fit into a byte.)

The other change seemed more innocent at first, but ended up being far more dramatic…

I decided to try giving the characters eight-directional facings just to see how it played. Only a very small handful of 8-bit (or even 16-bit games, for that matter) bothered doing this. The number of NES games that did it can probably be counted on two hands, if that many! Earthbound is the only RPG I’m aware of that used them in that era, and that’s an SNES game. It’s certainly stretching the aesthetic, and I’m not sure that I like the results. Not to mention it’s doubling the sprite graphics workload right out of the gate.

But I’ll be derned if it doesn’t look pretty in action.

This game has been in production off and on for some four years now with little to show for it. I have to stop adding things on a whim and decide what’s important. The scope of this game began big enough as it was, especially as a follow up to such a simple little RPG. I can’t allow it to continue growing and growing forever. As Derek Yu once pointed out, finishing things is a skill in and of itself, and one I’m admittedly not very good at. Eventually I have to draw that line in the sand. “This much and no further.”

Eventually…

[Ishi]

Here is the palette for Another Star 2:

I love this palette, and I love how you've represented it! Each ball mainly represents one palette colour but also shows which of the other palette colours could be used as highlight and shadow.

All those extra blue tones make a huge difference, it's a big improvement over the first game's palette. Good work

[TheGrandHero]

Yeah, I tend to feel like just showing a palette by itself doesn't usually give you too much information about it, as counter-intuitive as it might seem. Giving each color a context like this helps. A few color ramps probably would have helped as well, especially with the colors that can go in more than one direction like the light blue/gray, but maybe I'll save that for an entry specifically about the game's palettes. I would like to go into a little more depth about why I chose some of these particular colors.

In any case, I do prefer this game's palette to the first, but I do miss some of the subtleness of the original game's colors. Eventually I'm going to have to finish this game so I can go back to selecting a wider array of colors. It's frustrating when you can't get two colors to play together the way you want to because shifting any one R, G, or B value in either direction makes such an extreme change.

[TheGrandHero]

Dev Log #26
Path of Least Resistance

A whole lot has changed in the world since my last dev log entry. I wanted this to be the year that I finally got this project back on track, but it seems life has other plans. My day job is in retail. When the world hunkered down to brace for the initial impact of Covid-19, I was not stuck at home in a lockdown with lots of spare time to advance my own personal projects. Instead I was working overtime, doing my best to unload trucks and push food to empty grocery shelves. And that daily responsibility only continued to eat into my free time as I moved up through two promotions and the extra work load of the American twin holidays of Thanksgiving and Christmas.

Still, I've managed to eke out a little progress these past months that I wanted to share today.

Around the time of my last dev entry, I took some time away from this project to dabble in some NES homebrew development. Though I grew up with the system in the 80s and early 90s, I'm not wild about the system's graphical limitations. But here in the United States it's the most widespread 8-bit video game console, and thus the easiest to produce content for if you want people to be able to run it on actual hardware. I decided that if I really wanted to develop for an 8-bit console with strict hardware limitations, I should make something original for a real one instead of shackling Another Star 2 to an imaginary one. Here's a couple mockups I did of various ideas I had.

Eventually I began to toy with the NES's 6502 to see what came of it. It can be hard to wrap your head around programming in assembly on a CPU that is limited to single byte values and only has three general purpose registers, but after a lot of effort I actually managed to get something up and running, even if it never grew into anything. In the process, I learned something important.

It is often observed that the shortest distance between two points is a straight line. With the NES and its 6502 I had so little space, memory, and power to work with that I had to force myself to simplify how things worked in order to get a result. Other times I had to realize that, even if a solution to a problem was awkward, if it already worked just fine I needed to leave it alone and move on because a more "streamlined" version would not only take more time to write, it would often require more space and precious CPU cycles.

There's a lot of odd choices I made early on in Another Star's 2 development. Many of them derive from the game's stricter adherence to the original fake limitations of the game. However, I've had to tell myself to leave those decisions alone. They've already been implemented. They already work. It's time to move on to the next thing. I can do it different in another game.

An excellent example of this is a feature that I'd been putting off for a long time. Whenever you change a character's weapon in Another Star 2, I wanted the sprite to match. This works by giving each weapon its own unique set of sprites. The characters then have "attachment points" each frame to anchor the weapons to. But though the sprite data already contained a way to store the information for these attachment points, I'd never gotten around to implementing them in the sprite editor I made. For weeks, I went back and forth on how best to implement a way to drag and drop pieces, and thought in-depth about what interface buttons I would need to determine whether I wanted to select sprite pieces or attachment points, and so on.

But that's too much work! No, I forced my way through and just assigned selection to a hot key and made placing and renaming attachment points a function of the editor's existing right-click menu. Boom. Probably less than half a day of work and I had weapons up and running.

Same with per-frame event triggers. I wanted to know which frame of animation during an attack is where it "connects", hitting the opponent. It wasn't going to take long to program the editor to save the trigger name as a string to an existing string library in the sprite file and then cache the trigger names before each battle to check against—

No, no, no. That was going to take too long. Instead I went with an old idea I had and used the 32-bit integer value intended to store the index of the trigger name as the trigger itself in the form of a four character ASCII string. "HIT " becomes a four byte sequence that I can check as the hexadecimal value $00544948. It's just as efficent since it's still just comparing an integer to an integer, and I cut out the need to cache anything. I think it took me longer just now to explain how it works than to actually implement it.

It's easy to get caught up in trying to do things "the right way". There are obviously times where that's important. But other times, you need to focus on just getting the thing done and moving on. I'd like to make other games one day, after all.

[bayersglassey]

This looks amazing!..
It's subtle, but one thing which stands out are the "standing animations"... it's so hard to make little single-pixel changes to body parts to make it look like someone/something is breathing and moving their limbs while standing in one place, without going crazy and just jiggling around. But you've really nailed it. I can't tell if there's an underlying technique to it, like a specific goal, maybe like "separate the sprite into quadrants and try to more or less move each quadrant 1 pixel in a different direction than the other quadrants"?.. can't put my finger on it.

[TheGrandHero]

Can't say I have any real technique "goal" per se when it comes to animating the characters. A lot of it is just understanding and following through with the basic principles of animation. I have a background in animation to begin with, so that really helps. A lot of the designs are sketched out before I begin doing the pixel art, and I often don't initially think in terms of pixels, which helps I think. For me, the little touches like secondary animation are what really bring the characters to life; the way the motion of hair and clothing and such follow behind the character's movement so that they don't look like stiff bits of plastic.

Here are some good examples from some early animation tests:

Heck, notice how even when the character is standing still, their hair still moves a bit. It's exagerated, of course, but when you're working with pixels sometimes you have to oversell it just a little to make it work. Understanding the basics of "sub-pixel" motion in pixel art helps for this, even though I use it relatively sparingly in this game.

It's also important, to me at least, to focus on some of the subtle motions of the character in order to make them look believable. The battle sprites in this game are pretty big, so they look best when I pay attention to details like this. For example, in the clip I shared in the dev log watch the character on the right with the sword. Notice how their shoulders aren't static. They move in interesting ways to match the motions of their body and arms. It really breathes life into the character. Shoulders are super easy to overlook even beyond pixel art, but they're super expressive.

Beyond that, a lot of it is just experience and trial-and-error. If something doesn't look or feel right, I'll usually play with it. And if I can't make the pixels look right, sometimes I have to go back to the sketches. Even if they don't match the sprite art 1:1, looking at the freehand line art often gives me clues into what I'm doing wrong.

[TheGrandHero]

Dev Log #27
The Full Arsenal

The standard go-to action for any RPG is the humble "attack" command. Sometimes it has other names, like "fight" or "strike", but the meaning is the same: beat the crap out of your enemies with whatever happens to be in your hand. It's the bread and butter of 99% of RPGs, western and eastern alike. Like the majority of games in its genre, Another Star 2 toys with the mechanics of the "attack" command, but it doesn't fundamentally change it. Instead, it goes the tried-and-tested route of augmenting your standard attacks with supporting commands.

Here, at last, is the item interface in battle. Selecting "item" icon from the character command menu brings up a palette that contains any items in the party's inventory that can be used in combat. I went back and forth on the design for this during the game's development. At one point I was going to just have the game switch to the normal inventory screen but ended up deciding against it so that there's not an abrupt change of interface. As in the first game, only items that can be used in battle will show up, so you don't have to spend a bunch of time sorting through other junk to find what's useful.

There are some limitations when it comes to items that you'll have to be mindful of when you're deciding what orders to assign to your characters. For one, two separate characters cannot use the same item in a given round. That may be a good reason to buy a second healing item just in case, even though each one has multiple uses before they're consumed.

In the first game, using an item meant your party always went first. This was to counteract the fact that the "party leader" was the one who used the item, and so long as he wasn't KOed the party leader was always Tachi, who was the slowest by far of your three party members. The fact that items guaranteed first move advantage added a layer of strategy to that game, and it also encouraged them to chance pressing their luck just one more round before healing, knowing that as long as the characters survived they would always be able to use Healing Dust to restore their HP before the enemy could act again. Even though party members now act on their own, I may end up reusing this idea so that using an item gives a character a significant boost to their order in battle. Just be warned that in this game, some enemies also have an inventory of items that they can use!

Items in Another Star had a wide range of effects, and that is equally true of the items in this game. They're more than just a few healing items to get you by. Many items have unique effects and can prove especially useful against enemies. Because of this, it wasn't really possible just to have a simple "heal this much" property for items, so the past week or so I spent implementing the scripting needed to let my imagination really run wild. I also wanted to make sure that I could easily add graphic effects for that extra level of polish using a very simple particle system. Here's what the uncompiled code looks like for a healing item, for example:

Code:

function @Wafer1
	get $User from user
	get $Target from target	

	narp 0, "$B:Actor$ nibbles on a vanilla wafer."
	batanim $User "Use" and resume
	await $User "USE"

	sfx "_Heal1"
	rng? 10 to 15
	restore $Target hp by result
	
	epalette green lime
	psys "effects.sprite"
	emit "SmallSparkle" at (-10, -20) for 30
		pvel (0, -4)
	emit `` at (10, -20) for 30 after 5
		pvel (0, -4)
	emit `` at (0, -20) for 30 after 10
		pvel (0, -4)
			
	finish

Much of the scripting and code is easily carried over and reused for spells. (And originally, spells were just going to be another kind of item from the engine's perspective.)

The spells in this game are planned to be more diverse than those of the first, with a wider range of spells than just your basic elemental attacks and generic buffs/debuffs. How they're planned to work and interact with enemy scripting is likely to be the subject of the next dev log I write.

So there you have it, the item system in motion.  Items and spells are a huge part of the game's battle system, and it's really cool to see them up and running. Now pretty much all the player's options are on the table in the game's current version. Whether it was wise to work on these features now like I have instead of churning out a few environments to explore is yet to be seen, but at least I'm making forward progress for a change.