Merrak's Isometric Adventures -- Alpha Release 1

Coming Together... I now have what's arguably the most important feature of an editor: a working file writer. After all, what good is the editor if you can't save your work?

Here it is!

Programming the input box took significantly longer than the file writer. This seems to be a theme: UI taking longer than the real feature. But I need input boxes, so taking the time to write a flexible one should pay off in the long run. The input box supports most of the little things you don't really think about until they're missing: a cursor, clicking on the box to move the cursor, both backspace and delete keys. I don't have copy+paste or click-and-drag to highlight, but I don't think those are worth the trouble at the moment.

There's the file:

Loading the map should be negligible. I already use external files for maps.

Here is the text input box setup, using the GUI extension--

and the 'save' button that takes the input from the box and passes it as an argument

There is a block for the "get value of text input" feature, but I gave up making blocks for Vallas Engine a long time ago.

Latest happenings: I'm nearing the point where I can migrate over from Tiled to my own editor. It's coming along pretty well, even thought it feels like there's still a lot to do. Still, I think having an editor that fully integrates with the way Vallas handles maps is worth the effort. Plus, all the UI code can now be used across multiple projects.

Defining sectors using Tiled was handled in a very clunky way, using tiles. They are the colorful tiles seen in some of the screenshots from Tiled.

This approach made it hard to do anything fancy, like 3D sectors ("room over room"), define properties of the sectors themselves (things like the name of the sector, lighting properties, monster spawn rates, etc.). All I could do with Tiled was define what coordinates belong to what sector.

New editor lets me "paint" sectors in 3D and also define properties. So far I have name and display name set up, but I'll add some menu options for other features.

I also started adding shortcuts. I'd like the editor to be entirely keyboard controlled. The cursor is moved with arrow keys + pgup/pgdn, and 'enter' to draw. You can select multiple tiles by holding down shift, so it's possible to paint entire walls at once.

It's a bit late, but I also made a 'Hello, World!' room. Here the draw order appears to be working, but I'm still finding little bugs with it. Draw order is handled differently than in the real game. The in-game renderer uses walls, where as the editor uses tiles. This means I can't see lighting effects in real time. I have to "compile" the map in order to see those.

'import test2.xml' should load the test map, but it crashes the game. 'edmap new' will start the map editor with a new map, but it hangs before loading the UI.

The map viewer works, though. It's not as interesting to play around with unless you're interested in seeing how I did the 3D rendering. In that case, type 'vmap test' to load the test 1 map.

The next screen that pops up is the graph generated from the map tiles. It defaults to showing only the nodes that the player can occupy (floors and empty spaces, but not walls). You used to be able to look at other structures, but that feature wasn't maintained after I moved on. Still, this is the map the AI will use to hunt you down

Press '00' to set the view to Sector 0, then hit 'v'.

You can use left and right arrow key to change views. Use right to move forward through them. The 'diffuse', 'ambient', and 'dark' won't show anything anymore. I changed the way lit tiles are stored in memory. So just hit the right arrow key to scroll past them. Nothing to see here.

Next is walls. There used to be a view of the room that the wall highlights would overlay, but since 'ambient' doesn't work anymore, neither will the background. But you can hold down shift+left/right to view the different walls. It'll make more sense what you're seeing when you get to render.

Press z, then x

Next is 'shadow debug'. If you didn't press 'z' or 'x', then you won't see anything. 'z' adds lights and 'x' renders the shadows.

Next is 'render'. At least now the walls view should make more sense. Walls are groups of tiles merged together to form one structure. They're all rectangles (internally).

That's about it. You can press 'z' and 'x' again to make the lights brighter. After about five or six iterations the room will be fully lit. Hit left, then right again to refresh the render view. The map viewer isn't optimized and Flash is even worse, so don't expect a great framerate. Maybe sometime later I'll have a more interesting demo.

Stencyl 3.5 Update Special. So yesterday I went ahead and upgraded Temple of Idosra and its underlying Vallas Engine to Stencyl 3.5.

The upgrade process wasn't quite as bad as I thought it would be. Most of the compiler errors I ran into were easily fixed just by pruning outdated extensions that I no longer need, or whose features were rolled into the base Stencyl. The biggest hassle was updating hxPixels, the third party library I use to do fast per-pixel rendering. Fortunately, the developers behind hxPixels already had an updated version for the new OpenFL. I just had to go through all my calls to it and update a few things.

Once I got the upgrade process started, it only took a couple of hours to upgrade. Most of that time was spent on hxPixels.

So what have I noticed so far? Mainly, rendering is a lot faster. This was immediately noticeable when I loaded one of my test maps into the editor. My "large" test map is the standard 48 x 32 x 4 tile area that I was using for a while. It's about half filled with tiles, and the editor renders all of them--no removal of redundant images. The 1-2 second lag seems to have disappeared entirely.

Out of curiosity, I re-ran the "Per-Pixel Perplexion" test where I compared Image API vs hxPixels for per-pixel rendering. Here's the original thread: (link!). The basic premise is that I render a static image, one pixel at a time, N times per second. I can then measure the framerate when I render multiples of 122,880 pixels (the full screen).

The bottom two rows are the most significant to me. It suggests I can render 921,600 pixels in software and get close to 60 FPS. Keeping in mind that I wouldn't ever need to render that many pixels at once (a full-sized room still leaves blank spaces on the screen), it suggests I could get away without hardware shaders and get the visual look I want.

Stencyl 3.5 with the updated OpenFL also appears to be rendering twice as fast (45.6 FPS rendering 15 screens in Stencyl 3.5 vs 45 FPS rendering 7 1/2 screens in Stencyl 3.4). This is for desktop (Linux). I haven't tested mobile, HTML5, or Flash yet, but that would be interesting to see.

This opens up a lot of new possibilities for me. That said, I don't think I'm ever going to finish anything if I keep bouncing between projects and ideas. As tempting as it is to return to the full-color version (what is seen in the demos from last summer), I think I'm going to stick with the 8-color "retro" version for now. I can then use the additional time to research shaders and explore what new possibilities the latest OpenFL brings. So the future looks pretty bright from here

Actually, 'vmap' may still have a new life ahead for it. I realized I could use it as a kind of "AI editor", for fine-tuning what parts of the map each NPC can work with. The graph part would be perfect for that, since the map graph is right there to look at. The sector viewer will be rolled into the map editor so it is possible to view rooms and test different lighting configurations.

Hopefully you can create many games with it, or at least a huge game to have all that work come to light.

I'd still like to redo the original Temple of Idosra, but as I initially envisioned it instead of what I threw together in 10 days

I think I might need to look beyond Flash, though... even for the simpler games.

I forgot that all some of those demos I made a few months ago are accessible from the debug console. The commands don't show if you type 'help', but they are-- (press 'escape' to quit them)

stest -- the "Growing Squares" algorithm testbresenham -- Brensenham's Line Algorithm test.gtest -- should run the graphics test where I pulled the "Image API vs hxPixels" numbers, but it doesn't seem to work on Flash.

Sprites Layer Monday. First screenshot of March--I now have the sprites layer working. Now I can populate my maps! Right now I just have the handful that I made for the original game. So I'll need to get to work on making more.

Adding the sprites layer was no small feat, even if the map editor doesn't look much different than it used to. Internally, I had programmed the tile system to assume there was only one element for each (row,col,level) position. I had to gut a lot of code and redo it to allow for multiple elements to share the same (row,col,level) "cell". I guess that was poor planning on my part, but at least compiling in Stencyl 3.5 is easier. When compiler errors come up, the new errors dialog is much easier to work with.

Although I'm not finished with the map editor yet, I can at least start making some "real" rooms. Here's one that will form part of an underground water system.

One thing I didn't like about the original game was how all the rooms looked so alike. I had a "bright" tileset and a "dark" tileset--but that was it. I now have a larger variety of tiles. It's also a lot easier to make new ones now. At least, it's easier to make new visuals. Adding new structures (combinations of planes) is still a hassle. Abandoning tiles altogether would make adding new structure a whole lot easier--but then I'd have new problems with optimization. So I'm going to stick with tiles for now and see where the game goes from there.

You seem to have a way to do a lot next to your day-job. I'm jealous! Great progress as always and I understand that even when things don't appear to have taken a lot of time I know changing a little thing can potentially involve a lot of re-work.

" compiling in Stencyl 3.5 is easier. When compiler errors come up, the new errors dialog is much easier to work with. "

Totally agree! Apart from the underlying openfl upgrade this to me is a huge improvement of Stencyl.

To the casual observer, this might just look like an empty room with a single sprite. But it's actually a dark room with a single sprite in the actual game. I can now make maps, sprites, and get them to load in the game in a playable state. It wouldn't have been so anti-climatic if I had lights... but at least the light system is working

I walked around for a little bit and bumped into the walls. So I know the map has loaded correctly.

One thing that's been on the 'todo list' for a while is making the light system work with the 'retro version' look. It's mostly complete and nothing really fancy. Each tile face has 5 light states (0-4). For each pixel I round the light level hitting it to the nearest 25%, then draw the pixel from the appropriate source image. This is why I'm so interested in fast per-pixel rendering.

Speaking of which, I got the impression the hxPixels library was designed with HTML5 in mind. So the web version of the game may still be feasible. I was thinking about dropping it with all the issues I've had with Flash, but HTML5 may be the way to go. I have some time to think about that.

I suppose the next thing to do is work on the lighting options for the map editor. This is going to take some reworking of the core lighting system, though.

At the moment, all of the data needed to handle lighting is stored in actor behaviors. The original Idosra had a really weird loading system, now that I think about it. The .xml data files stored behavior attributes which were then copied into the appropriate actors when they were created. I'm not sure why I did it that way, but I'm sure it had something to do with the unusual workflow I had to adopt trying to make the game during the hurricane. Although the original game didn't have lights, I kept using this system for a while longer as I added new features.

Addendum. I recently played through A Dark Room, which is an interesting little game. It gave me the idea of starting the player off in total darkness. I liked the idea of mixing genres (in Idosra's case, starting with exploration and shifting to a more action-style RPG), but wasn't sure if it'd work. Seeing how A Dark Room and Candy Box 2 pulled it off, I have renewed interest in the idea.

I did think of a mechanism I could use to make a dark starting room work. It came to me while I was playing with the test scene I just showed. When Marika bumps into a wall, a faint red outline of the part of the wall she touched should appear. I wouldn't want to keep it up for very long--maybe just a room or two. If I had a lamp + fuel game element, this 'feeling your way in the dark' mechanic would also give me a way to let the player keep playing once their lamp runs out of fuel.

+---------+ The Temple of Ebon +--------+-----------+|RECALL PT| (north, east, south, west, up, down) |MV: 100%| 3pm 4/11 |+---------+ ........................................................... +--------+-----------+| | The Temple of Ebon was the first structure built in the great city. Designed as a| 1 | general meeting place, many marble benches circle around a large table with many| # | | green ferns planted in it, and a fountain in the center. Stairs lead down to the| - #*#1- | Market Square, and up to the tower. The room is lit by occasional flashes of green| # | | and blue light, which reflect off of the marble walls. There is a small carving in| 1 | the wall.| | +---------+ There is a large plaque here. DIRS: Training:2u 3w Commons:2u Market:d Crossroads:2d

The Ixtocyl Terror Alert Level poster is tacked to the wall.

A poster advertising the latest box-office hit, "Goku: True Hollywood Stories" (Subtitled Only) (Glowing) A Poster advertising the latest movie, "Crouching Elf, Hidden Rajani" The Realms of the Lost Dimension Notice Board with several images of links tattoo'd on its side.

Note that there's no real movement within a room. All movement takes place between rooms. Larger "rooms" could be made by joining up several smaller rooms, but this wasn't common. The original Temple of Idosra was designed like your typical MUD-style area. In fact, here's the map for Idosra.

Image is a link to a bigger version.

So how did this style of zone construction translate over to a tile-based game? The original Temple of Idosra is still up--so you can play it and see for yourself if you like. My own assessment is that it worked okay, but with several flaws. The biggest problem in my mind is the maze-like layout. I don't really like mazes. This isn't as noticeable in MUDs--where movement between rooms is quick and the occasional maze can be mapped out by the player's client.

The maze-like level design wasn't helped by the lack of variety in graphics. So next, what was I thinking?

The MUD output above is from a game I ran from 2002-2004. (You can probably tell the time period by looking at the various objects--movie posters, a parody of the 5-color terror alert level. I had a lot of players who were in the military, so there was plenty of lively discussion around the time the Iraq war started). The game had a novelty--rooms with spikes pits you could fall into, rooms with walls that would close in on you, fireball traps (like seen in the original game). If you're wondering how all of that would work in a text-based game, well, it actually kinda did. Area builders who took advantage of the features and were careful in how they used them made some neat things. Temple of Idosra had the same kind of traps and gimmicks I envisioned in the text-based versions.

But Idosra, at its core, is a MUD-style area adapted to a tile-based game engine. And therein lies the biggest flaw. The usual tools a player would have to find their way (text descriptions and, possibly, a mapper) are gone. The rooms all mush together.

Admittedly, level design isn't my strong area. But I do like to think I can learn and adapt. Lighting in the remake is a priority because I can use it as a means to guide the player. By controlling what rooms are illuminated, I can "steer" the player in the direction I want them to go. Take a look at the room at the top of the screen. Where would you go if you came from the dark exit at the bottom left? Probably the lit exit in the upper left. Of course, the careful player might take time to explore and find the other two exits that are hidden in the dark. What might they discover? Something good? Some kind of trap? Anything's possible!

In addition, I also have more tiles and, most important, more time. I can give each section of the temple its own look, which should greatly aid the player in their navigation. I'm also thinking about an auto-map. It shouldn't be that hard to build one off of the graph structure the map uses.

Next time: Adding the lighting system to the map editor so I don't have to manually add lights.

"By controlling what rooms are illuminated, I can "steer" the player in the direction I want them to go. "

Usually I would say that if you don't want the user to go any other direction that you disable to go to that direction.Either the door is looked or there isn't a door in the first place. Why put the door there if you don't want them to go into it?