Disclaimer: The following is my opinion. I am not a member of the SYs, nor am I a developer. I am just a guy who likes to mod games. For all I know, the SYs have better ideas than I do, and this will just be a side-jaunt to nowhere. Still, I feel it's time to describe these ideas, in the hopes that as Spring development continues, it will be a useful document to mine useful idea-nuggets out've. So whether anybody takes this seriously is entirely up to them.
Objective: This proposal describes the limitations of the current COB/BOS scripting system, and proposes a new model that will allow Spring to be a much more powerful game engine, graphically speaking.
Towards a New Animation Format. Very long.
Moderator: Moderators
Philosophy: You can skip this part if you don't like to know an author's prejudices or basic point of view- how they have arrived at their biased conclusions (because, let's face it- any proposal intended to cause action reflects the author's bias). This isn't a technical section, it just explains why I'm taking the time to talk about this now. Skip to the next post it if you just want to read the basic sketch of ideas, diagrams and descriptions.
Animations and animated particle effects are at least 50% of what makes a video game look visually stunning. Yes, we modelers/skinners/mappers play an important role... but the things that really make people sit up and take notice are the ways that objects act.
For those of you with memories long enough, I invite you to revisit a great, old classic- Dragon's Lair. Introduced waaaaay back in the Dark Ages (it ran off of a laser disc, of all things), Dragon's Lair was, to my knowledge, the most visually impressive video game that had ever been built, up to that point. Oh, sure, it was basically a gimmick game design, and its "interactivity" mainly consisted of hitting joysticks in the right direction at the right time in the right order... but at the time, it was visually stunning- an amazing work of gaming art.
What troubles me, these days... is how we can now render scenes that are every bit as beautiful (even, with shaders, as cartoony) as that game... but the level of animation in it has yet to really be met by any game engine, except in cutscenes. My thesis, throughout this essay, is that this is bad. And Spring can show people a better way.
Video games have, in many ways, been becoming more and more visually complex without adding additional animations into scenes, in large part, I suspect, because the tools available to modern developers have become so complex and difficult to work with that the time investment in a single animated object has become so large that it's become preferred to simply pile on more polygons, more complex shaders... and distract viewers from the fact that, when you get past the dynamic lights and shadow-maps... there's LESS going on these days. Fewer objects in motion, basically. Modern games hide this really well, but it's been a trend for awhile now.
Supreme Commander looks like it's answering that problem by deliberately encouraging the viewer to take a view from on-high, and I suspect it will be making heavy use of LODs (or maybe even tessalated LODs on-the-fly). That's great, but I don't see a lot've evidence, based on what I'm seeing thus far, that it's a whole lot more advanced of an animation system than what we already have, and it's probably very proprietary. I strongly prefer Spring's approach thus far, even with the admitted bugginess and teething problems, because COB/BOS was a such a powerful idea.
If I may steal a line from Star Trek... " Dammit, Jim, I'm not a coder, I'm a designer!". Sometimes I think that the Big Guys should remember that, especially when more and more games are built with modding as part of the business plan. I do not want to spend months of work just to see the final product in-game and go, "eeew". I want to rapid-prototype it, get it working... go back, revise, rebuild, re-animate.
And I want it to be simple. Simple is good. Complex is bad. Simple means that somebody knows the difference between "powerful" and "feature-rich" and "a poorly thought-out grab-bag of things that don't work well together". Rhino3D is simple. It's also extremely powerful. These two things aren't mutually exclusive.
Annoyed that in the decade I've been messing with games... that at the top end, it's actually becoming less rewarding and less easy to work with content, I decided that I'd rather migrate to Spring when I was finally burned out on modding Freelancer. So here I am
Animations and animated particle effects are at least 50% of what makes a video game look visually stunning. Yes, we modelers/skinners/mappers play an important role... but the things that really make people sit up and take notice are the ways that objects act.
For those of you with memories long enough, I invite you to revisit a great, old classic- Dragon's Lair. Introduced waaaaay back in the Dark Ages (it ran off of a laser disc, of all things), Dragon's Lair was, to my knowledge, the most visually impressive video game that had ever been built, up to that point. Oh, sure, it was basically a gimmick game design, and its "interactivity" mainly consisted of hitting joysticks in the right direction at the right time in the right order... but at the time, it was visually stunning- an amazing work of gaming art.
What troubles me, these days... is how we can now render scenes that are every bit as beautiful (even, with shaders, as cartoony) as that game... but the level of animation in it has yet to really be met by any game engine, except in cutscenes. My thesis, throughout this essay, is that this is bad. And Spring can show people a better way.
Video games have, in many ways, been becoming more and more visually complex without adding additional animations into scenes, in large part, I suspect, because the tools available to modern developers have become so complex and difficult to work with that the time investment in a single animated object has become so large that it's become preferred to simply pile on more polygons, more complex shaders... and distract viewers from the fact that, when you get past the dynamic lights and shadow-maps... there's LESS going on these days. Fewer objects in motion, basically. Modern games hide this really well, but it's been a trend for awhile now.
Supreme Commander looks like it's answering that problem by deliberately encouraging the viewer to take a view from on-high, and I suspect it will be making heavy use of LODs (or maybe even tessalated LODs on-the-fly). That's great, but I don't see a lot've evidence, based on what I'm seeing thus far, that it's a whole lot more advanced of an animation system than what we already have, and it's probably very proprietary. I strongly prefer Spring's approach thus far, even with the admitted bugginess and teething problems, because COB/BOS was a such a powerful idea.
If I may steal a line from Star Trek... " Dammit, Jim, I'm not a coder, I'm a designer!". Sometimes I think that the Big Guys should remember that, especially when more and more games are built with modding as part of the business plan. I do not want to spend months of work just to see the final product in-game and go, "eeew". I want to rapid-prototype it, get it working... go back, revise, rebuild, re-animate.
And I want it to be simple. Simple is good. Complex is bad. Simple means that somebody knows the difference between "powerful" and "feature-rich" and "a poorly thought-out grab-bag of things that don't work well together". Rhino3D is simple. It's also extremely powerful. These two things aren't mutually exclusive.
Annoyed that in the decade I've been messing with games... that at the top end, it's actually becoming less rewarding and less easy to work with content, I decided that I'd rather migrate to Spring when I was finally burned out on modding Freelancer. So here I am
Conceptualization: Spring is based on a rather difficult animation environment, inherited from the OTA engine. It is entirely scripted, has no real, working preview, and has no real, working animation editor. The closest thing we have is UpSpring, Servo and Scriptor.
This is not ideal.
This lack of a good content-side developement environment probably one of the reasons why attracting new developers from outside the OTA modding community has been slow. And a new animation format, with better tools, might really help us get there- a few demos in the right places could really attract a lot've talent. Zaphod, don't get me wrong- UpSpring rocks. Same goes for Mother and all of the other wonderful people who've given their free time to get us here- no disrespect is intended. I just want us to get to the next level.
The flipside to the current difficulty of creating good animation scripts with fluid, lifelike motion simulation is the sheer flexibility BOS offers. Unlike, say, working with Max, we are able to very easily work with very complex parent/child relationships in an intuitive way. If I want a sub-sub-sub-sub-part of some complex object to be moving precisely in its relative Y axis at such-and-such a speed RIGHT NOW, I can do that, with complete, numerical precision.
However, that very example, above, also demonstrates a big problem with COB/BOS: if we wanted to move that part using an absolute XYZ value, it'd require a great deal of very crunchy math. If we wanted that part to use a parent piece's origin as the relative axis for the motion, we'd also have to use very crunchy math. A lot've basic pieces of information, such as current velocity, current vector, etc. are very difficult to arrive at.
And there are a lot of things ... that if not impossible, simply require too much darn work. For example... animating something with multiple legs. BIG SCRIPT. Lots of places for things to go horribly wrong. No preview environment aside from getting the whole thing into Spring. Any changes have to be laboriously checked from one area to the next. It's little wonder, then, that very few people take the time to do things like this.
COB was, probably, the best thing Chris Taylor and the TA team built into the game engine. It allowed them to have graphics that were, in many ways, far superior to previous titles, and in some ways, the flexibility has never been really reproduced. Until Spring came along, I've always considered this one of the strongest animation environments around.
Evidence abounds- look at how many newbies, totally unfamiliar with 3D modeling, have made TA units over the years, with a wild array of shapes, sizes and moving parts.
BUT...
We can do better. Without creating something so uber-complex to use that people will run away screaming. Without causing developers' heads to explode. Without robbing the current TA modders of their tools.
After thinking on things for a bit... my vote is that we abandon COB and Scriptor ... entirely.
Why? After all Scriptor works, and is really not a bad editing environment. Its ability to bring in includes, etc., is really nice, saving coders from having to re-add the same darn smoke/rock/recoil/whatever script for the millionth time. Plus it will tell you on what line the script has failed, if it won't compile. I won't lie- Scriptor was an excellent tool. But for a New Animation Format to be a reality, we're going to need to abandon it, because the amount of side-tracking required to make it work (even if the source is available, which I assume it is) would be a waste of coder time, especially as it probably doesn't run well in Linux, if at all (under Wine, of course).
Instead of Scriptor, we need a built-in scripting environment that can run unit scripts... built into UpSpring.
This is not ideal.
This lack of a good content-side developement environment probably one of the reasons why attracting new developers from outside the OTA modding community has been slow. And a new animation format, with better tools, might really help us get there- a few demos in the right places could really attract a lot've talent. Zaphod, don't get me wrong- UpSpring rocks. Same goes for Mother and all of the other wonderful people who've given their free time to get us here- no disrespect is intended. I just want us to get to the next level.
The flipside to the current difficulty of creating good animation scripts with fluid, lifelike motion simulation is the sheer flexibility BOS offers. Unlike, say, working with Max, we are able to very easily work with very complex parent/child relationships in an intuitive way. If I want a sub-sub-sub-sub-part of some complex object to be moving precisely in its relative Y axis at such-and-such a speed RIGHT NOW, I can do that, with complete, numerical precision.
However, that very example, above, also demonstrates a big problem with COB/BOS: if we wanted to move that part using an absolute XYZ value, it'd require a great deal of very crunchy math. If we wanted that part to use a parent piece's origin as the relative axis for the motion, we'd also have to use very crunchy math. A lot've basic pieces of information, such as current velocity, current vector, etc. are very difficult to arrive at.
And there are a lot of things ... that if not impossible, simply require too much darn work. For example... animating something with multiple legs. BIG SCRIPT. Lots of places for things to go horribly wrong. No preview environment aside from getting the whole thing into Spring. Any changes have to be laboriously checked from one area to the next. It's little wonder, then, that very few people take the time to do things like this.
COB was, probably, the best thing Chris Taylor and the TA team built into the game engine. It allowed them to have graphics that were, in many ways, far superior to previous titles, and in some ways, the flexibility has never been really reproduced. Until Spring came along, I've always considered this one of the strongest animation environments around.
Evidence abounds- look at how many newbies, totally unfamiliar with 3D modeling, have made TA units over the years, with a wild array of shapes, sizes and moving parts.
BUT...
We can do better. Without creating something so uber-complex to use that people will run away screaming. Without causing developers' heads to explode. Without robbing the current TA modders of their tools.
After thinking on things for a bit... my vote is that we abandon COB and Scriptor ... entirely.
Why? After all Scriptor works, and is really not a bad editing environment. Its ability to bring in includes, etc., is really nice, saving coders from having to re-add the same darn smoke/rock/recoil/whatever script for the millionth time. Plus it will tell you on what line the script has failed, if it won't compile. I won't lie- Scriptor was an excellent tool. But for a New Animation Format to be a reality, we're going to need to abandon it, because the amount of side-tracking required to make it work (even if the source is available, which I assume it is) would be a waste of coder time, especially as it probably doesn't run well in Linux, if at all (under Wine, of course).
Instead of Scriptor, we need a built-in scripting environment that can run unit scripts... built into UpSpring.
My vote is that UpSpring become the "one-stop shop" for unit creation, and feature different "rooms", much like Poser does, where people can do different things with the same model- an area for destructive changes to the model's position/hierarchy/skin/parts, like we have now... an Animation room with the same basic layout of Servo, where people can design animation "sections", and a Scripting room where people can work with the final code, hooking "sections" together into final code and then compiling them into a final, very compact format for the game engine to read.
In addition, we sorely need to remove some of the suck of BOS, introduce some entirely new concepts, and generally have an environment that serves artists who need to get something done now, not in ten weeks. Let's be real here: the vast majority of people modding Spring aren't ever going to be the three classes of people who can spend all day working on video games: professionals, who get paid to, retired people, who, for the most part, aren't interested in this stuff, or people who have no jobs, no responsibilities, no school... I'm sure that there are people like that out there somewhere, but they're probably either losers in dark basements or rich guys who can kiss my arse. I have a job. I have other things going on that aren't optional.
Most of you are either working, or in school, or both. Aside from the occasional kid who shows up and is apparantly OK with flunking out've college while he/she gives up their life to Spring projects, we're all in the same boat here- the "too little time" boat. So... do I want an uber-shader system that takes days to learn, weeks to become competant, and months to master? NO. Do I want an animation system that requires me to define ragdoll points, muscular attachment points, points to count how many times I say "point"? NO. I want to build my geometry in the modeler of choice, skin a piece, bring that piece into UpSpring, etc... and three hours later, have a model that's ready to go. That part works- and Zaphod deserves enormous props for getting it that far. Whether we get to the next, logical step- animation with automation controls and particle systems... is not in my hands, but here's what I'd like to see:
1. I think that the basic syntax of BOS should be kept intact, and that the editing environment should output BOS commands- and that the New Animation Format should be 100% backwards-compatible.
There is nothing really wrong with BOS, if you're already familiar with coding, even at my rudimentary level. It's very, very simple, straightforward and not hard to understand. However, I think that a project goal should be to make it quite possible for someone with zero coding experience to walk through a step-by-step tutorial and end up with something that performed all of the basics of a TA unit- aim script, move script, aim-while-move script, smoke script, recoil/return script, death script. They should be able to go from importing a model's pieces into UpSpring to a final, working project without ever seeing a line of code. The masters will, of course, continue to hand-tweak things and use advanced functions, but even they will probably want to build their major animations in the preview environment, or at least run them there.
2. The Animation Room must have an interface that allows us to build "segments"- short series of animations, basically- and let us put them into any order, in a simple, visual fashion, combine one or more of them, and view them a simple way. Basically... I think that the way that UpSpring handles model hierarchies is the same kind've approach I'd want to see for segments- it's not, maybe, the most perfect approach for uber-giant, ultra-complex animation series, but when you're going beyond 20-30 different animations with different conditions, etc., then there's just no way to make that really user friendly, no matter what environment we're talking about.
3. We badly need new features- and an interface that will help us visualize how these features are working for us.
With all of the things that BOS can already do... what, exactly, do I think needs to be added to its list of legal instructions?
A. I would, very badly, like to see instructions that Get Unit XYZ Position, Heading (Absolute, from synch code) and Heading_Changed (X = time in ms). Having taken a look again at this issue- this is one of the big things that the TA team didn't provide themselves with that should be very straightforward.
B. Transforms of Parent but not Child.
C. Transforms affecting geometry. Now, before everybody jumps on me- I don't want ragdoll, I don't want bones or IK! No, I just want to be able to scale things in XYZ dimensions dynamically. That's it. It'd add a lot to attempts to use Spring for organic animation, and it wouldn't be too painful to add, I think.
D. The ability to auto-mirror a given segment's rotations, so that doing a right/left animation would not be such a royal pain. Yes, there are few elegant ways of doing that, but maybe... hmmm... perhaps you could build an animation... go to the OBJECT hierarchy, mirror it THERE, and the animation would follow and mirror it? That should be possible!
E. Changes in Piece names in the Geometry/Skin Room should result in change of Piece names called in the Animation/Preview and Scripting Rooms.
F. Motion Systems. This area gets rather complex, and I'll say first and foremost that I shouldn't even say anything at all- I'm not qualified to have much in the way of an opinion. But still, I'm going to put my toes in the water, and propose that several basic motion systems be included in Spring:
f1: Wheels that turn relative to true unit speeds XYZ. I know that the math on this is straightforward enough, and if the interface was basically a dialog that said, "Hey, what's your wheel object", and then said "Where's the center of this wheel?" and "Where's an outside vertex of this wheel" to get the necessary geometrical data for that calculation, and then made the script as a Segment... that'd ROCK.
f2: Animated track systems via null points. Very simply, like the wheel, it'd ask the user a few questions, "where's the object you're using for tread sections?", "where's the first section of the track?", "does this track form a complete loop?" and "how many repeats of this tread section are there?".
Animated tracks via various hacks are quite possible in Spring, and I will be featuring one using show/hide and very stupid code in NanoBlobs. But ... I am not happy with this, as an artist, nor am I at all confident that I could code it in BOS as it stands. I'd love it if I could just define this in a few clicks... and then preview it at different speeds in the Animation Room. That'd kick some butt!
f3: Dynamic, random, layerable, event-triggered and controlable particle effects.
This is such a giant topic that I'll have to make another post here in a bit- that section, all by itself, will take awhile, because some of it really should be shown with pictures.
In addition, we sorely need to remove some of the suck of BOS, introduce some entirely new concepts, and generally have an environment that serves artists who need to get something done now, not in ten weeks. Let's be real here: the vast majority of people modding Spring aren't ever going to be the three classes of people who can spend all day working on video games: professionals, who get paid to, retired people, who, for the most part, aren't interested in this stuff, or people who have no jobs, no responsibilities, no school... I'm sure that there are people like that out there somewhere, but they're probably either losers in dark basements or rich guys who can kiss my arse. I have a job. I have other things going on that aren't optional.
Most of you are either working, or in school, or both. Aside from the occasional kid who shows up and is apparantly OK with flunking out've college while he/she gives up their life to Spring projects, we're all in the same boat here- the "too little time" boat. So... do I want an uber-shader system that takes days to learn, weeks to become competant, and months to master? NO. Do I want an animation system that requires me to define ragdoll points, muscular attachment points, points to count how many times I say "point"? NO. I want to build my geometry in the modeler of choice, skin a piece, bring that piece into UpSpring, etc... and three hours later, have a model that's ready to go. That part works- and Zaphod deserves enormous props for getting it that far. Whether we get to the next, logical step- animation with automation controls and particle systems... is not in my hands, but here's what I'd like to see:
1. I think that the basic syntax of BOS should be kept intact, and that the editing environment should output BOS commands- and that the New Animation Format should be 100% backwards-compatible.
There is nothing really wrong with BOS, if you're already familiar with coding, even at my rudimentary level. It's very, very simple, straightforward and not hard to understand. However, I think that a project goal should be to make it quite possible for someone with zero coding experience to walk through a step-by-step tutorial and end up with something that performed all of the basics of a TA unit- aim script, move script, aim-while-move script, smoke script, recoil/return script, death script. They should be able to go from importing a model's pieces into UpSpring to a final, working project without ever seeing a line of code. The masters will, of course, continue to hand-tweak things and use advanced functions, but even they will probably want to build their major animations in the preview environment, or at least run them there.
2. The Animation Room must have an interface that allows us to build "segments"- short series of animations, basically- and let us put them into any order, in a simple, visual fashion, combine one or more of them, and view them a simple way. Basically... I think that the way that UpSpring handles model hierarchies is the same kind've approach I'd want to see for segments- it's not, maybe, the most perfect approach for uber-giant, ultra-complex animation series, but when you're going beyond 20-30 different animations with different conditions, etc., then there's just no way to make that really user friendly, no matter what environment we're talking about.
3. We badly need new features- and an interface that will help us visualize how these features are working for us.
With all of the things that BOS can already do... what, exactly, do I think needs to be added to its list of legal instructions?
A. I would, very badly, like to see instructions that Get Unit XYZ Position, Heading (Absolute, from synch code) and Heading_Changed (X = time in ms). Having taken a look again at this issue- this is one of the big things that the TA team didn't provide themselves with that should be very straightforward.
B. Transforms of Parent but not Child.
C. Transforms affecting geometry. Now, before everybody jumps on me- I don't want ragdoll, I don't want bones or IK! No, I just want to be able to scale things in XYZ dimensions dynamically. That's it. It'd add a lot to attempts to use Spring for organic animation, and it wouldn't be too painful to add, I think.
D. The ability to auto-mirror a given segment's rotations, so that doing a right/left animation would not be such a royal pain. Yes, there are few elegant ways of doing that, but maybe... hmmm... perhaps you could build an animation... go to the OBJECT hierarchy, mirror it THERE, and the animation would follow and mirror it? That should be possible!
E. Changes in Piece names in the Geometry/Skin Room should result in change of Piece names called in the Animation/Preview and Scripting Rooms.
F. Motion Systems. This area gets rather complex, and I'll say first and foremost that I shouldn't even say anything at all- I'm not qualified to have much in the way of an opinion. But still, I'm going to put my toes in the water, and propose that several basic motion systems be included in Spring:
f1: Wheels that turn relative to true unit speeds XYZ. I know that the math on this is straightforward enough, and if the interface was basically a dialog that said, "Hey, what's your wheel object", and then said "Where's the center of this wheel?" and "Where's an outside vertex of this wheel" to get the necessary geometrical data for that calculation, and then made the script as a Segment... that'd ROCK.
f2: Animated track systems via null points. Very simply, like the wheel, it'd ask the user a few questions, "where's the object you're using for tread sections?", "where's the first section of the track?", "does this track form a complete loop?" and "how many repeats of this tread section are there?".
Animated tracks via various hacks are quite possible in Spring, and I will be featuring one using show/hide and very stupid code in NanoBlobs. But ... I am not happy with this, as an artist, nor am I at all confident that I could code it in BOS as it stands. I'd love it if I could just define this in a few clicks... and then preview it at different speeds in the Animation Room. That'd kick some butt!
f3: Dynamic, random, layerable, event-triggered and controlable particle effects.
This is such a giant topic that I'll have to make another post here in a bit- that section, all by itself, will take awhile, because some of it really should be shown with pictures.
So the thing you want is a graphical way of scripting an unit.
You place the objects into place, and he makes the co├â┬Ârdinations for it.
Nice idea. I have no idea how long something like that will take but are you going to feed Zaphod enough lemons?
Although I never scripped a unit myself (I like to redo an existing and just replace the 3d object). But you manage to describe the current situation and the thing you wish to get to.
Lets see what other think about it.
You place the objects into place, and he makes the co├â┬Ârdinations for it.
Nice idea. I have no idea how long something like that will take but are you going to feed Zaphod enough lemons?
Although I never scripped a unit myself (I like to redo an existing and just replace the 3d object). But you manage to describe the current situation and the thing you wish to get to.
Lets see what other think about it.
Yeah eh... 
I want stuff too...
How is this different from wishlist #20321?
IMO, it would be better to pick a free animation format for another 3D engine (such as OGRE or Crystal Space, depending on which have the better set of model features), and work from there. But springs model code needs a lot of changes and abstraction before those steps can be taken.
I want stuff too...How is this different from wishlist #20321?
IMO, it would be better to pick a free animation format for another 3D engine (such as OGRE or Crystal Space, depending on which have the better set of model features), and work from there. But springs model code needs a lot of changes and abstraction before those steps can be taken.
I agree, having something built in scriptor that let you visually create "poses" by moving/turning pieces, and then with the list of time between each pose build a complete walkscript (including calculating the speed of move/turn, not like servo, and please no if(TRUE) this time) would be very good. Also, something that let you choose what pieces are turret, flare, etc... and from all that build a complete working bos and cob would be good, as it seems there are much more people who can model than people who are fluent in .bos. It won't ever be as powerful as hand made, unless there's some sort of plug-ins system where new script library can be easily made, but simple scripts would be much much quicker to do for new unitmaker.
While we're at it, let's make UpSpring build FBI (with nice mouse controlled visual input for things like fire arcs) and 96x96 pcx, and .... ok, poor Zaphod, he'll need a whole team of programmers in reinforcment for all that.
But having UpSpring able to produce simple scripts would help many modders, I think.
While we're at it, let's make UpSpring build FBI (with nice mouse controlled visual input for things like fire arcs) and 96x96 pcx, and .... ok, poor Zaphod, he'll need a whole team of programmers in reinforcment for all that.
But having UpSpring able to produce simple scripts would help many modders, I think.
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
It's LONGER!Zaphod wrote:Yeah eh...
How is this different from wishlist #20321?
IMO, it would be better to pick a free animation format for another 3D engine (such as OGRE or Crystal Space, depending on which have the better set of model features), and work from there. But springs model code needs a lot of changes and abstraction before those steps can be taken.
I kid, a more powerful animation system would be great. Someone just needs to do it
I believe a lua style system would be a good way forward, with BOS compatability introduced by adding a bos.h header with a mass of #define type statements.
Aside from that a lua style system is a necessity if SupCom support is ever to be integrated into spring, which is soemthing i think would be a very good strategic move allowing supcom users to easily port units over to spring and vice versa, and allowing a single pool of talent to work on 2 engines.
I also think that the current BOS style syntax may possibly be best kept in the current system running parallel along the new system rather than BOS support built into the new system. Such a thign if nto doable using defines would lead to a lot mroe work than simply using lua which means most of the work si doen and all you need todo is write the binding between the lua itnerface and the existing spring functions that manipulate the models, which in most cases are already present in the COB interface.
You also ahve the advantage of there already being numerous tools for lua and no need for an extra compiler/decompiler as they already exist ro could be itnegrated into spring if they arent already.
That adn we already ahve lua in spring for the missions.
Aside from that a lua style system is a necessity if SupCom support is ever to be integrated into spring, which is soemthing i think would be a very good strategic move allowing supcom users to easily port units over to spring and vice versa, and allowing a single pool of talent to work on 2 engines.
I also think that the current BOS style syntax may possibly be best kept in the current system running parallel along the new system rather than BOS support built into the new system. Such a thign if nto doable using defines would lead to a lot mroe work than simply using lua which means most of the work si doen and all you need todo is write the binding between the lua itnerface and the existing spring functions that manipulate the models, which in most cases are already present in the COB interface.
You also ahve the advantage of there already being numerous tools for lua and no need for an extra compiler/decompiler as they already exist ro could be itnegrated into spring if they arent already.
That adn we already ahve lua in spring for the missions.
<shrugs> I'm not claiming this is easy, or that Zaphod can do this all by himself, or that we all have infinite time, or that this should get done tomorrow, chop-chop. I'm talking out loud- if it happens, great... if not, ah well
I think that it would be easier to do this than incorporating a whole new animation library into Spring, though. Spring is built around BOS. If we went to an all-new animation format, we'd lose backwards-compatibility, or have yet another layer of kludge. I think that'd be a waste of resources.
BOS has advantages and disadvantages. I think we should build on the advantages, and lose the disadvantages.
And I'd be fine if BOS could just support a larger command-set, no longer required compilation via Scriptor (which would take us around a lot of the current Catch-22s) and that was that... like the new unit/weapon features, it'd be an advanced set of functions, documented in the Wiki or maybe in a helpful guide by game developers.
The only problem with that, as far as I am concerned, is that it doesn't really help with the core issue- which is that very few people have shown the skill levels required to step into this environment and make entirely new game designs. I would think that we'd have a lot've fledgling teams here by now, but I think that the sheer complexity is driving them away. It's not that you can't do some amazing things with Spring, really- it's that it's hard, if you don't already have the background.
I have been showing a friend of mine, step by step, how to walk through building a TA mod with Spring. He's a very smart guy, and I've been spoon-feeding him through one part or another for the last few weeks when we have some free time. I'm trying to get him trained up on animation, but he just kind've stares at it and gets that "geez, this is really complicated" look, which sucks, because I was hoping I'd have help for my mods, and not have to be the Developer of Everything, as usual
When I showed him Servo, and how it works, after rigging up a human model with null-point reference pieces and other things, his eyes finally lit up- our hours of painstaking work doing the model assembly, we finally seemed to have gotten somewhere that didn't seem like Work. Then I explained that basically... Servo is buggy, and you need to build one animation, frame-by-frame, and then export to Scriptor and painstakingly work the output code, because, among other things, it won't output timestamps correctly.
His response was, "but, um... when do I get to see the animation?" I kind've looked at him sadly, and said, "Well, you can either view it in Servo, which kind've works, or... um... you can see it in-game." That is the primary problem with development, imo, and why we mainly just see things that do simple rotations, or things that do a very simplistic tank animation. Not because people lack imagination, but because they're getting stuck in the transition from abstract code to working unit.
I think that it would be easier to do this than incorporating a whole new animation library into Spring, though. Spring is built around BOS. If we went to an all-new animation format, we'd lose backwards-compatibility, or have yet another layer of kludge. I think that'd be a waste of resources.
BOS has advantages and disadvantages. I think we should build on the advantages, and lose the disadvantages.
And I'd be fine if BOS could just support a larger command-set, no longer required compilation via Scriptor (which would take us around a lot of the current Catch-22s) and that was that... like the new unit/weapon features, it'd be an advanced set of functions, documented in the Wiki or maybe in a helpful guide by game developers.
The only problem with that, as far as I am concerned, is that it doesn't really help with the core issue- which is that very few people have shown the skill levels required to step into this environment and make entirely new game designs. I would think that we'd have a lot've fledgling teams here by now, but I think that the sheer complexity is driving them away. It's not that you can't do some amazing things with Spring, really- it's that it's hard, if you don't already have the background.
I have been showing a friend of mine, step by step, how to walk through building a TA mod with Spring. He's a very smart guy, and I've been spoon-feeding him through one part or another for the last few weeks when we have some free time. I'm trying to get him trained up on animation, but he just kind've stares at it and gets that "geez, this is really complicated" look, which sucks, because I was hoping I'd have help for my mods, and not have to be the Developer of Everything, as usual
When I showed him Servo, and how it works, after rigging up a human model with null-point reference pieces and other things, his eyes finally lit up- our hours of painstaking work doing the model assembly, we finally seemed to have gotten somewhere that didn't seem like Work. Then I explained that basically... Servo is buggy, and you need to build one animation, frame-by-frame, and then export to Scriptor and painstakingly work the output code, because, among other things, it won't output timestamps correctly.
His response was, "but, um... when do I get to see the animation?" I kind've looked at him sadly, and said, "Well, you can either view it in Servo, which kind've works, or... um... you can see it in-game." That is the primary problem with development, imo, and why we mainly just see things that do simple rotations, or things that do a very simplistic tank animation. Not because people lack imagination, but because they're getting stuck in the transition from abstract code to working unit.
-
Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
-
Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
Here ya go.
This appears to be the genuine sourcecode for Rhad's Servo. I hope that's useful to ye, Zaphod et al
This appears to be the genuine sourcecode for Rhad's Servo. I hope that's useful to ye, Zaphod et al
Ok that's pretty cool. I have taken a look at it but I don't know if I can use it. AFAICS, The BOS writing is spread across various parts, so that makes just copying and adjusting it to the upspring structure a lot harder.
My current plan with upspring is to bind a scripting language (no not lua
), and then add animation to it so someone else can write a plugin script to export the animation info into a BOS script, or other things.
I think that would offer more options, and saves me from learning how to do BOS scripting (Which is something I'm really not interested in).
My current plan with upspring is to bind a scripting language (no not lua
), and then add animation to it so someone else can write a plugin script to export the animation info into a BOS script, or other things.I think that would offer more options, and saves me from learning how to do BOS scripting (Which is something I'm really not interested in).
I'm pretty confused here.
If you're just going to use a new scripting language that's not LUA... um... what is it?
Maybe it's just me, but I see no point in bothering with a translation step- if I have to learn a new scripting language to get down-and-dirty, and it lacks the problems of BOS, that's what I'd rather do, rather than make an animation, run it through a translator, which may or may not bork it, and then have to hand-debug it, and then hope that I can compile it into COB.
That seems like a ridiculously large number of flaming hoops and possible pitfalls. If Spring is going to use an all-new scripting language to describe the motions of animated objects... then, um... let's talk more about that.
That's an entirely different animal- you're basically saying that everybody's going to have to learn a new scripting language in order to get the benefits of better motion code. I'm just fine with that, and I'll sit down and learn it, but if you don't know BOS, then you don't really understand why we'd like to keep its strengths... and lose the weaknesses. BOS is extremely powerful and flexible- its main weaknesses, in a Spring world, is that we lack a good content-development environment, and it'd be nice to ditch Scriptor and COB completely, so that we can have... for lack of a sexier term... BOS++... BOS with extra functions, that will run un-compiled (or will be compiled within the editing environment, so that we can catch bugs as we build our animations, which would be ideal).
If you're just going to use a new scripting language that's not LUA... um... what is it?
Maybe it's just me, but I see no point in bothering with a translation step- if I have to learn a new scripting language to get down-and-dirty, and it lacks the problems of BOS, that's what I'd rather do, rather than make an animation, run it through a translator, which may or may not bork it, and then have to hand-debug it, and then hope that I can compile it into COB.
That seems like a ridiculously large number of flaming hoops and possible pitfalls. If Spring is going to use an all-new scripting language to describe the motions of animated objects... then, um... let's talk more about that.
That's an entirely different animal- you're basically saying that everybody's going to have to learn a new scripting language in order to get the benefits of better motion code. I'm just fine with that, and I'll sit down and learn it, but if you don't know BOS, then you don't really understand why we'd like to keep its strengths... and lose the weaknesses. BOS is extremely powerful and flexible- its main weaknesses, in a Spring world, is that we lack a good content-development environment, and it'd be nice to ditch Scriptor and COB completely, so that we can have... for lack of a sexier term... BOS++... BOS with extra functions, that will run un-compiled (or will be compiled within the editing environment, so that we can catch bugs as we build our animations, which would be ideal).