• Add Review
  • Subscribe
  • Nominate
  • Submit Media
  • RSS

Announcement

Announcing a successor... The Secret of Varonis

Hey all, bet no one was expecting an update on /this/ game. Which is partially true -- we're announcing a continuation project of sorts, The Secret of Varonis, which features all-original assets, a touched-up story, lots of brand new maps, and a more stable engine. The end goal is to get it on Steam. It has its own gamepage at https://rpgmaker.net/games/12387/ and homepage at https://varonis-rpg.com/

Thanks for your time, hope you enjoy the new game once it's out!

Announcement

Featuring! Plus a new release version

Hey all, as is probably obvious by now, SaGa4 is the RMN feature game for March 2017. It's an honor so decided to spruce up the CSS a bit and now the gamepage should be looking a little spiffier. I've also taken the opportunity to put together a new release based on some minor tweaks that have piled up over the last year or so plus some bugfixes that have come up in the two weeks or so that we've been on the front page. Full list:

Balance:
- Buffed the SPEED staff (bigger agi boost)
- Heavily nerfed the HEAL staff (not as heavily influence by mana, it was previously healing about twice what it should've been)
- Increased the price of the DRAGON helm, SAMURAI guantlet, and DRAGON body (the resistances they offer are substantial)
- Buffed the EXIT spell (hits more often)
- Tweaked the HEAL spell (it was previously worse than the more mundane staff)
- Tweaked the BAND helm (it offers a bit less defense but true to its SaGa1 counterpart, it confers O-PARA)
- Buffed the NUKE spell
- Buffed the LASER bow
- Buffed the PETRIFY hammer
- Buffed the GREAT bow
- Buffed the LMG gun
- Buffed the TANK gun
- Buffed the armored beetle class of monsters (better physical tanking)
- O-ALL no longer includes phys damage resist (it was previously the only available source to players and made mutants that stumbled on it invincible)
- Corrected the description of O-PARA (it doesn't actually confer O-STONE)

Graphics:
- New defeat animations for all bosses
- Fancier (?) title screen

RPG:
- It's now possible to retrieve the elemental stones hidden in world 1 when revisiting it after world 3

Bugfix:
- Attempt to fix a save corruption issue caused by removing 5th party members
- Interiors in Ermengarde no longer crash

This new version is hotswapped out from 1.04 and available from the big button at the top. Thanks for tuning in!

Progress Report

Download is up

Finally pulling the trigger on this one. Version 1.00 is up and ready: http://rpgmaker.net/games/7236/downloads/8019/. Unless some major showstopping bugs come up that'll probably be the end of development. But if you see any bugs, let us know and we'll do our best. Same goes for if the game doesn't run on your system -- previous betas required a newish version of Java but now just about any non-ancient Java release should be fine. ...but yes it is a requirement

Oh, there's also an alternate version of the download available that includes our in-house database editor tool and an editable version of the database, if you want to check things out or cheat or do whatever. Reminder full source is up at https://github.com/psywombats/mgne. Thanks for the support!

Game Design

Combat design! (release next week)

Hey all, another design post slash progress update. Progress: I've been distracted with other stuff, but playtesting is wrapping up and all that's left is to fix a few issues that came up during beta, and then we'll have a packaged release sometime next week. It's nice to actually go back and fix stuff after the game's complete rather than our usual release pattern of "put it out immediately, cross fingers."

As for combat, this is the post I actually had in mind when I started doing the design updates. I'm not a design expert but I can at least illustrate our process. When we started design the combat system in SaGa, we had to answer a couple questions first: what exactly was fun or not fun about the original games? Ideally we'd like to steal as many systems as we can and leave out the garbage.

So to start, here's the most aggravating unfun world 1 encounter across the Gameboy SaGas:


It shows up once every second encounter on the overworld. It doesn't die in one round. It hardly poses a threat. It drops garbage-tier meat. It doesn't have any specific strengths or weakness, it just has to be hit for two rounds until it dies. It's a brainless timewaster.

Here's a more interesting world 1 encounter:


While all the enemies there are generally fodder and about as threatening as they look, the fact that there are multiple of them steps up the decision-making for the human. If you're like me and want to kill everything as quickly as possible, you'll pretty soon figure out that mutants should be casting their magic at the largest group present, the slow-but-strong 5th party member should be attacking one enemy while the weaker party members gang up on another, etc. What's fun about SaGa is using your different party capabilities to take on a group of enemies as fast as possible.

In SaGa4, we're trying to take that as far as possible. Here's a sample world 2 encounter:


Before this encounter, the player learns that a statue hits hard and a banshee can potentially SCREAM someone to death. Both are relatively slow. Just jamming A on melee attacks might kill off the banshee, but if the player can find a way to divide up their attacks, status conditions, fatal magic, etc, the fight should be winnable without having to take a single AXE to the face. This is why we've made the (somewhat controversial) decision of having attacks on dead enemies do nothing instead of automatically target the dead enemy. Players should know when they enter their attacks what should be hitting what. The fast human could shoot the banshee with a stun gun while the monster blasts the statue with FLAME, or maybe the mutant uses that newly-learned DEATH FANG.

Which brings me to the next point: different party members (and by extension races) should have different specialties to maximize the number of strategic options available. This was most pronounced in the first SaGa, where humans couldn't use magic and all three races had very different leveling. SaGa3 replicates this with different stat growths per race and stuff like double talent damage for monsters. Here's the basic breakdown in SaGa4:
  • Humans: Single-target damage, potentially super fast single target damage. They should be one-shotting the banshees and other weak casters and fodder
  • Mutants: Group specialists, whether by combat magic or status effects
  • Robots: Customizable companions! Throw on eight BATTLE swords and you have a powerhouse, or add six or seven body armors for a tank
  • Monsters: Versatility. They can round out the party in whatever you're missing at the time


Mixed parties are good. Although a mono-race party can work (4 monsters rules) and there is room for specialization within the races, they'll mostly be at a disadvantage. For reference, from the classic Final Fantasy Legend manual:



...whoever recommended four humans would want to reconsider in this game. The endgame is designed to "punish" certain bad decisions to force the player to adapt. For instance, how is the four human party going to deal with a 99-defense armored beetle or DEATHSKIN spamming disease? Or how are the four mutants going to deal with the SERAPH: immune to status effects and elemental damage? As the game progresses, the rules about who should be attacking whom get stricter, with the idea that monster encounters should almost always be dangerous to snooze through.

Other stuff we decided needed to go: system opacity. As much fun as it was trying to figure out whether it's worth spending 4000 gold on something called the "BUTT" martial arts or cursing at the gameboy because my LAMIA turned into a CLIPPER, not many of us have time for that any more. Some examples of places where we've tried to improve user experience:



So on the whole, no new systems, just taking what worked in SaGa and polishing it up to be par with modern design standards.

The other part of combat design is the raw numbers stuff: how much damage should a weapon deal, how much STR plays into that, what's the hit chance, etc. Mostly boring but you can see a full breakdown here: https://github.com/psywombats/mgne/wiki/Combat-Formulas It also includes some mechanics comparisons, so in case you like old game mechanics trivia, here's some old-fashioned weirdness from FFL:
  • Flee chance is a fixed 50%
  • Integer overflow at an intermediate step usually screws up your max damage: a HAMMER is just as a good as a SUN sword at max strength
  • The in-battle RNG is totally broken and produces the same rolls each time, which is why ASHURA's 3-HEADS always hits 3 times at first and kills you
  • SAW is famously bugged and will kill anything with greater defense than your strength, up to and including the literal Abrahamic god


In SaGa4, generally, we've buffed stat debuffs, increased the effectiveness of non-fatal status effects, nerfed AGI-based weapons a bit, increased the effect of DEF at high levels... oh and multihit moves still hit in a fixed order, but by design this time.

Game Design

The Making of a Pantheon

Hey guys, it's me, bob_esc again. We've just wrapped up our first round of internal playtesting, gotten together some testers, and started up more balance testing. I'm going to be WILDLY OPTIMISTIC and say we'll be done by March. But this blog isn't about that. This blog is about Monsters!

I originally had a bit in here about the monsters in the original SaGa games, but since I didn't do any research got some of my facts mixed up, it wasn't great. There was this whole thing about Black Pudding and bug-typed Pokemon. Now, though, you get the pure, unadulterated good stuff about...

Masters of the Demon World Monsters

To end of making a game that felt like SaGa, we needed a menagerie of monsters that fit the same criteria as those in the SaGa games did: groups of related monsters ranging from the more mundane to the more fantastic from a variety of different pantheons and mythologies from around the world. Well. The actual method of monsters generation from FFL1 ranged from "steal the D&D Monster Manual" to "Steal everything not nailed down." Our process here was fairly straightforward and a little more dignified.

Step 1: Spitball
Probably my favorite part of the whole process. We put our heads together and came up with general monster families. Some of these we ripped directly from SaGa. In our defense, these were the fantasy staples like Skeletons and Zombies and Goblins. The next stop was probably my favorite Wikipedia article: List of Legendary Beasts. Of course, this used to be laid out waaaay more chaotically and it was just a bunch of monster names stuck together, but then when you look at the List of Legendary Creatures by Type, you get a much better sense of how much is out there about related types of monsters. Perfect! This is how we found some of our more fun monster classes like the Goat class or the Weasel class. Most of our classes started life by spotting something fun and rolling with it:


The classic image of a Baphomet created by Eliphas Levi


When trolling around on teh interwebs, we came across the Baphomet. Thanks to the Church of Satan, what we traditionally see as a Baphomet is basically the devil. I think those guys are still trying to get a statue put up in Oklahoma? Whatever. But the Baphomet originally was what the Knights Templar were accused of worshiping. Poor bastards got burned at the steak because the King of France didn’t feel like paying his bills. They were rounded up on Friday the 13th in October, 1307. So, the made-up idol responsible for a huuuge Western superstition? Yes please. We had to have it.

Step 2: Populating and Organizing Groups
This part was a little harder. With the Baphomet, the problem became "What goes in a group with it?" We toyed around with having it included with a Royal Demon family we were considering, but that didn't pan out. But then I said, "Well there's a rich tradition of goat men running around and making love to nymphs in Greek mythology...." Viola! The Goat group was born. Look out for Satyrs. They will sing your ass to death.

In some of the other scenarios we were looking to fill up groups we rather enjoyed like the Jellyfish group and the Weasel group. In the case of both, we had a few monster types we liked, like the Moon Jelly and the Ratatoskr respectively.


The majestic Ratatoskr: Squirrel messenger of the Norse gods


So how do you fill these? Well, the answer is fudge. The Ratatoskr actually got moved out of the Weasel group and placed in the Rat group, while things like the Hinotama and Medusa (I'll explain, promise) ended up in the Jellyfish group to fill it up. By "fill it up," I mean that the way our monster transformations work, you need the same number of monsters in each group. While not, strictly speaking, a jellyfish, the Hinotama felt good as a jellyfish. It floats around, it’s pretty fantastical, and it could probably mess you up if you bumped into it in an alleyway.


Wait oops that's a Yu-Gi-Oh card SHIT


Well, uhh, that still makes my point: it’s dangerous-looking, and it has a very SaGa kind of feel in that it is some slightly obscure Japanese legend. Perfect! At the same time, a Ratatoskr might be a squirrel, it still fit in with the rodent-themed Rat class enough to shove him over there.

Oh, and I promised to explain why Medusa is a jellyfish. We liked the idea of having Medusa somewhere in our game, because you can't really play thought the first Final Fantasy Legend without someone in your party getting turned to stone by one, but it always felt odd to run into groups of 5 Medusas, when there was clearly only ever one. Gorgons? Sure. Medusas? Nah. So what else has lots of little squiggly things coming off it? Where does Medusa fall taxonomically? Jellyfish! Done, and done. Makes perfect sense.

Step 3: Making the Cut
This part of the process was difficult as well. We had a full list of some 52 different monster types but only room for 27. So we had to make some choices. Do we really need a Demon group AND a Demon Royalty group? Not really. Can we really justify some of the choices we made to fill up an enture group of Illusion enemies? Not really. Furthermore, do we really need Ghosts, Wisps, Burning Demons, Illusions, and Disembodied Eyes? That's a lot of stuff floating around, so Eyeballs and Illusions got axed. Sadly, some stuff we really liked had to go at this stage:


The Cipactli: Where the vowels don't matter and the pronunciation is made up


We had a whole host of fun Aztec creatures! South America has a rich and storied history of human sacrifice in the name of peyote-inspired gods. SaGa, the original, didn't pay much mind to South America. That said, there is exactly zero chance you knew what a Cipactli is. And actually, WE don't actually know much about them. I mean, I read the Wikipedia article. Still. Since absolutely no one knows anything about it, you'd have to google it, and that's no fun. If you have to google one or two things that's OK. But we didn't want to just confuse the shit out of everyone by making a whole group of incomprehensible monsters that you can't even pronounce.

So, sadly, we axed the Aztec Chimera group.

Step 4: Technical Stuff
Now for the good part! When I asked psy_wombats about how we went about this from a technical standpoint, he said...

author=psy_wombats
A quick word on how monster transformations work: In the original games, monster transformations are all handled slightly differently. In my opinion the best-balanced version was the original, where monsters had families and groups. Monsters of the same family would be like goblins, onis, and giants all having the same battle portrait, while the greater group would include rats and wolves, which share the same walking sprite. Internally, there's a huge table of what happens when monster of family X eats meat of group Y and rules for the level of the resulting monster based on the levels of the eater (and also the dead monster victim).

So the key balance element around monster transformations comes down to that monster X + monster Y table. How was the original one constructed for FFL1? No idea. Probably by hand. Either way, there are some strange balance things going on with that table and it's possible to end up accidentally eating something smelly in the World of the Sky and end up with a 20 HP CLIPPER, no warning. We've given players the favor of telling them what they'll transform into first, but we've also constructed the table a little more intelligently. I actually spent a week on a monster table construction program that uses iterative, genetic algorithms to construct an "optimal" table that matched our criteria: can't gain monster levels too quickly, can't suddenly lose power, some families are intrinsically rarer than others. Hopefully it did its job, and monsters should be rewarding to play and grow in SaGa4.


Well said, buddy. That "optimal table" he's referencing is this one right here:


The complete MotDW monster transformation guide! Now without labels!


Basically, how you read this is: if you're, say, a Cockroach (a member of the Bug group, sensibly abbreviated FLY) and you eat meat dropped by a Goblin (a member of the eponymous Goblin group, abbreviated GOB) you will transform into a Goblin. Simple, right?

How do you come up with a matrix like that for 27 different monster groups with 6 different monsters in each with 13 levels of monsters such that you minimize the number of individual monsters--that is, 1 in 162--that you can't transform into while simultaneously figuring out ~12 different groupings of families that actually make sense, and all the while minimizing the number of "non-incestuous" meat consumption that lead to no transformations.

TL;DR, its haaard. We used that genetic algorithm stuff psy metioned up above. I think we ran those algorithms upwards of 5000 times, and we finally ended up with this breakdown of groups such that the only monster you can't transform into is an Annis (level two Hag, of the HAG group). There are about 10 monsters on 13 levels. PERFECT!

After that was squared away, the only thing left was to group monsters together into sensible families. Those families basically mean that if you are a member of that family--say, a Ooze of the Slime group, abbreviated GOO--and you eat meat from another member of that family--say, a T-Cell of the Disease group, abbreviated DIS--you don't get anywhere.

So, which families make sense? Elephant (EPH) and Magic Bird (PNX) don't make sense. However, Bird (BRD) and Magic Bird DO make sense, and I guess Elephant makes sense to go with Goat (GOT) and Horse (HRS) because they have hooves (more or less). Frankly, that's my least favorite grouping, but everything else is juuust fine. Snake (SNK) and Jellyfish (JLY) is questionable, but I've decided everything else is fine.
Just.
Fine.

Thanks for reading! Leave me some comments if you've got questions.

Miscellaneous

Real Talk About SaGa's Art

Hey guys! bob_esc here to talk about the art in SaGa some more. A couple weeks ago week, psy_wombats talked a little bit about handling screen size, and he got into a little bit about color pallets and whatnot. As the guy responsible for just about all of the original art in SaGa 4: Masters of the Demon World, I felt like I could provide a little more detail about the process.

First of all, one of the things things people notice rather quickly about the game is that the sprites are a slightly different color than the rest of the tiles.


Its like when they switched grey colors in LEGO sets


I'm told this is a feature of how both how the original GameBoy rendered things and how we make things look not silly on a computer. The SECOND thing people tend to notice about the art is that there are 4 colors in each pallet. In the case of the sprites, the fourth color is "transparent." The THIRD thing people tend to notice is that we shamelessly stole all of the walking and battle sprites. I'll talk about that in a bit.


In deference to my RM2K days, those are the "lower chip" and "upper chip" files


So that's them; all of my hard work. Speaking as someone who has absolutely zero art in their background (I'm a trained engineer), these took forever. So I'm sure you artsy-types have an idea of how to go about doing this sort of thing, but for those of you who don't--or for those of you who are just curious how I got the job done--here's my process:

1: Look Up a Picture of What You're Making
I can't stress how important this ended up being. If you're just guessing what something looks like, when you try to recreate it, its gonna look bad, right? Take the chip modeled after the Japanese Torii gate. The one you see up there in the middle or so of the upper chip looks pretty good right? Looks a little something like this...


How Zen is this gate?/It is mostly red and black/Refrigerator


Well I probably should have done a quick google search for that before my original attempt:


What's that? A hotdog on sticks?


2: Setting Up the Environment
For those of us who have strange moral qualms about torrenting Photoshop, there aren't a lot of alternatives that do a good job for graphical work. One exception is the GIMP. It's an open source image manipulator, and its great! As much as I love MSPaint, the GIMP is great. Transparency handling, layers, an array of great filters, gradients, and a plethora of other artistic tools. When I work in color, one of my favorite tricks is to import a picture of, say, a piece of wood and then index the image such that it only has four colors (my palette size of choice), and then use those four colors in my rendition of, say, a wooden table. Indexing purely means that instead of the colors existing in the 64-bit range (that is, 2^64 possible colors), they exist in a space of say, 256 colors, which is what the RM2K used. For all of y'all out there still using that software, proper indexing is the reason your custom chipsets look like someone puked on them. You can take your chipsets from the 64 realm you made them in, import it into the GIMP, and index it to 256 colors! Export as a PNG and you're done. The GIMP picks the 256 most common colors in your image, and if you've used more than that, it "rounds" all of the other hues until they match one of the 256 most common colors. One of my favorite features!

As for MSPaint, boy am I a fan. So-called professionals may laugh when I say I do most of my work in MSPaint, but its really quite a good tool. Namely, its free with a copy of Windows. Back in my old recoloring days with the RM2K, I would painstakingly change one pixel at a time with the pencil tool. But I am much wiser now. If you take your eyedropper and select the target color as your background color (right-click using the eyedropper) and select the color to be changed as your foreground color, you can replace the original color with the target color by right-clicking with your eraser tool. Neat, huh? I use this feature a lot more when I'm working in color. When you have FFFFFF, AAAAAA, 555555, and 000000, its less important.

3: Outlines
This one is pretty self explanatory. If I don't have a clear outline, things tend to look like blobs. When things look like blobs, you don't know what they're gonna look like when you're done. Sort of in the same vein as that, if I make a bad outline, I generally figure out really fast that it looks bad. It won't be a huge amount of effort before I realize "Holy crap that looks bad and I should feel bad."


This is what happens when I ignore my own advice. WTF even is this?


4: Mid Tones and Texture
This one is much harder than the outline. Unless the intent is to make the object look like plastic, this is a tricky stage. Take this oversized mountain that never made it into the game.


This is an example of poor texturing


The second one is a little better than the first one. The astute among you will notice that it looks similar to the RM2K RTP mountain. There is a reason for this. This shows that when you need to make something bigger than one tile, you need to actually have something to put there. When you're the scale is really small, like the 16x16 pixels that this game uses for tiles, I'm always making sure that every pixel has a purpose. One pixel can be the difference between making a female sprite and a female sprite with knockers the size of her head. That's just another reason I don't make sprites. Human proportions are hard, yo.


One of my favorite tiles. Each an every pixel is important here to show curvature and detail


As I mentioned, depending on how you texture, an object or surface can be made to look like plastic, wood, stone, metal, ect. This is probably the biggest tool in my arsenal when you've got four colors. You can make something green and then, duh, its grass! Can't do that here. Take these stairs:



On the left are stone stairs and on the right are "other" stairs. They're narrow enough where it could be anything. But the point is, the stairs on the left are obviously a rougher material--they aren't polished or refined. Perfect for caves or shabby huts! Later on in fancier locations, smoother stairs are in evidence. Further note on this: The best way I found to give something a ragged edge or imply that something is really thin was to use the second darkest tone as a border.



Here you can see roughly the same sign: One on a piece of paper, one on a metal plate of some sort. With the tears and the lighter border, you can tell this is a threadbare sign.

5: Finishing
When I'm done I usually add that attractive pink background you've seen on so many of these images. That's just a placeholder for when I make things transparent, which is how our game engine handles sprites. What I usually do is import things into the GIMP and then just delete the pink. Simple, but you can't do it in mspaint, the premiere image manipulation program.

It really helps me to have someone else (eg, psy_wombats) taking a look at my work. It can be really easy to tunnel vision on these things when you've got them blown up 8x. "Yeah," I say, "That XYZ sure looks exactly like an XYZ," and then when I show it to psy_wombats, he'll say, "That's obviously a penis." And I'm like "Whaaaat, no," and he's like "Its totally a penis." And then I look at it again and I'm like "That's not--OH. Yeah. That's a penis."


Just be glad I lost the animated version


Once I make sure it looks the way its supposed to, then I put it into the chipset and push it to the master branch--we use Git with all of our MGNE games (ZSII, Blockbound, etc).

And that's it! That's how I made all of the art in SaGa.

I mentioned above walking sprites and battle portraits. Yeah, those look an awful lot like the ones you remember from Final Fantasy Legends 1 & 2. We didn't include those from FFL3 because, well, some of them look weirder than what I came up with.


Those SquareSoft devs....Someone was hiding sake under their desk


The monsters we ended up coming up with fit pretty well with a few exceptions into categories that we already had art for, and based on the fact that I don't have an art background, I seriously doubted I could come up with 27 battle portraits and 11 sprites in the time we wanted to develop the game. Since we have, ahaha, gone over the time we wanted to develop the game in, maybe I could have come up with something, but hey, I'm not a trained artist.


I learned how to design this quality gearbox instead!


Anyhow, I tried my hand at it and with a little bit a lot of effort, I actually came up with one or two things that worked. Sadly, though, humanoid things in general are really hard for me to capture. Our statue tile was just a base for about 3 months while I tried to make an angel ala the RM2K RTP statue, but I eventually gave up on it. I can't do people. Weird stuff, however...


This one, sadly, doesnt have a group of monsters to represent. I called him Mr. Slimey


This could be the battle portrait for the flame demon class of monsters instead of a burning wagon wheel (?)


These were made in two different parts of the development cycle: before we decided on final monster families and after. We dont have a floating eyeball class and we DO have a flaming demon class (that's the Djinni/Afrit/Helios class for people who have gotten a chance to play the game). This brings up a good point: if you're a slow worker, make sure you know what direction your game is going in before you make art. For example, I have a bunch of crap kicking around on my hard drive from when World 3 was going to look like feudal japan. That's why I had that lucky cat picture, actually. Be glad that never made it into the game. Anyhow, I wasn't about to put in a serious effort into making sprites that wouldnt get used. On the flip side of this, we had a rough lower chip sheet about a month before anything even got mapped!

Just a final bonus image for y'all just to prove again (as if I needed it) that I am not a trained artist.


Yuck


This is bob_esc signing off for now. We should actually have a game somewhat soon for you, so hang tight!

Progress Report

Beta testing, plus SaGa tech

Hey all, another design post here. On the development front things are going fine, just polishing off some bugs, making balance changes based on playtesting, and setting up a good release. Although if you have a controller that you usually use for PC games, hit me up with a PM -- we’re trying to get controller support but I don’t have anything to test with. Anyway, I’m covering our tech and dev tools this post. Hopefully it’s at least interesting to other people like me who are way too into editors/engines/makers.

Boring technical stuff first: most of SaGa4’s core code is written in Java. The low-level GL stuff is handled mostly by libGDX but the bulk of the code is a custom engine dubbed MGNE. This same code powers SaGa4, Blockbound, several of the roguelikes I’ve posted on this site, and even the action/exploration game divergence. It’s been pretty useful over the years, even if the only thing the games have in common really is that they all use overhead tile-based maps. There’s a bunch of game-specific code built on mgne that deals with RPG battles, UI, etc. It’s actually all public for the interested: https://github.com/psywombats/mgne. (side note: version control is great and if you’re not using at least dropbox for your games, you should consider it)



For those used to RPGmaker, here’s the slightly more interesting part. MGNE has a database editor to go along with it. All of the games built with it are also data-driven, in that you don’t need to mess with code to make changes to the game. The MGNE database is basically just a fancy JSON editor, but it’s pretty cool that you can screw around with pretty much the entire game with it. I’ll probably bundle it along with a release version of the game in case anyway else wants to make a cheap FFL clone. (...or cheat, w/e)



Probably the feature I miss most about RPGmaker is the map editor. Luckily, there’s a freeware equivalent called Tiled that we’re using to make SaGa4’s maps. It doesn’t have support for easy eventing the way RM does, and chipsets are a little hard to manage, but there are a lot of upsides as well. For instance, there are as many layers as needed, polygonal events are possible, and most importantly, it’s extensible and can export maps in a format the game engine can read.





Also, fun thing about how we have teleports set up. Remember in RM how much of a pain it was to change maps after setting up teleport events? If you shifting the map a few squares or moved a town on the world map or whatever, it’d all be off. We have a target system attached to our teleports instead, so that even when maps shuffle around the teleport targets are still set up right. It’s also a hell of a lot easier than entering coordinates. Here’s a bit of how it looks:





Another note about how that’s set up… That teleport command is lua script, which is what powers SaGa4’s eventing and all of its cutscenes. It’s supported in Tiled maps plus can be played out of separate files, which is where we have all our cutscenes stored. There’s also a debug console where a dev can execute any arbitrary lua command (for easy teleporting, item granting, turn encounters on/off, etc). I’ve also set up some data binding and a bunch of utility functions to make cutscene scripting as painless as possible:





The other fun piece of tech we’ve got is the audio system. For those that played the demo, you’ll notice everything’s just rips from the original SaGa games at the moment. But those aren’t MP3s sitting in there. We’re actually using data dumps from the original game cartridges played back via a built-in Gameboy APU emulator. Based on Blargg’s C++ APU emulator (see here), we have a Java implementation that plays back and renders the original sound data on the fly. So we get 30 tracks for 30kb of memory, and it’s all as authentic as possible. Maybe one day we’ll find a composer that knows how to use a Gameboy tracker. I kinda doubt it though. Oh well.

Game Design

Content complete, and screen size design

Hey all,

More SaGa updates and design stuff. Things are still moving along at a decent enough rate, and the game has actually been content-complete for a month now. I'm just working on some polish items and awaiting playtest feedback. With a full release probably coming before too long, I’ve taken down the demo as it’s no longer really indicative of the whole game. Hang tight!

On to the design item… I’ll cover screen size, resolution, map layout, and all that stuff. The essential problem here is that the original Gameboy has a resolution of 160 * 144, or 10 * 9 tiles. The monitor I’m using to write this post has a resolution of 1920 * 1200, or 120 * 75 tiles. Let’s say I’m dumb and just use the original resolution. Here goes!




Okay, that doesn’t look so hot. I like pixel art, but this is something like a 12x scale factor, and it makes it hard to see what’s going on on the screen. Instead of blowing up the individual tiles to match the Gameboy resolution, why don’t we just extend the viewport? We’ll keep tiles at 16 pixels by 16 pixels, but display more of them to fill the larger space of my desktop monitor.




This... doesn’t work so well either. The viewport is so ridiculously big that the player can see off one side of the world while standing on the other. It’s hard to see in the preview image, but it’s also difficult to make out individual details of the tiles. Even though the tiles are still 16*16 pixels like the Gameboy version, their effective size is smaller.

It looks like SaGa 4 won’t have full screen support, then. (well, it will, but you’re crazy if you use it in my opinion.) So we have to put together a windowed solution. A 160*144 window sitting in the 1920*1200 monitor doesn’t actually look all the great either because of the effective size problem, unless you like putting your face three inches from the screen. Instead, we’re opting for a combination of upscaling (tiles are 16*16 scaled to 32*32) and viewport expansion (20*15 tiles instead of 10*9) tiles to present a Gameboyish experience that’s appropriate for a monitor. All the screenshots up on the page are in this resolution.




We also considered a scaling strategy sometimes seen on emulators. All of these screenshots have been using a straightforward scaling algorithm that simply turns a 1*1 pixel into a 2*2 pixel with no inference. Instead, we could use a scaling shader like Scale2EX to blow up the image a bit while preserving some of the pixelyness. It was originally designed to work on 32-bit titles where the blockiness was a little less pronounced, and it works pretty well there.




SaGa not as much though. Having only four (well, eight) colors limits the effect a bit.




So now that we’ve decided on straight scaling, there are still a couple of design considerations aside from just graphics. Field of vision was important to a lot of the mazes and dungeons in the original games, and replicating them at the same size in SaGa 4 just wouldn’t feel right. For instance, here’s two field-of-view obstacles as they’d appear on the Gameboy compared with how they’d feel in our window.






Things get a little more obvious. If I want to make a similar puzzle in SaGa 4, I have to expand the map a little to keep the treasure chest or exit stairwell out of the player’s sight radius. With a bigger map, there’s more space to cover. With more space, there’s more tiles, and more chances for a random encounter. So the encounter rate has to be reduced. If we used the original 1 in 12 encounter rate (ew) you’d be looking at four times the encounters as in an average playthrough of SaGa. Clearly scaling things up from older platforms has consequences. As an aside, I think this the reason for one of the most egregious encounter rates of all time: the RM2K/3 default:




If you ever used this encounter rate in your 20*15 tile RPGmaker game, I hate you.

Game Design

SaGa alive?? Also, retro color scheme talk

Hey all,

Progress on SaGa is moving along slowly but surely, and we’re shaping up for a final release in a month or two? Until then, I figured I’d write a bit about some of the design decisions and technical tidbits we’ve run into while developing the game, mostly about capturing the Gameboy feel from both a programming and design perspective. So expect a mix of game design theory and obscure SaGa technical details!

I’ll start off with some notes around our color scheme (which is coincidentally where I left off on design stuff like a year ago…) Some history first though! If you played SaGa on the original bricklike Gameboy, you’ve experienced its original monotone green color scheme.




As you can see, it’s very green and looks a little strange on modern screens. That’s because the original Gameboy LCD screen didn’t have a backlight, and the simulated greeniness looks strange on a monitor. It’s supposed to be more of a black and white feel, which is why modern emulators (for backlit PC screens) usually just render grayscale.




It looks fine, but we can get more authentic than the clean palette even without simulating the original GB greens. On the Gameboy Color and Gameboy Advance (where I played a lot of SaGa), original Gameboy carts would be rendered with a colored palette. Because the original GB carts didn’t provide a palette, just intensity, the GBC would infer a palette. Each of the shades of gray gets mapped to a color.




Interestingly enough, the game now has more than four colors. What’s happening here is that the GBC is treating tiles and sprites differently. The Gameboy rendering pipeline makes a distinction between static maps and moving sprites, so there are actually seven colors here: four shades on the map layer, and then three shades plus transparency on the sprite layer. It’s pretty neat, you could even change the palette by holding different buttons on startup. Full list here: https://en.wikipedia.org/wiki/List_of_video_game_console_palettes#Game_Boy_Color

Things were starting to look a little better in SaGa4. Characters were actually brown, water was actually blue (or at least green-blue). But the GBC false color palettes were also not designed for a backlight, so the colors look pretty saturated on a PC monitor. To put together the final palette, we toned down the color scheme a bit until things looked only GBC-ish enough to be mistaken for monochrome.




Not too bad! All of this is done in a shader at a pretty high level so we can still do animated transitions like fade-in fade-out and the shader will enforce the palette. (If you’re curious, full source here: https://github.com/psywombats/mgne/blob/master/saga/res/shaders/gameboy.frag) Of course, the downside is it’s pretty easy to tell what’s on the map layer and what’s actually a sprite.




Hmmm, not suspicious at all.

Announcement

Complete world 1 demo!

There's a new download up, this one a complete version of the first world, up through the first real boss. So, that means two new dungeons and other areas to fill in the lost city of Hero. Hope you enjoy.

This download is mainly meant as an update to the previous demo, ironing out some balance problems and crashes. If you've played through the first release, your save should be compatible (although you'll probably have way more defense and cash than a normal playthrough). A full list of changes here:
https://github.com/psywombats/mgne/wiki/Changes-from-demo----world1-demo

There was a hiatus of about 3 months in the middle there, hopefully bob and I can take the summer to get the rest of the game done. Things are running surprisingly well now that the engine is (mostly) complete.
Pages: first 12 next last