Halloween beckons. Don’t forget to engage in rituals. Tap into the psychic aether of time and history and give yourself over to celebrating the societal memory of mankind. To ritual is to commune with humanity’s essence. Nobody can take it from you.
Huge ramble ahead, but TL;DR - a lot of systems are starting to come together well. Optimization is happening, but the big gains are coming next year. Upgrading cards, physics, and leveling up are all in the game. Check out the new gameplay video here:
Thanks for watching, anyone who is interested in software engineering or game development or my life can continue reading.
I have been working really hard. On INURBIS. And other things. I’m in that tryhard stage of my life, I guess.
This month, I spent the first week polishing up the card system, hardening the rules and bounds of the system, and I think they’re at a good spot now. I’m still planning on refreshing the base visual format in the future, but for now everything is working and that’s the important thing. Minor cards, card upgrades etc. are all working. Cards accept a currently unlimited number of minor upgrades, if the upgrade affects a parameter in use by that card. Those upgrades then level up if the player keeps applying the same upgrade.
This is layer one of two planned layers / paths for upgrading cards. The other being in-world upgrade and repair paths, planned for the future. Minor cards are focused on changing the stats of other cards, while repairing and upgrading are more focused on adding new gameplay variations to cards, or maybe progressing down branching paths of card evolutions - things like that, but actually making those changes to cards is something more tied to the world of INURBIS than the cloneling / player, and likely would be after the playtest.
I also did a nice two-day long optimization spree, and I feel like adding some caveats here. The current tutorial level is not optimized to any great degree, and it likely will never be. I’ve learned tons about optimization over the last year, and most importantly the current level would require a huge investment to fully optimize that would be detrimental to the delivery speed of the game. Rather than rebuild the current level, I’m putting my focus into designing and planning the level systems of next year. These will be optimized from the ground up, but it’s a lot of work and I want those optimizations to apply to everything moving forward. That is all to say that the gameplay landing next year should be hitting a new level of optimization far greater than the current playable game. I will at some point recreate the tutorial in the new system and the current level is likely going in the trash. I want to take all my learnings (and level gameplay logic) and pour them into the new permanent systems and architecture which support simulating an entire sector at a good level of performance.
Why is INURBIS hard to optimize, anyways? There as a technical goal of achievement I had with this project early on, and that was to get Lumen lighting running at 30 FPS on Steam Deck. There are currently some drops to 28 and it struggles a bit harder to render at 1080p (docked), but this goal should be easy to hit once I’ve built the new level systems. But despite that, I think my technical goal has changed a bit, and now more closely aligns with the statement: “I want INURBIS to feature full dynamic lighting and shadows on Steam Deck.” Which changes the implementation quite a bit, and if I focus in that direction instead I’m closer to achieving 60 fps on Steam Deck. That requires a lot of custom lighting logic where different systems take over depending on the user’s graphics settings. I have some foundations of these systems built out, but they need to be implemented in the new level systems so that I can get that work systemically and for “free” as I build out future levels without having to tweak lighting manually in every room / area.
ANYWAYS, I really wanted to talk about the main focus of this month’s time, which saw the development of the physics system, along with the first physics-based melee weapon, the ancient cutter.
Prior to this month I had a lot of scattered physics implementations which were experimental. All of this was hand tweaked on individual actors, tested separately etc. I was really probing physics at those junctures, trying to figure out how to get that feeling of encompassing everything into a real system where objects of varying hardness and mass all behave somewhat “realistically” or at least give the impression of some sort of fun gameplay logic.
I’m happy to report I was finally able to pull all of that into a coherent physics system, logic that attaches to any loose bodies and answers, how hard am I? how heavy am I? how fast am I moving? how much force is behind my mass and speed? And so forth. Along with this, the kick skill (which I’ve been working on in the background for months), generic explosions, and the physics sword were born. I am seeing the real emergent behavior during testing, meaning things are happening as the result of logical simulated conclusions instead of behaviors I’m manually building. Also known as the sauce.
Things like explosions launching a crate heavy enough to destroy a slime or kill the player, the player’s sword getting blocked by an overhanging ledge (hello dark souls gameplay reference #2), slicing through multiple soft objects only to be stopped by a hard object, revenging on slimes by kicking them off of ledges. The newly implemented dodge card is also physics driven with launch power, speed, momentum. Along with the entire player body. I still have improvements to be made here. The player can’t be knocked over, drones can’t be knocked from flight… but that stuff is coming.
Lying on top of the physics revamp, clonelings can now hold and throw all items. Weapons, Items, trash, rubble, crates - all tied to the cloneling’s strength value. Objects that are too heavy can’t be lifted or thrown, and throw power depends on the object’s mass. Throwing needs a bit more polish and tweaking and it needs to better tie into the cloneling’s strength… but that stuff is coming.
Along with the physics system, I built out a generic clutter system. Big objects and be broken down into smaller objects. Trash bags explode into smaller bits of trash. Blowing up a barrel in a pile of trash etc. in slow motion is super fun.
Tweaking this stuff further is on hold while I plan a pretty major refactor to enemies and NPCs - which is also a blocker on me building out new enemies. I’ll be focusing on finishing that refactor in November so I can start moving quicker on building them optimized and living within the game’s RPG systems in a more generic way. A lot of software engineering is getting things to the place where they’re easy to expand and maintain, and the slime and drone were created pretty experimentally. Again, I am taking my learnings to build out systems which will help me speed up overall development, just like the physics and clutter systems are going to save me from having to tweak mass and other behavior on every new object I create.
I also just added the cloneling leveling system… I mean, not really just added it. It’s the culmination of a lot of work over the last year, finishing the card system let me put a nice bow on it and actually implement the level up flow. The “pick 3” mechanic might be placeholder, I’m a bit annoyed at how well it fits against the card system, we’ll see. I’m adding new categories of cards pretty soonish as well. I have some patterns built out for how and why the player gets different types of cards…
Okay, that’s enough for now. Please give me your email on the main page and come check out INURBIS in December. Any feedback or sharing, or liking and subscribing to my YOUTUBE, BANDCAMP, and BLUESKY are VERY appreciated. Thanks, bye.
