Minoquar! Update.

A quick progress video on Minoquar!

I’ve got the player moving, and the ability of the sword already coded in.

Now for minoquar movement and the cloak and key.


Stop Resisting!

First, I am no longer resisting the grid.  I embrace the warm comfortableness of the grid.

And, moreover, I re-embrace ASCII graphics as the One True Way of doing things.

And, even more, I embrace QR codes, and their potential uses for game creation.

And, as usual, John Hattan is to blame.

Well, not directly.  Really this person is to blame.

So, taking a brief break from Yax (which more about later), I’m making a Minoquar version in Java.

I decided to use an ASCII grid because I already have one working from the version of JetLag I’ve been working on.

I acquired a very nice Java QR Encoder from here.

As a result, I learned some things about QR.

I have a suspicious that this accidental knowledge will one day be useful for a legitimate purpose at my day job.

But until then, MAEK GAEMS!

The most important thing is that I can take ANY TEXTUAL DATA and make a QR code with it.  There’s a limit on the number of characters, but I’ll burn that bridge when I come to it.

Also, because of the rules of Minoquar, there needs to be a “alignment square” in the lower right.

This square does not appear on all QR codes.

It also appears multiple times on larger QR codes.

Generally it appears on QR codes with a length of at least 18 characters (but not always… I think there is some sort of run-length encoding going on in QR).

So, for the nonce, I’m going to go with a set of about 20 “canned” pieces of text, plus the ability to enter in your own text.

Later (and likely as much work as the basic game itself) comes things like scanning existing QR codes and so on.

A few musings about Minoquar.

So, the link above talks about the rules of Minoquar.  Having read them and pondering them, I have come up with some of the following thoughts and potential problems (listed here primarily as notes to myself):

First, the player gets to choose initial position, and that initial position is going to be near to one of the three tools the player can use to complete the game.

The items are sword, cloak, and key. The sword allows tunneling through multiple black squares, the cloak allows crossing the minotaurs tracks, and the key teleports you to safety when the treasure has been obtained.

Without the sword, the player may only tunnel through 1 black block, making the sword the most important tool.

Which means that choosing to start next to either of the other tools is silly.

Potential Problem #1: The sword is so powerful that is makes no sense to start elsewhere.

Potential Solution: Randomize the starting location of the player, or randomize the locations of the items and have them be unknown until they are in direct line of sight.

Second is the “leaving a path” issue. Both the hero and the minoquar leave a path like a lightcycle (but only in the white areas). The hero cannot cross his own path. The Minoquar cannot cross his own path. The Minoquar CAN cross the heros path, but cannot stay on it. The Hero CAN (with the cloak) cross the Minoquar’s path similarly.

The problem here is that a QR code is pretty tight as it is to move around.

Potential problem #2: the hero may never need to worry about the treasure, because this game is essentially lightcycles of tron with tunneling.

Potential solution: Either don’t have a path, or have a path fade away after a certain number of turns.

First step, though, is to do a faithful port of the rules as they currently exist, in order to see what the rule flaws are, so we’ll see how much of a real problem these things are before we go about fixing them.

About Yax

The game with the moving circles will similarly be on a grid and in ASCII graphics.

Why? Because it simplifies the design, and basically allows me to make it into an open-ended turn-based roguelike but with resource gathering and crafting.

Will there be QR codes?

Oh, most assuredly. QR codes can make wonderful caverns, dungeons, and above-ground ruins.

Will there be Yaks?

Certainly, the primary resource is yak hair and the things you can make with it. And it’s called “Yax”.

Will there be Lemurs?

Definitely. And they will be Mighty.

Does this project have a chance in hell of really going anywhere?

Prolly not.



ASCII Graphics in SilverLight

I have recently begun work on a new version of JetLag called, unimaginitively, JetLag 2011.

The most recent “full” version of JetLag was 2003, and was written in C++ and used SDL and Visual Studio .NET (the 2002 version, so with the rare 7.0 runtime).

I’ve had a number of other quick versions with blocks and sans lucky charms, but this time I wanted to really make a version with all of the bells and whistles, including full ASCII text mode graphics emulation, as well as the same sounds that I used in JetLag1999.

The first major issue that I had with the SilverLight version was the graphics.

SilverLight is meant to make really pretty things. Not emulate an ASCII screen from DOS.

I could not find a way to colorize an image, at least not without a pixel shader.

My needs are simple.

I simply need to take a white graphic and give it a hue in which to shade.

Easy, right?

Not hardly.


So, plan B – use 16 image, one of each color, and use a cropping technique to set the visible part.

This works, but it was very slow, and my frame rate was abyssmal.

Not to say that I needed a huge frame rate. I can make do with about 20fps. It’s JetLag, so it doesn’t smoothly scroll.

So I dug a little while longer.

I discovered that ImageBrushes render quickly.

A ha!

Now the entire grid consists of layered rectangles given a Fill of various image brushes.

How many image brushes?

16 for the background rectangles.

4096 for the foreground rectangles. 256 characters each in 16 colors. Each one 16×16 pixels.

It takes quite a while to download the repository, as you might imagine.

Which is what I am doing now on another of my machines.

And I do cache them.  The image brushes do not load the image until needed. It makes starting out a little bit slower(not noticeable on any of my machines, but I haven’t fired up my clunker yet).

The only question left to ask is “why”.

Why ASCII graphics? And in SilverLight, even.

(I also did them on the iPhone, as some may remember).

Really the technique that I found for using ImageBrushes would help with any game where a fixed grid of layered rectangles is needed.

Which is really almost all of my games.