Stencyl 3.4.0 is now out. Get it now!

Merrak's Isometric Adventures -- Physics!

squeeb

  • Posts: 1130
Perhaps "Fight the invisible. Fight the inevitable"?
Cool!
If you can't see it, does it exist
You can't fear, what you can't see
Can you fight what you can't see
The shadows are dark, the evil is darker.
The shadows have eyes :p
Just bored brain storming haha

merrak

  • *
  • Posts: 1605
Actually I think they all could work to one extent or another :D

One of the key aspects of enemy AI (if I ever get to that stage in development) is that the enemies will hunt the player through the shadows. It's one reason I've put so much effort into that detail. I'm trying to think of a tagline that captures that mechanic. I'm pretty happy with the visuals on the "poster" at least. I think it gets that point across. (Admittedly, I don't have any background in design, so any advice on the matter would be much appreciated).

I have a neat idea to implement that behavior, too. My levels are represented as a graph. The AI extension allows you to set a specified cost to each edge in the graph. By setting the costs of paths through lit areas higher, A* will be more likely to return a path through dark tiles. If there are multiple enemies, I can also raise the cost of the path one enemy took, thereby encouraging a second enemy to take a second path. One enemy can lurk in the dark while a second charges the player from the front.... should be fun :D

My goal is to get an action RPG with a stronger emphasis on strategy... particularly in manipulating illuminating objects.

Edit. Despite appearances, this is actually a successful test of the in-game renderer (DrawStack)


DrawStack is attempting to render every sector in the map, which is not the intention. I haven't finished the sector system though, so it's trying to. Since there's no code to sort walls in different sectors, the walls overlap. The other problem isn't code related. I haven't yet updated the tile geometries and definitions for the entire Idosra tileset. I only redefined the tile geometries for the tiles I used in the test scenes.

The big thing that is working is that every tile is drawn in the correct (x,y) location on screen. They're also sorted correctly within their own sectors. One of the key differences between this iteration of DrawStack and the previous is that I'm using sorted BitmapWrappers ("image instances" as the Image API refers to them as), rather than the draw routine. This approach saves CPU cycles. I'm rendering the entire map with far fewer CPU cycles than rendering a single room in the old code. (2.5% CPU usage versus 8+%... so roughly 1/3). Rendering just a single sector will be negligible.

It's worth pointing out that I only expected managing a sorted list of images to be faster because I only have dozens of images to sort. When each side of a tile was its own image, sorting the resulting list of thousands of images would take far too long. This is where all the code that groups tiles into larger walls pays off.

Once I upgrade, I can also take advantage of features Stencyl 3.5 and updated OpenFL will offer. In case anyone's curious, I've been using build 9180 all this time.

So that image is pretty much what I expected given what code I have left to write. One step at a time :)

« Last Edit: August 23, 2017, 11:03:45 pm by merrak »

Tuo

  • *
  • Posts: 2469
I'm pretty happy with the visuals on the "poster" at least. I think it gets that point across. (Admittedly, I don't have any background in design, so any advice on the matter would be much appreciated).
I'll try to help by giving my honest feedback on it then. First off, the slash of black/white, while a bit cliché, did indeed catch my attention, especially with the enemies being cut off. Beyond that though, it really didn't do much for me. My second thought when I first saw it was "is this a guy or a girl?", which IMO isn't a good question to come up as a second thought. I also wondered why the disappearing aspect only was being utilized one way (i.e. why isn't s/he swinging the sword and having it partially cutoff in the black side?).

Basically, I think the poster falls into the category of "grabs my first attention and then loses it in the details"
Don't look to me but rather to the One who is the reason for what I do. :)

If you need help, send me a PM. Even if I haven't been on in the forums in ages, I still receive those messages via email notifications. You can also reply to any of my forum posts, regardless of the age (especially if I created it), and I will likely reply.

If you want to see the programming behind certain types of games, feel free to check out my "Demo-" games on StencylForge (http://community.stencyl.com/index.php/topic,16160.0.html)

merrak

  • *
  • Posts: 1605
I'll try to help by giving my honest feedback on it then. First off, the slash of black/white, while a bit cliché, did indeed catch my attention, especially with the enemies being cut off. Beyond that though, it really didn't do much for me. My second thought when I first saw it was "is this a guy or a girl?", which IMO isn't a good question to come up as a second thought. I also wondered why the disappearing aspect only was being utilized one way (i.e. why isn't s/he swinging the sword and having it partially cutoff in the black side?).

Basically, I think the poster falls into the category of "grabs my first attention and then loses it in the details"

Thanks for your honest feedback! I actually never thought of having the disappearing aspect go both ways. TBH, the entire "poster" was the result of some random doodling to occupy my time while the code compiled. I thought the outcome was pretty neat, though--but most of the decisions were just random. I like the suggestion, though, so I'll play around with it a bit more.

The silhouette is just a filled in version of the sketch from May 19 "Sketch Saturday". I think the silhouette gave her straighter angles in the line art. Maybe if I soften them a bit it'll give her a more feminine appearance. The lines aren't as harsh in the colored version.

This is the colored version of the silhouette--


Marika has changed appearance several times throughout the project. Ultimately I want to learn to use Blender and take an approach similar to what Dincicode used in his game from October's jam (The Undead City--I can't seem to find the thread). I think her current bright green costume makes her look a bit too much like Link, so I desaturated it some and altered its shape for future versions of the game. I'll keep the current one for the web version, though.

These are older versions from 2015 ("Thief of Vallas" sprite) and 2016 (current Idosra sprite)

     


fillergames

  • Posts: 732
If you need help with Blender, I could help you with the basics (making a mesh, UV seaming, modifiers). I have experimented with pre-rendered games myself, but I found that it could take awhile to set every frame up right when setting up the animation.

I'm not good at texturing or rendering, though.

merrak

  • *
  • Posts: 1605
If you need help with Blender, I could help you with the basics (making a mesh, UV seaming, modifiers). I have experimented with pre-rendered games myself, but I found that it could take awhile to set every frame up right when setting up the animation.

I'm not good at texturing or rendering, though.

I appreciate that, but right now I'm nowhere near that stage of development :o I used MakeHuman to model Marika's sprites, and I'm planning to model the others when the time comes. I have bvh files from CMU's motion data set. I really just need to sit down and give myself a day to play with Blender. Every now and then I'll look around it, but I always throw in the towel because I have bigger priorities. After all, what good are the sprites if there's no game code? :D

Another option would be to hire someone to do the sprite work (or even all the graphics). Of course, I'd want to be sure the game would sell if I took that route...

merrak

  • *
  • Posts: 1605
The revised DrawStack renderer is starting to take shape :D Here is the latest progress:



As you can see, there is still a lot to do. The "P" marks where the player is. I don't have moving actor rendering code yet. As for the walls, there are a lot of rendering errors. All the errors are due to the same problem I wrote about before--the tile geometry definitions need to be redone. This includes the windows and, most noticeably, the E/W staircases. (I did correct the N/S staircases for the test scene). The misconfigured geometry also causes a lot of shadow casting errors. All of this will have to be sorted out before I can work on the physics model. If I can't see the map properly, I can't even tell if the physics code is working.

On the positive side, a lot of other things are now working correctly. I spent a while chasing down bugs that caused the sectors to misalign. Now that it is fixed, rooms now connect properly. The camera is working correctly. Only one sector shows at a time now. The walls are ordered correctly (according to their defined geometries.. so as best as possible). The camera almost pans smoothly when transitioning between rooms. There's an occasional hiccup--but I think I know what's causing it.

Most importantly, I can travel through the entire map and maintain 60 FPS. So as long as light levels aren't changing, all the old problems I had with playability have been resolved. If every room is rendering every frame then I get from 8 FPS (big rooms with lots of lights) to 60 FPS (small rooms with only one light). I tested this by accident--due to a bug, the boolean function that checks if a wall needs to be redrawn was always returning true :P So it's good to know that even without planned optimizations to the wall redraw check routine, I get acceptable FPS in the thin corridors.

Roguelike Game?
One last thing I've been thinking about recently is what my plans are for the next few months. The more I work on the rendering code, the more I realize I should be developing in Stencyl 3.5 Beta--not 3.4 (9180). I had plans drawn up for a "roguelike" game using the 6-color tileset I used for the original game. A few motivating factors steering me in that direction--I'd like to release a game by the end of the year for one. I have a perfectly good tileset. Most importantly, it'd be fun to think about something else for a while. It's easy to get burnt out on these long projects. The "side project", though, would still contribute needed improvements to the engine... so it'd be a great way to get a change of development scenery but still stay on track to completing the larger project.

I wouldn't need moving lights, but I would need to finish the static lighting system. So I'm not quite there yet. There are also some procedural generation problems to solve, including a variation of the "bin packing problem". Generating 3D rooms that look nice seems like a messy task. So I outlined a plan to construct larger levels by gluing together "template rooms"--but I would need an algorithm to connect the rooms.

One thing I got positive attention from was the "retro" look of the original Temple of Idosra. I think I'd take that a notch further and come up with a "fantasy console" that the game runs on. I wouldn't go as far as, say, Pico8. Rather, I'd draw up a set of rules that the visuals and audio must adhere to, but the underlying code is still modern Haxe. The main goal here is just to get some consistency with the look of the game.

merrak

  • *
  • Posts: 1605
Slowly but surely... "DrawStack" renderer is coming together. It turned out most of the rendering errors weren't due to bad tile geometries, but a bug in the code that sorts walls in the right order. With that fixed, things are looking better.


One thing I should point out is that the "DrawStack" renderer code is taking on more tasks than the "edmap" test renderer most of my earlier screenshots came from. The test scene was a single sector, where as I'm now working with an entire map. It also comes with a new z-order sorter for the walls, designed to handle walls being their own images... hence these new complications.

But now that the walls are in order,  I realized I'm not too far from done with the entire renderer rewrite... "done" in this case meaning I have usable code (even if I don't have all my other features, like moving shadows, yet implemented). Some of these features may benefit from the new Stencyl. In the meantime, I really need to start nailing down real plans. I thought a bit more about the ideas I outlined a couple of days ago and then realized calling any future game "Temple of Idosra" may be a bad idea.

"Temple of Idosra" gets a lot of Google hits because I didn't put a sitelock on the original game. I think my best course of action would be to redo the original game (an idea I've been toying around with for a while) and address some of the problems people have mentioned. The redo could keep the original name. I also thought of a sequel (the "roguelike") I would want to make... and give it a new name.


"Temple of Idosra" and "Deeper into Idosra" would be two episodes of a two-part series, or maybe a trilogy, depending on how the background story develops. (I'm borrowing from the old 2/3-episode shareware game format).

First and foremost, it'd be a fun project to work on (otherwise why make it? :P) But I also thought that I should order any releases from simplest to complex, so that there's a sense of progression as the series develops.

Justin

  • *
  • Posts: 3815
That's a fun idea, and I'm starting to like how it sort of gives the vibe of an 80s or 90s game series.

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

merrak

  • *
  • Posts: 1605
The OpenFL 6 update is great news  :D What got me excited about 6 was improved (and simplified) shader support--so I'll have that to look forward to when I get further into development.

That's a fun idea, and I'm starting to like how it sort of gives the vibe of an 80s or 90s game series.

I'm liking it more and more. My thought was to mimic the shareware model that was so prevalent in the 80s/90s... particularly among Apogee and Epic. I'm wondering if that idea would work for a Flash/HTML5 "Demo" promoting a full desktop game. I've heard from time to time that demos as web games can be received poorly, but if I make three episodes where one episode could stand on its own as a full game, then it might be better received.

I looked back through some older posts and realized I've been non-committal on ideas--which I don't think is a problem (yet) because I'm still meeting my goals. But I do need to start making some commitments. Starting with an idea that would be simpler to execute, uses the code I have that is nearly done, and uses graphics that I already have would be easier than immediately jumping into a full desktop game. I could spend the next few months finishing a simpler game using the base I already have, or the next few months writing more code toward a full desktop game. I'm starting to worry about burnout, but finishing something would be fulfilling and give me a boost to tackle more challenges.

merrak

  • *
  • Posts: 1605
Wall Woes. Back when I was rendering all those test scenes, one thought I always had in the back of my mind was have I tested enough combinations of walls to be confident there won't be any surprises? Well... nope.

This is Room 9 of Entry Hall, one of the more complex rooms in terms of number and order of visible walls. And it doesn't render right.


Nevermind the jagged edges at the bottom. Those are a non-issue. The problems are the window sills overlapping the pillars, and wall 4 overlaps wall 3. The proper rendering order for the labelled walls should be 4-3-2-1.

This is an old, old problem. In fact, I wrote about it over two years ago in Solving the Visibility Problem. Ordering tiles from far to near is easy if every tile is the same size. The same can be said for my "wallplanes".

Each wallplane is a face of a tile, so ordering the tiles results in ordering the wallplanes. But I don't do that. I group wallplanes into larger walls. Walls can be different sizes, and, such as is the case with stairs, don't even have to be parallel to any coordinate plane.

The end result is that none of the usual sorting methods I've tried result in a proper sorting of the walls.

It's easy to sort something like a list of numbers from smallest to largest. Sorting the walls by distance from the viewer is difficult because there isn't an easy way to quantify distance. The distance from the viewer of a point (gx, gy, gz) is the sum of the coordinates (gx + gy + gz), where higher values represent points closer to the viewer. Each vertex of a wall would have a different distance value. If all walls are the same size, then we can sort by distance value of a chosen vertex (such as the farthest one back). But if walls are different sizes, no such standard can be defined.

Solution 1. I did some research and figured out I was thinking about the problem completely wrong. The problem isn't sorting walls from farthest to nearest, but rather resolving dependencies. I can create a directed graph, where walls are represented by nodes and edges connect overlapping walls. For example, the edge (2) -> (1) means wall 2 should be drawn before wall 1. I then apply a topological sorting (such as Kahn's algorithm) to resolve the dependencies. The result is a sorted list (not necessarily unique) that gives the draw order.

Solution 2. A "wall" is just a data structure. It contains some coordinate data and a bunch of pointers to "wallfaces". The wallfaces are what hold the image data and other data the player will interact with. I implemented two options: Have one wallface per wall, or several wallfaces per wall--one for each wallplane. There's nothing that says all the wallfaces have to be grouped to make one large image. I can implement one wallface per wallplane, and then I can render one image for each wallface. Since a wallface would be the size of a tile, I can use the easier, distance-based sorting to order the individual wallfaces. This is a potentially long list, though.

The best solution comes down to how I want to implement moving actors. After all this I'm leaning toward Solution 2, even though that negates one of the big advantages of having one image per wall--a smaller number of images to sort in-game. I think I can work around that though, and for a tile-based game, solution 2 could work. If I were to abandon tiles altogether (using sometime like Doom-style map construction), solution 1 would be ideal. One thing I haven't looked into is the efficiency of a topological sorting. I'm trying to avoid having to sort walls in-game--but if I have to, the quickest sorting solution would likely be the one I go with.

merrak

  • *
  • Posts: 1605
Wall Woes Update. I ended up implementing the topological sorting method ("Solution 1" from the last post). I actually got "Solution 2" for free by simply changing the calling order of a couple of functions. Now I have both solutions implemented and can switch between them when appropriate.

Here's what the room is supposed to look like:


I went with the topological sorting after some thought. What is the problem I'm trying to solve? For a long time I was thinking in terms of drawing the walls in order. But that's not the problem. The order I draw the walls in doesn't matter so long as the overlaps are drawn correctly. Drawing the walls in order guarantees the overlaps are drawn correctly, but that isn't the only way. Sorting only the walls that are necessary is less costly than sorting all of them.

Now when I sit down and try to implement moving actors then drawing all the walls in order might be more important. Wall rendering dependencies are represented using a graph: Nodes representing walls and directed edges representing a rendering order. The nice thing about the topological sort is that I can add whatever rules I need into the graph. As long as the graph has no cycles, then I can sort the walls however I wish.

So now I have a decent-looking room. There's still a minor error on the far right, due to the partial wall not being configured correctly. Otherwise, it's a perfect rendering. What isn't perfect are some of the other rooms with all kinds of little weirdnesses going on. I don't have screenshots of them because there's also a crash bug somewhere... so, there's still work to be done.  :o

Edit. Two Hours Later... I tweaked the shadow code and managed to correct some of the oddities I noticed earlier. I can't reproduce the crash, though... so in time. I got to walk around Entry Hall and take some screenshots. Here are some vacation photos.


This is room 10. I have no clue what that black rectangle in the window is... some kind of alien? I dug around the code for a long time before I realized the problem wasn't code-related at all. The room has some round pillars that have no tile geometry defined.  This room gets a "pass" for now, because I think the code is okay.


Except for the door, this room is fine. The staircase will lead to another map (tower). I'm fairly proud of that shadow on the staircase... because it took so much effort to make that work :P This room gets a "pass". The code is fine here.


A ballroom. Except for the shadow casting error with the invisible wall (far right pillar), this room renders correctly. It gets a "pass".


One of the guarded hallways. The original game had this hallway that kept the player from exploring further until they got the sword. This room gets a "D". There's a code error here with the computation of ambient light level, but I know what it is and how to fix it.


This room gets a "fail" :( The error is along the wall where the shadow doesn't cast correctly. I think I know what's up, though. Window tiles carry two wallplanes: a non-shadow casting wall (for the window itself), and a casting wall for the sill. A window also loads a light source that is placed slightly behind the glass. It looks like the sill is casting a shadow, but the wall behind it is not. Thus, the sliver of light closest to the wall is allowed to penetrate.

Each wall pillar has five wallplanes: the four walls and the top. However, wallplanes that are sandwiched between two pillars are deleted. Since the window is right above the pillar, then the top wallplane for the pillar below the window is deleted. In addition, the light is placed above the interior of the pillar.

A shadow is not cast if the light is behind a wallplane. Since the light is (almost) in the interior of the pillar, it is behind all of its wallplanes.

This will be easy to verify (I temporarily remove the wallplane optimization code and see if that fixes it). It'll be a pain to fix if I'm right, though. The optimization process is complicated.

So tonight's wrap-up: three passes, one almost pass, and one fail--not bad. Still making progress  8)

« Last Edit: September 12, 2017, 09:38:08 pm by merrak »

merrak

  • *
  • Posts: 1605
Spot the Differences. The bottom image is the correct version of "Ballroom" from the last post.


The difference between it and the earlier image is that little sliver of light on the right-most pillar was finally fixed. Getting that sliver out was a lot more involved than I anticipated... but isn't that how it always goes?  :o

The other problem with the room is the harsh lighting. The lighting model basically works like this: An "ambient" light level is computed based on a formula (# of light sources) and all tiles in a sector are lit to at least that level. Additional lighting is added based on distance from a light source and inclusion/exclusion from a shadow. The ambient level is not recomputed when the scene loads, so it is zero. In addition, every single window is its own light source--so either a lot of light hits tiles, or none at all. This is also why you don't see any shadows cast by the pillars between the windows--all those tiles are lit 100% because of the ambient level that close to the window.

I realized I could do something much cooler--implement a single global light source, the sun, that is in the same position regardless of what sector the room is in. I could then have this light source shine through the window. Windows are already programmed as 'non-casting' walls, meaning they don't block light or cast shadows. Putting the light far from the window would also fix the problems with the light being inside a wall.

I created a mock-up in the test renderer. The result:


It's a dim light, but I think this looks a lot better than the original. I can adjust the ambient level based on number of windows. The thing I really like about the sun is that I can change its position, brightness, and color in-game. This would let me use the setting sun as a game mechanic.


The original game had a time limit of one-hour. An artificial time limit isn't my preference. I could implement the time limit in the form of the setting sun. If the sun sets then the game isn't necessarily over--the player will just have to stumble through the dark. That makes it harder, but not impossible. Marika can find a lamp (limited fuel), or restore the lights by fixing the generator (permanent fix).

There's also a status line at the bottom of the screen through which Marika communicates with the player. She can stumble through complete darkness and give the player info on what she observes (e.g. "I can feel a wall to the west...") If the player fails to restore the lights before the time limit, it's not an automatic game-over.

Maybe I could make an "easy mode" version of the game in which there is a full moon. Or maybe that would be the "hard mode", because werewolves  >:(

Dincicode

  • Posts: 189
@Merrak You want me to make your character in Blender?  I'll do it for free. Just hit me with the details.

I'v attached an image so you can see what kind of quality to expect.