The New Unit Format, pt. 1

The New Unit Format, pt. 1

Various things about Spring that do not fit in any of the other forums listed below, including forum rules.

Moderators: Moderators, Moderators

Post Reply
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

The New Unit Format, pt. 1

Post by Argh »

As usual, the following post just represents my opinions. I am not a member of the Spring team, nor do I claim to speak for them in any way, shape or form. Nothing said here is garanteed to become a part of Spring.

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.
0 x

User avatar
[K.B.] Napalm Cobra
Posts: 1222
Joined: 16 Aug 2004, 06:15

Post by [K.B.] Napalm Cobra »

I don't have alot/any experience modding with TA, but I do have some programming experience, so heres my two cents...

I like the way you've divided up the different types into different categories, and believe it would be a good move to make the script more like c++, with each different type being a class, and to make a new unit you simple make a new subclass, if you combined this with headers containing functions provided by the SY's you'd have an easily expandible unit format, and you could easily distribute more detailed unit "classes" so if people wanted to develop their own units from an already available unit all they would have to do is create a sub class.

If you made the map a class and by making each "layer" a subclass it would open the possibility to add new "layers" to the map with theoretical ease.

Feel free to critisise my comments, but unwarrented critisisers will be smote.
0 x

User avatar
AF
AI Developer
Posts: 20671
Joined: 14 Sep 2004, 11:32

Post by AF »

Do you think it possible to create hybrid units using half TA scripting , half Lua scriptinggiven the correct engine modifications? I'm not exactly familiar with them so........
0 x

User avatar
PauloMorfeo
Posts: 2004
Joined: 15 Dec 2004, 20:53

Post by PauloMorfeo »

I would like to see in the units definition a field for AI.

In there, they could define if the unit's behavior was using the default AI files or we could specify a new AI file.

That way, there could be units smarter than others or units with odd behaviors without having to specifically modify the internals of the Spring engine.

Ofcourse, the engine would have to be made specifically to go get units behavior from configurable/scriptable files.

This does not apply to TA-Spring as all units behave the same.
But if there will ever be made TA-Kingdoms-Spring, Warcraft 3-Spring (hope not. It would be suicide), or others, it might be needed...
0 x

User avatar
Triaxx2
Posts: 422
Joined: 29 Aug 2004, 22:24

Post by Triaxx2 »

This is an excellent method, and will allow for missions to be reimplemented. I do recommend moving away from file archives, and into the area of folder archives, for ease of modification.
0 x

Post Reply

Return to “General Discussion”