Stayed up way too late again last night, but now down to 10 remaining animations to place and script. I've placed dozens and dozens and scripted them all as I go. Hoping to get through a chunk of those tonight, then perhaps tomorrow starting on audio for that extra bit of feedback that I mentioned.

As it sits, I've been re-playing each scene (building up my save files so that I have the appropriate items to trigger the animations), and it's pretty great to see the world come alive due to your actions.

There are some items which I could really splash out on when I have the budget (that didn't exist in the original), like idle animations for every character, but in every case, a static sprite is better than none.

Final animations were added (some are a bit clunky until I pay for new ones to be made), and I have a list of about 10 sound effects I would like to add for various situations.

Once that is complete, the game is done (pending new artwork). Work on my next game begins in earnest this weekend!

Thanks luvthatapex2 - I think it plays pretty well! The basis is Lexy's playfield layout, which I find super challenging and fun to shoot, so that part is excellent. Moving between screens is very easy now that I have mapped that to a point and click type interface, and shooting the appropriate shots to complete a puzzle or otherwise progress is quite fun.

The skill progression takes a bit to wrap your head around, if you're a new player (from observations of my family) - hitting a shot dead on doesn't necessarily guarantee the reaction you expect if your level is too low. Where that happens, I've tried to ensure that callouts fire to alert you that you've failed. The character sheet is pretty important to review as you'll be able to see at what skill level you were able to accomplish the task.

Combat is also fun, but in a different way - there is a huge sense of urgency as the monster or villain will occasionally smack you. Your consumable stats are also tracked and will refill only upon resting, but resting is not available in some scenes. Paying attention to inventory/spells can help you out in a jam.

I have also reduced the number of dead ends in the game to 2. One of the unwinnable circumstances only occurs to one of the character classes, and you have to do something without thinking in order to run into that one - the scene in which it occurs is also optional.

The animations really add a lot of heart to the game. It makes a big difference seeing a variety of characters moving around.

I'm going to hire my background artist, hopefully, to draw apron/score/instruction card artwork. Describing how to play will be quite difficult at shows.

I haven't gotten that far into the game on real hardware yet, but mostly that is due to the bugs I've run into on physical builds of the software. Now that I've been through the game in the simulator many multiple times, I suspect things will work a bit better.

I'm looking forward to playing it again physically soon, and seeing if the mini-monitor functions properly, and two of the optional scenes in particular. The optional scenes are quite neat and should be a lot of fun to play.

I've officially(?) finished the heavy development phase of the game as of about 2:30 this morning. Now it will be fixing physical interaction bugs if they occur in testing on the real hardware.

I'm taking a short break for part of today, then will begin on my next game.

Received another six pieces of background art today.

Here's what's involved with placing that art:
1) Export file and associated scene elements from PSD to individual PNGs
2) Open scene in Unity
3) Import the PNGs as 2D sprites.
4) Expand GameObject tree until I find the background
5) Drag over the PNG for the background and make separate GameObjects for any other items that the player's avatar needs to move around.
6) Add scripting to enable/disable those separate elements if needed, and tie to specific actions.
7) Add scripting to handle the walking animation paths and shift around arrow indicators or whatever other elements might need to change.
8) Determine if there are any issues with the delivered file once in the game. If so, speak to the artist and ask if changes are possible. The big one is walking paths. Exits/entrances have to be mostly visible, if possible. Sometimes I can determine this before placement, other times, not so much.

BabaYagaInterior (resized).png

Spent lunchtime today adding those interiors I mentioned. Above is one of them, the interior of Baba Yaga's hut! Baba Yaga is one of the most dangerous characters in the game - in folklore, she is a very powerful witch that eats people. Not someone you want to toy with, but here you are, within her stronghold!

The game allows you to place yourself in many dangerous situations such as this, and it's up to you to find a way out. In some cases, perhaps just listening is enough. In others, specific items must be used in specific timeframes.

When within her hut, I do not allow the game to be saved, as you could easily get stuck that way.

I've spent my scant development time to port QFG to the new version of the SDK Multimorphic released yesterday.
The new SDK added a lot of really great profile options and Bluetooth pairing support, so I wanted to get that integrated ASAP.
Everything works well now, and I reviewed another set of images from the background artist. After these latest revisions, only five backgrounds remain!

After the last images come back, I'll be testing again on real hardware and we'll see how things go!

Wrong game! Made a post about RITR and put it in the wrong thread. Need to pay more attention.

Final set of art deliverables were received today, and I've requested a few modifications. Once those are returned, I'll integrate them and then QFG will be finished? It'll need to be tested after the huge raft of improvements on actual hardware. Assuming that goes well, it'll be time to send a video and letter to Activision.

So a question I have is: how many of those following this project would download and play it if it was free to download (assuming Activision granted rights to freely distribute) in some fashion? I have a potential plan that might be more palatable to the lawyers.

Haha, I would love to, but to clarify, I want any distribution of the game to have the full blessing/approval of Activision/Blizzard.

Regarding final assets - the revisions were received this morning! I'll be pausing my work on RITR to implement these, then will do another build and likely stream some gameplay.

Still trucking through the various screens. I have... 10 left (5 complete). I am thrilled with the quality of the artwork, she really did an amazing job.

Each screen requires various custom bits of programming (item interactions - the houses you can burgle are still left, yikes!), and lots of fiddling to make sure your character is not rendered on top of or behind a part of a sprite.

Fiverr - I went through a few before I found one that clicked. She has been the background artist for the entire game.

That site has a huge talent pool (and a lot of people trying to make a buck). When you find the gems it's worth it, but you have to be willing to put in the work and fire contractors if something's not working. Overall, I've been very pleased with the quality of the work from the people I've contracted with. The harpist and background artist in particular!

There are a few voiceovers that I will have re-recorded. They are acting as placeholders currently, for when I have time (one day).

It's no different than being a general contractor, in my opinion. Sometimes it's just not a good fit! Nobody's fault. I always try to hire for something small and reasonably priced to see before really committing (as is the case with the art). That way, you can part company nicely - I discuss scope of work without promising anything, and provide honest feedback, pay agreed, and a tip, even if I don't like the work. That way, if they happen to be a fit in the future, it's ok to start a conversation.

Musicians are a bit easier than art in my opinion, as almost all have samples of their playing recorded on their own gear. Almost all. Be sure to listen to all samples and use the messaging system to ensure you're getting what you want. Every contractor except for one has been really cool - and that guy might've just been having a bad day. One even told me that he was excited to play it at a show one day!

7 screens left!

Just built version 0.9, which has all of the backgrounds and new programming to go along with it. I've also improved support for the custom high score tables/loader that I use in the instance this ever does become distributable.

Barring any new bugs or issues with the light shows or mini display, I think this is pretty well done!

Some things have happened in the past 60 days...

https://www.multimorphic.com/store/p3-game-kits/3rd-party-game-kits/ranger-in-the-ruins/

My first commercial game was released!

In the effort to get that game prepared, I've learned several things about making a pinball software package production-ready.

I am going to be working to add these things to QFG, when I'm not working on a new game...

Thanks @zimjoe!

I spent today applying a smooth fading method to every scene (between some work on the new game).

Now the game -looks- much more polished.

I'm going through and adding some other production tweaks and tricks I learned.

My launch failure routine needs some tweaking (if it fails to launch on the right - default - it should launch on the left, but it's just trying right over and over).

Also, in going through each scene, one doesn't have the new artwork! When my cheapo development computer crashes, even after I save the scene in Unity, sometimes I'll load it back up and notice stuff has been reset to the previous state. This is a pretty annoying occurrence that I'd written off as not saving frequently enough. However, I have really good saving habits. I don't know if there's some kinda delay in writing to disk, but regardless I'm pretty irritated.

Aside from that, there are a few quirky things which I'll see if I can resolve - Unity animations sometimes wiggle when rendering certain frames. I've not been able to figure out why, so there are two animations in particular that shimmy and shake. I'm still on the lookout for a couple of male voice actors to replace myself for one character and one professional voice actor that just couldn't dial in a good performance for another character.

I'll get that stuff set, then it should be ready for my toughest critic, Ava, to play. Assuming I haven't made any really dumb mistakes, hopefully she'll get to play pretty far into the game.

One thing that I've kept a bit mum about is coin play. I imagined this would work like a quarter-munching brawler of old. To continue your game, play off a credit. From an operator's perspective, this is a much better value proposition for a pinball, wherein the game awards skillful play by allowing the user to progress their character further, but any misstep requires additional payment. From the player's perspective? The hook is the adventure. Seeing 'what's next' and trying to figure out puzzles, make shots, etc.

For the operator? The hook is in having multiple passionate players interested in seeing the game through to completion. There will (hopefully) be groups that decide to throw in together... and I would suggest that that is a good way to experience the game, as you can work through the puzzles together.

Also worth noting that there is a replay factor even for those that have already finished the game - there are multiple solutions to most puzzles in the game - and each character class has their own unique methods for dealing with the obstacles in the game.

Some scenes are only viewable by some character classes as well, and players will enjoy finding the paths to the maximum points within the game. Unlike a traditional pinball, where points accrue during normal play, a player that succeeds at solving puzzles achieves greater scores. Some puzzles provide a bonus if solved as you would for your character class... for example, a thief might not take the most direct approach, but a subtle answer to a puzzle might provide more points than charging in guns blazing (like the fighter).

Added persistent credit display to the playfield and backglass LCDs. Next to add credit awareness to continue/restart.

In order to handle coin play properly, because I am overriding some really basic behaviors, I have had to write something custom. I am in the process of doing so, and hopefully will have some good news over the weekend!

I've got handlers to handle increment/decrement using the standard coin pricing menu items, bonus credits, etc. One of the cool things about the P3 is credit persistence. Meaning, credits are not lost once the app has exited. My implementation cannot do this, so I am still thinking about how to handle this. If I can crack that code, I can also reduce the number of handlers I need.

I worked today on my coin methods and testing to ensure that starting a game from attract, coining up, and handling free play all work.

I still have a few more things to work on regarding coin testing:
1) Sounds when coins are added/attempting to start a game with zero credits
2) Changing to/from free play in settings menu doesn't update credit item (a recent change may have fixed this).
3) Updating credit display is an event that is fired from each scene. I need to add the event to each scene's SceneLive method. I have experimented with putting this in a more centralized location, but because I am pulling attributes from the settings and the settings are not initialized before the game bootstraps, I have to push the 'pull' downstream.
4) Calling my new handlers in the death selection mode. These handlers handle everything from calculating the number of bonus credits you should receive to decrementing the credits. Since this is centralized, once I have this added once, it'll work on every scene.

I also took a photo of the Lexy playfield from above, something I should have done ages ago.

I add this as a special prefab, and on each scene, I drag it in to help me align the arrows pointing to various targets. I've so far aligned the target indicators for the first scene... and now I know why I was putting this off... It takes quite a while, but of course gives a much more polished appearance.

That said, I'm not quite happy with how the indicators and fonts appear - in order to fit all dialog options on screen, I have to shrink the indicators. When I do this, I have to shrink the text. I am toying with the idea of completely revamping the communication system (other than a vanishingly few instances in other types) to allow a choice to by cycled through by the player. The problem is communicating this to the player. I'll keep thinking about it.

I was having some issues with a massive slowdown at certain points - well, it turned out I had much more thorough debugging enabled than normal.

Simple stuff, but necessary to correct.

Tomorrow I hope to add the image for the Ogre's area, and perhaps build another test version if I get the above items addressed.

I've been working on this game every day, at least a bit.

I built a test version and excitingly/embarassingly, Ava hit several bugs in quick succession. The good news is most are/were pretty simple.

One of my favorites is that the game would lock up when you were a thief and tried to switch to Use mode on any screen. Yeesh. There are two lockpicking items in the game, and I was checking for the currently selected item to enable the lockpick modes on any screen (and unfortunately, you can use the lockpick on every screen), and if you didn't actually have the second lockpick item, the game would crash. Smooth. All fixed, though.

Unity is a very powerful/flexible engine, but one of my cardinal rules is to execute as little as possible in the Update() loop. This is a great way to introduce performance problems into an otherwise very performant game.

So, in order to jam through coding as quickly as possible, I ignored this rule. Each callout was monitored in the Update() loop, preventing arrows (inserts) from flashing. Well... this isn't super great. Mostly because when it does this, it's actually checking and adding/removing modes once per frame. It worked, but it's not great.

The smarter way to handle this is to write a coroutine that checks for the active audio and prevents those arrows from appearing. Unlike in a traditional pinball game, QFG has a variety of shots with callouts that the player needs to hear.

Of course, this presents another problem... how to handle situations where players cannot hear. Especially those that are hearing impaired. I've thought about a way to present this information on the screen, and will likely be working to add it once I finish updating the Update loops on all 70 scenes (I'm not very smart).

While the player -can- connect bluetooth headphones and listen to the callouts this way, I feel this will provide some much needed feedback on the shots. I've been adding some light shows and tweaking things to provide more feedback, but I have been concerned that these efforts are not enough. There will likely be some awkward corners that will require some kinda intense testing - there are many many branching paths in the game, and the callouts change subtly depending on who is on the receiving end.

Anyway, another thing I need to do that is similarly tedious (but necessary) is preventing the player from expending all credits by jamming on the start button a billion times while a game is currently started.

So I've slept on this next issue and think I've come up with a good solution.

One of the problems with this game is that it is unclear what you are supposed to do and how you are supposed to do it. Another problem is that for modes other than walking, you can hit any lit target to get the indicated call-out.

When there are a dozen shots that provide a separate call-out, this is a problem. The likelihood that you will hit the wrong target is much larger than the likelihood that you'll hit the correct one. While in a normal game, that's fine, as you achieve something for your flubbed shots, in QFG, you get nothing.

So a few changes, influenced by the changes to walking and the issue noted above where I'm having to resize indicators in a pretty crazy way.

1) in any mode except for walking, the game allows you to change the item selected by hitting the yellow buttons. This change doesn't actually matter unless you're in the USE mode. This is entirely useless, but I implemented it that way to provide consistency.

I am going to change this to allow you to select a shot in any mode except for use by pressing the yellow buttons. There are some timed events that might cause a problem, will need to test.

2) there are no specific light shows. One thing I've added is a generic show that executes when you hit a shot. It'll blink an insert light, then go back to a solid color. While I like the solid colors, if I am controlling the shots you are calling, I can flash an insert on the shot you need to provide additional context.

3) I will be adding context-sensitive text to the game that will enable/disable when you are within a call out. This will direct you which buttons to press and what they do. This eats a bit into the screen real estate, but I think worth it so that you won't need Nick to explain how to play the game. Especially ESPECIALLY important on class specific scenes like the dagger game or mage's maze.

4) pop up text will explain what shot is active as you switch through them. If there are no shots available (perhaps you've TAKEn everything on the screen or the people you could TALK to have left due to time of day or day of game time) the game will inform you.

5) MAYBE - I'm considering, again, adding a separate scoring system for players that don't hit the shots. Even something as simple as only incrementing a counter when you hit the wrong targets would be fun and provide something about how skilled a hero you might be on the high score table. Easiest way might be to add a shot counter and increment on bad shots.

Of course, the above has downsides. Namely, the game becomes even more of a sharpshooter's game. I don't think this is actually a bad thing as many shots are clustered tightly together and getting the flash feedback when you hit the wrong target will help you understand how close you were to the correct shot. This is where adding a separate scoring system has big advantages. The player won't feel robbed by poor performance.

While the game was complete/complete able as it was, I want it to be a good pinball game, and not just a port of the adventure game. This requires me to be willing to rip up the floor boards and start over in some ways.

While I'm changing things, I am also working on a generic way to handle achievements within the game. One of the issues I had with the scoring is that it is not obvious enough that you've done a good thing.

Now I will slide up a little window that shows one of three icons and some descriptive text about the achievement you've unlocked. On the first screen, talking to the Sheriff gives you a point. Though a little sound plays, having an animated visual indicator is important to draw the player's attention.

I've added the generic trophy/achievement/congratulations system! It pops up a small window towards the center of the screen, informing you of the number of points you were awarded, and giving you a little joke or note as to why.

I've also added in a two generic text areas:

1) towards the middle of the screen - this one informs the player of which choice is currently selected within a mode (Hit Left Side Target to Look at Inn).
2) Between the slings - this one informs the player of mode-specific instructions (LOOK MODE ACTIVATED - Press yellow buttons to choose option, hit indicated target to Look).

I'm still struggling a bit with how to handle the walk mode, which is the only mode that works differently. Should I go back to making it a called shot? If so, using the same setup as the other modes will make it much more easy to understand. If not, should I switch the button to change destination to the yellow buttons, and the confirmation to the launch button?

Since I have all this extra real estate now, I am stretching out and enjoying the space by increasing the arrow indicators to a standard width. That helps immensely with the look + feel.

I am also adding an outline to each text item, and am considering changing the color of the text to white to make it more legible in all color conditions (there are no white scenes). Since the popup text fades after a brief time, I don't want to rely too heavily upon the player remembering what it said. Especially because there will be some that don't read it.

I also need to add a set of intro texts like I have in RITR to help explain what the heck is going on when you first start... not sure what form that will take yet, or if strictly necessary. Still pondering.

Hoping to have the majority of additional development done near the end of the month, but that's wildly ambitious.

It's been a long time since I filmed anything on the game, so I'm not sure if the last stream shows the new walk mode or not. I like sharpshooter games as well, and I like the idea of providing -something- if you just can't hit the shot you call.

Where this becomes problematic is that movement through the game is crucial to progression. You have to quickly and effortlessly move from location to location as you play. You are correct that a balance is necessary. I think, based on that, I will switch from flipper buttons to yellow buttons to change walking path, and launch button to confirm. Sometimes it helps to talk it through.

I am very very slowly going through the other scenes. So far I'm up to two!

I have added a couple of spaces on the screen that will hold mode-specific and shot-specific text. Now, when you swap through modes, and swap through shots, it will pop up instructions. I showed my wife last night (she liked the achievement popup), and she said that it might be better to just have a tutorial that played for a bit before you gain control. I don't really like that idea for a couple of reasons:
1) it's not that hard
2) displaying that text will help with lapsed players.

Her concern was that it temporarily hides the beautiful artwork, but I think it is most important, for a pinball machine, to make your goals very clear (and not just make a game for myself). There may be a happy medium of changing some of the text to graphics, but I think the text is fairly clearly written.

These changes require, quite a bit of programming on each scene. I've made a series of changes (for the better) in the first scene, and backporting those to the other scenes is just going to take some time. I think my estimate of end of the month was way too optimistic. I've done two scenes in about a week (but a chunk of that was figuring out how I wanted to do this on a lower level.

Once I finish the changes, I will go back through and add light shows. I have a special dynamic light show that is going to be added to each shot. Then I am going to add the flubbed points and handle the high score table additions (remember I made my own). Lots to do now!

So I changed my mind because I am capricious.

I added the flubbed points handlers because I realized that I needed to add this to every shot in the game for the high priority shot modes.

I am still running through the various scenes within the village. There are a healthy variety of things to do for each main game mode in the screens within the village, so it's a good test case of all the changes I am making.

There are 70 scenes total, but the village comprises 11 scenes:

Jail/Entrance
West of Entrance
East of Entrance
Alley
Guild Hall
Magic Shop
Sheriff's House
Bar
Thieves Guild
Thief House
Dag-nab-it.

I've got the first four updated, and am now working on the Guild Hall.

Once I finish going through every scene, and every mode and submode of every scene, I'll need to loop back around and do it all over again to add in custom light shows. Next, I'll add the new flubbed shot high score table(s) (there should be two) then loop back through and add achievements for all puzzle points. Finally, I will add a variety of secret achievements.

Once -that- is done, I will be able to retest the game, undoubtedly find the billion bugs I introduced, then fix those.

Actually quite a long road ahead, now that I lay it out like this, so... yeah, end of October was insanely optimistic.

Getting faster, maybe? I finished the Guild Hall yesterday and finished the GUI and base mode for the Magic Shop today. I should be finished with the Magic Shop tonight, then will hopefully make really solid progress over the weekend between other things. Who needs sleep?

The Bar is enormous, tons to do in that scene and lots of variability with regard to previous actions within the scene. The Alley was similarly complex, and I am kinda dreading the Bar, but it's got good music, so there's that!

Wait, is that a thing?

well, for one day anyway.

Only 3 scenes remain in the village. Whew! Lot of work! Testing in the simulator is really an improvement, though. I will be pleased when everything is updated. Quite a ways to go, but most of the complex dialog trees happen in only a handful of scenes outside of the village, so this is a big chunk of the work.

But I'm going to switch to a new project for today...

Village complete, now working on some of the external scenes.

I did push a build to the P3 and tried it out yesterday.

Couple of bugs:
1) Game crashed when a ball returned to trough from the UFO after a game was over. Looks like I need a handler there in attract...
2) I'm experiencing a weird 'hitching' after the intro is played in any given scene. I haven't debugged this much - depending on the timing, flippers work and if the ball is in play for about ~4 seconds, all is well. However, if not, the ball drains and switch handler doesn't fire. Very weird as I don't have any kind of looping going on that should cause this to happen. Obviously something is up, but I'm hopeful that it's a general issue that can be fixed in every scene. I might be firing a generic introcomplete handler... and haven't followed that to its conclusion. Should be easy to find. Reviewing logs shows nothing.

Other than that, I did have an improper game save in the magic shop. The game saved the Guild Hall, but loaded the Magic Shop. Weird issues with loading the game after dying.

The fading image appears over the death box, so I will need to reorder stuff a bit in my prefabs (pretty small stuff).

My light shows work in proof of concept, but need a lot of refinement. I am not centralizing shows, which causes some minor errors with expected colors and such, silly issues.

I'll have that fixed up relatively quickly once the scenes are all rewritten.

Playing the game is cool (I think)!

Quite a lot of coding still taking place. I had a big project at work that slowed me down a bit last week, and this week will be a little touch and go, but I was able to finish another couple of scenes at lunch today.