Category Archives: Another Star 2

Posts and dev log entries for the sequel project to Another Star.

Another Star 2 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…

Another Star 2 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.

Another Star Dev Log #23: Issuing Orders

Wow, it’s been a long time! I guess I should clear out some of these cobwebs before I continue on. In any case, rest assured that I haven’t given up work on this project, although my current day job and a freelance project are taking up most of my free time. It’s hard to make progress when you feel drained all the time.

Now, in a previous entry I mentioned that I was seriously considering ditching the “omni-battle” system from the original Another Star and replacing it with a more traditional battle system where you can issue individual orders for each character. As those of you who follow me on Twitter should already know, I ended up implementing this change. Part of me is sad to see the omni-battle system go, but I don’t think this is the game for it. Maybe I’ll get to reuse and perfect it one day in another, smaller game.

In any case, you now tell each party member individually what they should do for a given round. You can only target one enemy normally, more like most players will expect. You’ll also notice a percentage displayed along with the targeted enemy. This is the hit chance, and it changes depending on the difference between the agility gap between the attacker and defender.

Note that if a combatant’s target is eliminated before they get the chance to attack it themselves, they don’t automatically select a new target. However, they don’t lose their turn altogether. Instead you’ll get a notice that they are deciding on a new target, and their turn will get pushed back to the end of the queue for the round. This should encourage you to be more tactical with your targeting decisions, while not punishing you too harshly for not micromanaging every single turn.

Another neat addition to the battle interface is that numbers now bounce into view more naturally, although it means that there are going to be far more sprites on screen than there should be. As it was I was already bending the rules, but the little damage boxes I was using before were kind of distracting and didn’t read very well. Yet another sacrifice for the sake of improved gameplay.

You’ll also notice something else really cool, and that’s the little flames that surround the characters as their turn comes up. These are called spirit points and they work mostly like magic points in other RPGs. Gone is the hit point based magic casting of the first game. You spend spirit points to cast spells now. Spent spirit points appear as dimmed flames. Spirit points are difficult to recover, so you’ll want to manage them wisely, especially in the early portions of the game.

That covers most of the changes that have been implemented over the past year or so. Not very much progress, sadly, but hopefully it won’t be nearly as long until the next dev log.

Another Star 2 Dev Log #22: The Shape of Music

As mentioned in previous dev logs, Another Star 2 uses a real-time software synthesizer to generate its music and sound effects as you play. This required me to program a special tool called FM Pipe Organ that I use to set up the sound of the “instruments” and actually compose each track. It’s a little buggy in places and lacks a lot of helpful tools that most composing interfaces provide, but it’s good enough that I’ve already put together quite a bit of music, some of which I’ve shared in past dev logs. Granted, there’s still a long way to go, but the music is already shaping up pretty well in my opinion.

In the early stages of developing the synthesizer, I’d get lots of audio pops and other artifacts. It’s hard—and, in some cases, rather impossible—to tell what’s going on just by listening. Thankfully, sound is a wave, so it’s fairly easy to represent as a winding line that maps the waveform over time. To debug the synthesizer early on I would record the output using whatever sound editing software I had on hand at the time, and then go peek back at what the waves looked like. I often continued to do this whenever I made a new instrument setting and was trying to get a specific shape for the waveform. Even back then, I realized how helpful it would be to have this capability inside FM Pipe Organ instead of having to rely on an outside tool.

FM Pipe Organ oscilloscope visualization

The hills are alive.

This past week I hastily added a handy little oscilloscope visualization to FM Pipe Organ. Not only does it show the final left and right audio output that’s sent to the system, it also displays the individual output of each of the eight channels. The visualizations for the individual channels do their best to show the actual timber of each sound by left-aligning the waveforms based on when they pass the zero-boundary while going upward. They further stabilize the waveform rendering by checking multiple passes through the boundary and choosing one based on how close it is to the one before it. This is really helpful for complex waveforms that pass the boundary multiple times in a single repetition and otherwise end up snapping back and forth a lot in the rendering. Sometimes this works and sometimes it doesn’t, but usually you can see the waveform pretty clearly. It gives a really good indication of what the channel is doing and why it sounds the way it does.

Below you can watch and listen to FM Pipe Organ in action, playing a song I specifically wrote to show off what it can do. It’s meant to be used in some of the early hidden areas you can explore, but we’ll see how it ends up used in the final game. It may even end up sounding quite different in the end. Pardon any frame skips or audio pops in the video; they aren’t normally present when I’m not trying to use capture software.

If you watch carefully, you’ll notice that the bottom two channels, channels seven and eight, never do anything. That’s because Another Star 2 only uses six of the eight channels in an attempt (possibly in vain) to avoid sounding too much like a later 16-bit console game. I haven’t fully decided what the limitations for the game’s soundtrack are going to be, but that one in particular is pretty firmly set at this point.

One day, I’ll publicly release FM Pipe Organ for sure, so that everyone who is interested can play around with it. However, I don’t see that happening until after the game itself is released. Like a magician, I don’t want to give away all my secrets in the middle of the show!

Another Star 2 Dev Log #21: Adventures With Friends

Another Star 2 footage

Sally forth!

Adventuring is always more fun with friends. Even the darkest dungeons aren’t so dreary when you have comrades by your side. As noted before, there are nine planned party members for Another Star 2. I’ve completed the map sprites for three of them thus far, allowing me to test a proper party. They all need plenty of tweaks their sprites still need, but it’s a start.

Party composition will be a fairly big deal in Another Star 2. In the first Another Star, the hero Tachi had two companions, giving you a set party of three characters that were with you for pretty much the entire game. However, I really wanted to build on the party mechanics and give the player options to balance the strengths and weaknesses of each party member by teaming them up in different ways. Instead of being forced to stick with glass cannon Tachi, what if you could have occasionally switched him out in favor of a faster and sturdier character that wasn’t quite as strong, and lacked Tachi’s strength buff spell?

I want players to have reasons to experiment and change their lineup regularly. First off, like with most games, each character has their own stats. Some specialize in strength, some in defense or speed, and so on. Second, each character has their own unique skills, a new addition for Another Star 2, giving each character their own flavor and gameplay style. Most RPGs are content with these two properties for characters, but Another Star 2 goes a bit further. As mentioned in an earlier dev blog, each character has their own elemental strengths and weaknesses. You may be able to compensate for these a bit later in the game, but you can’t get rid of them altogether. If you’re headed into an ice cave, you may have to swap your favorite character out for awhile because they’re weak against ice and can’t defend against the hits they’re receiving from the ice-themed enemies. Forth, a character’s guard meter only goes down a small amount at the end of a battle. If it’s starting to fill up, you may want to swap the character out for a bit. Every character’s guard meter goes back down a bit after a battle, even if they aren’t in the active party. Finally, you may not always have access to all nine party members at all times. Each character has their own things to deal with in the wide, wide world, and so they may be unavailable from time to time. You may even be able to send them off on their own mini-quests for a set amount of in-game time, to return with loot and items if they’re successful.

Here’s a preview video that I recorded of in-game footage, showing the current state of the project and letting you listen to the game’s real-time FM synth at work. Give it a view and then I’ll discuss some of what you’ll see.

First off… the glitches. I kept wanting to put this recording off until I fixed everything perfectly, but then the game would be finished and four years would have passed without a single dev log update! The biggest issues to notice are that the animation for the two follower members likes to glitch out because they’re changing speed and direction so often. Sometimes they have trouble figuring out which direction to face and end up walking backwards (this happens most often in the overworld). Don’t worry. These issues will be fixed before release, and I promise they’ll look great as they follow you around the world. The frame rate also tends to skip at points, and there’s some video and audio artifacts, but these are mostly recording issues because my computer isn’t the best. Ignore all of these for the moment, and I’ll get on to the more interesting stuff.

First off, encounters. If you played the first game, you know how the system works. As you walk around, prompts show up above the main character’s head indicating an encounter. A yellow “!” means that you can fight or ignore the battle, while a red “!!” means that you have to accept the battle right away or else you’ll be ambushed. But right off the bat, in the video you’ll see a red “!!!” followed by a yellow “!!” and then a yellow “!”. What’s the difference? Difficulty! Battles that force you to think about how to beat your opponent are great, but if every battle is such a mental workout it gets tedious and boring, and sometimes just downright stressful. It’s nice to spice things up by having some simpler battles that you can basically just button-mash through. Some games do this by mixing difficult bosses with cakewalk normal battles, but that can make the easy normal battles bland and forgettable. Another Star 2 does its best to strike a balance by having a wider range of standard battles. Those encounters with a single “!” are easy, those with “!!” harder, and those with “!!!” the hardest. These happen independently of whether a battle is forced or not, thus the icon changes. When you first enter a new area, maybe you’ll only accept the easiest battles to make sure you can handle them before venturing further and risking the chance of a more difficult forced battle.

(You may notice I’m skipping all the forced encounters, by the way. That’s because the game is in debug mode–and also because the ambush doesn’t properly trigger yet.)

There’s also another type of encounter icon that the game will introduce that aren’t demonstrated because they haven’t been implemented yet, and those are mini-boss encounters. In the first game, mini-bosses were set encounters in fixed locations visible on the map. Another Star 2 will probably still have those in spades, but very rarely you will get a special encounter icon for a mini-boss. You are forced to accept these in order to avoid an ambush, and will be pitted against incredibly rare and difficult foes to further break up the monotony.

Now, pay special attention to the battle footage. If you watch careful, you’ll notice the rat enemies don’t use the same attack animation every time. Every time an enemy or party member attacks, the game will randomly determine if they managed a weak, moderate, or strong attack. You can tell what level of attack they get by how many strikes they make in the attack. One strike represents a weak attack, while three strikes represents a strong one. Strong attacks do higher damage (although this hasn’t been properly implemented yet). You’ll only see the attack levels with enemies right now, because none of the party members have their proper attack frames yet. Critical hits, of course, are a different beast and have their own unique attack animation, but they haven’t been implemented yet either.

Now, one last thing before I go, and this one is a biggie. Another Star used an “omni-battle” system where every attack hits every possible opponent. With Another Star 2 I intended to build on and refine the system by introducing the guard system and letting you choose your party composition, among other major changes. However, I’m seriously considering ditching it altogether and letting you select a command and individual target for each party member, just like a traditional RPG. Another Star is shaping up to have a more ambitious scope than its predecessor, even if it’s not planned to be that much longer in playtime, and I fear the old battle system will feel out-of-place and grow stale as the game goes on. Perhaps I can save all my ideas for the “omni-battle system 2.0” and use them in another, smaller RPG some other time in the future.

I do hesitate to commit to the change yet, though, for a few reasons. The biggest one is that I want to keep that connection to the first game. The omni-battle system was one of Another Star’s staple minimalist design choices. If you can only hit one target at a time, will Another Star 2’s battle system feel too generic, even with all the ideas I am still bringing over from the first game? I also worry that it will slow the game down too much. Battles (usually) played out so quickly in Another Star that they were an in-and-out affair and never ground the game’s progress to a halt. I don’t want Another Star 2’s battles to be something slow and tedious that you would automatically cut out of Let’s Plays and such without a second thought.

What are your thoughts about the battle system, and the project’s current state? I look forward to hearing your input!

Another Star 2 Dev Log #20: Setbacks

They say that the road to success is paved with failure, but it’s also paved with lots of sudden and unexpected detours. You may have noticed that I haven’t posted any dev logs in some time. There’s a reason for that, and it’s not because I’ve given up on the project.

In July of last year I got a new job, and am now working full time. Alas, it’s not in my field, which is really frustrating at times, but it is keeping my bills paid and that’s what’s important right now. Sadly, this means I simply can’t dedicate twenty-to-forty hours a week on this project anymore. Any progress is made in my free time now, and there was even a long period where I didn’t try making progress at all. I’ve been meaning to post about this for months now, but I kept putting it off until I had something new to show at the same time. I shouldn’t have done that, I suppose. I’ll try to get back to making updates semi-regularly again. Sorry about that!

That also brings me to another subject that needs to be discussed here: cutting content. As creators, we usually hate parting with the perfect vision we see in our minds. But we can’t do everything. Whenever you create something, be it video games or books or movies or something else, you eventually have to part with some of your ideas, even the ones you love the most. Some things have to be cut because they would take too long, others because they don’t work as well as was planned, and still others because they’re just not feasible.

Another Star 2: Fate of the Catalyst design document

The original design document for Another Star 2, complete with its original working title.

When I first began work on this game, I wrote out an enormous document. It detailed the game’s mechanics, its world and characters, and most importantly it included a very detailed outline of the game’s story from beginning to end. The document is a little over a hundred pages long (and single-spaced, at that). I knew from the beginning that I would probably have to trim quite a bit of fat to actually finish the game in a reasonable amount of time, and that was before I got caught up in pretend system limitations before rebooting the code from near-scratch! However, now that I have so much less time to do things, I’m probably going to have to cut even more than I had initially hoped. A lot more.

The question is, what are those cuts going to be? The game, as currently envisioned, contains nine playable characters, ten major dungeons, about twice that number of mini-dungeons, and like the original Another Star it includes countless little side areas to seek out that would consist of just a screen or two. So where do I point my knife? Should I reduce the number of playable characters to cut down on the number of highest-quality sprites I need to pixel out? Or do I just simplify their sprites, or even reduce the number of animations for them? Should I cut out entire dungeons whole cloth, or should I make them smaller, or leave them as intended and reduce the number of mini-dungeon side quests instead? If I streamline the game too much, will that detract from exploration because there’s nothing to find? Or do I just accept that maybe this is going to be a ten year project instead of one that one lasts only another year or two? These are all questions I need to consider very carefully right now.

I also wonder if I should carry on with my “vertical slice” demo that I mentioned before, or simply begin the actual game. I’ve honestly never really done a vertical slice. For better or worse, I usually just start at the beginning and go from there, accepting that I’ll have to come back and polish the early game content later. (Either way, I’d release some sort of demo as early as possible, just not a proper “vertical slice”.)

But regardless of what I cut, I think the harshest truth I must face is this: the game won’t be perfect. No game ever will, of course, but this one even less so. I have a habit of obsessing over little details, wanting to polish every pixel to its finest. I can’t do that anymore. I think I’m going to have to accept that some battle animations won’t be perfectly fluid, that some lines of dialog will be lackluster, that some map layouts won’t be as engaging as others. And then I will have to move on to the next piece of content that needs to be worked on.

Oh! And before I go, I mentioned I was holding out to show my progress. Well, here you go!

Another Star 2 gameplay

Enemies are fully animated, and each has a neat little entrance animation at the beginning of the battle.

I promise I won’t wait so long for the next update! I’m planning to continue working on the battle sprites and animations so that I can get the battles mechanics into place. Look forward to it!

Another Star 2 Dev Log #19: Taking Inventory

It’s been a week and a half now since my last dev log entry where I noted that I was working towards a little playable build of the game for public release. I wanted to finish it by the end of the month. I haven’t made as much progress as I was hoping for, so it looks like I won’t have anything ready quite so soon. I just need to learn how to make games faster, I suppose.

But at least progress is being made, even if it’s not as quick as I was hoping. In the past week I’ve worked on getting the game’s item system up and running. The scripting commands needed for items to be usable haven’t been added yet, but almost everything else is done. This includes the inventory system, which is what I’m going to talk about today.

Another Star 2 screenshot

Here’s the main inventory screen.

It’s hard to imagine an RPG without some sort of inventory system. Not that it can’t be done—it certainly can. But it’s such a fundamental simulation of how we store and use our tools and possessions in real life that it’s not just a cornerstone of RPGs, but of countless other genres as well. Items are usually very important in RPGs. You are an adventurer! Here is your sword! Here is your shield! Another Star 2, of course, is no exception.

Inventories in games tend to be broken down into two camps: infinite inventories that can hold everything, and limited inventories that only allow you to carry so many items (often based on weight, or count, or a combination thereof). Personally, I kind of like inventory management, so long as it’s not too tedious, which is the main reason why Another Star had a limited inventory.

For a limited inventory to work well, the player needs to have access to information about the usefulness of items, and they need to be able to understand how much room they have. Both of these allow the player to make informed decisions about what items to keep and what items to toss or sell. Older games tended to fail at the former. Many came with fold-out charts in the box along with the manual. If you didn’t have the chart, there was rarely an in-game way to find how powerful a given weapon or piece of armor is. Thankfully, improved display resolutions and better interface designs have pretty much nipped that problem in the bud.

Informing the player about the space left in their inventory still tends to be a problem, though. Bethesda games like Skyrim and Fallout are an example of this. Those games’ inventories are limited based on weight, but when it’s time to clear out your inventory it’s often a struggle to figure out where all the weight is. Is it a few heavy items, or many light items that are the problem? This is an area where Another Star failed, I think. In Another Star you had 50 item slots. Players usually didn’t realize this, though, because other than an untitled counter up in the corner of the inventory screen the game never really tells you up-front. Most players discover the item limit when they go to open a chest or buy something and the game suddenly tells them that they’re already full.

There are a few ways I want to approach this differently in Another Star 2. First off, you’ll notice that the inventory isn’t an old-style list of text, it’s icon-based. The graphics aren’t just to be pretty. They add some valuable information that text alone has trouble conveying. There are visible slots for items to be in, so it’s easy for the player to realize at a glance “oh, I only have this much room” without being explicitly told. Second, the inventory is going to be smaller at first. Maybe a dozen or so item slots at the beginning of the game. This means that the first time the player opens up the inventory, they’ll see that there are less slots on screen than there is room for, meaning they don’t have to scroll down before they realize the item slots don’t go on forever. It also lets them “practice” managing a small inventory early in the game that’s easy to track while they’re still figuring out how different sorts of items are useful. Don’t worry about the small starting inventory too much. Unlike the first Another Star, as this game goes on you’ll be able to earn more inventory slots.

One more thing I’d like to do is to better encourage the player to use their items instead of hording them just for boss battles. The first Another Star had lots of battle-minded items like nets and bait that were useful in certain situations. However, other than the throwing stars and bows, even I usually just sell them when I go back and play the game. I want items you find to look and sound like they’d be fun to use when you come across them so that you’ll want to try them out right away. I also want to make items like this more reliable. Why shouldn’t the net always immobilize or slow down low-level non-intelligent enemies instead of only working half the time? If it’s reliable instead of a gamble, people will want to make use of them because now they’re a dependable tactic in battle. Plus, if it isn’t as useful on bosses, players are likely to be less stingy with them.

Another Star 2 screenshot

This option sorts your entire inventory by type, name, or how long you’ve had each item.

The one thing I haven’t quite figured out yet is “key” items. These were a problem in Another Star. They took up room in your inventory, but the game would never deny you one when you were out of inventory room. What sometimes happened is that a player would end up with 51 items or more in their inventory because they’d just gotten some key items. They’d go sell a single item when told to free up room to buy something, then get confused when they still couldn’t buy the thing since their inventory was now at 50—still no room.

In my original notes for the game I planned to not have key items count towards the item total at all, but this might also be confusing, suddenly adding extra slots when you go over the limit just to have them disappear when you sell off items to make room. Most games tend to solve this by moving key items to their own special inventory, but I’m not sure this is a good idea for Another Star 2. In the first game, key items weren’t just MacGuffins that have no purpose. They were often items that you could equip, such as the very useful “Father’s Pendant” accessory acquired early in the game. If they’re all in their own little “key item” inventory, the player is less likely to remember them or even realize they can be used. I may make some sort of “overflow” inventory where key items get banished to when you acquire one but have no room for it.

I suppose I should also mention to two icons at the end of the inventory screen. The first is just a simple sort option, as pointed out in the caption above. Another Star 1 also had this. Selecting it multiple times in a row has the game sort your inventory by a few different criteria. I assume most people will use this if their inventory starts to get too cluttered instead of doing it all manually by hand, especially as the inventory size grows.

The second icon is more interesting to me, though. In my original mock-up image of the inventory I added a recycling symbol to the trash bin to make it more obvious that when you “drop” an item, you aren’t just throwing it away. As in the first game you get a little loot for it, although it’s just a pittance so that it’s still more worthwhile to hold on to it until you can sell it, if possible.

When I began working on the inventory this week, I went back to that mock-up in order to figure out where to put everything on the screen. When I did, I couldn’t remember at first why I made it a recycle bin icon and not an actual trash icon. It reminded me so much of the “recycle bin” in modern operating systems that I decided to just roll with it.

Another Star 2 screenshot

Thanks for the gamedev pointers, Windows 95!

When you drop an item into the inventory’s recycle bin, you get your bit of loot, but the item isn’t actually disposed of yet. The most recent five items remain in the bin. If you change your mind, or pressed the button by mistake in a hurry, you can open up the recycle bin and select the item to get it back so long as you still have the loot from it, and have room in your inventory.

Now, it is possible in theory to abuse this mechanic to get five extra slots in your inventory. However, it’s not as simple as you might think. Nothing in the recycle bin is safe; not once you leave the status menu and go back to exploring. If you die in battle, the entire contents of the bin is gone forever even if you choose to retry the battle. They’ll also be gone if you ever reload a save. They aren’t even guaranteed to be there while just walking around as maybe they’ll start to randomly disappear from the bin after just a few seconds.

Another Star 2 captured footage

Here’s the inventory in action.

Well, that pretty much sums up the inventory and my thoughts on it. What are your preferences when it comes to the way games handle items? What are some of your examples of both good and bad inventory designs in games you’ve played?

I think my next goal now is to get the character status and equipment screens up and running. Hopefully those go more quickly.

Another Star 2 Dev Log #18: The Path Forward

Lately, I’ve been working on a new tileset. This will be used for many of the ruins dotted across the world of Byo, built by all sorts of past civilizations that have come and gone.

Another Star 2 screenshot

My tilesets usually begin as mockups, like this one. I can display images in the engine to test them.

Ruins can be kind of tricky to get right with low resolution tile-based graphics, because if they look too nice and uniform then they just look like slightly run-down castles instead of crumbling ruins being slowly reclaimed by vegetation. I’ve been looking at Star Ocean: Blue Sphere a lot lately for inspiration on this. It’s a Game Boy Color game that never left Japan, and it has some really nice looking ruins (well actually, it has some really nice looking everything). That game’s graphics show what you can accomplish even on a grid with limited colors.

Another Star 2 screenshot

I added roots and broken floors to make it feel more run down. Variety helps keep it from looking too clean.

Some of my biggest progress in the past week has been finally hooking rooms up to the battle system. Encounters now trigger, and you can accept them as in the first game to begin a battle. After the battle, you get experience and loot, and are returned to the room to continue exploring. So far every battle is exactly the same because enemy parties haven’t been properly implemented, and your HP isn’t tracked between battles because the characters aren’t actually in your party, but it’s starting to feel like a real game at last. (I even find myself reflexively pressing the A button as soon as I hear the ambush alert sound, even though ambushes don’t begin on their own yet.)

Another Star 2 screenshot

“BEE-DA-LEE-DA-LEEP!”

I began Another Star 2 about a year and a half ago. While I haven’t been working on the game that whole time, a great chunk of that year and a half has been dedicated towards this one project. It can get a little frustrating when it takes so long for something to bear fruit. The first Another Star was playable within just hours, and could be played from beginning to end within a few months. (Completing it took much longer, though; about nine months all together.)

But with Another Star 2 I’m only now getting the map system and battle system to tie into each other. Granted, I spent a lot of time building a new engine for Another Star 2 in C++, while the majority of the first game’s basic code was put together long before I began work on it. Still, this is taking a lot longer than it should. Even ignoring the time I spent before rebooting the engine, I’ve poured a lot of work into this with very little to show for it.

It’s time to change all that.

Early on in Another Star’s development, I put up a very early version of the game for download, jokingly calling it a “leaked” version. It was unpolished and had lots of bugs and typos, but it was complete up through about the third or fourth dungeon. I wasn’t having very much luck with finding people who wanted to playtest the game for me at that point, so this was sort of my last-ditch effort to get feedback. I was hoping a few people would try it out, but to my surprise it really took off. (Granted, I assumed “now they’re interested and will buy it when it’s released” instead of continuing to post about the game and keep those people engaged, but that’s another topic for another day.)

I’d like to do some similar things with this game. The first phase of that will be a preview build of the game. This won’t be a full “leaked” release containing lots of unfinished dungeons. It will be more like a small demo in that, while incomplete, it will have some level of polish and be self-contained with an achievable end goal. I suppose this is akin to what many professional developers call a “vertical slice”. The idea here is that the demo will be centered around a single small dungeon. It will give players a chance to try out the game, get interested, and give feedback. It also allows me to figure out how to streamline content creation so that I can churn out the assets for the full game. It will also help me decide what constitutes a “small” dungeon, how big a “full” dungeon should be, and how many the final game needs. This preview build won’t be long. Maybe a half hour at most, and I think most of that will be just from getting used to a new game and trying things out.

Since I now have something to work towards, instead of aimlessly deciding what to work on next I can map out definite tasks that need to be completed. RPGs are really difficult to boil down to their essentials, because they need so many different components to work together before they are all that interesting. Thinking it over, I believe the following things need to be done in order to release this preview build. In no particular order:

  • The preview build needs a small, non-linear dungeon to explore. I have a rough layout planned, and am already playing with room layouts to figure out how build they should be. Because the player character can run, and because the characters are larger than the first game, rooms may need to be rather big in order to avoid feeling cramped.
  • The dungeon needs a couple of tilesets to build these rooms out of. (This part is mostly done; the outside tileset for the ruins is the only one I haven’t done any work on yet.)
  • There should be optional areas and secrets to find, encouraging the player to explore, and making the dungeon feel more like a real place instead of a simple obstacle course.
  • There needs to be a variety of enemies. The enemies have to be drawn and animated, and they have to formed into enemy parties (called “formations” in the As2Tool editor). The game also needs to decide on which formation to use from several possibilities per room.
  • There should be a challenging end boss for the dungeon. Of course, they have to be bigger and more impressive than normal enemies, because that’s what makes them a boss!
  • There needs to be a battle background or two for the ruins. Right now, the only backgrounds in the game are tests from early in the game’s development, and they don’t match the direction that the art style has been going. (Also, none of them are ruins.)
  • Battles need to be further fleshed out. Right now, all either side can do is attack. The foundation of the enemy AI also needs to be implemented.
  • There needs to be a full party to play with. That means three playable characters need to have a full set of animations for moving around, and for battle. Thus far, no playable characters have more than a handful of frames. Ridley, the game’s main character, will be one of the party members in the preview build. I haven’t decided yet who the other two will be. Ideally, they should bring a good balance to the team, because the player’s customization options for them are going to be super-limited compared to the finished game.
  • There needs to be a few different pieces of music, though they don’t have to be 100% finished. Most needed are: the dungeon’s theme, a battle theme, and a victory theme. These three all exist in varying states, but I don’t think the dungeon theme or battle theme are ready even for the preview build.
  • Items and equipment need to be implemented. It won’t be much fun to explore if there isn’t anything to find as a reward.
  • The playable character’s battle sprites need attachment points for their weapon sprites. The basic code for attaching sprites to each other has existed in the code for some time now, but there’s currently no way to place these attachment points in As2Tool’s sprite editor.
  • The status menu needs to be up and running. Everything in the status menu needn’t be functional, but the basic ability to check your party’s current health and inventory are a must. The actual status page showing each character’s detailed stats is likely to be a placeholder for now, though.
  • I need to continue working on the scripting engine so that I can not only add interactive objects to a room, but also play out said interactions through dialog and cut scenes.
  • Said cut scenes need to be written. There should be a few as the player progresses, letting the preview build’s little side story play out. This will give players a chance to get a feel for the game’s storytelling style.
  • There needs to be some sort of title screen to greet the player when starting the game.
  • There also needs to be a loading screen at startup. Right now, the game window remains invisible until its initial resources are in place, which takes a few seconds and may confuse players.
  • There needs to be a game over screen, and a way for the player to carry on without having to start all over from the beginning.

Another Star 2 screenshot

Pictured: every single battle in the game right now. Every. Single. One.

In the interest of getting this preview build out the door, there are other tasks that are needed for the final game that, maybe, just maybe, aren’t that important yet. Some of these include:

  • Magic. It may not be implemented in the preview build. Items and magic both use scripting to function, so they’re quite similar, but magic needs additional visual functions whereas most items can get by with a basic “use item” animation from the character and some text.
  • Likewise, The characters almost certainly will not have their skills implemented, even if I implement magic in time for the preview build.
  • PC games tend to have pretty large and complex option menus. A lot of this has to do with the wide variety of hardware you need to accommodate. I may put off programming this for now.
  • Difficulty levels will absolutely be in the final game. However, you might not be able to select your difficulty level in this preview build because that would require having a working options menu.
  • It would be nice to have a town in the demo so that you can buy supplies. Maybe the preview build even starts in the town and then you leave for the dungeon using an option in the town menu? However, while the town itself would be very easy to script, I’d have to set the game up to handle said script, so I’ll likely put that off. You might get a merchant somewhere at the beginning of the dungeon instead.
  • Another Star 2 has a new system planned for its leveling-up mechanic. It takes more work than just telling the player what stats got raised, though. For this preview build I may just give the character some more HP and call it a day. Your other stats are not quite as important in Another Star 2 as they were in Another Star; for a single dungeon, just improving your characters with stronger equipment found along the way should be enough to feel like you’re making progress.
  • The game’s overworld is already functional as past dev logs have shown, but there’s not really a reason to use it for this preview build. And while the mini-dungeon used here will almost certainly be in the game, I haven’t even decided its position in the world anyway.
  • You may or may not be able to save your game.

The goal here is to have this preview build out sooner rather than later. My aim is to have it up and running by the end of the month, but more likely it’ll be well into August. A lot of this also depends on how much time I have to devote to the project. Depending on how real life plays out, Another Star 2 may have to set on the backburner for a bit. In any case, I’ll continue to post on my progress and give insights into Another Star 2’s mechanics and development as I do my best to press forward.

Another Star 2 Dev Log #16: “Welcome To Our Town!”

The original Another Star’s limitations and theme of minimalism led to a lot of interesting decisions that defined it as a game. Some results were positive, such as the unique battle system. Others not so much so, like the strict tile limit for the graphics in a 20 hour RPG.

Another Star screenshot

A common sight in the first game.

Villages and towns in the first Another Star were one of the more curious outcomes. They were completely menu-driven. You would walk into a location, get a description of the place, and then select where you wanted to go. Hunting down NPCs for flavor text was replaced with the “news” option in the menu that allowed you to get a bit of backstory, some indication of where to go and what to do, and even some gameplay tips and pointers. The menu-driven towns were a direct result of the tile limit; I couldn’t afford to use up tiles to create a bunch of NPC graphics or furniture. However, it also fit pretty snugly with the game’s theme of minimalism. Locations had been reduced to their most essential base elements, streamlining the entire experience. It was a solution even used by some other games at the time. (I’m reminded of my father playing Sid Meier’s Pirates! on the Commodore 64 when I was a kid.)

Player reactions to the towns in Another Star are possibly among the most divisive issues I come across in the game’s feedback. There are people who absolutely love the classic RPG town experience, and they live to seek out each and every NPC to hear what they have to say, no matter how mundane. For them, Another Star’s town menus were a major let-down. Others quite enjoyed the reduced “drive-thru” town experience. It was easy in Another Star to jump into a town, sell off your loot, rest, buy a couple slots worth of healing dust, and then jump right back out again, all without disrupting the game’s larger flow.

But the menu-driven towns also had a wider, most curious side effect. Because I didn’t have to make any maps for them, it was very easy for me to add a complete town to the game. Very, very easy. As a result, Another Star has maybe a hundred individual towns, cities, and villages spread across its world. The starting area alone has a good twelve menu-driven locations you can visit (only two of which are hidden). Furthermore, because of the lack of maps or visible NPCs, each location could be as big or as small as it needed to be. Instead of a vast, sprawling metropolis of a dozen people aimlessly shambling back and forth down a single street, I could just say there were tens of thousands of people and be done with it. Because we never see them directly, from the game’s own descriptions the world of Another Star can be assumed to have a semi-realistic population count for its size and technology level. This affected the game and its story more than I think people realize.

However, there were things lost in the trade-off. All these towns were reduced to flavor text. You could tell a location’s size by the relative number of huts it had on the overworld, but that was really all you actually saw of it. Every place was varied and unique, but you could only read about them and imagine what they must look like. In such a visual medium as video games, that’s kind of disappointing.

It’s now getting close to the time for me to begin properly implementing villages and towns in the sequel, so I had to start really thinking about how I wanted them to work. Like with so many other aspects of the game, I decided that a simple mockup would be the best way to plan this.

Another Star 2 location mockup

Tile limit? What tile limit?

Another Star 2, even if it doesn’t end up being a direct sequel to Another Star, will at the very least be a spiritual follow-up to that game. I want this game to continue the first game’s tradition of numerous and varied locations, set in a world that has a semi-realistic population count. Menu-driven towns are the best way I can think of to achieve that in a simple top-down 2d tile-based game. Bringing the town menus back achieves both that, and, by building on the original game’s menu system, allows the game to feel more like a proper, connected sequel. (Some games, especially modern RPGs starting from the PlayStation era, accomplish much the same thing by roping off your exploration to just a small section of a town or city, but that usually feels arbitrary to me and I didn’t want to go that route.)

The first thing that needed to change was that we needed to see where we were. Adding a big graphic hits that nail right on the head. Just by looking at the mockup screen, without reading anything, you can tell the player is in a small-ish rural village. The power poles indicate that, even though they seem somewhat primitive from the thatch roofing, they have some level of advanced technology; a mix of medieval and modern that you’ll likely see a lot of in this game. Ideally each location would have its own, unique graphic, but it will all come down to how much work it is to do hundreds of them in a reasonable amount of time.

Another thing I did was set the background to a nice blue color instead of pitch black. It makes the location feel more inviting, I think, although I’m not sure if every location would have the same color, or if maybe it changes from place to place.

Finally, you’ll notice that the player character is talking about what they’ve come across. In Another Star, locations were described in the third person by a disembodied narrator. Another Star 2 is meant to be a more visual, active game, so I wanted to reduce the use of a narrator in places where I could instead show something, or have the characters themselves directly express something. Ideally, when you arrive at a location, you’ll hear from one of the characters instead of reading about how “Tachi did this” or “Tachi saw that”.

Another Star 2 location mockup

What will Ridley do?

The menu itself hasn’t changed much, other than the fact the character now gives a short description of each location when you highlight it. Before you had to guess at the meaning of new or unique options. I have mixed feelings about how much real estate the menu is taking up in this mockup, but at least the player would have already seen the full graphic at this point. The “news” option returns, although I may spice it up a bit—more on that another time, though. The other options, “shop”, “tavern”, and “leave” should be likewise familiar.

However, there’s one unusual option among them that’s not a carryover from the first game: “town square”. Players of the first game may initially think this is the game’s version of the clan chief mechanic, but it’s not. If you were to select it, you’d get something like this:

Another Star 2 screenshot

Actual in-game screenshot.

A small area of the village you can run around. You can’t randomly barge into people’s homes and steal their stuff as they compliment your heroics, and it’s only a very small portion of the village, so in a lot of ways I suppose it’s very much like the alternate solution I discussed earlier. However, not every location has a town square. This is a unique feature to this particular village. Other locations may have their own unique locations.

They aren’t meant to replace the “news” option in the town menu. Instead they are primarily planned for story purposes. These would usually be places you have to go in order to progress either the main story or a side quest, so anything NPCs have to say in these places would likely be tied directly to the side quest instead of the more general advice and dialog of the news option. (Also, other reasons, but again, I don’t want to discuss that until I’m closer to implementing and playtesting it.) This isn’t really meant to be a “best of both worlds” solution, because I don’t think people missing classic RPG towns will be fully satisfied with this. However, it should add a little flavor and uniqueness to each location, and it gives a place for story scenes within a location to play out. (In the first game they were usually narrated, which tended to be sort of tacky.)

Another Star 2 screenshot

I can import images into the game to preview them. Helps see what works in mockups like this.

Perhaps every location will have a least one of these unique explorable areas? I don’t know yet. I’m still working to get my tools set up so that I can generate a lot of good content very quickly. How many of these areas get added depends entirely on how much trouble they are to get up and running.

Another Star Dev Log #15: Points of Interest

One of the most memorable features of Another Star was its secrets. You had to keep an eye open and scour the world in search of hidden areas and secret passages, searching every corner in the hopes of finding a good reward. The game took a lot of inspiration from the original NES/Famicom Legend of Zelda in this regard. Though that game was so simple, there was always an excitement in never knowing just what you might find.

Likewise, almost everyone who has played Another Star absolutely loved looking for secrets. It’s often mentioned in reviews, and it helped the game to forge its own identity.

But there was also a small minority of players that didn’t care for it. While there were usually obvious tells to guide players to a secret area—a lone group of trees on the overworld here that warps you to an area full of treasure, or a strange and narrow corridor there that seems to be a dead end but really leads you through the wall—some were not so obvious, especially when the rewards were very good. This meant that some players felt like they had to trek over every tile and bump into every solid object just to make sure they didn’t miss anything.

It’s impossible to please everybody, so it’s easy to ignore such criticism by deciding that this style of game is simply not for them. Indeed, sometimes you have to accept that you can’t make the perfect game for everyone to love equally. But, like all the responses to the game, I made sure to take note of it. Over time I continued to digest the complaint and, almost by accident, I think I stumbled on a sort of solution, at least in the case of the overworld.

Another Star game footage

Wait, what was that? Was this here before?…

In Another Star 2, locations on the overworld are sprites instead of being part of the tilemap. In the game’s code, they’re referred to as “pois”, short for “points of interest”. I mentioned them in my last dev log here. They spawn as they come into view of the screen, and then despawn once they’re a little ways out of view.

This was originally going to be a way to get around tile limitations, because having lots of unique locations would eat up a lot of source tiles even when they weren’t visible on-screen. But even after I loosened restrictions I went ahead and kept this implementation. As I was programming it into the game, I started to realize that, since the locations are sprites, they don’t always have to be there, even when they’re within the screen’s view. Hidden areas can wait until the player gets much closer, and then they can suddenly pop into existence. This allows for the thrill of discovery without having to physically comb over literally every single tile. And, once revealed, they can stay in their “discovered” state so that the player can find them again easily if they need to come back for some reason.

I’ve been using simple caves as the early test pieces for this concept, since there’s a lot of mountains in the player’s starting area, and caves are a quintessential RPG staple anyway. This meant I needed a cave tileset, of course, so I went about whipping one up.

Old cave tileset

An old cave tileset from a game idea that I never did anything with.

One thing that 8-bit games tended to rely on, especially with the super-limited palettes of the NES/Famicom and the later Game Boy Color, was to use separate color palettes for walls and floors. This made it easy to tell what you could walk through and what you couldn’t, and it became a distinctive artistic feature for those consoles. Originally the walls and floor of the caves were going to be the same color, like in the old tileset pictured, but it looked kind of boring. So I made the walls gray and the floors brown. Of course, each individual cave can have its own palette, so there will likely be lots of color variations as you explore the world.

Another Star screenshot

First step is getting the basic walls and floors to look okay.

I kind of wanted the transition between walls and floors to be more natural, more like a real-life cave than some artificial tunnel, but it would have required a lot more tiles, and I’m not sure how well it mixed with the game’s art style. (I want the tile grid to be obvious, but not too obvious, if that makes any sense.)

Another Star screenshot

With lots of debris and other little touches added for interest.

The brown of the floor is the “transparent background” color, which lets me do neat tricks like have tiles that appear “above” character sprites without using multiple layers like a 16-bit or modern game would. Master System games absolutely loved to do this all over the place. Granted, it means those “above character” tiles can’t have any little bumps or stones in the part that’s the floor, because anything not the background color will appear above the character sprite, ruining the effect.

Another Star close-up screenshot

“Look! This wall is in front of me! No, really!”

It also sort of breaks down wherever there’s a shadow meeting a bottom wall, because the color of the shadow isn’t the background color. Thus, it appears above the character sprite. This can be partially hidden by the fact each 8×8 pixel corner of the sprite can independently be set above or below, just as on the Master System, but I can’t make it go completely away unless I make the walls perfect rectangles. The effect was too much fun and too iconic to loose altogether, so you’ll have to just ignore where it breaks. Old games had to make a lot of these very same trade offs, so I don’t feel too bad.

Another Star close-up screenshot

“Pay no attention to that tile in front of the curtain!”

Speaking of which, caves in RPGs tend to be… well, boring. They’re usually filler, they’re usually very samey from game to game, and they’re almost always a repetitive grind. The original Another Star was certainly no exception in this. It’s a shame, too, because in real-life caves are pretty cool. They feel so foreign to us surface-dwellers; at the same time wondrous and imposing. I’d like to try and do better; to capture a little bit of that feeling.

One way is by making caves some of the more treacherous areas of the game to chance upon. Exploring them might be a bit of a gamble when you first stumble upon them. But I’m not quite ready to talk about the ways that the game balances area difficulty yet, so I’ll leave that for another day.

The other big factor is lighting. 8-bit games were very limited in this regard. They couldn’t use layering to hide parts of the screen behind semi-transparent circles like later consoles, emulating the area of a light’s effect, and real-time GPU-driven 3d per-pixel lighting is of course right on out. Pretty much everything has to be evenly applied to the entire screen because it’s all the same palette. But it doesn’t really have to be anything fancy in this case, I don’t think.

You see, you’ll have some caves that are brightly lit (never mind where the light comes from; that’s just how caves work in video games). These will probably not be too much more dangerous than any other area you might discover. But then you’ll have dimly lit caves that have a darker color palette. They’ll contain more difficult foes, but also more desirable treasures.

And then you’ll have this…

Another Star screenshot

I think I’ll just curl up into a ball right here.

Pitch black caves where the walls are only barely visible. Sure, you might be able to see those walls, but you can’t see what’s hiding on the floor! There’s liable to be spikes or instant-death pits scattered about that maybe you normally can’t walk into, but with no lighting they’re the same color as the floor. Battles could be compounded by having your party unable to see the enemy, lowering their hit rate. And maybe even the game won’t even show you the enemy you’re fighting. Or tell you what they are.

You’ll no doubt need to have some sort of torch or lantern to explore these darkest of caves, moving them up a notch from “dark” to “dim” so you can see what you’re doing. And maybe there will be some of these caves with really good loot that are worth the risk to try and venture into early, even without something to light the way? As a game designer, I can’t wait to explore the possibilities.

And I know what you’re probably thinking: I’ll have to make sure that said lighting isn’t too much of a hassle to stock up on and use. Lantern oil that only lasts a couple minutes before having to be restored isn’t much fun. Likely I’ll end up having your torch/lantern/whatever last until you return to the overworld. Could even have some cheap ability or early item that won’t run out and that only lights the screen for a moment, allowing you a glimpse your surroundings just long enough to make a little progress before stopping to use it again.