Builder Blocks: An item matching in-world minigame

[MirceaKitsune]

I managed to create this during the past 5 days, which is the only thing I find scarier than the fact I managed to make it at all. I'll start with a little background on what I wanted to do and why.

I felt that TDM was in need of some kind of playable minigame. Not just because its beautifully flexible scripting and gui system makes it so inviting to code one, but I feel it makes missions more pleasant to go through. A lot of AAA games add complexity in little details to make them enjoyable. During a normal mission in the 3D world, players find brief minigames or side activities to distract themselves and take their mind off the main objectives, after which they resume playing the normal match; This gives the world a nice effect and makes it feel more wholesome overall. I'm presently working on a FM that will feature interactive city hubs, this is one of the things I wanted to have to make each city feel more alive.

Onto how it works: This is a pk4 mod you can download and drop in your FM to enable the minigame. The prefab mechanical/game_blocks.pfb contains a functional arcade machine, the entity itself is static/mechanical/atdm:game_blocks. Once you've placed an arcade in the world and compiled your map, simply approach it and frob the screen to bring up the overlay and start playing. It's an item matching game with simple rules: When 3 or more items form a lump their group is cleared and the player gains score, the more score you gain the more items you unlock, however the game gets faster and more difficult. You use the movement keys as follows: Forward to disconnect from the device (un-frob and regain control of the player), backwards to project the active item to the ground when you don't want to wait for it to fall, left and right to move the active item. From here I'll list the important highlights individually:

• One advantage is that in its current form, the game uses no custom assets (images or sounds): Everything is achieved using the vanilla graphics and audio exclusively. The only three files are a def, a script, and a gui... the prefabs for the default in-world device is also included. Hence why for all the complex functionality it achieves, the pk4 is just a ridiculous 17.0 Kilobytes!
• The game is highly configurable using spawnargs. From the game rules to the items and background, most aspects can be customized per-entity. This means arcade on the map can have its own rules for items, scoring, leveling, not to mention its unique appearance! See the def and the editor descriptions for info on each spawnarg.
• The game is meant to interact with the world via targets. You can use multiple trigger_on_* variables to activate objects in various circumstances. This includes starting or ending a game, leveling up, reaching a specific level, or beating the default high score. The later can be used to open a door that's only accessible if you beat the game.
• I made full use of the gui system. The game is normally played on an overlay, however the entity represents a screen (textures/darkmod/decals/signs/decal_gui plane) which mirrors the same interface. This lets you see your paused game in-world when you disengage the device, even watch the items fall at the edges of the screen if you're facing the right way. There's even a spawnarg to disable the overlay and play only on the world surface, though turning off the overlay isn't recommended as it's much harder to see detail on the surface.
• Other than the script and entity which you can use with your own geometry, I also created a prefab containing a fully functional arcade game ready to place on the map. I tried making it interactive and operable by adding other in-world entities in the mix: You have a side door which can be lockpicked to give you access to the power button, which lets you turn off the device or reset an active game. When beating the high score, the other utility door will open and give you access to some loot. It also contains details like spinning machine gears, refractive glass screen, even a short-range projector for light emanating from the screen... all are toggled on and off with the device. Despite arcade games being a little questionable for a steampunk world, I stylized it so it looks fitting for the environment. Lastly there's a broken (unplayable) version of the prefab which you can add as an accompanying decoration.

I'm eager to hear your thoughts and what you think. If you like this minigame, the best way to support the work I put into it is to include it in your FM and use it, I would enjoy that the most. I'd be happy if it could be included in vanilla TDM in some form... not just because I'd be humbled to have contributed my own creation, but I feel it would benefit the default game to have this accessible to mappers. I'm happy with the base entity and functionality which I think is as good as it gets... beyond that it might need a better model than prefab, perhaps someone could help with creating one? Feel free to look at script too and let me know if you feel it's coded right, if it's something easy I might further improve it.

Important: When placing the pk4 in your FM directory, be aware that any existing tdm_custom_scripts.script will either override or be overriden by the game's and break stuff! If you're already using that file, edit the pk4 to delete it from there, then manually add the following line to your existing FM's:

#include "script/tdm_game_blocks.script"

And here's the pk4 of the initial release as of today, as well as some screenshots of how this all looks so far. Wish TDM had a builtin recorder so I could share a video as well.

game_blocks_1.1.pk4

Edited July 24, 2021 by MirceaKitsune
Updated to 1.1

[MirceaKitsune]

Unavoidably there are a few bugs. I'll need to release an updated version but would like to cram as many fixes as possible first. Please test and let me know!

I was informed that save games might be broken. That's weird because I tested saving and loading, under both the simple test map and my already complex FM: No errors and the states of active games are remembered too, didn't even need to add any save / load handling to the script. Is anyone else getting this error or similar?

ERROR:Error: file script\tdm_game_blocks.script, line 14: 'game_blocks' : redef
inition; different basic types

That line is the standard object definition (object game_blocks) as done in every other script. Why would the engine feel that anything is being redefined?

Other than that I noticed a few crashes and rare gameplay glitches myself. Will try to fix them today.

[Dragofer]

Nice work! It's like you've packed an FM into that machine I think it'd also have potential as a good generic machine prefab with some variants, possibly taking out or replacing some of the more arcade-machine elements like the overhead arch.

Feedback-wise from here:

- the screenshots indicate that the parchment texture is a little too small to fit the game, would be worth stretching that GUI window.

- saving and loading problems generally occur when a scriptobject is stored within a map script (so i.e. nameoffm.script next to nameoffm.map, instead of script/game_blocks.script) or when a script is called from the console. There are also functions that can be added to a scriptobject to Save or Restore, though I have no experience with when that may be a good idea to have.

- "game_blocks" doesn't occur in core .script files, so the only thing I can suggest is that you might have a leftover .script file floating about in your base install or in a .pk4

[MirceaKitsune]

Finished a bunch of important fixes. Please discard the rushed pk4 from last night and download the new one, updated in the first post. Notable changes:

• Fix sound cutting off when items are falling too rapidly, by making proper use of sound channels for each event audio.
• Saner way of scanning for entity keys when spawning new items. I'm hoping this prevents a rare crash I got once citing a possible infinite loop .
• Improved the scoring mechanism a bit to better handle clearing multiple items in a row. Shortly after posting I've ran into an edge case where too many items got cleared at once and suddenly added 3 million score with hundreds of levels on the old calculation. This is hopefully no longer possible.
• In the process I further refined the default balancing to make games last a little longer and be a bit gentler on the player before turning impossibly difficult.
• When the device is turned off by a button, the entity is no longer rendered completely invisible, the root GUI window is hidden instead. This allows the entity to have a full model containing textures other than just the screen... toggling it will stop showing the screen without making the model pop out of existence in the process.
• Added credits and basic license information in a top comment. The code is obviously GPL licensed in the way compatible with TDM.

Edited July 24, 2021 by MirceaKitsune

[MirceaKitsune]

29 minutes ago, Dragofer said:

Nice work! It's like you've packed an FM into that machine I think it'd also have potential as a good generic machine prefab with some variants, possibly taking out or replacing some of the more arcade-machine elements like the overhead arch.

Feedback-wise from here:

- the screenshots indicate that the parchment texture is a little too small to fit the game, would be worth stretching that GUI window.

- saving and loading problems generally occur when a scriptobject is stored within a map script (so i.e. nameoffm.script next to nameoffm.map, instead of script/game_blocks.script) or when a script is called from the console. There are also functions that can be added to a scriptobject to Save or Restore, though I have no experience with when that may be a good idea to have.

- "game_blocks" doesn't occur in core .script files, so the only thing I can suggest is that you might have a leftover .script file floating about in your base install or in a .pk4

The user in cause clarified their issue was related to tdm_custom_scripts.script, most likely the script got included twice or a savegame saw it as such. It's an annoying limitation that you can only have one custom scripts file per FM yet need it to include scripts as they aren't loaded automatically, so if your FM has multiple such addons you need to edit them in order to maintain a singular tdm_custom_scripts which includes everything.

Like I said saving and loading of savegames seems to work for me: No errors and you can resume the game as if nothing happened... even if you didn't pause it the game loop function will continue upon loading. I take it TDM already knows how to handle all kinds of scriptobjects scenarios since it does a great job here.

As for GUI stretching, I did my best to maintain the aspect ratio and use a background fitting for the window size. A little complication though is I'm using the same GUI definition for both the overlay and world surface, it seemed messy and unnecessary to separate them. However the player's screen has a resolution of 1920 x 1080 (nearly 2:1 aspect ration) whereas the screen on the arcade is typically square if not stretched the other way around. What I did to fix this was to make the GUI surface cut through the screen in the prefab and eliminate some border, though this is kind of a hack I don't feel most proud for using.

[Dragofer]

@MirceaKitsune
To me the 2 GUIs look the same - same format, and both just a tad too short. Can't you just increase the vertical size of that GUI window?

Debugging crashes is worlds easier when you can build yourself a debug build, showing which entity and which function was the problem. It's pretty easy to install, pretty easy to compile a new build (open the code in Microsoft Visual Studio, select "Debug with Inlines" from a dropdown list and press F7) and would probably have a high payoff for someone scripting as much as you do:

TDM Compilation Guide

[MirceaKitsune]

I might still be able to compile the engine from scratch if requirements didn't change... not sure if I tested that after switching distros from openSUSE to Manjaro but hopefully it still works. Will check again if I get more crashes, as of today's patches all seems to be fine for now.

As for the GUI they are indeed the same. I didn't want it to fully fill the screen even vertically, so you could still see some of the world behind it. But I use a fullscreen tint effect behind the main paper sheet, both to darken the world (similarly to readables) and I also apply a brightness tint (customizable from the def) to simulate screen glow and match the light emanating from the screen surface. The standard base setting for the main window is 640 x 480 so I left it at that (those numbers remind me of the Windows 95 days).

Another thing on the GUI: I set it up so the main window size is based on the number and size of item icons, you can resize everything just by changing the size of the grid item. I settled for 24 x 24 for which looks best for icons, so the paper background auto-adjusts to 8 x 24 horizontally and 16 x 24 + 2 x 24 (HUD space) vertically.

Edited July 24, 2021 by MirceaKitsune

[MirceaKitsune]

Looking for more feedback on this as well, please help test it! Anyone tried the arcade so far in your FM? Found any other issues? What do you think about it and the current functionality? I'm hoping the gui / def / script at least can be included for 2.10, this would be a fun minigame to have available for mappers by default.

[Dragofer]

On 8/7/2021 at 4:57 PM, MirceaKitsune said:

I'm hoping the gui / def / script at least can be included for 2.10, this would be a fun minigame to have available for mappers by default.

It's an interesting idea and impressive that you got it to work, but we're kind of split on this for a couple of reasons:

- as you say, an arcade game is somewhat questionable in a steampunk universe. I can definitely imagine a situation or two where it would seem fitting, such as the recreational area of an Inventor Guild compound, but those are somewhat unique scenarios.

- testing is another matter. It's a technically complex asset, and as you've said it's crashed a few times. I think it'd be best if it featured in an FM first, since you'd have a good amount of players with a variety of PCs and approaches try it out. It should also result in feedback on how a minigame like this can be integrated into stealth gameplay.

[MirceaKitsune]

9 hours ago, Dragofer said:

It's an interesting idea and impressive that you got it to work, but we're kind of split on this for a couple of reasons:

- as you say, an arcade game is somewhat questionable in a steampunk universe. I can definitely imagine a situation or two where it would seem fitting, such as the recreational area of an Inventor Guild compound, but those are somewhat unique scenarios.

- testing is another matter. It's a technically complex asset, and as you've said it's crashed a few times. I think it'd be best if it featured in an FM first, since you'd have a good amount of players with a variety of PCs and approaches try it out. It should also result in feedback on how a minigame like this can be integrated into stealth gameplay.

TDM is in an interesting position world wise: It's meant to take place somewhere between the 1600's - 1800's but not in a historically accurate version. Apart from having undead which don't exist in real life (as far as we know ) there are many technologies that didn't exist at their time, envisioned as they would have been if they did. One thing that inspired me for this was the inclusion of the automaton AI, along with other beyond-their-time inventions like the steambot or camera: I figured another exception wouldn't hurt... long as it matches the style, hence why I decided against a retro background or 8-bit music but left it looking more like an interactive paper (who knows how they built the device). Though as a mod for this mod, I might make one with custom assets such as pixelated graphics and 8-bit tunes, for just those FM's that wanna go there.

Including it with a FM first sounds like a good way to test. I'm working on one which will likely feature this asset by default, but it's still got a long way to go and will be released later after 2.10. Only FM I actually got around to releasing was Scroll of Remembrance, which I've been thinking of redoing due to the horrid performance and the fact that I didn't monsterclip anything as I didn't know I should at the time; Maybe I should take the opportunity to throw one of these machines in there? In the meantime, if anyone's working on a FM where they feel this might be fitting, do feel free to include it!

[kingsal]

That is very cool and very impressive!

Right now it would be a lot of us to take it on for 2.10, but getting it in a mission would be awesome and prove out a bunch of stuff before going into the mod. I'll download this though and do some testing and play around with it when I get a chance. 

 

[MirceaKitsune]

2 hours ago, kingsal said:

That is very cool and very impressive!

Right now it would be a lot of us to take it on for 2.10, but getting it in a mission would be awesome and prove out a bunch of stuff before going into the mod. I'll download this though and do some testing and play around with it when I get a chance.

Yes, likely too early of a target. 2.11 might do hopefully. Hope to have it stable enough and tested to use in FM's soon.