Merrak's Isometric Adventures -- Dimetric Dilemna

Thanks for checking it out!

Was this the rectangle that showed up?

It's a separate actor that overlays a button. I had to throw together a new button highlight at the last minute, since the existing one didn't work right on HTML5.

A map is definitely on the agenda. In fact, I pretty much already have the code for it. The "AI Sector Graph" tool I made for the map editor's AI tools is essentially a map. I just need to change the way the output image is drawn so that it fits in the game better.

...reading it awards you experience points without actually reading anything

That's the way textbooks work in school

I don't think my hit/damage model spreadsheet is doing a bad job. I just took my best guess at assigning difficulty ratings. I definitely noticed a difference between actual scenarios the model predicted as "1" vs. "10"--but difficulty is very subjective so it's good to get some feedback on how others perceive it.

I think I missed the mark on estimating how much more difficult groups of enemies are. The two maps accessible from the stairs furthest from the starting point are particularly difficult. I did want them to be a little more difficult than the closer maps, but I might have pushed it too far. I made sure to place the keys in the hub area so that the nearest "A" map is one of the two easier ones. The harder ones guard better objects and books, though. I had the most fun making the dark map where you need the lamp. There are a few hidden passageways that reveal themselves if you pay close attention to the way the lights interact with the walls and floors.

Yes that was the blinking actor. It was introduced after opening a chest. In my case it was for the boots. Not sure if that is the only place it would/could happen.

Map : COOL ! But to be honest I kind of would have an option to see only the parts that I have visited and my current position. It will be a spoiler when for instance there are 'hidden/dark' areas visible. I like the adventure type of thing : looking for clues/keys and knowing that there is a hidden treasure or path is especially cool.
Maybe have a switch on the map for the lazy ones, and default it only tells you wich paths you have taken?!  I don't know: just throwing ideas

Probably I haven't found the more difficult enemies because I am terrible at hack&slash. The ones that I did encounter where either nicely fooled (Keep that ! I like the fact that one of the enemies was looking at a different spot and didn't follow m.e. !)
or they did have a low health in regards of my own.

Hi merrak,

first of all...congratulations!
This is a huge step and i really enjoyed it. Thanks for sharing!
I would like to share some hopefully constructive thoughts:

Performance:

• My system: Windows 10, Core i7 @ 2,1GHz, 8BG RAM, Intel HD Graphics Family
• 5-10 frames in start menu
• 25-60 frames in game depending on which action or direction (does mot scale up to 60 when i am idleing). It feels very fluent.

Various observations:

• Options screen is not working
• The font in the about screen is very difficult to read
• The big door in start room which cant be entered still confuses me

The version you shared is fantastic, its fun, its great. Has its unique style. Here are a couple of things i would like to have to make it even better.

What i would like to add:

• The game feels a bit empty right now. I would add more interactions. Either more small/weak enemies or more switches or more traps or more lootable objects.
• Level progression: I dont know how far i am in a level. How far it will spread. Either add a map (that you already think about) or some sort of progression bar to see how far i am to keep me motivated
• More interactions with enemies: One of the features i enjoyed most was that enemies follow me. Why not have enemies which attack each other. Lets say monsters or lions which i can lure to humans and so on. This would be great.
• Navigation: Adding a map would be great, or a compass to show me where to go next. Where the next main objective is. I would also add tiny arrows add the level borders to show where you can move to. Its not alwys clear from the lighting.

Compass and arrows:


I love those "almost" secret rooms. Such a great feeling. Please hide more not so obvious secrets. This could be one of the unique selling points of this game:


Would i buy it if it had a bit more content? Yes!

All the best,
Bombini

There's nothing special about that chest. It happened to me on another one--I think it's just a quirk in the timing between when the Actor attribute that stores that actor is set and its previous value deleted. I'm not too concerned about it, since that whole setup was a temporary solution. I really want the buttons to dim/highlight like the inventory cards do, but I didn't feel like drawing dim versions of all those graphics at the moment.

Map : COOL ! But to be honest I kind of would have an option to see only the parts that I have visited and my current position. It will be a spoiler when for instance there are 'hidden/dark' areas visible. I like the adventure type of thing : looking for clues/keys and knowing that there is a hidden treasure or path is especially cool.
Maybe have a switch on the map for the lazy ones, and default it only tells you wich paths you have taken?!  I don't know: just throwing ideas

My thought on the map was to take something like Bombini suggested (mock-up below) and implement it as a skill "Perception" that you can get in the hub area.

The graphic shows Marika's relative position in the map along with anything that makes sense for her to be aware of--so not secret areas I'd like to have a more elaborate map that can be brought up that shows more detail, but it would either fill in as the map is explored, or fill in with details as maps or other pick-ups are found.

The ones that I did encounter where either nicely fooled (Keep that ! I like the fact that one of the enemies was looking at a different spot and didn't follow m.e. !)

That's a definite feature of the AI When an enemy loses sight of its target, it stops and looks around. Right now they're programmed to look in random directions. Smarter enemies would be better at scanning. I want to be careful how ambitious I get with the AI on the first run, since AI is challenging to debug--but I would like to at least have enemies react to sound. If they hear Marika's footsteps, they'll turn in that direction (making "Sneak" a skill book you can find), or other enemies can alert their colleagues on her position.

Various observations:

• Options screen is not working
• The font in the about screen is very difficult to read
• The big door in start room which cant be entered still confuses me

The version you shared is fantastic, its fun, its great. Has its unique style. Here are a couple of things i would like to have to make it even better.

Thanks for sharing your thoughts! That font definitely needs improvement. I'd like to add a dialog system so I can give books text, pass along Marika's observations to the player, etc. That would also fix the door at the beginning of the game... have a prompt along the lines of "I can't leave until I finish my mission..."

I don't have any game options yet, but for desktop build I want to add controller support. Those controls will go there. Maybe a mobile port, too? I'm not sure.

Your system is far better than my old Windows 7 laptop I was using. It's some kind of Core i3, 4GB RAM. I'm surprised you only got 25 FPS... but then again, I never tested the game with a FPS monitor on the laptop. I checked for numerical bugs (there are some rooms that don't render correctly if the floating point math is off), but not FPS. What monitor are you using? I can squeeze some better performance out of the renderer. Ultimately I'll need to move away from software rendering, but if I can get acceptable performance out of software I don't want to get diverted by that job yet.

What i would like to add:

• The game feels a bit empty right now. I would add more interactions. Either more small/weak enemies or more switches or more traps or more lootable objects.
• Level progression: I dont know how far i am in a level. How far it will spread. Either add a map (that you already think about) or some sort of progression bar to see how far i am to keep me motivated
• More interactions with enemies: One of the features i enjoyed most was that enemies follow me. Why not have enemies which attack each other. Lets say monsters or lions which i can lure to humans and so on. This would be great.
• Navigation: Adding a map would be great, or a compass to show me where to go next. Where the next main objective is. I would also add tiny arrows add the level borders to show where you can move to. Its not alwys clear from the lighting.

I really liked the navigation arrows idea. I sketched out a system where arrows flash/pulsate to indicate a new direction, and solid to indicate a direction already explored. Of course, secret areas wouldn't have arrows. I don't remember if it's accessible in this version, but there is one map that has a lot of 1-tile-wide doors. Those are easy to miss, since they blend in with the half-walls.

I'm slowly adding more pick-ups, skill books, and such. I like the idea of having more interactions with NPCs. I need to nail down the story line, though, which at the moment is vague. Although I like the idea of having NPC/NPC interactions (like enemies that fight each other), at this point I can't say if that makes sense with respect to the game's story. I have a vague idea, but I need to write down details.

Just thinking "out loud" here, but I realized that the armor items you find in the game would probably be the armor items the guards use. If you're wearing enough of them, or the combinations of items that the rest of them would use, the dumber ones might be fooled into thinking you're a guard

I do need more enemy types at least. For the longest time my focus had been on the engine side of things. I'm still in the process of shifting focus to the actual game. There are still some core features missing, though. Right now I'm working on the save game system. I got the hardest part done--planning how to redo the game boot-up sequence to work with save files. I just need to implement and debug the code.

My thought on the map was to take something like Bombini suggested (mock-up below) and implement it as a skill "Perception" that you can get in the hub area.

I like this a lot! This would be very helpful. Maybe add the final goal of the level (if there is one) as a yellow pixel.

I'm surprised you only got 25 FPS...

FPS: I used Fraps which has been a reliable source for me. The game felt fluet all the time and i have never seen something like this. The FPS would not go up to 60 when ideling. It would stay where it was at last. Maybe you pause the system when not getting input form the player? Each direction i went had different FPS ranging from 25-60.

I like this a lot! This would be very helpful. Maybe add the final goal of the level (if there is one) as a yellow pixel.

FPS: I used Fraps which has been a reliable source for me. The game felt fluet all the time and i have never seen something like this. The FPS would not go up to 60 when ideling. It would stay where it was at last. Maybe you pause the system when not getting input form the player? Each direction i went had different FPS ranging from 25-60.

My thought was to add a pixel to indicate anything interesting that Marika becomes aware of. I'd need to think of ways she would become aware of things and their whereabouts, but this would give me an opportunity to add map pick-ups, NPCs to talk to

I'll have to try Fraps out on the Windows laptop. I have my own built-in FPS indicator setup, but there is no display for it in the game. I had it set up for the renderer test. It's interesting that it's direction-specific. Maybe my code that sorts actors within a layer isn't efficient.

Lately I've been working on the save game system. I cleaned all the game initialization (placing enemies in maps, objects in maps, setting door states, etc.) code out of the boot-up sequence. The game is now setup when the "New Game" option is selected. If "Load Game" is selected, I'll be able to set up the enemies and objects in different positions.

I also now have some new game screens. I've set them up in one large image split up into three screens. There are five save slots supported in Desktop version. If I have a Flash or HTML5 version then I'll need to rethink how I approach saving, since I'm using separate files for save games.

Lately I've been working on the save game system. I cleaned all the game initialization (placing enemies in maps, objects in maps, setting door states, etc.) code out of the boot-up sequence. The game is now setup when the "New Game" option is selected. If "Load Game" is selected, I'll be able to set up the enemies and objects in different positions.

I use a the same concept. A bit messy are the view checkpoints i use in the levels themselves but thats fine.

I also now have some new game screens.

Look very cool. Will the scroll horizontal when changing screens?

Look very cool. Will the scroll horizontal when changing screens?

Yep Getting the save game code working has proven to be very tedious. I've been maintaining my sanity by taking some time to draw some cutscenes and title screen art. I liked how the level loading screen came out, but I'm getting tired of seeing the same picture for every level.

Hi,merrak! I got inspired by your thread and also wrote a little isometric video game:
https://nikitasadkov.itch.io/spell-of-mastery-demo

Although I did everything differently, especially topological sorting (which I reverse engineered from Ultima 8 and Magic & Mayhem).

New Goals! I've spent the better part of the week working on save game. I've been very busy at work and haven't had a lot of free time, but I do have some progress. The biggest problem is that the Stencyl code that interfaces with my own "Vallas Engine" code is a mess. I've done a lot to tidy the startup process, but I still have some work to do there.

I'd like to have Alpha Build 3 ready next month. Somehow I feel these deadlines are arbitrary, but I did meet the previous two. Save game is the last core engine feature.

As for core game features, I need a dialog system. I'm not expecting this will be a long endeavor. I already have my UI code I can build off of. I won't need anything elaborate--nor do I really have the space for it. I just need something to let me display more text than can fit in the bottom prompt. I don't anticipate having time to implement NPC conversations for Alpha Build 3, but I can at least use it to give the player some key descriptions (e.g. how to use the front door).

I also want to get my map system working.

The rest of my wish-list is just to clean up some things and add new content. I want some more types of NPCs. I need some finer control over their levels. More decoration objects and interactive objects would be nice. At this point I'd rather focus on adding more to do with the existing maps, adjusting their difficulties, etc., than making new ones. I have a lot more skills implemented than originally planned, so I need to re-think where skill books are placed, add new ones for skills I've coded but can't be used yet, and so on. So--more new, fun things to come 

I also have some new level loading screen artwork. I came up with the idea of showing the dominant gimmick in each map. So far I have a map with a lot of spike traps, a map with a lot of projectiles, the dark map, and a map with a higher number of melee enemies than usual.

Hi,merrak! I got inspired by your thread and also wrote a little isometric video game:...

Pretty neat. Looks like it's been in development for just as long.

Pretty neat. Looks like it's been in development for just as long.

Yeah. It seems your main difficulties come from using Stencyl, which wasn't build for isometry or anything beyond a simple tile games. Why wont you just use raw SDL or even OpenGL?

I myself use plain SDL (without  OpenGL),  so I had to do all 3d stuff in the game's code. I tried using even ZBuffer, but it failed to handle transparency, so I still had to topological sort everything. The other solution appears to be sorting transparent sprites by depth and draw them after non-transparent sprites. Polygonal 3d engines use a few tricks to process transparent surfaces. Life is much easier, if one uses ray-tracing instead, but then CPU requirements will be too high

Yeah. It seems your main difficulties come from using Stencyl, which wasn't build for isometry or anything beyond a simple tile games. Why wont you just use raw SDL or even OpenGL?

That's a fair question I haven't written anything "from scratch" with OpenGL since I took a course in computer graphics (2005), so it's definitely been a while. I did make a variant of "The Light Corridor" with it:

Still runs! Shown running under Wine on Linux

I wouldn't say Stencyl wasn't built for anything beyond simple tile games, though. Rather, much of Stencyl's marketing is directed toward novice programmers and simple tile games are easier to code than games involving complex graphics or physics. There are plenty of examples of people who have done impressive, complex programming with Stencyl. See, for example, mdotedot's 3D integration and NC Tactics.

While I don't use the Stencyl engine for the actual gameplay, my game does use Stencyl for just about everything else: menu screens, user interface, audio, game controls, low-level code--these low-level things I don't want to take the time to get working (nor take the time to keep working, as the case would be with iOS updates, etc.)

I myself use plain SDL (without  OpenGL),  so I had to do all 3d stuff in the game's code. I tried using even ZBuffer, but it failed to handle transparency, so I still had to topological sort everything. The other solution appears to be sorting transparent sprites by depth and draw them after non-transparent sprites. Polygonal 3d engines use a few tricks to process transparent surfaces. Life is much easier, if one uses ray-tracing instead, but then CPU requirements will be too high

The "Vallas Engine" renderer uses a ray-tracing approach. It doesn't handle reflections, and so is very simple compared to most ray-tracing implementations.

The "Vallas Engine" renderer uses a ray-tracing approach. It doesn't handle reflections, and so is very simple compared to most ray-tracing implementations.

Wow! You actually did it! I'm surprised it runs in browser at all!

I wouldn't say Stencyl wasn't built for anything beyond simple tile games, though. Rather, much of Stencyl's marketing is directed toward novice programmers and simple tile games are easier to code than games involving complex graphics or physics.

Exactly! Just setting-up a modern OpenGL viewport to blit a sprite takes 1000 lines of C/C++ code, not speaking about resource management, like loading and and caching graphics, and then we also have sound and music playing. And you already mentioned GUI, which is a science in itself.
http://git.savannah.gnu.org/cgit/freedink.git/tree/src/IOGfxSurfaceGL2.cpp
http://git.savannah.gnu.org/cgit/freedink.git/tree/src/IOGfxDisplayGL2.cpp
That is a daunting task for a person who just wants to make a game. Unreal would be even more daunting, because it was designed for larger teams with a programmer specialized on maintaining the 3d engine itself.
Still I remember that in 1989 drawing graphics was as simple as

Code: [Select]

*(char*)(0xA0000+y*320+x) = color;Compare that to https://github.com/SaschaWillems/Vulkan/blob/master/examples/triangle/triangle.cpp

I once wrote an MMX optimized textured triangle rasterizer in less lines of code.  So yeah, for most people it is either making a game with pre-made engine, like Stencyl, or making no game at all, ending up with unfinished engine.

The "Vallas Engine" renderer uses a ray-tracing approach. It doesn't handle reflections, and so is very simple compared to most ray-tracing implementations.

Wow! You actually did it! I'm surprised it runs in browser at all!

It performs a lot better on Desktop, which is the direction I'm now heading... but even the resolution 160x144 is taxing if I'm not very careful. I outlined how the renderer works way back earlier in the thread, but the short story is that instead of looping through every pixel and every light source, I pre-compute which surfaces are lit by which lights. I also throw a lot of linear algebra tricks at the problem. Instead of representing each wall surface in the same 3D coordinate system, I compute a basis unique to each wall in which the coordinate system minimizes the number of arithmetic operations needed run computations against light vectors

Exactly! Just setting-up a modern OpenGL viewport to blit a sprite takes 1000 lines of C/C++ code, not speaking about resource management, like loading and and caching graphics, and then we also have sound and music playing. And you already mentioned GUI, which is a science in itself.
http://git.savannah.gnu.org/cgit/freedink.git/tree/src/IOGfxSurfaceGL2.cpp
http://git.savannah.gnu.org/cgit/freedink.git/tree/src/IOGfxDisplayGL2.cpp
That is a daunting task for a person who just wants to make a game. Unreal would be even more daunting, because it was designed for larger teams with a programmer specialized on maintaining the 3d engine itself.
Still I remember that in 1989 drawing graphics was as simple as

Code: [Select]

*(char*)(0xA0000+y*320+x) = color;Compare that to https://github.com/SaschaWillems/Vulkan/blob/master/examples/triangle/triangle.cpp

I once wrote an MMX optimized textured triangle rasterizer in less lines of code.  So yeah, for most people it is either making a game with pre-made engine, like Stencyl, or making no game at all, ending up with unfinished engine.

I think you have good points on graphics and, in general, difficulties in using larger engines--but I don't think it's fair to compare to programming in 1989 without talking about RAM and processor speeds. There were plenty of challenges in the 1980s. They were just different. While there weren't vast, complex libraries and engines to learn, programmers had to be a lot more cautious with resources. It took a lot of skill to get the most out of every byte of memory. Plus, it was a lot harder to look up how to do something. Now we have online documentation, chat, forums, and for better or worse, the expectation of an immediate solution.

There were plenty of challenges in the 1980s. They were just different. While there weren't vast, complex libraries and engines to learn, programmers had to be a lot more cautious with resources. It took a lot of skill to get the most out of every byte of memory. Plus, it was a lot harder to look up how to do something. Now we have online documentation, chat, forums, and for better or worse, the expectation of an immediate solution.

In some cases limited resources can be a boon. For example, with the NES's 2kb RAM you wont be making a huge all-encompassing open world game with overwhelming amount of cut-scenes and dialogue, but instead concentrate on making smaller game with well polished gameplay. Although one can probably argue that Metroid and Zelda are open world, and there were even a few isometric games for NES, like Marble Madness, Solstice and Snake Rattle n Roll. But they were all well designed and straight to the point. I doubt these games had superhuman game designers behind, but the hardware limitations reducing the decision space in game design. And now we have Fallout Online - a game so big, it is impossible to balance and debug even for thousands of beta-testers. So I think less can be more.