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.

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, 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”.

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:

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.)

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.

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.

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.

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.

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.)

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.

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.

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…

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.

Almost everything in the original Another Star was hard coded, other than the layout of the map itself. Every item, every enemy, and every scene was entered as lines of C# code. Even the layout of some of the tile graphics I manually typed in. For many things, this actually wasn’t too much of a bother. Typing up all the enemies and their stats could be a little annoying because the C-derived family of languages tends to be so verbose, but it’s not too different than creating a parsable data file.

Scene scripting, on the other hand, was an absolute nightmare of a chore. Another Star was a very simple game. Other than the player, characters couldn’t move and were limited to “teleporting” around to room if the story needed them to be somewhere, and they always faced down with no alternate sprites for the other cardinal directions. Most of the story was given using raw text and nothing else. And yet, despite how little really needed to be done, it was still such a pain every time I had to write a new scene to advance the plot.

Writing a story in a programming language just feels unnatural to me. Remembering to slap a semicolon on the end of every line, no matter how short, or having to reach for the parenthesis and curly bracket keys all the time. It may seem silly, but it really does disrupt my thought flow. I suppose you could say it puts me in a “programming” state of mind for problem solving, instead of a creative one for coming up with interesting scenarios and enjoyable dialog.

Worst of all, if you look over the code you’ll probably notice another, even bigger issue: none of the actual dialog is in there! The localized dialog is another of the small handful of things that’s not compiled into the code. It’s all off in a plain text file so that it could be possible to translate the game into other languages. So whenever I wrote a scene in Another Star, I’d have to constantly go back and forth between the code file and the dialog text file. Countless numbers of times I’d mismatch a line, or forget to remove a cut line no longer there, or just leave an important line out by accident altogether. Some of these made it all the way into the original release without being caught.

For Another Star 2, I wanted to avoid having to go through all that again.

Now, there’s a lot of scripting languages out there that I could have just downloaded a library for and dropped into my project, but the vast majority of them have the C-style syntax I was trying to get away from, or just throw weird characters all over the place, like LISP’s unsettling infatuation with parentheses. I wanted something that felt a little more like natural English and didn’t have me reaching all over the keyboard just to do simple things. And I honestly didn’t need the raw power of most of these languages anyway. 95% of what I need to do is just pop a dialog box up on the screen. A simple language without a lot of bells and whistles would be just fine.

After a lot of thought and a couple weeks of work I managed to put together a simple command-driven scripting language with support for functions and if-then-else blocks for branching. It could still use some tweaking for sure, but already it feels a lot more like writing a novel than writing a game engine. Writing a test scene was a lot more fun than frustrating, even as I was working out some of the kinks in the language’s syntax.

And see how all the actual dialog can be easily included in the script itself. The script is compiled to bytecode with a custom compiler so that the game doesn’t have to parse it on-the-fly, and this compiler outputs two files: the script bytecode goes to one file, and all the localized text goes to a separate text file to support possible translations in the future. You’ll notice that each line of dialog is indexed, so that moving things around in the code won’t completely mess up existing translations just to do minor fixes. I’m not wild about having to number all the lines out like that, but it beats having to manually track them in another file.

I’ve been careful to document how the language works and what all the commands do so that everything is ironed out and I won’t forget little details like what each command’s compiled byte code means. But maybe I got a little carried away on that front…

The first successful test for running the script in the game was to lock the player’s controls for a couple seconds and then play a song, but that’s kind of hard to show in a picture, so instead I used it to place this little lookout tower on the overworld.

That probably seems like a weird thing to use scripting for, instead of just slapping it there in the room editor, but I promise it will make more sense later.