Spring RTS Engine

Posted: **22 Dec 2016, 22:57**

This troubled me greatly:

viewtopic.php?f=11&t=35843

I even PM'd him with the offer of 1:1 help if he were to contribute to rewriting the tutorial. Alas, he is lost.

Community is on the wane in many respects, one thing that might improve it is better introduction for new content developers, partly as an end unto itself and partly as a way to 'advertise' Spring as an engine.

https://springrts.com/wiki/User:Flozi/Tutorial

I propose replacing the 'Complete Spring tutorial' with smaller, more manageable 'lessons' that take a new dev through the motions required on a very basic level (For instance, on the first lesson an s3o would be provided without recourse for 'heres a whole tutorial on using wings and upspring'). There would then be a further series of 'In Depth' articles looking at more advanced use of Spring. Finally there would be the current API pages for expert users. This concept is built around something Smoth proposed a while back for a 3-tiered documentation; perhaps each page can have a relevant template added with a Bronze / Siler / Gold star or such to indicate what level of knowledge it is aimed at.

Obviously I am willing to put time and effort into creating some of these myself, but I am not an expert on everything. Who might offer some help?

RFC on the page and the post, thanks.

Posted: **22 Dec 2016, 23:38**

I think that "making a complete" spring game is so much work that its mad to even suggest the option to new devs. I don't see much potential for new devs to start that way, even if we had perfect tutorials, its just too hard for a newcomer. Instead I think we should encourage them to borrow units from elsewhere (as a starting point) and then get going with lua & chili, or to try and attach to dev teams of existing games.

Imo a good way to approach this is

(a) Finally fix the fact that new users are being directed to https://springrts.com/wiki/Download resulting in a wtf content-less spring.exe that they have no idea how to use. I have tried this before and reached viewtopic.php?f=1&t=35622&p=579576&hili ... ds#p579695 which seems like the crucial thing to change... if I had commit access to the website I'd change it like a flash.

(b) A tutorial based entirely on ABC, which would start with C and look at the process of
* taking a pre-existing unit out of another game, say ZK, and adding it into C.
* writing a simple chili widget and adding it into C (I'm happy to do this part).
* writing a simple gadget, that interacts with the new unit, and adding it into C (also happy to do this part).
* then, a short explanation of what the pre-existing parts of C do, and what A and B are, by comparison to C.

(c) Re-write some of the existing stuff to discuss making units from scratch, but not include it in a beginners tutorials.

(d) Archive/delete ALL the old "everything in one" tutorials in a way that means new users will never find them.

Posted: **23 Dec 2016, 00:17**

Silentwings wrote:I think that "making a complete" spring game is so much work that its mad to even suggest the option to new devs. I don't see much potential for new devs to start that way, even if we had perfect tutorials, its just too hard for a newcomer. Instead I think we should encourage them to borrow units from elsewhere (as a starting point) and then get going with lua & chili, or to try and attach to dev teams of existing games.

We have a similar perspective, though I think number fiddling in a unitdef (and even a basic stumpy-like tank script) are easier intros than a chili widget; to each his own biases. Also the 'just join another group and see how it's done' approach is not very appealing to someone looking to create their own masterpiece, no matter how good advice it may be.

Imo a good way to approach this is

(a) Finally fix the fact that new users are being directed to https://springrts.com/wiki/Download resulting in a wtf content-less spring.exe that they have no idea how to use. I have tried this before and reached viewtopic.php?f=1&t=35622&p=579576&hili ... ds#p579695 which seems like the crucial thing to change... if I had commit access to the website I'd change it like a flash.

I actually don't have a problem with the content-less spring.exe for developers, so long as the guides bear it in mind. Developers need to get accustomed to running spring.exe directly without lobbies, and magic-pixie-dust rapid files are no good for peaking inside of, either. I do agree that the whole lobby/installer download and get started is a total mess, though.

(b) A tutorial based entirely on ABC, which would start with C and look at the process of
* taking a pre-existing unit out of another game, say ZK, and adding it into C.
* writing a simple chili widget and adding it into C (I'm happy to do this part).
* writing a simple gadget, that interacts with the new unit, and adding it into C (also happy to do this part).
* then, a short explanation of what the pre-existing parts of C do, and what A and B are, by comparison to C.

Concur that it should be based on ABC, though i favour teaching how to construct a rudimentary unitdef and script, copying other (art) assets. As such I might start with B rather than C, or at least, widgets and chili would be a separate lesson and not the first step. Ditto the gadget. lesson 4 and 5 respectively in my schema)

(c) Re-write some of the existing stuff to discuss making units from scratch, but not include it in a beginners tutorials.

Do you really think making unitdefs is harder than chili widgets?

(d) Archive/delete ALL the old "everything in one" tutorials in a way that means new users will never find them.

I'd probably just outright delete most of them. Some parts might be scavengable but imo we should have e.g. guides on how to import models into Spring via different methods but no guides on modelling a tank.

Posted: **23 Dec 2016, 01:05**

Developers need to get accustomed to running spring.exe directly without lobbies

I never have. Why would you?

Do you really think making unitdefs is harder than chili widgets?

Making from scratch, yes - modifying already existing, no. I agree that fiddling with numbers in a unitdef is something worth including at/near the start.

widgets and chili would be a separate lesson and not the first step

Maybe it makes sense to have two separate pathways, one towards unit creation and one towards lua use, that can be followed independently. I think there are quite a few people who get good at lua but never get into model/script stuff.

Also the 'just join another group and see how it's done' approach is not very appealing to someone looking to create their own masterpiece, no matter how good advice it may be.

Afaics people with unrealistic expectations of their own abilities eventually get what they deserve, one way or another, and there's very little docs/help can do to change it. For this, I can't imagine anyone being successful without soon joining #moddev to talk with humans and be directed towards examples from BA/ZK/etc.

Posted: **23 Dec 2016, 05:56**

I constantly have a stream of guys from steam who very much want to help and get into it, but frankly, I don't ahve the foggiest idea to tell them where to start.

As far as content that is free that they can use... Dude, Evo has shitloads of content they can use. Additionally Evo's master lego file is in the repo, so if you use legos you instantly get access to all of those already completed models where you can make new ones for yourself as well. As far as performance, the master atlas that evo uses is 512x512 for something like 70 units or so? That's pretty disgustingly efficient and frankly we should encourage lego-style unit creation. It's far easier and it results in far better performance. If they want specific individual textures for each unt, then ok, more power to them, but there is no harm in strongly suggesting unified atlas.

If you want to have a slightly more advanced version of ABC, just pull content from evo and stick it in there. For that matter you (or I, I guess) could make a very simplistic rps style of game with very basic spring engine mechanics and a bare minimum of lua wizardry which would be more of a practical base to work from than abc. I actually disagree with this statement, however, from a visual standpoint, abc is too basic, and I think that at the end of the day, it actually hurts itself wrt new devs because of it.

It should be emphasized how quickly you can get a basic game going. Hell, most of us could probably reuse content to death and have a new game ready to go in an afternoon. Speed appeals. If you can get someone to create a basic game quickly, then imo they will be hungry for more.

Frankly, that's how most of us started out.

Posted: **23 Dec 2016, 09:38**

Smaller, more manageable parts is definitely preferable, especially since it could serve as reference for more experienced devs later, and is easier to keep updated.
Random comments:
1. better use .dae or similar file formats - more likely people are familiar with it and/or can edit it easier.
2. spring.exe is OK for development. It's just confusing for players.
3. Teach people how to add libraries to their game, rather than just use existing template repos like ABC or the SkeletonGame from SpringCabal. It's an important skill as they'll likely need to add custom stuff and be able to update later.

Posted: **23 Dec 2016, 11:08**

Silentwings wrote: I never have. Why would you?

All lobbies suck.

Making from scratch, yes - modifying already existing, no. I agree that fiddling with numbers in a unitdef is something worth including at/near the start.
...
Maybe it makes sense to have two separate pathways, one towards unit creation and one towards lua use, that can be followed independently. I think there are quite a few people who get good at lua but never get into model/script stuff.

I also considered making it less linear so that we might direct people to start at the point that interests / is relevant to them, but that might require a new TutorialGame along the lines Forb is suggesting so that the content is already there to play around with - it's hard to write a useful widget when there are no units available.

Pathways is an interesting concept and i agree that many people have specialisms in either artwork or code side, but both (in my experience) tend to be comfortable with modifying a def. I do agree that constructing defs is somewhat more challenging but that's only if you don't know what you need... that is why we end up with copy pasta defs that still contain OTA tags that never existed in Spring over a decade later. In a tutorial you can introduce tags as needed and explain why thoroughly.

Afaics people with unrealistic expectations of their own abilities eventually get what they deserve, one way or another, and there's very little docs/help can do to change it. For this, I can't imagine anyone being successful without soon joining #moddev to talk with humans and be directed towards examples from BA/ZK/etc.

Not untrue, and I am always a fan of promoting #moddev and realtime feedback, but some things are better committed to the page.

The Mighty Forbo wrote: I constantly have a stream of guys from steam who very much want to help and get into it, but frankly, I don't ahve the foggiest idea to tell them where to start.

Good to hear there is interest, and this is aimed at establishing a solid starting point.

As far as content that is free that they can use... Dude, Evo has shitloads of content they can use. Additionally Evo's master lego file is in the repo, so if you use legos you instantly get access to all of those already completed models where you can make new ones for yourself as well. As far as performance, the master atlas that evo uses is 512x512 for something like 70 units or so? That's pretty disgustingly efficient and frankly we should encourage lego-style unit creation. It's far easier and it results in far better performance. If they want specific individual textures for each unt, then ok, more power to them, but there is no harm in strongly suggesting unified atlas.

Good to know that Evo is a source of free artwork we might utilise, but I would point out that atlassing is an approach that works for some game designs rather more than others; those that reuse common textures. Atlassing all units in S44 would be utterly bonkers (we use atlassing on a smaller scale where units look mostly similar i.e. each nations infantry (could be 20+ units) each share a single texture e.g. GBRInfantry.dds)

If you want to have a slightly more advanced version of ABC, just pull content from evo and stick it in there. For that matter you (or I, I guess) could make a very simplistic rps style of game with very basic spring engine mechanics and a bare minimum of lua wizardry which would be more of a practical base to work from than abc. I actually disagree with this statement, however, from a visual standpoint, abc is too basic, and I think that at the end of the day, it actually hurts itself wrt new devs because of it.

I'm not sure that recreating SpringTutorialGame is really the best bet, and visually no such mini game will compare to the manhours invested in Evo, ZK, etc. I am more attuned to teaching the basics, there are a huge number of public repos to point at for more visually stimulating and complex game design implementations.

It should be emphasized how quickly you can get a basic game going. Hell, most of us could probably reuse content to death and have a new game ready to go in an afternoon. Speed appeals. If you can get someone to create a basic game quickly, then imo they will be hungry for more.

Frankly, that's how most of us started out.

I agree. Let me again reiterate that all artwork would be pulled from existing games, only defs, scripts and lua would be being written 'from scratch' and even then they would be either copy-paste snippets from the wiki itself or downloadable files to shove in your sdd.

Gajop wrote:Smaller, more manageable parts is definitely preferable, especially since it could serve as reference for more experienced devs later, and is easier to keep updated.
Random comments:
1. better use .dae or similar file formats - more likely people are familiar with it and/or can edit it easier.
2. spring.exe is OK for development. It's just confusing for players.
3. Teach people how to add libraries to their game, rather than just use existing template repos like ABC or the SkeletonGame from SpringCabal. It's an important skill as they'll likely need to add custom stuff and be able to update later.

Wins all round.

1. As noted above artwork will be pulled in so s3o vs dae isn't a major factor for such a tutorial imo. This may be my own s3o bias shining through though (Search mantis for assimp). 2. I agree. 3. Via modinfo and rapid tags? Still don't work properly afaik, c.f. why I run via spring.exe at the top of this post.

edit: Further to the final point:

Code: Select all

[17:49:01] <[S44]FLOZi> ok got it working
[17:49:06] <[S44]FLOZi> strangely, F11 is taking screenshots
[17:49:12] <[S44]FLOZi> widget menu?
[17:53:55] <[LCC]jK> ah
[17:54:09] <[LCC]jK> maybe the basecontent handler doesn't got the new widgets needed
[17:54:23] <[LCC]jK> I got a github repo with those
[17:54:57] <[LCC]jK> (widget menu is a widget itself that's why)
[18:00:48] <[S44]FLOZi> hmm
[18:00:58] <[S44]FLOZi> so at the moment, still not so simple
[18:03:02] <[LCC]jK> it is (semi)
[18:03:19] <[LCC]jK> but I have to leave the house in 30mins to get my flight :x
[18:03:53] <[LCC]jK> duno if i can help you from Bonn (without my desktop pc)
[18:05:23] <[S44]FLOZi> point me at the repo? :)
[18:05:37] <[S44]FLOZi> https://github.com/jk3064/new_widgethandler ?
[18:06:50] <[LCC]jK> yes
[18:08:04] <[S44]FLOZi> still, not in base content or in chili, so games must include them, that is what I meant by 'not so simple'
[18:08:39] <[S44]FLOZi> not yet at the 'depends = "chili blah blah" ' and go :)

You have to manually include selector.lua and LuaUI/Utilities/fonts.lua to get the widget menu (there's other stuff missing too).

Posted: **23 Dec 2016, 23:09**

At this point utilities should be part of basecontent. I ran into the utter fail that is not having utilities when working to update BA. At this point it is basically essential, and I feel as though anything that is essential should be included in the engine as usually there are no clean repositories for these essentials.

Posted: **23 Dec 2016, 23:32**

I want to suggest a alternative route to keep the wikki dokumentation up to date with less work for FLOZi.

The Idea is simple- add a questionmark Button to every Headline in the wikki.
1.If a user presses the Button a form enters, where the user can state his question. Also a link to Turboss WebIrc Client is offered.
2. The Question is together with the wikki-part then send to a channel dedicated to questions. Can be moddev, can be sy.
3. The Answer is discussed.
4. The Answer is stated e.g. : @Wikki "Units will turn there piece on the shortest route, so if you want to complete a full turn, you will have to break it up into two turns. Such functionality might be found in several lua libs allready."
5. The answer is then appended to the Wikkis article.
6. Updated Wikki, Instant Connection of searching Users with Community Core.

+1 To Forboding Angle

Posted: **24 Dec 2016, 02:40**

Would be better to send them to Discord. It is far more widely used by gamers, and it is a lot easier to manage conversation. There are ton's of APIs that should make a lobby<>Discord bridge a fairly straight forward process. If we could get someone to give it a shot, that would allow Discord <> lobby communication which would put us in far easier direct contact with users.

Posted: **07 Feb 2017, 14:15**

I constantly have a stream of guys from steam who very much want to help and get into it, but frankly, I don't ahve the foggiest idea to tell them where to start.

Sad that so many people's first contact with spring is with someone who does not have the foggiest idea to tell them where to start.
That makes it ineffective to improve tutorials or documentation because it will be ignored anyway.

Posted: **07 Feb 2017, 14:25**

Dev-Apprentice ticket system?

Assign easy to solve bugs to it, and new-devs can get right into it.

Posted: **07 Feb 2017, 14:26**

8611z wrote:That makes it ineffective to improve tutorials or documentation because it will be ignored anyway.

That's complete horsecrap. The lack of proper tutorials or documentation geared towards total complete noobs is exactly why I don't have the foggiest Idea where to tell them to start.

Your position seems to be that they should be pointed at the wiki with a swift pat on the back. They will spend 5 minutes on it, then go do something that is actually interesting.

Perhaps you should share where you would tell them to start.

Posted: **07 Feb 2017, 14:31**

Forboding Angel wrote:
8611z wrote:That makes it ineffective to improve tutorials or documentation because it will be ignored anyway.

That's complete horsecrap. The lack of proper tutorials or documentation geared towards total complete noobs is exactly why I don't have the foggiest Idea where to tell them to start.

Sorry, but to me you do not appear to be the person to judge documentation because you regularly fail to use it, even when pointed to it, and complain even about the parts that are best maintained.

Your position seems to be that they should be pointed at the wiki with a swift pat on the back

I did not write this. If you want to lead both side of this discussion then feel free to talk to yourself.

Posted: **07 Feb 2017, 14:36**

Forboding Angel wrote:Perhaps you should share where you would tell them to start.

Posted: **07 Feb 2017, 14:38**

in this forum.
not on dozen external chat channels, social media crap profiles and all the other dead places with only one person to answer. (and maybe not even able to give an answer)

Posted: **08 Feb 2017, 22:00**

Get a thread you two - and keep it there. Not everyone can get up late, because your loves decibels go through all dry walls.

Posted: **10 Feb 2017, 21:47**

I dont think beyond improving the wiki a whole lot can be done to make spring easier usable without significant effort.

Another problem that is a major downfall from my view is still the lack of a central repository for standalone gadgets/widgets and other assets.
In many ways accessability and sharing of assets would make development much more convenient.
For example godot has such a thing, i dont know how useful it is, but it sure as hell is a better option than digging in repos to find a healthbar widget, for example.

I am working on a cheapo spring ide sort of thing, but i dont think it will be usable for newbies and dont hold your breath, ill have to see how this turns out ad maybe i can give more significant feedback on such projects.
Another idea could be an ingame game editor, but i have no idea how flexible spring is terms of writing to files it allows.
A text editor and perhaps asset editor in lua could be doable for certain, but if useful is another question.
An ingame balancer tool might be useful, i will make one eventually but dont hold your breath there either.

Im not aware of the state of the new development tutorials and single unit mod, but sounds like something not too hard to clean up.
If you guys think its a good idea checking it i could do so.

I must also say to be honest i dont think spring is ready to the general public yet.
The pathfiding, targetting and collisions and cross interaction of those from my experience is horrible, i can understand such things, but people from not technical backgrounds unlikely will be.

I cant belive its been three years since i started myself, what a ride.

Posted: **10 Feb 2017, 23:09**

I am abstracting gadgets quickly and giving them their own repo. Lately sprunk has been helping me. I feel the same as you about it, hence, https://github.com/Spring-Helper-Projects

Posted: **11 Feb 2017, 01:06**

There was a widget database but afaik it died. Gadget database never really got going due to it being a flawed concept; IMO drag and drop gadgets are nice in theory but rarely pan out in practice, c.f. the bloated mess that is the morph gadget.

My suggested alternative was a technical 'showcase' with direct links to gadgets that implement particular gameplay features https://springrts.com/wiki/User:Flozi/S ... f_Interest

Spring RTS Engine

Improving the 'New Dev' Experience

Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience

Re: Improving the 'New Dev' Experience