Spring RTS Engine

If Evo is to be completely free (that's what the page says) then what does Steam get out of this?

Google_Frog wrote:If Evo is to be completely free (that's what the page says) then what does Steam get out of this?

Market penetration... Steam being the de facto way for people to get and play PC games is inherently valuable.

People loading steam to play Evo may spy a sale or offer, or a new game that they subsequently purchase. There's plenty of reasons aside from that, but that alone would be sufficient so long as there are quality controls.

it's my understanding that we can't couple to the closed source commercial SteamWorks API under the current SpringRTS licence

I guess if forb uses weblobby and weblobby gets some REST-like interface to communicate with Steam, then it's ok, though?

https://partner.steamgames.com/documentation/webapi

not sure whats possible through the webapi.

not sure whats possible through the webapi.

While it does seem the API docs mostly concern cpp stuff, that doesn't prevent creation of an api bridge to serve as an intermediary.

I.E:

spring (GPL2) < -- script.txt -- > weblobby (GPL2) < -- REST-- > Wrapper (MIT, BSD, W/E) <-- binary linking --> SteamWorks (proprietary)

A similar approach could be devised for SPADS hosts which Evo seems to mostly use, and/or for Springies (with additional benefit of possibly getting ZK that closer)

Anarchid wrote:spring (GPL2) < -- script.txt -- > weblobby (GPL2) < -- REST-- > Wrapper (MIT, BSD, W/E) <-- binary linking --> SteamWorks (proprietary)

you should carefully read the license of SteamWorks/NDA before doing that. not sure if the wrapper can be made open-source or if it is allowed to make such a wrapper.

edit:

https://github.com/SteamRE/open-steamworks

not sure if the wrapper can be made open-source.

That's why i wrote "MIT,BSD,W/E".

Can i read that NDA/licence thing somewhere public?

abma wrote:https://partner.steamgames.com/documentation/webapi

not sure whats possible through the webapi.

Web API keys provide access to sensitive user data and protected methods. These keys are intended to be used for Web API requests that originate from secure publisher servers. The keys must be stored securely, and must not be distributed with a game client. All Web API requests that contain Web API keys should be made over HTTPS.

OK, so maybe if the server hosting weblobby had private code for talking to the SteamWorks Web API it might work.

That said... this illuminates the issue with all of the other suggested methods... in order for secure communication to be established the client software has to know the publisher key... which needs to be buried to prevent third-parties (or cheaters) from obtaining it... making an intermediary method for allowing potentially falsified REST messages to be sent through the SteamWorks API enabled local software defeats the protection from cheating (at least in regards to obtaining achievements) it is meant to provide... though I suppose it could implement some kind of internal REST message verification code.

integrating the steam api is a lot of work and the benefits are mostly unknown (yes, its integrated then, but other problems will still exist.). not sure if the time should be used at other parts, like missions for a game. most of the features the steam api offers exist in the spring universe, too.

Let's see how it can be currently used on steam. Good luck Forb!

SinbadEV wrote:

Google_Frog wrote:If Evo is to be completely free (that's what the page says) then what does Steam get out of this?

Market penetration...

Yup, viral marketing. Valve does not have to spend much effort, devs and gamers will do it for them.
All games in competetion put links to steam on their websites.
Games want to mobilize their players to vote for them. The players will further spread the word to help their favorite games, but what they really do is spreading stream.
Steam is already pretty much known by all gamers, but this way it gets fresh wind even in communities where users might be a bit "anti steam" like indiedb/desura. Basically steam lets other people do free advertisement for them.

Didn't read this in entirety, but it mentions Steam NDA and open source software: http://www.phoronix.com/forums/showthre ... rce-spirit .
Really a PITA you would need to make wrappers and jump through hoops to use Steam within Spring legally.

@FA: Since it concerns you more than the rest of us, could you ask a question (forums or something) on Steam and link the discussion here? Would like to see if there's a reasonable solution to NDA/GPL conflict.

I think once this happens I'mma just move the evo license to cc-by-sa. Maybe tomorrow. I wanted to wait till I had all the legos done, but my time is short and I'm taking forever to get anything done these days. Only 6 models left to go.

I guess the license change doesn't really affect anything at all, considering that that was ONLY for the non-legoed models, but I really wanted to have something that newbie modders could just copy pasta, gut what they don't like, keep what they do and presto! Functioning game! Regardless, it probably isn't a big deal to anyone except me. *shrug*

WRT the api stuff, sure, I'd be happy to, but I don't really know what I'm talking about wrt spring <-> steam, so someone might want to craft the questions for me.

Isn't the point of an API the allow programs to talk to each other regardless of their origins and licenses?

Just a note on the license, your work as a whole under cc-by-sa won't do. Scripts need to be distributed under the terms of the GNU GPL and that is not a GPL-compatible license. Soo you'll have to use multiple licenses for code and content or something along those lines.

And you'll have to be very careful about all the software you include in the steam package. You'll need to worry about things like whether your distribution of Firefox can actually be branded as Firefox (assuming you're still planning on using FF with WebLobby).

Just figured I'd point this out because I suspect even an accidental misstep in the legal domain will be much more of an issue with steam involved.


Also of note is the use of Spring community infrastructure. Appearing on steam has the potential to create a significant influx of players, and this may overwhelm the infrastructure we currently have in place to serve them. Opinions on this matter will differ but I would suggest that it's very much your responsibility to provide a separate lobby server and map site in the event that this influx proves to cause issues. I might even suggest doing so pre-emptively.


Oh and congratulations are in order I suppose. Don't let these potential issues rain on your parade!

http://www.phoronix.com/scan.php?page=n ... px=MTQ4NTY

- One of the larger problems is that there's currently no free/open-source library for supporting the SteamWorks API. Valve doesn't require Steam-published titles to use SteamWorks, but then you lack many of the benefits of using Steam like statistics tracking, Steam infrastructure integration, and other features. However, Xonotic developers would likely keep using their own "XonStat" statistics component anyhow over SteamWorks support.

@peet, wrt license, I know. The GPL is a bad license for art assets, hence cc.

You're a bit behind on weblobbeh news

https://code.google.com/p/springweblobby/

Ironic you mentioning a different server after knorke butthurt all over the forums about my previous distancing myself.

In the meantime I've been sticking pretty close to spring for the past year and a half and things are going well. No need to rock the boat.

Forboding Angel wrote: WRT the api stuff, sure, I'd be happy to, but I don't really know what I'm talking about wrt spring <-> steam, so someone might want to craft the questions for me.

Isn't the point of an API the allow programs to talk to each other regardless of their origins and licenses?

From what I understand, using the Steam API involves writing C++ code that uses it, and you've signed an NDA that prevents you from sharing the details of the API (which probably forbids you from sharing your C++ code that uses it).
This means that you can't just change Spring code to use the Steam API (and thereby produce a new executable, e.g. spring-98-steam.exe) because under GPL you are required to share that code, and the NDA forbids you to do that.

You know more about the NDA than the rest of us, as you have an idea what it covers. If it allows you to share the C++ code that invokes the Steam API (unlikely I think), then there's no problem. You need to check what it covers, and what parts can be public.
What you could do I think is create a local service (closed source and not connected to spring.exe), that wraps around the Steam API, and invoke that service from Spring. This would probably be legal.

The topic of wether a program A that uses an API B in a library C that is under a non-GPL compatible license, is one that is legally ambiguous and the source of thousands of flamewars. The only reasonable conclusion is to be conservative and ensure you're okay regardless of the interpretation.

Peet wrote:Just a note on the license, your work as a whole under cc-by-sa won't do. Scripts need to be distributed under the terms of the GNU GPL and that is not a GPL-compatible license. Soo you'll have to use multiple licenses for code and content or something along those lines.

Are Lua-scripts not already under GPL anyway, because that is what their authors released them as? Is it really possible to "overwrite" GPL like that by saying "whole thing is cc-by-sa" now?