Noxico

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.

In Dwarf Fortress Adventure Mode, combat is done mostly turn-based, Rogue-like. You got your sword, you got your target. Press against the target and you hit him with your sword. It might get stuck in your target, in which case pressing against him again without either of you leaving your current positions means you get to twist the sword around inside of your target. Yay. You can also throw stuff like darts and other people.

In Megazeux, combat is done real-time. By default you only have a gun. Hold space and press a direction to fire a fast-moving but easily dodged projectile. The gun is also an automatic. Several sword engines have been made that replace the unlimited-range gun with a close-range sword (duh) that usually does damage in a two or three tile strip perpendicular to the player. That is, if you face north, the sword strikes the tiles from northwest to northeast.

In Corruption of Champions, combat is strictly turn-based, like the average RPG. You pick an action, the opponent picks an action, and whoever’s faster gets to do his thing first.

For Noxico, which has (MZX-style) realtime movement and exploration, I was thinking of going MZX-style with the combat, too. Most weapons would be close-range, with bigger blades having more range (imagine a BFS reaching some three tiles far and a simple knife only one tile). Guns would still be more or less unlimited in range, but instantly hit – there’s no visible bullet. The further the target, the higher chance of not getting hit, and maybe if you do get hit, it won’t be as effective if it’s from far away. And if that’s not enough, just make guns relatively rare.

What do you think?