Recycling IDs is a bad idea for a couple of reasons. In no particular order: if you have a bug elsewhere in your code, whereby you store the ID reference in another data structure, say, another Mobile Unit that is attacking that ID, and your code does not properly clear out the unit ID reference, it may be that at some point in the future, the ID is reused and now the unit that maintains the reference to the old version of the ID now knows about the new unit.
Another reason is with multiplayer games. If you recycle IDs, however unlikely it may be, players may be able to somehow find an exploit that stores one or more previously used IDs and when that ID is then recycled, use the information to pull out information that they may not have access to.
Recycling IDs also permits you to easily record all of the IDs for debugging purposes, logging, database storage, etc. You are assured that the ID was used once, and only once, for a very specific object.
IDs should be a unique key of some description, both for ease of implementation and for your own sanity. Nobody would propose ever storing a non-unique key in a database to uniquely identify** a record, and an RTS game (many games in fact) are just databases with a fancy user interface put on top of it.
I am not sure what you mean by “keep the collection size… down.” You would not ordinarily track all IDs ever created all the time, you would just make sure you never reuse a previous ID, which means you either have a simple cycling counter, i.e. you set up a counter that starts at zero, and when you create a new unit, static or mobile, you increment the counter by one. Alternatively, you could use a GUID or a ShortGUID to assign unique IDs to your units.
Unity supports LINQ, you just have to put the appropriate “using” at the top of your source module and you are good to go. LINQ to Objects, and you probably know all this based on your familiarity with LINQ, is a very powerful way to query your data objects for that match particular criteria and perform an action on those objects. I have used LINQ in traditional websites – which is where I first starting using it – and in projects as diverse as a MMORPG bot, a World of Warcraft multiboxing application, a Bookworm-like word game, a genetic game solver and a medical simulation.
With regard to creating lots of prefabs or just one prefab with different data, that comes down to personal preference for your architecture and managing the complexity of the project. Neither way is inherently better than the other in this particular instance. If you know how many unit types you have ahead of time, and you do not have dozens or even hundreds of unit types, multiple prefabs, e.g. a single prefab representing each unit type, may be the ideal way to go.
You may also want to consider a Unity editor extension specifically created to handle the creation and modification of unit prefabs. What form this editor extension takes, and the functionality it provides, I cannot say at this time as I have no clear idea of the unit types you will be defining in your game. Most units, I suspect, are going to be your standard ones, e.g. infantry, ground armoured transports and various flying units.
Philosophically, if I were approaching this with Unity as my engine, I would create a number of standard scripts that do one specific part of the functionality for a unit, e.g. ground movement, ground navigation and fighting, that could be attached to each unit prefab. I would define a number of unit prefabs, at least at the beginning if I had no clear idea of how many units I was implementing, i.e. I am just rough prototyping the game rather than working from a well written game design document. I would also write a number of scripts that can be attached to the more esoteric units, e.g. flying movement, flying navigation, healing effect, laying mines effect.
Each unity prefab would be a “pick and mix” aggregate of all the smaller scripts. I would, philosophically speaking, steer away from attempting to make the monolithic uber-script that does every feature and every action for every unit type possible as it will very quickly grow to be unmanageable and cause many headaches as you yourself hit your complexity limitation. If you are creating scripts for units that are more than one or two hundred lines long, you’re probably putting too many features in a single script. It’s okay to have scripts that are longer, but the majority would be better if they were kept to the tens of lines of working code (this doesn’t include blank lines and comments and curly braces) rather than the many hundreds of lines.
I would also suggest that you make use of some of the more complex ideas of both .NET and software development, things such as state machines for each unit, behaviour trees for units deciding what to do next, LINQ to query objects, delegates and events for inter-object communication, and an overall good, solid architecture to build off of. You will find that if you build a good architecture for your game, you can try out new ideas for it very quickly, and should you actually finish your project, be able to turn the now reasonably generic “RTS engine” to other games too.
For your unit design, I would recommend a rock-paper-scissors approach, and keep the number of possible unit types very low until you have a good strong structure available to you.
** They might store a record with a non-unique key for unique identification, but it is an esoteric usage that we don’t need to explore here.
