Noxico

As of today, the game has an overworld. Assuming a reach (width and height of the world) of… let’s go with 8, the first 8*8 boards known to the game will be considered part of the overworld and get special handling for a literal edge condition.

Literally in that when you stand on the edge and push on, you’ll flip to a neighboring board. I could make the world a donut shape by wrapping in both directions, or keep to the original plan and add a strip of mountains to show the edges.

Right now, the overworld is plainer than an Amish wife – there’s only a screenful of random grass, recolored for the other three biomes. You can only tell you entered a new screen because the exact pattern on the ground has changed, and maybe the color. Maybe the background music, too. Step two is to add biome-specific structures like trees and rocks and such to the boards.

Thanks to the swell guys at gamedev.stackexchange.com for helping out with the shaping of the biomes.

Generate boards with a method chain.

For example, step 1 could be a typical dungeon generator, which would produce square rooms with corridors connecting them. Already, this output is processed by Noxico to produce something nicer-looking, and that is in fact the basis of this consideration.

Step 2 could be producing a dungeon or town from the generator’s output. The difference being that a town is open space with single-width walls forming houses and the corridors becoming streets, perhaps, while dungeons are solid rock with rooms carved out. For this, we’d need to replace the current (stolen) dungeon generator (as used in step 1) because that one always carves out of solid rock, but I got it covered.

Step 3, if it’s not done in step 2, would dress the board up according to its parent biome.

Step 4, finally, would place entities and other fun stuff.

The nice thing is that you could replace the “square rooms and connecting corridors” generator for something else entirely if you want your rooms to be something not square. Perhaps use BSP for towns and CA for, well, caves?

Compare and contrast.

This is by far not over yet. I’m just messing around a bit until I get proper suggestions in the other post.

Oh and pay no attention to the font.

You start on the title screen. If there’s no earlier save, pressing Enter or clicking brings you to the character creator, which leads to the game itself, popping up a Look window on the player to describe what you ended up with.

But if there is a save, the above pops up. One answer leads to the character creator as usual, but the other restores the game and gives you the Look window as a refresher.

Between the character creator and the game proper, the world is generated. Right now this is hardly noticable but it’ll certainly take a while at its final scope. I wonder if I could multithread the process – generate a playerless world as the player is still mucking about in the character creator, and only waiting if it’s not done yet. Or maybe disable the Go button until the world is done, I dunno?

If this is the title screen, what’s that blob of dither blocks supposed to be? Well, it was converted by hand from this image by an FA artist named Furore.

I think this title screen is okay, but I’m always open for suggestions. So here’s your chance to officially suggest better title screens. What’ve you got for me?

So far, characters in the game can be any of the following creatures:

• Human
• Elf-like
• Dog
• Cow
• Cat
• Dragon
• Insect
• Bat-like
• Horse
• Demon-like
• Squirrel
• Fox
• Slime
• Naga

And any combination of the above, with normal skin, fur, scales, slime, rubber…

Want to play as a creature with rubber skin, a snake tail, the head of a horse, and dragon wings? You can do that.

And that’s horrible.

In modern Megazeux, the developers added a whole lot of neat new functions to the Robotic scripting system, such as file I/O, substring manipulation and various new display methods. Adding those was probably a good idea. What wasn’t is the way they did so. Here’s an excerpt from the Robotics manual in MZX 2.83:

RID (read-only)
ROBOT_ID_ (read-only)

Both of these give the robot_id number of the given named
Robot. In the case of multiple robots with the same name, the
ID number corresponds to only one of them (the one with the
largest robot_id). If no robots have the name, or if the name
in question only belongs to the global Robot, -1 is given.

BEWARE: The existence of this counter makes it impossible to
use words which start with "rid" as counters. The port will NOT
fall through and give the values of any counter that starts
with "rid"; instead, it ends at -1 (since the Robot the counter
is trying to find, like "dles" (for "riddles"), will most
likely not exist). Older games will allow this, but only for
compatibility reasons.

It’s the “riddles” example that really shows what a dumb idea this actually was, and why this post is titled “Counter Creep”. The more counters with special effects they add, the less counters you can use yourself, and they had to add a special compatibility mode just to allow the use of reserved counter names.

For double the facepalm, they could’ve just removed the “RIDx” variant and kept “ROBOT_ID_x”.

And don’t get me started on how to open a file. If you can tell the difference between old and new games, why not break the original limit on the number of actual commands (256) and free up all those counters?

The whole world can now be saved to file and the game has an INI file for settings. You can specify in that INI file which tileset and color palette files to use, disable all sound or change the volume, and some other stuff.

This is also where you specify how to save worlds – you can have it gzipped and/or with the high bits flipped… which serves no actual purpose at all, really.

I also decided to publish my plans and designs. You can find them here, and they’ll be updated every so often.

This is the default INI so far:

doublesize=false
interpolate=false
tileset=ascii.png
extiles=extended.png
palette=colors.PspPalette
 
[sound]
enabled=true
musicvolume=100
soundvolume=100
 
[saving]
gzip=false
flip=false

There are some things that you just can’t do with merely a tag tree. Things would just become too damn hairy that way! Now, I had planned to have towns and such be predefined, with perhaps a bit of random variation – say, placing a building on another spot, moving all the things inside with it, and having semi-important characters rolled up randomly like any other encounter – and it’s exactly those semi-important characters that could really use a proper scripting method!

I talked about this on IRC yesterday and though I won’t name the other guy, he was all “why reinvent the wheel when you’re writing this game in C# and have a full compiler right there?”

Here’s why.

First of all, using CodeDOM and such to compile and run arbitrary code simply won’t do because of a bunch of important limitations. These include that the code block must be contained in at least one method, in turn contained in a class, in a namespace. You could make the script system assume the wrapper class but that doesn’t solve the other problem: everything must be a method call on an object.

this.Move(Direction.Up);
this.Wait(20); //mind you, other entities should still run.
this.Character = (char)0x42;

Second, you can’t easily have a script repeat itself. Imagine a character who constantly (that is, until interrupted) checks a readout, looks surprised, moves a small distance towards a control panel, waits a bit (to tweak the controls) then moves back to the readout and repeats. Sure, it can be done, but it won’t be pretty.

“So why not use something else like Lua?” you might ask. Because it has many of the same or similar problems, when you think about it. That, and some personal problems that go beyond scope.

Noxico takes after Megazeux, and MZX’s Robotic language may have problems of its own, but it works. For the early games like Caverns of Zeux and Cans, Robotic was perfectly suitable.

It’s easy enough for me to write a reasonably suitable scripting engine for Noxico. The big problems I see are with conditionals and loops, and even then I have a good idea how to do it, without getting a full and proper parse tree involved and still support nested ifs! No trees, just a simple list of script lines, one command per line.

move up //or north…
wait 20
char 0x42 //or ‘B’ or 100…

Reinventing the wheel seems like a pretty good idea, really. Especially when you need a bicycle wheel and all the off-the-shelf ones are for SUVs.

Earlier today, I reduced the function that takes the dungeon generator’s output and makes it look nice with proper wall outlines and stuff and turned it from a ~190 line if-else monstrosity with five discrete steps into a nice and tidy ~60 lines, where the only ifs are checking for map edges and a quick loop to fix a bug in the lookup table that makes this optimization possible where certain T junctions aren’t.

I’m very pleased with this, I’m sure you can understand.