next »

[TheGrandHero]

Dev Log #10
The Battle Menu

A disclaimer before I begin, it must be noted beforehand that I'm talking about a game in active production that is still early in its development cycle. Some of things I'm going to talk about today have already been implemented. Other things are half-finished, while others still are merely planned. It should go without saying, but be aware that lots can change between now and the final game as things are implemented, tested, refined, and, in some cases, dropped altogether.

The first Another Star had a pretty typical battle system for an RPG modeled after the 8-bit era. Battles were fought in rounds. You'd pick a command, the game would randomly decide on a turn order based on each combatants's agility, and then the battle would play out for you to watch. Fairly standard stuff. There were five commands in battle: Fight, Defend, Magic, Item, and Flee. They all did pretty much exactly what you'd expect they'd do in an RPG, with the exception that there is no targeting—everyone always attacked everyone else—and the defend command not only lowered damage taken but also restored a little bit of HP.

Another Star 2 builds on the first game's battle system, so little has changed when it comes to the commands available. That said, however, the way you use many of the commands is liable to change.

The biggest single addition to the battle system comes in the form of "guard points". Each character will have a few guard points; probably just two or three at first, but they'll gain a few more as they gain EXP and level up. But even maxed out, each character will still only have a precious few—maybe 10 to 16 at most, and that's only for certain characters. These guard points form the character's "guard meter". Certain actions in battle will begin to fill the meter, while others (more slowly) will allow the meter to lower back down until it empties out again.

Here's the basic gist of it: you do not want the guard meter to fill up. Collectively, your active party's guard meters make up the "guard pool". If the guard pool is completely filled—that is, if the guard meter for every party member is filled—and the enemy manages to land a hit, then a "guard break" happens. The round immediately ends, and new one will start with the enemy free to wail on you with heavily increased damage while your party stands there in a daze unable to resist. In other words, it's designed to be an easy way to get yourself killed if you're not careful with your actions in battle. Character's guard meters are not emptied after victory either, so plan accordingly.

Another Star 2 has six battle commands, in the form of icons. (Speaking of which, it turns out there was a Famicom RPG with an icon-based interface...) Here are the commands in Another Star 2, and here's what they do:

FIGHT

This is your basic "attack" command. As with the original game, every party member will attack every enemy. There is no traditional targeting system. And again as with the original game, the fight command is a bit of a gamble. There's a chance the attacker will miss a defender completely, dealing no damage at all. Or they might land a critical hit and deal loads of extra damage. The damage range is also likely to be very wide, more variable than the first game. If you absolutely must kill an enemy this turn, then "fight" might not be the way to go.

There's also another interesting difference between Another Star and Another Star 2's fight command. Characters with high agility have a chance to attack twice in the same round. The chance of it happening depends greatly on their order in the turn queue. And if you're really lucky, and the character is really fast, they might even get a third attack in... (To make up for the lack of hits, characters with higher strength will likely have a better chance of getting good "rolls" which lead to better, higher-damage attacks. You'll be able to tell how good an attack is by the character's attack animation.)

The attack command is also important for another reason: it's the primary way to get your guard meter to go back down. When the character attacks during a round (but probably only the first time, if they're lucky and get multiple attacks) their guard meter will go down by half a point.

DEFEND

Defending will significantly lower any damage that characters take during the round. And, like the first game, when the character's turn comes around in battle they'll regenerate a decent chunk of their HP. The system was easy to cheese in the first game if you were patient and leveled up enough that you could restore more HP than the damage you took from enemies. But, as you might have already guessed, Another Star 2's guard system is designed specifically to prevent that particular exploit. In addition to restoring HP, the character's guard meter will go up by one point. Or, if the character's meter is already full, that point will either be split between the other two characters, or given to the only character left with any room in their meter. This can make characters with smaller guard meters a liability if you're not careful.

Defending is also not something to take for granted. In Another Star 2, each character has their own innate elemental affinities, which means they have their own elemental weaknesses and strengths. Those who played the first game should already know what this means: if a character is hit by an elemental weakness, it won't matter if they're defending. They'll still take the same amount of damage as if they weren't—which means extra damage, since it's a weakness after all.

Getting hit by a weakness also causes the character's guard meter to go up by one point, whether or not they're defending.

MAGIC

Magic is going to work a little differently than the first game, but it's still the same idea. There are no "magic points" in Another Star 2. Spells are cast by sacrificing your hit points. Since magic cost HP, there aren't really any traditional healing spells (which is why the defend command is so useful in both games).

When casting magic, only the caster gets to act in battle; the other party members do not get to do anything that round. However, magic attacks ignore enemy's armor rating, meaning they can often do just as much damage as all three characters together if the caster is good, and they can do a lot more if they exploit an enemy's elemental weakness. Magic attacks will also tend to do more "stable" damage in Another Star 2, with very little variance from round to round. There's also plenty of buffs and debuffs and support magic, too. Veterans of the first game will be glad to learn that hit point costs for magic are planned to be fixed-cost in Another Star 2 instead of percentage-based, and you'll likely have access to earlier forms of spells instead of just the most recent upgrade. Useful, since the cost will still go up with each new spell evolution.

It's also worthy to note that spells are not planned to be tied to characters in Another Star 2. Each character will get a fixed number of spell slots (with access to a few more as they level up), and you will be able to equip spells like you would weapons or armor. Some characters will get more slots than others, making them more useful for magic. But remember that characters have innate elemental affinities now. They can use spells of any element, but they likely won't be able to do as much damage with spells that they're weak to the element of.

SKILL

This is a new command for this game that wasn't in the original. Skills are innate to a character, similar to how magic was in the first game. You can't just unequip a skill and give in to someone else. Each character has at least one skill, but may gain more as they level up. There will likely be ways to use skills from characters who aren't in the active party, at the cost of guard points. As with magic, only the skill-user will go during the round.

ITEM

Items are meant to be especially useful in Another Star 2. Other than defending, healing items are the primary way for you to restore HP. There's also magic scrolls to cast spells you don't have equipped, and without using up HP. And there's going to be lots of situational battle items and fun little things to play around with, just like in the original Another Star. Certainly there will be rare or expensive items to do something about your guard pool getting dangerously close to filling up...

The best part is, just like in the first game, agility is not factored into turn order when using an item. The party leader will use the item right away as soon as the round starts. So go ahead, take a chance and let your HP get really low before burning a consumable to bring it back up! As long as you survive the round, you'll be able to heal up right away come the next.

FLEE

Sometimes things go wrong. Like, very wrong. In that case, there's little to do but run away and live to fight another day.

As with the first game, you can't run away on the first turn. You'll also lose a good chunk of your loot when you do choose to run.

But one planned change from the first game is that fleeing doesn't happen right away. The enemy gets one last free turn to smack you around before you go. Thankfully, however, you're guaranteed escape. For this last beating anyone left standing will retain at least one hit point, and you won't get your guard broken even if you take a hit with a filled guard pool.

[TheGrandHero]

Dev Log #11
Getting Around

So, with the rudimentary basics of the battle system implemented, I decided it was time to go back and reimplement the overhead map portion of the game in the new engine. It actually didn't take too long to get everything back up and running since a lot of the code could just be copy-pasted verbatim, although I still had to sit down occasionally and work out exactly how some things should work now. This finally brought me back to where I was before chunking the old "pseudo emulator" engine.

I decided my next task was to actually link maps together so that you can get around. While I'm sure you could make an RPG that takes place in a single room, it'd take some real skill to give it enough gameplay to make it interesting for hours on end. Since the earliest dungeon crawlers of the 1970s played on university mainframes, role playing video games have done their best to drop you into a world—sometimes small, and sometimes vast—that you are meant to explore.

Don't mind me. I'm just exploring.

It seems like a really simple little thing, but the mere act of moving from one screen to another is a huge moment for me. All of a sudden, individual maps have context and purpose. I remember getting the same feeling when working on the original Another Star. When I made it so that you could move between sections suddenly it felt like I was playing a real game. In any case, this means I can finally start building up actual content and start piecing the game together.

You may also notice that the protagonist has a running animation now. Speeding along at two pixels per frame while watching a normal walk cycle always looked strange to me, so I decided to throw in a simple run whenever the player characters speed up. I think it gives it more of a Chrono Trigger feel than I really wanted, but it just feels like it controls so much better, even though literally nothing else changed other than the animation. It also gives the character a little more personality when they can zip along like that, especially if I give each party member their own running style. I'm currently undecided if I should implement a classic "run button" when using the digital d-pad.

I think the next big hurdle to tackle is scripting. Right now, moving between rooms (maps) is a simple system of "warps" and "labels". In the room editor, you can drag out a rectangular label in one room and a rectangular warp area in another, then tell it the name of the room and label to take the player and the game will handle it all on its own. For most uses, this is perfectly fine, but there also needs to be a way to handle more complex transitions. Not to mention a way to actual add the NPCs and objects for the player to interact with. Scripting can be big and complex, but having done this once before, I don't think it will take me very long to get the basics up and running.

[TheGrandHero]

Dev Log #12
FM Synthesis

"I think the next big hurdle to tackle is scripting," I wrote in my last dev log. Well, that was the plan, anyway. But shortly after writing that I decided to make a quick addition to the game's room code. With just a little work, the game could automatically switch door tiles between "open" and "closed" variations as the player approached. It worked quite well and right away, despite being such a minor thing, really made the tiny world inside the game feel all that more grounded.

I'd imagine in real life, she'd just leave a bunch of open doors behind her with all the lights turned on.

This is done programmatically, by the way. No scripting is involved, which makes it really easy to throw doors into a room. The game simply caches all the door tiles after loading up a room and then the entities moving around the map ping their location as they move. But as I tested it out, I couldn't help but realize how empty it felt because everything was so quiet. The doors needed a satisfying audio cue as they changed state. To do that, I'd need to implement a proper sound engine, the only major core engine task left other than scripting.

Being a child of the 1980s, I really love FM synthesis. Especially the early, somewhat cheap sounding little FM synth chips that Yamaha liked to develop. The first Another Star played prerecorded music composed in FL Studio using samples from (and a VST that emulated) a Yamaha YM2413, a chip used in the Japanese version of the Sega Master System. Most game soundtracks flock to the more traditional chip tunes of the NES or Commodore 64, so working with early FM synth sounds instead was a real treat for me. For those who never played Another Star, here's an unused track from the original game to give an idea of how it sounded:

As I've noted in past dev logs, I've always planned for Another Star 2 to have a similar soundtrack that emulates early FM synth chiptunes. But I wanted it to sound more unique instead of being almost entirely limited to the preset instrument selection of the YM2413. Instead of just choosing a different emulated chip VST to record, I decided to go a step further and actually write a software FM synthesizer of my own to run in-game in real-time. Not the brightest solution, perhaps, but I've written a few before as experiments and I really had my heart set on doing this. To justify going through all the trouble of making it work, I decided I would create ways for the game to dynamically react to what's happening on-screen. While far from impossible, that's a lot harder to do with your usual pre-recorded tracks.

It took a month and a half of work—time I really probably should have spent elsewhere—but I finally accomplished it. Most of my time was spent writing the tool to actually get the music into the game. I thought about writing a simple General MIDI file importer, but even then I would need a custom tool to be able to do things like place event triggers and create song variations by enabling or disabling individual tracks.

Up to four operator FM is supported in the editor, but in-game only operators one and two are enabled. This is partially for optimization on older systems, and also to stick closer to the simpler, "cheaper" sound of the earlier FM chips used before the 16-bit era.

Most of my tools are written in C# with WinForms because it's really quick to get things up and running, and afterwards I rarely need to rewrite any code in C++ for the game other than the routines for importing files, which usually doesn't take very long. But a software synthesizer is a much different beast, and I didn't feel like writing it or the playback code twice, once in each language. So I ended up writing the composing tool in straight C++, something I don't normally care to do. As you can see, I wasted a lot more time trying to make it look pretty than I should have.

Because I wasn't using WinForms, I even had to write custom interfaces for normally trivial things like picking where to save a file.

The playback format is similar to MOD music in that it's pattern based, although each pattern is a variable-sized list of single-byte commands for a single monophonic channel instead of a table having something for all the channels together. Notes and other commands are inserted in the piano roll for each pattern, and then patterns can be assigned to tracks down below the piano roll.

The little board at the top is displaying volume in this screenshot, but it can also be used for editing stereo panning, assigning instruments, and more.

Finally, the variation editor is used to decide which tracks will be used on which channel. Internally all the tracks advance together and there can be any number of them, but only the assigned tracks send their notes to a channel to play. Originally, there were going to be only four channels of FM synthesis, and then there would be two other channels limited to just noise generation and low-fidelity PCM samples that could be used primarily for percussion. But this would require actually programming special channels for noise generation and low-fidelity PCM samples instead of, you know, just telling the computer to make six FM channels instead of four. The FM channels can already switch from sine waves to noise generation anyway.

In the end I think I won't limit any channel to any ability the others don't have and just continue to use all six FM channels as proper FM channels. I really need to get back to making a game instead of messing around with this anyway. (The editor actually supports eight channels, but that's an awful lot for a simple 8-bit system, so the game only uses six.)

Notice that by this point I stopped caring about fixing visual bugs in the editor.

Now, here's that same track from before, recreated using the new software synthesizer and playing back in the editor:

[TheGrandHero]

(Sorry; splitting this off because the board only supports two YouTube embeds per post.)

And, since the game and the editor use the same synthesis and playback code, it only took literally an afternoon to get the audio into the game itself. It's still rough around the edges, but here's some actual footage I recorded this morning:

Notice how the music switches between variations when going from one room to the next. You'll probably also notice that sound effects cut out parts of the music so they can play. This was common back in the day, and makes me feel nostalgic, but I may break down and add a couple of channels that are reserved just for playing sound effects.

And now I really do need to get to work on that scripting engine!

[Pixel Noise]

Dude. Wow. You are absolutely right about loving those old FM chips (as a child of the 80's myself). I loved the sound of the original - but your custom synth is awesome! Really nice character to it - oh, and the music itself is beautiful. Really, this is great.

You said you spent more time on this than you should have. First of all - I don't think so! But, musician bias. However - is there a possibility of selling/sharing the tool you wrote? I don't know if it's feasible, or if you would even want to. Just an idea to get more "mileage" and recognition out of your work.

 

[TheGrandHero]

One of the reasons I put so much work into making it look nice was because I kept think "well, maybe other people would like to play around with this". So I can assure you, it's almost a given that it will get released in some form. I don't know if I'd bother licensing it out—there are better software synths and tools out there. If I wanted to monetize it somehow, I think a donation basis would be better.

[Pixel Noise]

It does look great - and I'm glad you thought about that because I'm sure people would be interested in it! (me)

[swordofkings128]

Woah you wrote your own FM synth for this!? Having a real time FM synth within in the game... so authentic! I can appreciate that kind of dedication... It's something 90% of people who play games don't care about but when the music is being played as if it were coming from a soundchip, it just adds so much, especially if you kept sound effects cutting out some of the music at times! (maybe... fake lag if there is too much stuff going on!?) Really it's such a challenge recreating the technical stuff an old console had like that and I love it so much when someone goes the extra mile(or extra hundred miles it seems like sometimes) to capture that kind of stuff.

This is going to be an amazing game!!

[joemusashi]

It's official, I need your game. When? :D

[TheGrandHero]

(maybe... fake lag if there is too much stuff going on!?)

Most of the games that lagged 8-bit consoles were action titles. RPGs didn't tend to be nearly so flashy, at least not until the mid-to-late 16-bit console era, so I don't think there's much benefit to simulating that. And people would probably think that the game is actually lagging...

The original version of the engine did have sprite flickering if there were more than 16 eight-pixel-wide sprites on a line, but it was also rendered entirely on the CPU like an emulator. Simulating sprite flickering on the GPU in the new engine is a different beast, so I'm not sure I'll implement it as a feature most people will probably end up turning off anyway.

It's official, I need your game. When? :D

Not before the beginning of next year--at the earliest. It really depends on how much time I have that I can devote to the project, and how much I'm willing to cut from the game down the road.

There will be some form of playable preview as the game's development progresses, though.

[TheGrandHero]

Dev Log #13
The Unfinished Overworld

Lately, I've been spending a lot of time working on the graphics for the game's overworld. Yes, yes, I know I keep saying I'm going to do the scripting next, but I wanted something to test the scripting on. Besides, scripts by themselves don't make for very interesting pictures that you can post online to get people excited.

As you'll recall, here is the original concept mockup for the overworld.

Like with everything else in Another Star 2, it was important to me that just looking at the overworld should make you really want to play the game. I wanted the graphics not only to be bright and inviting, I wanted them to have a consistent feel, with a standardized scale—even if that scale wasn't remotely realistic. I wanted the overworld to look big, so I went the Chrono Trigger route and made the player character small. And I created huge, detailed mountains pretty early on, and tried to make everything else fit around them. They're bigger mountains than would really be feasible in the amount of VRAM the pretend console system supposedly has, but they came out too good to throw away!

One of the first actual screenshots from the overworld.

But there was a lot I wanted to change from the mockup. I wasn't happy with the trees, and I also wanted multiple types of forests. I thought it would be neat if broadleaf forests dominated the warmer areas near this world's equator, while conifers begin to dominate as you get closer to the poles. By arranging the conifers in columns, I was able to add an entire forest type to the tileset while only needing three unique tiles. Getting the scale right took some trial and error. I like the original conifer forest tiles shown above, but they just didn't fit in well with everything else. I also lightened the darkest green of the palette, to make it more obvious you can walk over the forest tiles. I really like the touch of blue it added.

I also started to tweak the roads so that they weren't so blocky.

Another thing I didn't like about the original mockup is the coastline. I made it pretty plain because I couldn't get a beach that I liked, so I just sort of did a callback to the first game's rounded coastlines. Coasts like that would have required less tiles, too. But since I already threw virtually all the game's hard technical limits out, I didn't really have to care, and so I experimented until I came up with some nice cliffs.

The coastline can get really jagged in the far north.

Rivers were another struggle. I didn't want to just reuse the ocean. I wanted real rivers this time! I don't have any screenshots of my early attempts, but the early rivers were all a full tile wide so that I wouldn't need unique tiles for both snow and grass and whatever else there might be for the river to plow through. But it all came out so blocky that it just wasn't working, especially with how organic everything else was starting to look. I finally gave in and made them more similar to the dirt roads. Suddenly, the ability to snake the rivers all over the place really began to sell it.

Like the first game, you can expect to see plenty of rivers.

I also created proper beaches for the variety. It took eight frames to make the surf look right, pretty high for an 8-bit title, but I think it's worth stretching the norm in this case.

If you leave Ridley long enough, she'll do a little dance.

The tileset still needs quite a bit of work. For example, the ocean water looks really nice in stills, but it's just too busy in motion. Too much pixel noise with everything moving around, detracting from the animation of the coastline. That'll have to be tweaked. I was also trying to avoid having to do inner diagonals on the beaches. For a game like this, I like the nostalgic feel when certain tiles don't line up quite right and you can clearly see the grid in spots. But the beach surf just doesn't look right with all those interruptions in the shoreline.

Yet overall, I am quite pleased with how the overworld is turning out.

Here's the tileset thus far, without aspect ratio correction.

I am also starting to run out of tiles to work with. The way tilesets are stored currently allows for up to a whopping 65,535 individual tiles, but the current room format only allows the first 256 tiles to be properly placed in the grid. The lower 256 tiles shown above are used exclusively for animated frames. 256 tiles is more than enough tiles for what I really should need in a game of this style, but the wide variety I'm trying to achieve on the overworld does demand a lot of graphics. That said, I'm not too worried about it, since almost all the needed terrain types have been implemented. I can always tweak the format later as need be, I suppose.

You'll notice that there are no cities or villages or caves or anything like that in the tileset. All locations will be purely sprite-based objects, which is where scripting starts to come in to play. I'll have to start working on that soon, but in the meantime, here's a video preview of walking about the unfinished overworld. Enjoy!

[TheGrandHero]

Dev Log #14
A Scripting Language

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.

Code for an early scene in Another Star.

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.

Speaking of which, the all-caps dialog didn't help with catching typos.

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.

A test draft of an early scene in Another Star 2.

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

I've paid for released products that aren't this well documented...

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.

You can walk over it to enter, but it doesn't take you to the right place yet.

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.

In any case, after audio, as scripting was the last major backend system for the game I hadn't yet completed, I can finally move the game's progress bar up a notch to 10%, I think.

[TheGrandHero]

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.

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.

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.

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

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.

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

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

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.

[qMopey]

Posting for follow! Beautiful looking game (yet to read entire blog) 

[TheGrandHero]

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.

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.

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

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:

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

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.

[blekdar]

This is hot.

I am particularly fond of those battle icons. God damn are those sexy.

[nathy after dark]

Ooh it looks cute, and I love cute! I also see you've written about your scripting language, which I don't have time to read at the moment but is the kind of stuff I don't get enough of. I'll be following!

[TheGrandHero]

I am particularly fond of those battle icons. God damn are those sexy.

They don't quite fit the game's motif of being a late 8-bit era game, but they've grown on me so much at this point that I'm not sure I even care. :3

Ooh it looks cute, and I love cute! I also see you've written about your scripting language, which I don't have time to read at the moment but is the kind of stuff I don't get enough of. I'll be following!

I always enjoy seeing the solutions and tools other people come up with for their own games so that I can shamelessly steal them and call them my own. Anything in particular with the scripting system you'd be interested in me covering for a future dev log update?

[qMopey]

Yeah! Cover the technique for parsing, and how do you generate the bytecode? Do you store the bytecode and plaintext and load that? Or binary? Also how do you plan on packaging the scripts along with your game? Will you compress them at all or package them in any way? Did you ever consider converting those $13 symbols to keywords, and doing a hash table lookup? That way you can type keywords like return in the language?

[TheGrandHero]

Cover the technique for parsing, and how do you generate the bytecode?

The script is converted to bytecode using a custom compiler. Since a couple people now have shown interest, I may write about it in more technical detail for a future dev log.

Do you store the bytecode and plaintext and load that? Or binary?

The script is written in plain text, but then it's converted to a binary bytecode file by the compiler. The bytecode file also includes a header, a function table that records the starting offset of each function in the bytecode, and a collection of constant data that contains strings and any other values that don't fit nicely in four bytes or less. The only plain text data the game itself ever really touches is the localized text, which is pulled out and stored in a separate file from the script bytecode (this way, said text can be easily changed to other languages).

Also how do you plan on packaging the scripts along with your game? Will you compress them at all or package them in any way?

I have Visual Studio set up to run the custom compiler as a post-build event. The source script folder is passed to the compiler as a command line argument. All the scripts in the folder are compiled, and each script's bytecode is stored in a binary .script file in the game's data folder. (As noted, any localized text output from the script goes to a separate file in the game's English text folder.) The script files aren't compressed, but they're already really small anyway so there's not really any need. The game only loads each script file as needed instead of keeping them all in memory (although they're small enough, it probably could keep them in memory without a problem, although it'd take a bit longer to start the game).

Did you ever consider converting those $13 symbols to keywords, and doing a hash table lookup? That way you can type keywords like return in the language?

$13 is another way of writing 0x13. That is, the hexadecimal value 13, which is the number 19 in our usual decimal number system. The game itself never sees a command like "return". All it does is read a single byte at the current position in the bytecode and sees that its value is $05 (hexadecimal 5), which is the byte code that "return" compiles to. The game then checks the call stack for the script and works its way back to wherever it most recently came from. There's not really any reason to do a hash table lookup; checking the instruction's byte code value is implemented as a switch block in the C++ source code.