Tales of Heroes 3 was suppose to be an FPS+RTS game inspired from Battlezone2. The CEO at ThinkingMonkeys is a big fan of that game and wanted something similar but set in modern military setting.
It was supposed to be a decent quality 3D multiplayer game so we needed a new game engine since old engine used for TOH1 and 2 was 8bit sprite based 2d engine. So I tested/evaluated different game engines including UniEngine, C4, SourceEngine, CryEngine, Unity3D, etc.
I was personally biased towards SourceEngine, CryEngine and Unity3D. I tried each of these engines for few days by implementing some small things like a new custom weapon, moving an NPC from script or code, making custom properties for the editor, etc. Also tested tools, art pipeline, built-in features, PC configuration requirements, learning curve, documentation, licenses, etc.
In the end, it was clear to me that Unity3D is the only practical choice both in terms of business and development reasons even though I really wanted to work on some high-end stuff on SourceEngine or CryEngine, but licensing terms were not that transparent (or affordable according to info we gathered from secret sources). Also in case of CryEngine min PC requirements were a lot higher than our target market and there was no way to run the engine in sort of exclude fancy stuff & run as fast as it can on low-end configs. Unity3D was affordable, requirements were low, easy to learn with a lot of documentation & tutorial videos available online, It was minimalistic of 3 but quite easy and fast to build upon. For example, I easily imported some of the AI code for movement behaviors and pathfinding from game engine – JustAnotherGameEngine in one day.
So I continued on with Unity3D to start building some stuff for 3rd game. I worked on this for approx 1 month before leaving the company. In that time, I made a working multiplayer FPS game, some scripts for RTS part, Even thought I implemented multiplayer FPS part first, the architecture was designed considering the fact that it will be FPS+RTS eventually and RTS elements can be easily added for example, Weapon functionality wasn’t hard coded or tied to player class or single player instead I implemented some I call WeaponManager which could be drag n dropped on anything ranging from player, NPC or buildings. This class managed everything from initializing weapons, toggling weapon on or off, firing, ammo etc. Scripts were coded for different bullet types also whether it’s a physics-based bullet or spray based ray casting, etc. Also, the player controller logic was kind of separate from input controller so we can plug in FPS or 3rd person or NPC controller or even airplanes.
The project should work on low-end systems and multiplayer was only limited to LAN, so I implemented a sort of peer to peer topology so that each client is responsible for ever object generated on that client and send the updates to others. I was hoping to distribute the workload this way so no single system gets overloaded even though I could see it will be little more complicated than Server-Client architecture.
Also coded some custom shaders for specular maps, normal maps, etc. as requested by the artist. Also made a lot of reusable utility scripts/templates for GUI, editor scripts for placing GUI, for server tasks, connections, etc. I almost implemented all the ways possible to connect over the network, like Direct Connect using IP, Master Server (lobby functionality provided by unity) and UDP. Weapon templates for ray casting weapons, projectiles based weapons, recoils, etc.
Ignoring the scoreboard system, the game code was good enough to convert it into quake3 without touching any code (but optimized for LAN only), with a lot of ready use scripts for RTS parts too.
Platforms : Windows
Languages : C#, HLSL,
Game Engine : Unity 3D
Team Size : 2 ( 1 programmers, 1 Artist )