Is implementing a scaled-down CK2-type game realistic?

I have a couple of years of programming experience with the Java language as well as Javascript, so I figured a transition to Unity would be relatively easy, and it has been so far (great engine, Unity team, if only I had half your collective skill I would be like the Superman of the coding world). Anyway, I wanted to build a 3D game that is basically a clone of CK2 in many ways, only it should also work on the high-end Android devices (think the Nexus devices, and some Samsung and Verizon tablets as well as Kindle Fires).

I will be using a very data-oriented format so as to support modding as best as I can with my limited resources. The game will have ~10000 characters being simulated, with 1500 - 2000 lords. The game will be played on a 3D map. There will be 1000-2000 map 'nodes', each with a keep on it (basically a 3D castle model drawn on the map surface). Each keep has a population, of which a percentage may be drafted into peasant levies that comprise the bulk of the local lords' forces. Each army will be graphically represented by an animated medieval knight. I would need to regularly update the characters and have them react and interact in a realistic way. I already have an idea as to how I would improve AI evaluation performance. This is what the game should be able to do:

1.) It should be able to draw 2000 static castle models.

2.) It should be able to draw 2000 military unit models and animate them in a minimalist way (e.g. during unit combat and movement)

3.) Draw a waving coat of arms above each keep. Pretty basic.

4.) The game should be able to evaluate for 500 - 1000 events defined in external script files. These would be sorted according to the frequency by which they run and would be evaluated monthly for characters they run for. Think of the event system in most Paradox games to get an idea of what I am talking about.

5.) The game should be able to load its heightmaps, splat-maps and definition files from an external directory. In Desktop this should be in "users/documents/MyGameFolder". On Android it should be "\mnt\sdcard\documents\MyGameFolder". This is primarily for moddability.

6.) The game should be able to run at at least 30fps while handling this and one should be able to "fast forward" (e.g. decrease the amount of time each in-game day takes) as well as decrease it.

Now, this might sound ambitious, but keep in mind that I primarily want to simulate the life and death of a few generations of the player, and this will primarily be accomplished via the event system I am building + a decision system for things like taxes and laws. Is this still too ambitious? What should I realistically be aiming for? I have never been one to "know my own limits", and I usually plan things extremely ambitiously for a 1-man team. Is Unity capable of doing these tasks performantly?*

Thanks in advance for the insight ;-)


* I know, you can do just about anything with Unity, but key word is PERFORMANTLY.

 

Having target is important, but to know if you can achieve them you should do prototype to validate each point separately, then in combination. Prototyping will answer your specific need.

 

Edit: I missed the part about you wanting to target mobile devices. My comments below are meant for good gaming PCs as target plattforms. Trying to do Total War scale battles with thousands of units on mobile devices is crazy and imho not possible. It also doesn't sound at all like a game to play for 5 minutes while taking a dump or waiting for the bus. I'm super disconnected from the mobile world, so I may be wrong, but this has "PC only game" written all over it for me.

Yes. Very much so.

I don't know for sure (you need to test yourself to know for sure, like neoshaman suggested), but I would be very surprised if you'd hit your performance target.
The terrain system currently isn't good, I'm not even sure if runtime heightmap loading is possible. Terrain can give you performance problems even without any of the couple thousand units you want to have on there. Also if you manage runtime loading you'll probably miss out on optimizations for static data like baked occlusion culling.

My suggestion would be to find a way to boil down the visualization to as little as you can. You clearly are fascinated by the "grand simulation" aspect with high level of detail. If you want to focus on that, then do it, but see if you can get the visual representation down to managable levels. Either try something "retro" with 1 unity = 1 pixel. Or maybe abstract everything onto thematically fitting props. E.g. old paper map on a table, lit by candles, and you see the drawings on the paper change to visualize the current state of your world.

If the experience you bring to the table is "only" non-game programming, then I'd suggest to start with something much much simpler.

 

I think you should be able to do this on PC, but in my opinion, on mobile devices this probably won't be happening.

The problem here is that when there are "10000 characters being simulated", it is YOUR job to ensure it runs fast. So the engine is fairly irrelevant in here.

I'd suggest to start making a prototype.

 

Note that 10 000 character don't have to be simulated every frame nor every ticks, studying the structure of the experience and finding shortcut can leverage a lot of performances.

 

These numbers are extremely bloated compared to CK2.

 

I do have prior experience making games, but nothing published. I used the Java based libgdx framework to tinker with small scale RTS games and turn-based civ-like strategy games. Moved to Unity because I hate tinkering with

I was not talking about "Total War" sized battles on mobile (not that ignorant ). I meant that each "unit" would be positioned on a "node", and that it would remain relatively still. And I might have been misleading when I said 2000 units on screen. The number of "units" would correspond to how many lords have their "levies" raised. It would actually likely cap at 200 - 300 at any given moment (the chances of every single medieval lord raising his leavies is... slim). 2000 is just a worst-case scenario. Only maybe 40 - 100 battle simulations should actually be running at a time. I probably miscommunicated there by assuming you knew what Crusader Kings 2 is.

I am not trying to target smartphones, just the highest end tablets. I have played around with tablet games like GTA San Andreas. And many of us actually do play strategy games on tablets. I have been dying to see Paradox release a Grand Strategy on mobile, but according to an interview with the CEO of Paradox Interactive that will not happen until one of their teams decides they WANT to port one to mobile (and who would WANT to rework the systems that have made them such a success to work on mobile). I have nothing really to lose, however, and the end result from all the work it would require would be rewarding IMO.

By "runtime" I meant when the user starts a new game/loads a save. Not the actual meaning of the word, I know.

 

Actually, no. I will represent my fictional game world on a holding-by-holding setup. CK2 had 1-2000 provinces, each with a varrying number of holdings. Assuming most lords and some barons ingame had 10-15 characters in-court, this is roughly correct (give or take a thousand characters).

 

I was mainly asking if the engine can draw that many things performantly. Of course it will be my job to make sure the "simulations" are handled efficiently. I was just trying to convey that I will need the majority of my CPU time spent on updating all of the many simulations (and will likely need to do some multithreading to get the system to run at a decent speed).

 

I am sure. For example, I will have a "meeting" mechanic, and players can only take most actions with other characters they have "met", their liege, or any player that has a holding that borders theirs. They will also not form an "opinion" on another character until they meet him/her. Court characters will be evaluated twice a month on random days. Preferably one a day, but that is probably pretty unrealistic given the sheer numbers. I will also have to implement an efficient character culling system to regularly search for and "kill" unneeded characters (removing them from the evaluation process). I have been thinking through this for quite a while

 

Also note that CK2 is using a lot of make belief AI, they are essentially using an utility systems that allow to go fast (especially if it's implemented as essentially one big array you swipe through while being cache coherent) and a bit of randomness.

In case you aren't aware they made a talk

 

Thanks for the video link. Was not aware of it, I'll look at it when I have the time later tonight.

 

With the appropriate tricks and fakery, I don't see why it couldn't be done.

On key would be separating your simulation from for visualisation. You won't be simulating your world frame by frame in Unity, you'll have it off running in C# land on another thread. Your visualisation will be limited to only what the player can see on screen at the time.

 

Unity's built in terrain wouldn't be appropriate for this type of game.

But for the record, runtime loading of hieght maps is possible, and actually pretty easy. It's just too slow to do mid frame.

 

I prefer C#-land anyway. Just using Unity for the UI and to help me improve graphics quality ;-)

Just curious, why wouldn't Unitys built-in terrain be sufficient for my purposes? Does it cause a lot of lag or CPU strain?

 

Speaking of which, crusader kings 2 has very low number of units visible on the map at any time.

I think that your main difficulty will be rendering the map itself and making sure it is pretty, properly colored, with highlighted borders and nicely aligned country names.

 

Yeah, like 400 tops (there is always a war somewhere). As for the map, I have some ideas. First I will need to learn Unity's mesh editing and creation API and figure out an algorithm to highlight the border provinces. As for the country names, I doubt I am going to implement the "draw country names on map" and other such things until I get the system as a whole up and running. I will probably add it in an update or patch after release though.

 

Mesh creation api is ridiculously simple, it'll take you 15 minutes top.

This is pretty much the whole thing:
https://docs.unity3d.com/ScriptReference/Mesh.html

The only thing you should avoid is passing mesh vertex/face arrays to JsonUtility. Because this has a non-zero chance of crashing json utility.

You'll spend much more time making proper graph structure for the map, IMO.

 

I also don't see why this couldn't be done. You might have to make some compromises to get it to run well on tablets, but it doesn't sound impossible.

The biggest hurdle will probably be drawing everything when you are zoomed out, so you might have to resort to some trickery in that situation.
E.g.:

• Not drawing the actual 3D terrain but essentially just a plane with different colours for different terrain/countries. (If you make a nice transition between the two, it could actually look really cool.)
• Not drawing every single character/castle as a 3D model, but maybe overlaying them with icons (this might also improve readability). Armies which are close together could be displayed as a single, larger group (again, saving drawcalls and reducing clutter).

 

Also number of unit can be misleading, visually you could have 100 unit, technically it's only one model or 1 image, cheat like that happen all the time.

 

Probably. I imagine to support moddability I will have to place alot of information in external files. Handwriting these files will be the biggest pain and timesink IMO (with accurately representing the map coming in as a close second). As for the JSON, thanks for the tip. Most of my data will be loaded from JSON files.

Yeah, that is a very common technique to save memory by avoiding having hundreds of copies of memory-intensive data.

The map is a node-based system, so all units on the same tile will be drawn as a single model. I will likely draw the "border colors" affect as several "world units" above the terrain and just lock the camera so that it cannot go "under" the borders and toggle drawing of the border mesh with mapmodes. When zoomed fully out units will preferably not be drawn. Did some ai prototyping and I can evaluate 15,000 - 20,000 character ai at 35 - 50 fps on my craptop (amusingly GTA and some RTS games run better on my Kindle Fire, so I have high expectations). The idea on displaying the terrain only when zoomed in is a pretty good idea, but I will have to do some prototyping on the terrain first. The continent of my fictional world will be relatively small and compact, so I *MIGHT* not have to do this. I might roll my own heightmap system if things get too bad performance-wise.

 

Unity's terrain is pretty slow. Its also built with something like an FPS in mind. You drop a handful of characters on it and they run around and interact with each other. It just doesn't feel like the right tool for your game.