Merrak's Isometric Adventures -- Dimetric Dilemna

Thought you might be interested to know Terry Cavanagh made a really great puzzle game based around that: trying to figure out confusing ambiguous isometric geometry. http://terrycavanaghgames.com/nayasquest/

And whoa that's super interesting about Zelda.

That's really cool! I thought about using perspective tricks like that to hide secret areas.

Of course, lighting would give away the true geometry of the room. Then again, that could be an interesting game mechanic--using light and shadows to redefine the structure of a room.

Thought you might be interested to know Terry Cavanagh made a really great puzzle game based around that: trying to figure out confusing ambiguous isometric geometry. http://terrycavanaghgames.com/nayasquest/

And whoa that's super interesting about Zelda.

That's really cool! I thought about using perspective tricks like that to hide secret areas.

Of course, lighting would give away the true geometry of the room. Then again, that could be an interesting game mechanic--using light and shadows to redefine the structure of a room.

Do you think you'll use that to make a game?

Do you think you'll use that to make a game?

I thought about it but I couldn't think of a way to execute the idea in a way that would be the sort of game I'd want to play for very long. My goal was to write the rendering engine generic enough to apply to different things, but I think I need to resist the temptation to stray from my current projects. I have two going at once and they've been under development for a while--so I need to wrap them up and move on.

Do you think you'll use that to make a game?

I thought about it but I couldn't think of a way to execute the idea in a way that would be the sort of game I'd want to play for very long. My goal was to write the rendering engine generic enough to apply to different things, but I think I need to resist the temptation to stray from my current projects. I have two going at once and they've been under development for a while--so I need to wrap them up and move on.

What else are you working on?

The Legend of Fordham Forest. It's been on and off hold for a while, but is still progressing. Stencyl 3.5 should breathe some additional life into the project.

Nice!

Idosra Indecisions. Physics is coming along rather nicely, but the vast scope of the undertaking is quickly becoming apparent. "Physics" in Idosra means any code relevant to moving actors (including rendering) since it's all tied together.

I'm working on an idea where I implement a 3D version of the "growing squares" algorithm used to partition a structrual wall (called a "WallGroup" in the engine) into rectangular partitions ("Walls" in-engine). The 3D variant, "growing cubes", would be used to partition a space into rectangular solid volumes. These 3D regions would be used to determine the correct rendering order. Rather than run a topological sort every time an actor changes position, I would sort walls and rectangular solids together, then render all actors in a 3D partition. (In the event an actor occupies multiple partitions then something special will happen. I'm still thinking about the details).

Another option would be to redo the topological sort every time an actor changed partitions. One thing I need to do before going much further is stress-test the topological sort. I don't want to waste a lot of time solving a problem that doesn't need to be solved.

Story Time! The game itself is also starting to take shape. I spent some time thinking about the series story line and drafted a few thoughts. In typical MUD-fashion, most of the world will be presented in the descriptions of rooms and objects. At least in this first game, there is a pretty small cast of characters. One mistake I'm working on revising with Legend of Fordham Forest (mentioned above) is not running such a long prologue. Rather, I want to drop the player right into the action as soon as possible, then develop the story as they move along.

As a consequence, the beginning of the game is vague. The player is dropped into the world with little backstory. But that doesn't mean I can't work in a lot of little clues that something is amiss. One of my favorites so far is this card casually placed into the player's inventory (like the "Impending Doom" card from earlier screenshots)

I took a bit of inspiration from the "no tea" inventory item in the "The Hitchhiker's Guide to the Galaxy" game. I haven't drawn it yet, but the player will also start with a "mortality" card, for a total of four (Marika, Humanity, Mortality, Fists). The implication is that the "humanity" and "mortality" cards can be lost. At this point I'm not sure if that will actually be possible,  just an elaborate red herring, or setup for a future game in the series.

I'll probably take "impending doom" out. I liked that card from the earlier development version, but I'm leaning against a time limit.

Interesting idea. Just found the GameJolt page for Temple of Idosra. Looks great!

Thanks

I think the GameJolt version is 1.0.3? I don't remember, but it's the better version. I didn't put a sitelock on the weaker version with buggy doors (1.0.2), and a whole bunch of non-English Flash portals picked it up and rewrote the description. I can't find my favorite anymore, but it went: "Marika is not only a beautiful girl, she knows how to deal with the keeper", and she is now on a mission to explore deep corridors and help disabled animals.

I just realized that game is a year old. Last year was the hurricane and I had to do all my programming on pen-and-paper because there was no power.

Thanks

I think the GameJolt version is 1.0.3? I don't remember, but it's the better version. I didn't put a sitelock on the weaker version with buggy doors (1.0.2), and a whole bunch of non-English Flash portals picked it up and rewrote the description. I can't find my favorite anymore, but it went: "Marika is not only a beautiful girl, she knows how to deal with the keeper", and she is now on a mission to explore deep corridors and help disabled animals.

I just realized that game is a year old. Last year was the hurricane and I had to do all my programming on pen-and-paper because there was no power.

Someone ripped off your game and thought that was an accurate description?

Someone ripped off your game and thought that was an accurate description?

Apparently so I had no plans to try to monetize that version, so I didn't really mind. Although if I knew someone was going to do that, I would've put more links to my own stuff in the title and credits pages. The official version is the first hit on Google, so I don't think I'll have to compete against all those old versions when I complete the re-release. I also have no plans to look for a sponsorship.

Lesson learned, though: Sitelock if you don't want your game popping up everywhere, or embed some of your own promotional material if you do.

Little Things. One of my pet peeves with keyboard games is when I have to use the mouse to navigate menu items. If it's a keyboard game, I should be able to use the keyboard for everything. But I should also be able to use the mouse if I want to.

Despite that, I never really bothered to set up keyboard menu item scrolling for my own games. It's a bit of a pain to do since you have to track which button is highlighted.

So I finally set up a nice behavior to manage this. I'm pretty pleased with how it came out. I attached the behavior to this post if you want to import it for use in your own projects. The code is commented throughout so it should be easy to figure out how it works and modify it to suit your needs.

Basic Instructions. Attach the behavior to an actor functioning as a button. When the button is executed then it will trigger the specified custom event in all scene behaviors. The contents of the custom event will contain the code that makes the button do its thing.

Keyboard scrolling is managed by the "Scroll Position" setting. If left at -1 then the button will ignore keyboard scrolling. If the scroll position is set to 0 then the button is the "Master". The master is configured to keep track of which button is highlighted and will trigger when the action key (Enter) is pressed. Otherwise if "Scroll Position" is set greater than 0 then it is "Slave". Its highlighted state is managed by the master.

To work properly you'll need to place the button in the scene and use customize to set its scroll position. There must be a master. You must also not repeat any scroll positions and not skip any.

Figure 1. This button is configured to trigger the custom event "Instructions" in all scene behaviors

Edit. Updated version of behavior, see two posts down.

That's a really cool behavior. Is it possible to tween the text when you (for example) highlight the text with the keyboard or cursor? Could this behavior be used for like a character select screen or shop or something? Just wondering cause I've been trying to find the best way to go about a seamless shop/character select screen and this looks like it has a lot of flexibility. Cool title screen btw...can't wait to hear about any sound integration you have planned.

Thanks!

Is it possible to tween the text when you (for example) highlight the text with the keyboard or cursor? Could this behavior be used for like a character select screen or shop or something?

The buttons in the title screen don't use text. The highlight/normal label are just the actor's animations. I think it could be used for a character select screen. The way it is set up you would have to create a scene event and then a separate custom event that selects each individual character. You could also modify the behavior to have extra variables (say, for which character was selected).

I made a slightly updated version that would make it easier to do tweens or other effects. You can now specify a custom event that will be triggered whenever the animation state changes. The specified event is triggered in all behaviors for that actor. The idea is that you make a second behavior that contains those events and reacts accordingly--then you don't have to change the code for the button behavior.

I also changed how the animations are updated. Now the button calls an event "SetToUp, SetToDown, SetToOver" rather than using an animation block. Now there aren't duplicate animation block changes. So it should be easier to modify the behavior code to make it do other things when the button is clicked, highlighted, etc.

Cool title screen btw...can't wait to hear about any sound integration you have planned.

I need to find some good sound resources... but then again, I'm still on physics and actor rendering code right now. I have a bit of a way to go.

Low-Level Victories. The downside to working on low-level code is there is little fanfare to accompany successes. If I were working on enemies or levels or something visible, I could post some screenshots showing off new effects. Instead, all I really have to show for a couple weeks' work is this screenshot that, while unimpressive, demonstrates a significant milestone in getting actor rendering and physics completed.

There's Marika in the temple, which up until now has been completely empty. While there's still a lot of work left to do, the new physics system will support some handy features.

Stencyl actors are now a sort of facade for an actor data class (VActor) that reside in a map. Basically, my actors can persist between scene changes and the physics system can continue to model them. This means I can run enemy AI scripts, like hunting the player down, on enemies that aren't in the scene.

This would be especially useful if, in the future, I wanted to make a large-world RTS game. In fact, Vallas Engine ought to be capable of reproducing the rendering found in SC4, Age of Empires, or any of those isometric games that had multiple-sized units. I don't have near the time or resources available to make something of that magnitude, though, but something like a small-scale city-builder might be a fun next project to look into.