Development News

Main Side Projects

November 3rd, 2023

Welcome back trespassers!

Apologies for having missed the end-of-October dev blog. I got a little too caught up in out-of-game spooktivities!

This is a small and somewhat technical blog to highlight the core systems I've been redeveloping for the game, now that the game's more unique systems have stabilized (AI foundation and house generation, which you can read about here).

As always, newcomers can first find game details on the side. The rest of you, read on!

FAQ For Newcomers

What's this game about?

Your pal Kevin has run into a spooky house on a dare. He hasn't come out. You need to go in and save him!

Okay but what's in it for me?

Well, friendship! Okay but also: A new house, new puzzles, and new monsters every time you play.

Can I play this with friends?

Eventually! I'm just a solo developer working at this part time, but once multiplayer is implemented I'll be launching an Early Access version of the game.

Wait, that's not One Wicked Night.....

Core Systems: Movement, Animation, Combat, Inventory, Equipment

There are some basic requirements for any game in the action genre and to be honest, these systems haven't gotten much love in One Wicked Night. Most of what you've seen has been my best-to-date prototypes from previous projects and learning modules. While this let me focus on the most unique code required for OWN (procedural generation), I decided to come back to the standard systems before I go about implementing the AI that I talked about last time.

The logic here is that if I'm smart enough in my approach, the AI and the player will use much of the same code. This is a big advantage, especially for a multiplayer game like OWN: I want to make sure that the network code for systems like combat, item interactions, animation, movement and more is fast, simple, and synchronized. So if I can reuse code in these areas, that will save me loads of work down the line in maintaining the network elements.

Better yet, if I'm REALLY smart about this, my generic code can be re-used across projects. This means less time spent re-writing basic systems, and more time spent on the really neat stuff like procedural generation and extra spooky AI directors. Which brings me to my next point...

Wait who is this guy...

My Backwards-First Approach

I'm going to work backwards here. Instead of developing core systems for OWN and then reusing them later on future projects, I'm going to build those future projects first. What?

I've lined up a number of small-scale projects that will let me develop, test, and iterate on core systems and networking long before any of this code enters "the big one." OWN is my big shiny baby and I don't want any nasty code messing that up. So, bring on the tiny nasty baby games!

In the above images you can see about all there is to see of the first mini projects. But apart from the sparse art and prototype pieces, here's what's inside:

All those core systems... but why?

Because it's super cool, that's why! But also, every one of these systems has been built using some pedantic adherence to coding concepts of "SOLID" principles and the observer pattern. That means the systems are HIGHLY reusable and extensible: this is basically a sandbox of functionality, where I can change out game content and behaviour by clicking and dragging in most cases, or maybe creating about 50 lines of new code instead of 200-1000. As an example, check out the image below.

Modular movement system.

What you're seeing here is my new move system. Instead of code handling input and movement, the functionality has been broken out into "subjects" and "observers." This is the observer pattern, in which a subject system (such as "Input") is being watched by observers (such as jump, move, or run actions). When an observer sees an event that they find interesting (maybe the Jump function sees Input reporting that the jump button was pressed), the observer will do its action (such as create upward force for a jump). And there can be layers here: The Character Body observer can be watching the Jump action, and when it sees the Jump action create a force, it can take that force and apply it to the actual character model.

Does that sound long and confusing? Maybe. But here's the advantage:  

This modularity applies to all systems in the game, including "what happens when you equip an item," "what happens when you hit a character," "what happens when audio should play," etc. As a final example, imagine you want a game with swords. Easy, done. But now you want one sword that can set stuff on fire. No problem, just make a "fire attack" module and put it on the sword. But maybe you want that on a bunch of other weapons too? No problem, just drag that module onto the other weapons (or assign it randomly). 

Modularity is going to be a key part of spell crafting in OWN when it comes around, so it's important to me that my C# skills are "sharp" enough (pun intended) to pull off the generic programming patterns that will support this kind of flexibility.

And so far, it's going great!

Poor Jane is alone in the house while I work on other projects.

November News

This was technically the October update, so I'll get back to you at the end of the month- and hopefully I'll have lots of content to show you for the upcoming fantasy RPG rogue-lite mini game.

Thanks for reading!

- Trombo

How To Keep Up With Kevin

Visit the TromboSpace discord for a small news updates and community chat about all sorts of games.

I also keep a mailing list now! New blog posts and major news only (about 1 message a month). Interested?