Thanks!

Thought I had found the main cause of the crashing bug today. Turns out that it crashes on any screen outside of the first one because it's trying to reset the score after the scene has been destroyed. At least that's how it appears. The good news is that I've cleaned up the profile related bugs - that -was- related to the thing I thought was the main cause.

Now to attack this crashing bug. I must have separate mode_stopped code in my initial scene vs. any other. I should have this sorted soon, which will be great!

EDIT: Haha, turns out I'm calling base.mode_stopped() before my mode cleanup actually happens in every other scene. Quickly fixed. Silly mistake.

So I thought that was the cause, and I'm sure it wasn't helping, but it turned out that I have a separate call in a low-level mode that destroys any active modes before ending the game. This had to be manually compiled and I was missing the majority of the scenes in the list... whoops.

I'm going through and adding each scene to each part of the game now, to prevent just this type of issue in the future as I add more scenes...

This will also prevent some build-related headaches later on and other weird issues that I've coded myself into a corner with. Knock 'em all out at once! I'll do a final count, but it'll be something > 60 separate screens.

Turns out I can't count - after culling some of the original screens, but before adding some pinball-related minigames I'll be adding, the final screen count is 61 exactly. Minigames might bump it up to the mid-60s.

I've come up with a way to modify the movement that will still require an element of skill. Flippers, which already handle lane change, will handle change to direction. The bottom set of buttons will confirm movement. You'll still have to keep the ball alive, so that's something. It's not as heavily skill-based as I'd like, but it's better than draining 100 out of 100 times when trying to simply move out of the village.

Rewriting this should be easy, but I'll have to significantly alter the GUI for each screen to add handlers to enable/disable each path. I'll likely switch them to a numeric index and pass that index to the mode layer. On the mode layer, when the button's pressed, it'll check a small lookup table in what I call the 'WalkShotMode' for that scene, and move you around. In this way, I can add in as many paths as I wish while still keeping the feel of the walk mode.

Note that I'll need to run the 'WalkShotMode' at a much higher priority than my ItemSelectionMode - the button is repurposed from that and much less clean than I'd like, but you can't walk and use items at the same time, so I guess it's ok (at least that's what I tell myself through the tears).

While I'm at it, with adding scenes, I am going to go ahead and build in my prefabs and provisional artwork. This will at least allow build and change between scenes so I can more effectively test walking through the whole map.

Will take a little extra time, but should prove fruitful.

Turns out I still can't count, I forgot a few of the scenes in the town in this count, it's somewhere close to 67 with minigames.

I have made all the main scenes, and built a POC for the walking using button nav. I think it will be frantic enough to make it fun on the real game. Hopefully I'll be able to do another test soon and find out! At this point, I can build out modes, and luckily, I was able to use almost the same structure, so there's not a ton that needs to change. Each screen has a different max number of walking points, so I'll have to tweak that on a per-scene basis, but that's the same amount of work I have to do anyway to set up the shots.

So with 67 distinct scenes, there are generally 5-10 distinct modes per scene. Usually more. So the true number of 'modes' is something closer to 670.

Thanks man! I do my best to do something crazy with every new game.

Like many new, popular games, you can choose to enter the Wizard mode right from the start! Well, not a Wizard mode, since you haven't attended the Wizard's Institute of Technocery (WIT) and completed your exam yet, but at least a Magic User mode.

Alright, new walking has been added to all existing scenes, and I'm working on adding new scene 'icon' modes. That's the walk, look, touch, talk, and use interactions on every screen.

I've got a long, long way to go. Bite at a time.

She was an absolute joy to work with - I wish I could have shown a bit more of her stuff because it's all fantastic! Hopefully more soon (and maybe better image quality).

I've written almost all of the skeletal scene modes and all icon modes for each scene. A real ton of work! But now you can traverse through the entire world map. In some cases, I have to write handlers to prevent travel due to puzzles or other barriers, but this allows me to test loading and moving through each scene.

Samples of potential bugs:
1) Cannot load scene because I typoed the name - would be really irritating to find in the physical game, because I unload the prior scene upon loading the new one...
2) Cannot choose one or more directions to travel - I number the walking paths, and then on a scene-by-scene basis limit the number of potential paths to the number of different paths shown. Do it wrong and you can choose to walk in a direction that shouldn't exist (nothing would happen except the GUI would show an arrow that it shouldn't), or you wouldn't be able to choose a direction that you should.

There's lots more, I'm sure, but I'm being quite careful to prevent introducing them! Very difficult with the number of scenes I have!

Once those are totally written and tested, I have a rock solid foundation to start adding on different types of modes. For example, adding the look shot paths for each scene will be super easy.

Before I move on to that, I believe the next challenge will be combat. I have an interesting idea I'd like to try.

Let me try to describe it - combat happens on a screen:

1) Shoot the scoop on the right. Movement is disabled while combat has been initiated by the monster. Scene changes to show the fight.
2) Pop up the walls and scoops, then launch the ball.
3) Detect the ball hitting near a wall. If detected, have the character use a stabbing motion towards the monster.
4) Detect the ball hitting the side targets. If detected, have the character swipe.
5) Slingshots would allow character to dodge left/right.
6) Depending on character class:
a) Second tier of buttons would parry and third tier would use a stamina or health potion OR
b) Second tier of buttons would choose a spell and third tier would fire it off. Stamina/health potions would appear in this area as well.

I'll need to write special item handling modes for within combat, as the base level item modes wouldn't work. The cool thing about the P3's priority system for modes is that underneath, in the original scene from which the combat mode was fired, I can essentially override the switch hits and button presses for underlying modes (like changing items or icons).

You will not need to hit a shot to loot the corpse of the monster when finished. Day/night will still pass as normal while in combat, but 'R-E-S-T' will be disabled. Your stats, of course, play into how much damage you do to the monster. I believe the challenge will be in writing the monster AI. I want it to be challenging, but not impossible. Of course, you skills will improve over the course of your adventure.

Cool ideas! Many of the enemies in the game are non-human monsters that don't have armor, per se. However, all enemies have hit points. All enemies also have their own unique set of skills that will be rolled upon their instantiation in the game. In this way, if you fight a Cheetaur with a strength of 80, it's going to hit a lot harder than a Cheetaur with a strength of 60. Each creature will have a minimum and maximum set for each stat. My goal is to make each encounter totally different.

I'm not sure I could effectively utilize the armor idea - I'll talk to my sprite artist and see what we can come up with when he starts drawing those creatures!\

I definitely like the idea of hitting a single open scoop to finish off the creature. Again, I'll play around with it. Would be very frustrating to knock off the last of the enemy's hit points then get a bad bounce right into the drain.

There is a single spell that can be utilized to increase attack skill, but there is not a potion which would do the same, and I have all the artwork for those already delivered, so going back to the well would be difficult. :-/

And I very much appreciate the ideas! I think from a pinball perspective, Cheeks has a good idea there, sort of similar to the warehouse mode in Lexy, but with dynamically changing walls.

The combat would be quite different, but I could implement some really interesting light shows - chasing a colored light across all the walls... wearing it down from green to blue to red to none... I'm liking that more and more... but it will heavily depend on how much that extra artwork costs. My sprite artist is not cheap, and is not very quick, but he's good.

Trying to be good and budgeting for such things.

Ooh, that sounds interesting.

Well, I'm letting some design ideas for the combat solidify... I'm thinking something akin to a drop target sweep (on the side targets) would allow you to do double damage with your next attack.

Combat is going to be very tricky to implement as I don't have all of my sprites. So I'll need to do some placeholder/imagination stuff.

Now that I have walking working and bugtested in every scene, I am going through and adding the 'Take' shots. In most scenes, you're able to take something simple like a handful of rocks... but in certain situations, you are taking or touching something that is gated behind a puzzle, or only available at certain times of the day.

I am also trying to add the scene-specific logic for special functions. For example, there is a scene that starts a behind-the-scenes countdown timer if you head there at the wrong time, and if you don't perform some action, you die. Trying to knock that stuff out while I go, then I'll circle back and add the 'Look' shots. Those require me to slice and dice the narrator script... which is going to take quite a bit of time. Looking has the most narrator callouts, I believe.

Once that is done (hopefully by the end of the week?), I'll work on adding the talking paths. Talking is handled via an enabling shot, then a secondary shot to ask about "X". That requires me to sew up most of the remaining dialog, which will be a bit of a relief. There's lots to add.

Once all that is done, I've already begun the process of adding the main character animations. I'll need to add a handler into most scenes to allow the character to traverse the environment when you are walking... I'd ideally like the character to move briefly before changing scenes. I have my walking animation controller written, but need to tie it in programmatically. We'll see how long that takes... (I'm guessing a long, long time).

Then I'll likely swing back to combat before moving on to the 'Use' handler. That's the most complex handler for each scene and will require the most thinking and programming. But if I'm on a roll, I'll probably continue on with that too before moving to the scene-specific pinball modes and combat. Using items also has a lot of dialog.

I am also adding points as I go, but as I am changing puzzles slightly and various other small things, I need to ensure it's possible to get a full 500 points... I think I'm down about 4 points from the original.

Oh! I might have mentioned it earlier, but initially I rewrote one of the puzzles so that one of the character classes could hit a dead end and die during a puzzle sequence if they solved a different puzzle out of order. That couldn't happen in the original game, but I was thinking of removing one of the items. I figured out a way to make it semi-natural to include the item back in the game, and all should be well.

Semi-related note: I still need about 5 male voice actors. Either because I am unsatisfied with the performance overall of an actor or because I have added in previously cut characters. Aside from Nic (whom I will be contacting soon - I've got a specific part in mind for you), does anyone have a mic and need some hobby $?

I provide a script and direction on the type of voice I would like to hear. If you would like to participate, please send me a sample of your voice so that I can determine which role might best suit you, and we'll talk pricing once you've seen the script. Most of the remaining parts are not extremely large. I'm looking for a Brooklyn-type accent for one character, the rest I am more flexible on style of voice, but direction will be provided. My email is [email protected] -- your name in lights, just imagine!

Take modes are almost done - I have about 6 screens left that need some attention. Tonight I should be starting on the Look modes/shots.

Take modes, I thought were done, but my task for tonight was to split up the 20 pages of narrator dialog, and I've noticed several scene-specific take shots I need to add. I'll try to get that done tomorrow and start working on splitting the rest of the dialog audio. I might as well do everything at once if I am splitting things up in this way...

We'll see how long I last before I want to work on a different aspect of the game, haha!

Slicing and dicing dialog - I've got another three or four files left to go before I get back to heavy coding, but my sprite artist returned a piece today! I built the animation and put it in the scene - looks pretty good!

https://www.instagram.com/p/B9sjbihhFAT/?utm_source=ig_web_copy_link

I have spent a while learning about Blendtrees, which are really useful ways to animate something like an 8-directional series of animations. Using the built-in animation controller interface, I was building in relationships between 8 different states for walking, 8 different idle states, the default state, etc. It was a huge mess, and I knew there must be a simpler way.

I'm used to defining this kind of thing completely in code, so I started building the backend pieces into a script, but quickly learned that Unity, while it doesn't exactly -require- that you build it in the GUI, it really frowns upon building directly in a script if you touch any part of the animation engine.

Not wanting to give up the convenience of auto-building the animations, I decided to do a bunch of research, which led me to Blendtrees. Essentially, you can build two logical pieces in your controller for movement - an Idle state and a Walk state. Transitions between states happen by setting a boolean (in a script), and checking for that boolean in the relationship interface (the controller).

Then the blendtree allows you to set more variables (a couple of positional floating points). For each combination of positive and negative values on the X and Y coords, a different animation can be triggered. This is super powerful and cool! And it saves a ton of time!

So I got that working and then tried it out. Works well, but I needed an ability to know where to set the player sprite, and when animating, from which direction the character should enter.

So I built in a single event handler (which I have moved to the low-level graphical handler), and it can be called from each scene setup routine. The important stuff (coordinates for starting and finishing from each direction) are set on the scene setup. I throw the player sprite outside of the render area in case it doesn't get set properly, which will help me find bugs.

Got a little sidetracked this weekend, but animations were something I needed to do anyway.

Whew! Character walking animations are complete for every scene in the game. I'm now going through and adding the various Look interactions.

I also had an idea for improving the speed of switch processing behind-the-scenes. If you look at my last video, there are a couple of instances where a handler doesn't seem to fire though it is in the proper blinky mode for a thing.

That's due to how I am handling my child and grandchildren modes, and garbage collecting between them. I'm essentially driving them at a layer that is too low, which is causing them to be reaped and started over and over. Hitting a switch at just the right time would not fire a handler in this instance. I will need to significantly rewrite the handling of these things, but it will vastly improve the switching speed and reduce the overall workload of the game. I wrote the basics for the game before I really had a handle on a good way to do mode handling... and now I'm paying the price.

Just kidding - it's super satisfying to come up with solutions like this as it will definitely improve the game and make things much quicker overall.

Had a problem with certain scenes firing my entry walk animation twice... eventually narrowed it down to calling an underlying startgame method in my scene startgame method. Disabled that and all seems to be well.

The game is pretty bug-free (I think), so once I get all of the shots and callouts built in, I'll be going through and improving the efficiency as noted above.

I may do all of this before the next playtest, but I'm not sure yet.

I'll likely film a quick video to showcase the player animation, I was surprised at how much of a difference it made!

Oh and still don't have combat written, but it's coming. I have a good way to make the monsters move now, and then making them appear is going to be a roll of the virtual dice. 2d6 for night time.

So... many... callouts. Still working. Since not every screen has shots to hit for Look or Take or Talk, I have to keep a document to help me keep track of what I've already done and what is still left to do. Satisfying to add another to the list. I added the Kobold's Cave today at lunch.

Going to stream a current build in a few minutes! Join me, if you dare (apologies to James Willing)

Very pleased with the lack or horrendous game-breaking bugs. Go me.

Thank you to everyone that checked it out! Off to program some more (after some family time and a few more rounds of Heist)!

It's taken me 7 days to work through the Look shot modes? I'm still about 12 screens away from being finished. There's a lot of fine detail needed there, compared to something like dialog, as the dialog only appears on certain screens (though you can talk to yourself on any screen).

Use modes are going to take a very long time indeed.

I'm still working with the artists to achieve the look I want in certain scenes. The latest stream didn't show off as much of the custom artwork as I'd have liked, so maybe I'll change that once I have the base modes in place.

Without certain sprites, some of the work in scripting certain things within the game becomes much harder. I'll have to see what I can do. Still working away, but another game has really caught my attention for a little while...

https://pinside.com/pinball/forum/topic/heist-revealed-by-multimorphic

It's super great - getting a lot of play every day (check it out, if you haven't)!

Look modes are done! Now I am adding in the audio to the take modes before swinging back around to the Talk modes.

Both artists have returned some excellent work this week. I need to add their work and animations into the game as well. I hope to have most of this done by the end of the weekend, which will put me in a good place to start separating the final scripts and focus more on getting those recorded.

Take mode sounds are done - both sound effects and callouts. I'm working on talk modes now - after that, all that will remain are the Use modes for every screen. There's tons of interactions that -can- happen on each screen with different items. Talk modes will likely take me a while as there are lots of characters that have lots to say.

Looks like at this point there are 17 talking modes left to program - with 2 that still need voices.

I'll work on getting those scripts in the hands of voice actors today along with the remaining talking modes! I've gotten a few written this morning... lots of work.

I was wrong, there were 20. I got through 11 today, with recording one of the last character voices (a third set of characters that speak together that I didn't mention above - my wife and kids are the voices!). 9 left, 2 that still need voices. Spent more than 15 minutes troubleshooting a switch handler that I wrote with the wrong number of parameters. The exception told me the problem (mismatched # of params), but my eyes disbelieved as I had written the handler to expect mode-to-gui params. Just a dumb mistake, but I dislike losing time to something like that. Inevitable, though!

Most of the remaining modes require multiple phases of dialog. For example, the gargoyle that requires you to answer 3 questions before you can visit the wizard, Erasmus... should be fun, and in fact is next in line.

*Edit* 8 left.

7 left - there is a bit of an art form to splitting these callouts up. I am trying to ensure that the game flow is not interrupted for too long, but I am consolidating some of the dialog to prevent a player from having to hit two or more targets to get a full callout.

One of the modes I am most excited about creating is the dialog from Erasmus the wizard. Erasmus is an... eccentric wizard that lives at the top of a large mountain. He thinks he's very funny, and tells pretty awful jokes. As with other similar modes, every so often the wizard will tell you the beginning of a joke, wait a while, then tell you the punchline. It should be pretty fun. I've written some similar dialog modes in the bar, where the butcher and baker are playing go fish with a deck of old maid cards... In the original game you can guess the punchlines. If you do that enough, he gets mad at you and will teleport you to the bottom of the mountain. In the pinball, I thought that would be too punishing, so he'll tell his jokes without the disincentive.

Split up and sent off a few animations yesterday to be redone.

*Edit* 6 left.