Main Side Projects

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...

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:

• Core input system

• Core movement system

• Core inventory system

• Core equipment system

• Core animation system

• Core audio system

• Core UI interaction system

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.

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:  

• "Jump" doesn't need to know what the jump button is (eg. spacebar). It just knows that the Input system said jump, so it jumps.

• The Character Body doesn't need to know anything about Input, and it doesn't even need to know how jump works. It just takes whatever force it receives from a move action like Jump.

• Here's where it gets cool: Let's say I'm playing around with different types of jumps. Some go up, some go forward, some do both, some might jump higher if the jump key is pressed for a long time. If I want to change jumping in the game, I simply remove the old jump module, and plug in the new one! Nothing changes in the Character Body, and nothing changes in Input. 

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!

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

Get all previous news here.