Stencyl 3.4.0 is now out. Get it now!

Merrak's Isometric Adventures -- Physics!

merrak

  • *
  • Posts: 1605
I finally replaced the room system used in the original Temple of Idosra. In the original game, each room was a fixed 12x12x4 tiles size, which was the easiest to implement in a 10-day span. The new system lets me "paint" sectors.

Here is an example which duplicates the original game, with one exception.


The room one to the right of the lower-left corner has been split into two sectors, allowing the camera to move behind the wall. I made a little video showing some of the gameplay, including the split room (it has a staircase in it)

<a href="https://www.youtube.com/v/YxxSNgngjgw" target="_blank" class="new_win">https://www.youtube.com/v/YxxSNgngjgw</a>
https://www.youtube.com/watch?v=YxxSNgngjgw

The sector map will let me design more intricate levels--the kind I really envisioned, like the one in this older post

I also made some updates to the UI. I'm not sure if I want to have no indication whatsoever of enemy HP and damage numbers, use just numbers, or keep the MUD-like text output that overlays the view.

Bombini

  • Posts: 832

merrak

  • *
  • Posts: 1605
Levels are coming along nicely :)

Tiled is a useful tool, but I'm still thinking that I'll need to make my own in-game editor in order to set up switches, doors, chests, and other interactive elements in the levels.

Attached are a couple of levels as they look in the editor and in-game. I'm also working on making some new tiles so that the rooms have more variety. I'm taking some inspiration from Frank Lloyd Wright's --A Fireproof House for $5,000--

merrak

  • *
  • Posts: 1605
A couple of new additions--

The core functionality of the inventory system is complete, and I'm slowly adding object actions. One of the first items I made is an oil lamp you can use to look around in dark areas. Of course, you'll have to find oil. Here's a short video showing it all in action.

<a href="https://www.youtube.com/v/edXXuo9v4lg" target="_blank" class="new_win">https://www.youtube.com/v/edXXuo9v4lg</a>
https://www.youtube.com/watch?v=edXXuo9v4lg

One thing I'd like to do is give the player the option to use objects in ways they weren't intended, such as throwing the (lit) oil lamp at a monster. The fireball would deliver a lot of damage--but destroy the lamp.

So this brings up the possibility of the player rendering the game unbeatable. I had the idea of determining the latest save point at which the game was still winnable, and resetting the player to that point (instead of the last save point) when they die.

One way to do that would be to make a graph of all the elements that are required to beat the game, and which ones depend on others. (e.g. you need the red key to open the door that hides the blue key). I can then run A* to determine if a "path" to the game's goal still exists.

For "Temple of Idosra", I can create this graph by hand. For a game using random dungeon generation, algorithms that use graphs (such as lock and keys) provide the necessities to figure out how far back the player will need to be sent.

merrak

  • *
  • Posts: 1605
So far I'm finding the level design phase to be more challenging than I originally anticipated. The added flexibility to design levels in almost any way I want has been met with the challenge of doing so.

The constraints of the original Temple of Idosra forced me to make every room the same size and with exits to neighboring rooms in the same places (on the borders of the 12x12 grid).  On top of that, I had time constraints. When the hurricane struck and I had no power, I passed the time drawing rooms on paper. When power was restored I had too little time left in the game jam to make revisions to my plans.

KramerGames left some good advice over here about rough drafts of manuscripts and how to relate them to games. It's a nice reminder that you don't have to get everything right the first time, since it's not likely to happen anyway. I used to spend quite a bit of time over on the literature forums on DeviantART, and the usual advice given on writing was to just get something down first. You can't edit a manuscript that doesn't exist. So I decided just to start sketching areas and see where my imagination takes me.

Here's one I put together in a couple of days.



I'm pretty happy with how it looks in the actual game. The game has an adventure feeling with a number of puzzles--but depending on your play style, you can actually ignore many of them. It's heavily influenced by the types of areas in a MUD I used to operate.



An early puzzle that is somewhat optional is to figure out how to get the lamps to turn on. It's not difficult to solve--mainly just hunting down the pieces needed to restore a crude generator. It's a reward for exploring and the lights reveal passages that are totally hidden in the darkness--although you can find them early by stumbling around in the dark.



I took my eyes off the screen for one moment to push the "capture screenshot" button and died. Whoops. I took some steps to steer the player in the right direction at the beginning, and to get to this area I ignored them--so it's pretty tough. While I'm not using "experience points" as is the tradition in RPGs, you can find more powerful weapons and books that teach the player character new skills. Obviously she has some reading to do before reaching this room.

Irock

  • *
  • Posts: 2838
Ahh, this is looking really sweet!

merrak

  • *
  • Posts: 1605
Ahh, this is looking really sweet!

Thanks!  :D

Lately I've been putting together the stats and "leveling" system for the game. Despite the many MUD influences, I'm diverting from many of the usual RPG tropes. Notably, there are no experience points and no magic system. Instead, I've settled on an alternate history world with technology roughly equivalent to that of early 20th century, late 19th century, with some technology exaggerated or removed.

I have three character stats: Strength, Dexterity, and Intelligence. Intelligence mainly affects what a skills you can learn, what books you can read, and how many clues Marika gives you (through speech bubbles) about what she is observing. I might not stick with the speech bubbles. Those came from one of my LD games (Evolution Dungeon).


In effect, intelligence replaces "experience points", as Marika can learn from her experiences.

Speaking of which, I've added a couple more stages to gain experience in. Below are some scenes from an outdoor area. Some graphics from the original Temple of Idosra game are still placeholders. The area is tougher than I originally intended. On narrow bridges, a single strike can knock you into the water--which is instant death. There are multiple routes to get to this area, though. One route which I haven't finished yet will let you pick up a bow and arrow--allowing you to kill the floating black/orange things that are the most likely to knock you off.



One last thing I settled on is replacing Box2D with simple physics. I only need Box2D to use the raycast feature--so if I can write my own raycast routine, I can get rid of Box2D. The main issue isn't lag in-game, but loading time. When you switch scenes, the loading time can take up to a minute. This issue seems to correct itself the longer the game has been running. The culprit is garbage collection... namely, on the order of a million (!!) instances of vector class being created and destroyed.

gurigraphics

  • Posts: 688
Quote
The main issue isn't lag in-game, but loading time. When you switch scenes, the loading time can take up to a minute. This issue seems to correct itself the longer the game has been running. The culprit is garbage collection... namely, on the order of a million (!!) instances of vector class being created and destroyed.

If you did this with Stencyl imagine with a more suitable Engine for this game.

I would do only the Demo and the Prototype with Stencyl to think about how the game is going to be. And the official version with Godot Engine to isometric games. Because sooner or later you will want even more performance. And you're already over the edge.


merrak

  • *
  • Posts: 1605
If you did this with Stencyl imagine with a more suitable Engine for this game.

I would do only the Demo and the Prototype with Stencyl to think about how the game is going to be. And the official version with Godot Engine to isometric games. Because sooner or later you will want even more performance. And you're already over the edge.

But I really don't think I've pushed the edge of what Stencyl can do at all. Most of the issues I've ran into were my own doing--particularly in the routines that construct the levels and that draw the scenes. There are also potentials I haven't even touched yet, such as shader support.

Godot Engine looks pretty cool, though. I was thinking this summer it wouldn't hurt to learn some new systems and broaden a bit. I wanted to pick up Pico 8 and play around with that for a while. Maybe Godot Engine would be worth experimenting with, too.

But as for this game, switching engines would be a significant undertaking. If I felt like I hit a brick wall, it may be worth it--but at the moment I haven't ran into any problems I'm not confident I can eventually solve with enough research and patience.

gurigraphics

  • Posts: 688
Quote
Godot Engine looks pretty cool, though. I was thinking this summer it wouldn't hurt to learn some new systems and broaden a bit. I wanted to pick up Pico 8 and play around with that for a while. Maybe Godot Engine would be worth experimenting with, too.

I think Godot and Defold the best options nowadays. The advantages are lighting, particles, zoom, skeleton bones, kinematics, etc. However, Defold is a bit too standardized. Now, aesthetics features is not as important as performance for me.

Quote
But as for this game, switching engines would be a significant undertaking. If I felt like I hit a brick wall, it may be worth it--but at the moment I haven't ran into any problems I'm not confident I can eventually solve with enough research and patience.

Even if it takes 6 months, It would be better than learning another engine. Because the rest in Stencyl the developement is faster.

Would it be possible to use sections of Flambe Engine or HaxeFlixel to solve this?

How in code you verify what affects performance?

My post 666  :o

« Last Edit: March 29, 2017, 08:25:12 pm by gurigraphics »

merrak

  • *
  • Posts: 1605
If I can work out how to pass a normal map into a shader, I could get the lighting to be on par with what many of the 3D engines can do. I don't know what Godot provides "out of the box" as far as normal maps and lighting--but I looked through their gallery and only saw one example... so I don't think it's easy (although it may be easier than in Stencyl--I haven't worked on it yet)

One thing I think I should point out is that unlike most isometric game examples I've seen, mine has a 3D world. The camera is still in a fixed position with isometric perspective, but the world has 3D coordinates and supports multiple levels. This significantly impacts light and shadow calculations, since those can't be done on a 2D plane. The 3D world also necessitates at least basic 3D physics. That means I had to implement 3D collision solids--which are all cylinders of uniform height.

Porting the game to any 2D engine would require solving all these problems again.

Quote
How in code you verify what affects performance?

HxScout is my primary tool. I analyzed the frames during which scenes were loading and it reported the number of different types of objects (Array, b2Vec, etc) that were being created and collected. The number of Array objects that are created and destroyed in the few seconds that the scene is loading reaches into the 100,000's. I traced many of these to raycast calls--mainly in the routine that computes which tiles are hit by which light sources.

I think I worked out an alternative to Box2D raycast that uses simple vector algebra, which would spare the garbage collection at the expense of only having square collision boxes. But since raycasting is the only reason I'm holding onto Box2D, that expense isn't a concern.

Quote
My post 666  :o

 >:(

Justin

  • *
  • Posts: 3815
Quote
My post 666  :o

 >:(

It's silly, but this made me laugh out loud.

The isometric engine is looking swell. Keep up the nice work!

For Live Support: Join our discord channel and ping me @justin.

gurigraphics

  • Posts: 688
Quote
I think I worked out an alternative to Box2D raycast that uses simple vector algebra, which would spare the garbage collection at the expense of only having square collision boxes. But since raycasting is the only reason I'm holding onto Box2D, that expense isn't a concern.

So Box2D is the only factor of performance problem that does not depend on our code?

Then, maybe Nape can be other solution for those who do not develop to mobile:
http://community.stencyl.com/index.php?topic=31314.0

Quote
My post 666  :o

 >:(

It's silly, but this made me laugh out loud.
:D

iii

  • *
  • Posts: 182
+1 for Nape.

I've seen some says its also faster on Mobile too, other than Desktop.
Flash is pretty much the same using either one.

Not a fan of box2D.
Most of the time I'm using Simple Physics, or just rolling my own custom solution.

ceosol

  • *
  • Posts: 2132
Quote
If I felt like I hit a brick wall, it may be worth it--but at the moment I haven't ran into any problems I'm not confident I can eventually solve with enough research and patience.

I totally feel the same way. I have not felt limited by Stencyl. I also have not hit a brick wall - except for making my extensions since I do not understand that :P

Merrak, you have the mathematics backgrounds to really plow through these calculations. I can understand why others would find the task too daunting and decide to go for an engine that already does the calculations automatically in the background. I actually find it enjoyable and rewarding doing the calculations on my own.