Relying on the Game Engine

I'm taking a slightly different mindset for this project.  Instead of going into this knowing how I'm going to implement everything, I'm instead exploring and relying on the game engine.  This is partially because I want to learn Unreal better, but it's also because I'm curious where this will lead.

When I worked on my last side project, which also happened to be a tactic-like game, it was for a long-term game jam competition.  Because of the limited time, I dove straight into it with full intent of how I would implement everything.

Since it was a multiplayer game and I was both unfamiliar and not confident in Unity's multiplayer support, I went with an approach I knew.  The main architecture of the game was that the game client was just a "dumb" asynchronous view of the game state, and all the game logic ran on a standard LAMP stack.  There was a completely different codebase for the client engine (C# in Unity) and the game logic on the server (PHP/MySQL).

This decision forced a lot of how the game was built.  All logic was written in stateless PHP.  Essentially, I would receive a command as a JSON string, read the MySQL database, process the command, then return back updated game state as JSON.  It actually worked remarkably well, and I was really happy with the final result of the game.  It felt like a real game, it played well, and the multiplayer aspects worked flawlessly.

A major downside was that building the game content was not intuitive.  All game data lived in a MySQL database, including all NPCs, quests, the rules for building random dungeons, etc.  The game was a randomized rogue-like, so it worked for what we wanted, but content authoring was not easy.  We also couldn't take advantage of any of the game engine's features, such as AI, pathfinding, etc.

Another problem was that everything felt sort of stiff.  Sure, it's a turn-based game and that's a fairly common problem, but since the only processing that could occur was as the result of someone hitting the PHP backend (stateless system, and we never built a job scheduler), nothing would or could occur outside of you or another player issuing a command.

For this new game, I'm instead aiming for a purely single player experience.  I intend that levels would be built by hand in Unreal, NPCs can be scripted via Blueprints, etc.

A neat side effect of this is that I'm using a lot more of the tool than the previous project.  That project, built with Unity, really didn't make much use of the engine other than as a graphics engine and object manager.  This time, I'm having a lot of fun relying more heavily on the underlying AI tools, navigation system, physics for gameplay/UI, etc.

So while the underlying tactics genre is the same, these are ultimately very different games with very different architectures.

Ultimately, I think the end result will be a far richer game.  Where the previous project felt like a fancy game of chess where the tile was everything, this will feel more like a top-down turn-based shooter where tiles are just grid helper lines.  Even though the level has nothing to it, it already feels far more fluid and alive than the previous project.

I see now why Firaxis built XCom in Unreal, and I'm even starting to see some basic similarities form as the game takes shape.