Merrak's Isometric Adventures -- RPG Reflections

Super glad that you are ok and that the hurricane didn't hit home so to speak!

Since I don't like the value/experience/based games that much I haven't much to say about balancing. I'm more of a puzzle / adventure kind of player and when bashing keys need to be done I'm not interested in that gameplay.
Having a running Spreadsheet with formulas to balance gameplay sounds like a bit overcomplicated thing to do, but again I'm not into designing these kinds of RPGs.

Finding secrets and other treasures is what I do like. Also the idea you had about sounds and the possible interference you could do with the golems was what I was interested in. I would love for games where you can turn on/off certain features so that people can play the game more suited to their needs. If the player doesn't want to fight have an option to turn fight-mode off.

I know that will do much about the balance of the game, but it will allow those people to go and find the route to the balcony

...I'm more of a puzzle / adventure kind of player and when bashing keys need to be done I'm not interested in that gameplay.
Having a running Spreadsheet with formulas to balance gameplay sounds like a bit overcomplicated thing to do, but again I'm not into designing these kinds of RPGs.

I tend to fall somewhere in between. I've mentioned a few times that the Vallas Engine games take a lot of inspiration from a MUD server I used to run ~15 years ago. The MUD was based off of a system called "ACK!MUD", which was heavily hack-and-slash. I found that gameplay very repetitive, albeit enjoyable in shorter bursts and mixed in with other challenges. So that's what I had set out to do back then.

For "Towers of Vallas" I'm sticking to the Game Boy as much as possible: resolution, sound, and controls. Between the limited controls and resolution, I'm probably going to end up with a game that is a lot more hack-and-slash than I'd prefer... but I'm also not intending it to be very long.

I'm viewing "Towers of Vallas" as part exercise/part "real game". It's a bit of a tangent project... but it's simpler and will allow me to test a lot of engine fundamentals before stepping up to more complex features. When I get back to Idosra and its golems, there will be more opportunity for the gameplay I'd really like to have.

Wow!
That will be indeed a good test of the engine.
I was a bit confused with all the different things you did in this 29 page journal
And then I just revisited your first post and noticed you edited it!! That made sense. I should have read that earlier.

So you have temple of Idosra where the Thief of Vallas (Marika) is locked in a temple. (http://www.stencyl.com/game/play/35396)
The latest AI gameplay videos are kind of the latest state of things?

And then you have Towers of Vallas which is the GameBoy version for which I couldn't find a playable version. But you posted that awesome gif:
http://anorthogonaluniverse.com/misc/vallas/2018-09-09-01.gif

Are you switching development between those two projects or do you change the engine with both projects in mind and test the changes on both of them?!

...And then I just revisited your first post and noticed you edited it!! That made sense. I should have read that earlier.

It's probably out of date again I've gone back and forth so many times. Part of that is bad planning, but also part is due to unexpected surprises. In a lot of ways the engine is more capable than I thought it would be.

"Temple of Idosra" is the main title. "Towers of Vallas" is a prequel of sorts. I do have a rough story arc in mind, but it's not terribly important. The enemies in Towers are just guards. Nothing special about them. Their AI is even limited. I use simpler AI so that I have more control over the difficulty of the game. In my mind, Towers is an exercise in level design... something I need to learn more about.

Both games use the same engine--even the same renderer. The engine offers two renderers: a blending renderer (this is the one that made the red/green columns) and a dithering renderer. Both of these games use dithering.

The only real difference I've run into so far is that Towers, with its Game Boy resolution, is more prone to numerical errors. The engine is very customizable through XML files. In fact, although both of these games are separate Stencyl projects, I could bundle them together and even mix "Game Boy" levels with "Idosra" levels. That feature is a holdover from when the map parameters were defined from the Stencyl scene that initialized the map. Before I used XML data to configure a map, I used a scene behavior and the scene gravity, tilesize properties, etc.

November Update! A couple weeks ago I set a goal of working toward a playable demo of "Towers of Vallas". I don't think I have much exciting to show in Alpha Release 1, but it's a good milestone. The last playable anything I made with the Vallas Engine was the original "Temple of Idosra".

My to-do list is quickly dwindling. I'm still chasing the occasional odd bug in the shadow and rendering code. One of the worst offenders was in the light copy code. When I'm constructing a sector, each wall gets its own copy of each light. Each copy then has a list of the shadows that are cast against it. Somehow I had set it so that each copy of the light also copied all of the shadows casted against each other copy. The result was an exponential growth in shadows that wasn't apparent unless I had a room with lots of lights (like rooms with a lot of window panes).

So that was a dumb bug  Rooms with lots of windows now work a lot better--but I also went ahead and changed it so that each group of window panes counted as a single light, rather than every single pane.

I also fixed the way the physics of light is implemented. I had an error in the formula used to compute light intensity as a function of distance. The result produces a bit more dramatic lighting, which I'm happy with.

I made a variety of changes to the player avatar. I'll probably end up taking out the sprite shadows. It's a neat proof of concept, but the game resolution and number of light levels is just too small to put it to real use. Each pixel can have only one of nine light levels. So I don't get a smooth transition in the sprite shadows--and the low resolution makes them look too chunky. It's hard enough to see the sprites as it is.

Speaking of which, I did finally add code that adds a spot shadow under the feet of NPCs and the player.

Unlike the "Isometric Crash Course" demo that's on the very top of the first post, the spot shadow is a properly drawn shadow--not a separate actor. So the spot shadow correctly follows the slopes of stairs and doesn't "hang over" cliffs when the player is halfway off of a ledge.

I haven't gotten to the NPCs yet, but Marika herself is now higher contrast.

This helps her stand out more than any of the other changes. For the attacking image I added a swipe effect so that it's clearer where her attacks will connect. Melee combat is a bit tricky because the collision boxes for actors are right cylinders. This means when you walk into an NPC to get close enough to attack, you're more likely to slide around it.

I haven't figured out a good solution to that problem yet. Marika can't move while the attack animations are playing, but there's still too narrow of a window between walking and pressing attack. Attack too soon and Marika will be too far away. Attack too late and she'll slide past her opponent.

If the actors were bigger, I don't think it'd be as much of a problem. A tile is only 8x8 grid units, so there isn't much grid resolution to work with.

The last thing I added was a ranking system. My old MUD server that this game draws some inspiration from had the same kind of system that rewarded players with higher EXP points for completing special tasks within an area.

The usual A, B, C, D ranks are there, awarded for recovering various amounts of gold from the towers. There's also an S rank which requires the player find the secret area. If the player retrieves all of the gold, obtains the maximum player character level by finding (and reading) all the books, and doesn't die, a P rank is awarded.

I'm not completely settled on the names, but the final ranks will be something like these.

Code: [Select]

Rogue Rating  Rank Name / Pts

D  Daring Damsel            0
C  Dauntless Desperado    240
B  Robust Raider          440
A  Predominant Prowler    600
S  Cunning Corsair        720
P  Mighty Marauder        800 (Perfect)

I don't really like "Daring Damsel", but that's the D rank, so maybe I leave it for some incentive to do better

Demo Time! 89 days later, my GBJam 6 entry is finally in a playable state. I made a Flash port and uploaded it to Stencyl Aracde.

Alpha Release 1

Gameplay: Arrow keys to move. WASD or numpad is not yet supported. Jump is z, Attack is x, and action key is enter.

If you stand close to an object, like a chest, you'll see its identity flash at the prompt on the bottom of the screen. Then you can press enter to interact with it.

Get the sword from the first chest. Press enter (when not standing next to an object) to open inventory. Select the sword then equip it to deal better damage.

You can reset the game by pressing tilde + escape. This drops you into the command prompt. Type "launch" and press enter to restart.

Known issues:
It's a bit too easy to get pointed in the wrong direction during combat. Not yet sure of the best way to fix this, but it's something I'm working on.
NPC animations aren't done yet. They're still low contrast and so hard to see.
Opening and closing inventory items too quickly will cause a crash.
Some of the walls do not render in the correct order. Apparently there is a difference between how the desktop build and Flash handles floating point arithmetic. As a result, the tolerances in the code that checks for overlapping wall images are not strict enough to prevent the game from thinking some walls are in front of others when they really aren't.

Unfortunately, there are a myriad of new little issues on top of the known ones. The execution order of important functions does not appear to be consistent between the desktop build and the Flash build. The first symptom is the "Lime Screen of Death" whenever you kill an NPC.

The error "VA04" occurs when an actor's physics model gets separated from the actor itself. That's a really weird thing to happen. A good analogy would be if one of an actor's behaviors suddenly disappeared in run time.

A lot of these errors act like virtual fuses that stop the game when something unusual happens. To get the Flash port to run, I just disabled the error check, but you might then notice something else happens. When an NPC is killed, it gets one last attack in. Attacking, like any other actions, are handled by the actor's physics model. So somehow the model is surviving one extra frame, separated from the actor.

Another problem seems to be when exiting a map, sometimes the new map doesn't load and the player character disappears. This doesn't even trigger an error flag, so I have less to go on to try to fix it. If I had to guess right now, though, it's probably another execution order related bug.

I don't think it's worth fixing these. By the time I'm done with the intended desktop build, some of these issues may resolve themselves. At this point, the alpha build is more of a proof of concept than a game.

One take-away from all this: It's worthwhile to develop on the platform you intend to release on. There are little differences between the platforms, which is unfortunate but inevitable.

Fun Fact. One foot in length is approximately one light nanosecond.

Hi merrak,

this is already a lot of fun and i enjoy it a lot.
The enemies especially because they feel "alive". Very good job.

I would adjust the jumping a bit. Right now it feels that she stays at the highest point a bit too long which is a bit unnatural.
I wish i could see the equipped weapon or fist if unequipped in th UI.
I wish i could lure different enemies to another...lets say an animal to an enemy and they start fighting each other.

I can confirm that there are doors which "kill" the main actor (see attached).
Also i was confused that i cant go through the door at the start.

Overall very excited!"

Very nice!

Although I crashed and even froze my browser I enjoyed it very much up to that point.
The crash occurred while trying to walk up a slope (I guess that it was that) while an enemy was chasing m.e.

I agree with Bombini on the jumping and the feel ' alive ' of the enemies. 

Sometimes the game spontaneously lags (don't really know why) and then it ' jumps '  a bit . (for instance I lost her and she was in a doorway)

I really like the inventory system and the interaction with it. You might give a hint on the keys in-game for this?!? The chest for instance. Maybe on the first encounter a hint "[Enter Key]"  to unlock it?! You wrote about the keys in the post, but it would be cool to guide the player along in-game.

It is really awesome to play this!!! Hopefully you can trace the crashing/freezing issues?!

I really like the inventory system and the interaction with it. You might give a hint on the keys in-game for this?!? The chest for instance. Maybe on the first encounter a hint "[Enter Key]"  to unlock it?! You wrote about the keys in the post, but it would be cool to guide the player along in-game.

+1 on this.

Also a tiny detail: I am never a huge fan of Z as button becasue some keywords (like my german one) has the Z somewhere completly else. Again, tiny detial.

Hi merrak,

this is already a lot of fun and i enjoy it a lot.
The enemies especially because they feel "alive". Very good job.

I would adjust the jumping a bit. Right now it feels that she stays at the highest point a bit too long which is a bit unnatural.
I wish i could see the equipped weapon or fist if unequipped in th UI.
I wish i could lure different enemies to another...lets say an animal to an enemy and they start fighting each other.

I can confirm that there are doors which "kill" the main actor (see attached).
Also i was confused that i cant go through the door at the start.

Overall very excited!"

When it's not having issues, I really enjoy working with the enemy AI system. I'm only using a small set of the features I have available. Adding new features, however, can be a real hassle. I think that's the cause of the browser hangup m.e. mentioned above. I have some safeguards in place to prevent the main AI routine from getting stuck in an infinite loop, but that doesn't seem to be working in Flash.

All of these crash issues seem to be Flash related. The desktop build is very stable. The one thing that all these problems popping up have in common is they could be the result of critical functions being called in the wrong order. Anything involving motion--leaving the map, climbing up a ramp, and the "VA04" bug are all managed by the same timing-sensitive routine. I don't know why that would happen in Flash and not desktop, but that does give me something to go off of.

The doorway at the beginning doesn't have its door yet. In fact, there are a few other doorways that should have doors. I'm still thinking about how to implement doors. Since doors will have to move, I can't make them like I do walls. But sprites all have to be the same size, and the doorways are too big. I have a couple of ideas, though. Eventually the doorway at the start will be the game exit.

I didn't think of putting the currently equipped weapon in the UI, but that does sound like a good idea. So does getting enemies to fight each other I'm not sure if that idea would fit for this particular game, but if I could find a way to make it work that'd make for some interesting strategy. Perhaps you could befriend a guard dog and get it to turn on its former master. I'll have to play with the idea

Very nice!

Although I crashed and even froze my browser I enjoyed it very much up to that point.
The crash occurred while trying to walk up a slope (I guess that it was that) while an enemy was chasing m.e.

I agree with Bombini on the jumping and the feel ' alive ' of the enemies. 

Sometimes the game spontaneously lags (don't really know why) and then it ' jumps '  a bit . (for instance I lost her and she was in a doorway)

I really like the inventory system and the interaction with it. You might give a hint on the keys in-game for this?!? The chest for instance. Maybe on the first encounter a hint "[Enter Key]"  to unlock it?! You wrote about the keys in the post, but it would be cool to guide the player along in-game.

It is really awesome to play this!!! Hopefully you can trace the crashing/freezing issues?!

The inventory system definitely needs a revision. I haven't gotten around to it yet, so what you're seeing is the original version I threw together back when I was operating under the GBJam time limit. There were exactly 15 items... so with those, plus "Marika", there were 16 cards and just enough space for all of them. Since I have more than 15 items now, I'll need something that scrolls. But then I can design the inventory UI so that it has room for keys, tooltips, or any other usability features.

One thing I got out of reading Bombini's Space Pirate thread is that I could be doing a much better job designing the first level to teach the player how to play the game. That first map was another one that was quickly designed under the original time limit. I haven't gone back to it since, but it needs some adjustments. For one, there is nowhere you need to jump, so the player isn't introduced to jumping until way later. And, of course, the chest and other items can be introduced at a better pace.

The "hang time" while jumping is a bit of a gravity hack. If I set gravity too high, it's impossible to jump over even small sized gaps. If gravity is too low, jumps are too unrealistically high. The proper fix would be to introduce some forward momentum, but I added the 'hang time' as a simpler solution. I think it can work, but I need to draw the proper animations for it. Right now the walking animation plays when you jump, so a proper animation is on the to do list.

Spontaneous lag is probably garbage collection. It's not noticeable on desktop unless you have a system monitor running, and then you'll see a little CPU usage jump whenever a lot of shadows are redrawn. This usually occurs when you change sectors (rooms), but can also occur if you step into or out of a bright light. It's more noticeable on Flash.

I probably don't need to cast actor's shadows against walls in this particular game. It works--and on desktop, at an acceptable speed. But there are very few rooms where you can even see actor shadows, and even then they're not very noticeable because there are only four colors and the images too small to get good dithering. I'll definitely leave the little circle shadows on the floor, but should probably disable the "real" actor shadows.

Memory usage in general is also terrible. It's one reason why I made a Flash port and not HTML5. You don't see it in the version I uploaded, but if you run the game in "editor mode" (720p resolution with the full command prompt), it reports almost 1GB memory in use before you even get to the main menu. The game flat out refused to run in HTML5 without Chrome complaining about memory. I can definitely fix it--but I just haven't made the time yet to do it.

Also a tiny detail: I am never a huge fan of Z as button becasue some keywords (like my german one) has the Z somewhere completly else. Again, tiny detial.

Ultimately I'd like to have a feature in the "options" menu to let the player completely customize the controls. What would be a good alternative to 'z' on a German keyboard? I don't think it'd be hard to add a few presets to select from along with the 'custom' option. I'd really like to have controller support, too. But that might have to be a desktop version feature.

wasnt able to play, because of huge lags, hero moving in one step from one side of the room to other, and a lot of other type of lags also the game is loading too long. Strange for oldest style pixel art game. But i see you ve made a great job.
better to change the engine. in construct you can rebuild this job in a week and it will work without any lag on any platform

I am never a huge fan of Z as button...

I'm not huge fan of the Z button because my keyboard is weird and can't register left and up/down while pressing Z.

But I'm not one to talk; I'm developing a game using the Z button.

wasnt able to play, because of huge lags, hero moving in one step from one side of the room to other, and a lot of other type of lags also the game is loading too long. Strange for oldest style pixel art game. But i see you ve made a great job.
better to change the engine. in construct you can rebuild this job in a week and it will work without any lag on any platform

These both sound like graphics memory management issues. If the game takes a long time to load on the lime "Towers of Vallas" screen then it doesn't surprise me that actual game play is lagged, too. What computer specs are you running on? Flash is not the ideal platform for this sort of thing.  I just went with it for this demo.

Interestingly enough, I loaded the game in "editor mode" on Flash and just discovered it's claiming 2.4GB (!)

Back in February I crunched some numbers: how efficient is the renderer? I never did run this test in Flash. I uploaded a modified version of the game that drops you straight into the prompt: http://www.stencyl.com/game/play/39675

Type 'gtest' and press enter. Use up/down to change the multiplier. If you look at my February post, you can see I got 60FPS up to about the 10x multiplier. With Flash, I have some periods of 60 FPS on the 1x multiplier, but only about 30 on the 2x multiplier. So we're looking at an efficiency drop of almost an entire order of magnitude between CPP (desktop) and Flash.

Changing game engines would be a massive undertaking. A week sounds like a generous estimate even without factoring in the time it takes to acquire experience and expertise... itself no trivial task. Remember that I don't use Stencyl engine for rendering. I'm writing rendering code targeting a level lower that works alongside the Stencyl engine, not on top of it. Considering that the graphics management routines are my own, rewriting the same code is going to generate the same problem.

The proper solution would be to optimize the code for Flash, as well as finish the rest of the optimization tasks on my to-do list. Some of these I've been putting off because they're involved tasks... although much less involved than starting over

I'm not huge fan of the Z button because my keyboard is weird and can't register left and up/down while pressing Z.

But I'm not one to talk; I'm developing a game using the Z button.

Oddly enough, I'm not either. I just got used to it But--it makes sense to support the options most people would guess. On that point, I should have 'r' do something. If for some reason someone gets stuck, that'd be the go-to reset button.

One thing I got out of reading Bombini's Space Pirate thread is that I could be doing a much better job designing the first level to teach the player how to play the game. That first map was another one that was quickly designed under the original time limit. I haven't gone back to it since, but it needs some adjustments.

This will be time spend well. It is so important to find the right balance between showing enough features and also not overwhelm the player. Pinpointing the player towards features and design without making her/him feel stupid. Having those important aha-moments which create fun and make your game unique.

I build the levels always with a first gut feeling of course. I have a huge spreadsheet which shows which feature (for example the bomb which lest you blow up walls) is introduces and where it is active to find the right balance. Afterwards i test thje level myself until i have all the crashes and bugs out followed by user tests who dont know the level at all. This is always the most crucial part. Letting someone play and sitting next to her/him to take notes. I always ask to think out loud everything and that they cant hamr my feelings.

Cheers!

And one small comments on the "z" key
This is a german keyboard (attached).
You see the x, z and aroows are ste in a way that it can hurt

I would ignore this though because i dont hink that the game will be targeted at the German market.
Just wantes to explain