This is a very complex and sort've ultimate-goal thing, but I'm going to ask now, because I'm going to need one soon, and I'd much rather that we started talking about the how and what about this now rather than later, so that hopefully by the time I need this tech, I won't have to build it myself, but can just bootstrap it into my project, modify it a bit, and go.
One of the major, major, GIANT things Spring mods need is a proper training scenario. The LUA GUI code is about the only thing that we have right now that might be able to deliver this.
Basically, what we need is a set of tools that give instructions to a user (both audio and visual) and then, when the user performs the required steps, the code needs to "see" that and respond.
IOW, we need, "this is how you move your units, Johnny... left-click on that tank... now, right click on the red, flashing icon." <waits for the tank to get to desired x,z> "Good job, Johnny! Now, let's learn how to attack a target..." etc., etc., etc.
For all of you ultra-geeks out there, who learned Spring without reading the manual (yes, that includes me) it may seem dumb that we have the ability to write, edit and present such materials... guess what, IT IS NOT. Most users don't make use of, I'd say, about 50% of Spring's huge arsenal of tools for automating gameplay. People need to be taught how to click-n-drag to create boxes and rectangles of buildings, for example, how to align units into basic formations, what the buttons all do, etc., etc., etc.
We need this soooooooo bad. I am begging people here to start thinking about this issue, and start coming up with ways to achieve this. Whatever is done needs to be bulletproof... it needs to be something that can be run the very first time a mod is started (very big deal), and it needs to be very easy for modders to work with.
I am in the same boat with every other modder working on a big project, in that if I sit down and devote a lot've time to developing LUA stuff, that is time away from doing things that are required by the game, such as animation code and modeling and sound work and game design and balancing. We're all kind've screwed, guys- there just aren't all that many of us, and we're all short on time. Please, take this seriously, and start figuring out how we can deliver much better interactive educational tools to the players, so that the games we deliver can have the same level of professional polish on the getting-users-into-the-game that every game you pay money for delivers.
Please, resist the urge to sneer at my request here, because you might have found Spring easy to get into. Every game engine I look at/play... the first thing I look at is the training missions, if they have any. I skip through them if the game is easy to learn, but with something with very complex gameplay, like BA or Gundam or, for that matter, NanoBlobs (which looks easy and simple but actually requires very good use of Spring's GUI to play well) I'd definately want to be taught things like:
1. How to Move Things Around.
2. How to Use the Minimap.
3. How to Build Stuff.
4. How to use Move/Attack/Patrol/Fight.
5. How to use Fire at Will/Return Fire/Hold Fire
6. How to use Cloaking, and what limits pertain
Etc., etc., etc.! Spring mods are often very complex, and yet our tools for people who do not want to read manuals is just about ZERO! It's amazing that as many people play as they do, when for a newbie, especially one who never played OTA, the difficulty curve must be huge. Please, I know it's high on everybody's priority list right now to make Widgets that do various clever stuff, and to make GUIs that are prettier than the defaults, and stuff... but without proper educational tools, Spring will never get to the levels of popular acceptance that it truly deserves. The LUA GUI stuff finally gives us the tools... let's make it happen.
Big Request- Interactive Educational Tools
Moderator: Moderators
Most of what Argh wants can be done with LuaUI alone. It can
hook every user command to see what the user is doing, and is
capable of monitoring all of the users units. It can also draw
indicators to tell the user what to do (as well as text messages).
For setting up enemies, you could have the user start a plain
Commanders 1000/1000 session, without any AI. Then use
the .cheat/.give commands to place the units, and ShareResources()
to make them enemies. The SVN code allows for enemy unit visibility,
so that can be checked as well.
Once the code for modrules / gaia / cob synchronized lua handles
is committed, they could also be used to setup the enemies. One
way to distribute such a tutorial would be as a mod mutator. This
would contain the tutorial widget, and any supporting synchronized
lua code.
P.S. The new synchronized lua handles are much more capable
then the current lua mission code. They can access much more
game state information, are capable of issuing any order, and can
draw into the game world. The modrules code can also reject
commands that it doesn't agree with (preferably with a warning to
the team that issued the command). It can also adjust the available
commands on a per-unit basis.
hook every user command to see what the user is doing, and is
capable of monitoring all of the users units. It can also draw
indicators to tell the user what to do (as well as text messages).
For setting up enemies, you could have the user start a plain
Commanders 1000/1000 session, without any AI. Then use
the .cheat/.give commands to place the units, and ShareResources()
to make them enemies. The SVN code allows for enemy unit visibility,
so that can be checked as well.
Once the code for modrules / gaia / cob synchronized lua handles
is committed, they could also be used to setup the enemies. One
way to distribute such a tutorial would be as a mod mutator. This
would contain the tutorial widget, and any supporting synchronized
lua code.
P.S. The new synchronized lua handles are much more capable
then the current lua mission code. They can access much more
game state information, are capable of issuing any order, and can
draw into the game world. The modrules code can also reject
commands that it doesn't agree with (preferably with a warning to
the team that issued the command). It can also adjust the available
commands on a per-unit basis.
