This discussion is meant to be a serious and moderately-detailed talk about the New Unit Format, which one of the most important elements needed to get Spring from where it'll be at 1.0 to where it wants to be- the best darn RTS game engine, ever.
Please don't post here if you don't know anything about making units for OTA or making scripted 3D animations in general. If you don't know what you're talking about, you're just wasting my time, and I will be grouchy- this is a fairly technical topic, and I'd like it to be realistic. You've been warned...
*************************************************************
At this point, it looks like (short of the SY's all having heart attacks) that Spring 1.0 will get finished over the next few months. And it's going to kick some butt- the improvements in the visuals due to smoother animations, shadows, explosion physics and the unit-movement AI... is really looking great.
So. We're going to get our hands on a really kewl game engine. For free. Like, omigod
And it's very flexible- after all, it'll do everything TA did, and quite a few new things as well. It's not going to *be* TA, in many senses- the changes in the way that units shoot will change the gameplay quite a bit, as will the other improvements and additions. But it's going to be super-cool no matter how you cut it.
I think it's time to start looking towards the future. What do we want Spring to become? Given the goal of becoming the "best RTS ever"... how are we going to meet this challenge? Well, the single biggest area in Spring's design goals is the New Unit Format, so I think that it'd be a good idea to start talking about what we want to get from this.
First, let's talk about philosophy.
In my ideal world... I'd like Spring to be:
1. Capable of duplicating most other RTS game designs, including their special features.
2. Graphically competitive with commercial game engines.
3. Easy to make maps with, and easy to mod.
4. Open-Source, or with an SDK that will allow extensions to the core.
5. Able to use text-based scripts to radically change the behavior of the game engine. I'm really heavily voting for Lua support here, because I've used it in Dawn of War and Freelancer... and I think it kicks ass.
As this post is about the New Unit Format, I'm mainly going to be talking about points 1 through 3, although 4 and 5 will get touched upon. All 5 points are directly relevant to the design of the NUF, though... because, when you get down to it... RTS games are mainly about the capabilities of the units.
This is, obviously a very wide gamut, that ranges from the "Magic Upgrade Building of Faster Oatmeal-Munching +4" to the "Oatmeal-Munching Archers of Doom".
In short... whether a game object is merely a destroyable piece of scenery, an interactive game object controlled by the player, or an animated and active object controlled by the computer... these can all be thought of as units, albeit specialized ones.
The Unit
I think that... from Day One... the NUF ought to consider most of the objects in Spring to be various forms of "Unit". There are special objects that obviously do not qualify, such as light sources, the map componants (the heightmap, metalmap, and other features), but I think that if it's not map, and it's not the core engine or GUI art... it should share the same basic structure with everything else.
Why? Because it keeps things simple, of course! Instead of having special cases for every type of game object... one should be able to call up any valid Unit... and so long as the operations requested of that Unit are valid, then it should be able to perform the requested job. TA more or less adhered to this standard, with a few exceptions. All Buildings and Units share the same basic file structure, the same scripting systems, etc.
So, let's look at definitions and sub-definitions.
*************************************************************
UNIT: A Unit is anything that fits under the NUF definitions. It can be anything from a piece of Scenery, a Mobile, an Interactive NonMobile, or an Automated Mobile (more down below).
A Unit has 3 required parts:
1. A .NUF file, which describes/defines physical properties, script locations, etc.
2. A model file, which may contain animation data.
3. One or more textures, explicitly named in the .NUF file.
These are the bare minimums, of course. And there are lots of other files that would be needed to describe an entire TC, race or large unit pack, such as a list of sounds, weapons, projectiles, emitters and other things. I'll talk about these things as I get into talking about the kinds of things game designers will want to be able to attach to Units later on.
*************************************************************
SCENERY: Scenery objects may have animations associated with Events and Fuses (more later on), and may or may not be destroyed, and should have Physical Properties (more later), but are... well... scenery. Everything from trees to rocks to buildings in a city counts as Scenery. Some of these items may have animations that run all of the time, such as a water-wheel, and some may run a series of scripts. If we can open up some game variables for scripting to look at, we could even do some very cool things, like have buildings that fly different-colored flags depending on who is winning the game, or whoever has a building nearest to them, or other things.
MOBILE: A Mobile is any Unit that can be interacted with by players (or an AI player) that is capable of changing the position of its Base. This includes things like Kbots, aircraft, tanks, ships, and hovercraft... as well as some new types, which I'll discuss later on.
INTERACTIVE NONMOBILE: This covers buildings that may or may not build units, storage units, resource creation / harvest buildings, etc. In short, an Interactive NonMobile is a building that players or an AI can interact with.
AUTOMATED MOBILE: These are Mobiles that are controlled by a Neutral AI. Until there is a working Skirmish AI for Spring, we're mainly talking about things like the occasional bird or other animals that show up at random, but eventually I'd like this category to include things like civilians that run away from the forces of each side, neutral AI players who occasionally attack players or the AI, and other things like this.
I will be quite honest and admit that I'm stealing very heavily from Kohan II in building these categories. I was quite impressed with the Automated Mobiles they included- the random animals and Neutral Races that populated each game map, making the game feel much less generic and more like a complete world unto itself. Yes, I know that TA's scale is a little bigger, but there are lots of other game designs where the scale may be perfect for having lots've semi-random and automated events happening.
