Spring RTS Engine

btw, was wondering. is it ok if i advetise games mentioned above on one of the forums ? (of the biggest gaming magazine in my country, probably biggest in this part of europe. long time ago they released TA together with magazine )

knorke wrote:*a players

this

Karl wrote:Well i actually meant for Mods to using maybe a Folder on the Root of it
something like this .../Spring/Translation/Modname/Language Folders
that should be fleasible instead of making it on mods directly due to obvious reasons

Again and who would populate all the translations? It isn't a simple operation we are talking hundreds and hundreds of strings. After that suppose the player needs support but cannot communicate in english. Unless they are japanese I am not going to bother trying to google translate it.

zwzsg wrote:I mean, it could be done by a modder, just lots of work.

A LOT OF WORK ontop of A LOT OF WORK already

smoth wrote:who would populate all the translations

Users. Have a look at the current SL status. Neither BD or I have translated more than a handful of those.

Gundam frequently changes, so say I update a unit and it's description for it's role changes dramatically. That is where you run into things.

With the gettext method the translation of the changed string would then be missing, not stuck on the old one, if that is your concern.

how do you mean?

The gettext method in short:
- dev marks strings as translatable/for extraction (for example with a macro.function)
- tool extracts those, generating a translation template containing all translatable strings, their positions and such
- user submits a file based on that template with the actual translated strings for a given locale
- at runtime strings are loaded from those files. If a translation is missing, the untranslated string is used

Now if you change a string, that's basically providing a new string to translate. So if you don't get an updated translation file containing the new translation for the next release, that string will simply be untranslated.

I dont like most translated programs. The translations often sound strange (and you have to guess what they mean by translating it back to english).
And sometimes they break the GUI when the translations do not fit in their GUI elements.
Sorry, but I really dislike german springlobby for instance ("Schlachtraum" anyone? ). Same for git-gui, its not usable in german translation.

I absolutely agree. In fact all my boxes have their locale set to en. From my experience around colleagues and friends I'm in a tiny minority with this though.

I already showed the numbers- the A*'s aren't a threat to anybody's marketing plans.

The rest of the analysis is equally questionable:

First: A large number of people would not be able to play the most popular game without treading into ÔÇ£questionable intellectual propertyÔÇØ territory regarding ported content.

If we go by most popular, and we exclude P.U.R.E. and BA, CA is the most popular, in terms of downloads worldwide. I did some checking on their numbers, and if they had a solid SP experience, they'd be a very popular game.

Second: The engine and games for it, while very playable, lack a certain amount of ÔÇ£somethingÔÇØ that would really make them shine. People tend to waffle on what this ÔÇ£somethingÔÇØ is, be it barriers to new player adoption like lack of tutorial campaigns or GUI or stability issues or whatever.

The main lack is having SP gameplay and a polished frontend. Both are areas of engineering concern. Quantum's work on the Mission Builder is very important, and what Quantum's done is very exciting.

The fact that we don't have a decent game-skinnable frontend that is simply a part of the engine at this late date is a mystery to me.

Is it because people with commit access have refused to let this happen, as AF semi-suggested, or because nothing has been done because nobody has described what we need it to do (in which case, I may find time to describe a business case) and established some agreement with everybody?

In addition, the idea that campaigns are just "tutorials" is a very shallow understanding of the RTS market. Of the people who bought Starcraft II, for example, less than 15% have played it online at all. The fact that people here still don't understand what these numbers mean is pretty funny. People do not play RTS games online at anywhere near the levels that they expect to play a FPS online. Developing solely for the online segment is a strategic error.

Third: That the ÔÇ£engineÔÇØ shouldnÔÇÖt be marketed directly because it is the responsibility of game makers to promote their own games/content.

There is no point in advertising the engine as an engine, other than to researchers and academics looking for something that does RTS functionality, and in many ways, the complexity of the engine makes it unattractive. The engine developers would be doing themselves a giant favor by actually acting upon the query which came up about porting more engine functionality over to Lua, other than core processes, so that the underlying engine is cleaner, meaner, and more focused.

The attractiveness to teams seeking an engine for commercial purposes is zero, because it's so dated and all code would have to be GPL'd. There are few people out there who want to develop really hot tech and put it under GPL in that context, which also makes it harder to attract people to work on the engine, especially when they could work on OGRE and sell their work instead.

The attractiveness to serious mod teams is also zero, because the engine's graphics are so dated compared to anything modern, building new content is difficult, there is no library of plug-in-and-make-game content available and other problems. If you mod Crysis, you don't have to model / rig / animate / code / etc. / etc. every tree in the forest- with Spring, you are largely stuck. This is a very bad situation, and I don't know what to do about it, other than to continue working on World Builder content and hoping that eventually people get it, or that somebody builds some tech that uses it that makes it obvious to everybody, like a copy of the Starcraft II map editing system (which, again, people here need to go view some videos about- it makes the best stuff we've done look sad indeed).

In short, other than attracting more research projects (which isn't bad, but is hardly a raison d'être for a game engine) the engine is actually a negative. Until the fundamental engineering problems have been solved and the engine is modern enough to be presentable, emphasizing the engine will be counterproductive.

It would probably be a good idea for Spring to explicitly advertise for more engineering talent through various resources at this time, but it would be very unwise to try and put Spring up against OGRE, Unity3D et al.

We don't need to worry about "competition" from other engines atm, because either the people seeking an engine want something modern, or they really don't care, so long as it isn't utter rubbish, and are much more interested in the powerful, flexible Lua guts of the engine (which is the only thing about Spring that is remotely attractive atm) or want a RTS gametype without much work.

But basically, without the games, Spring's not that interesting atm. Also, we don't even have any official tech demos to show the engine off, and if we did, we've been breaking backwards compatibility a lot over the last year, and until MT is final, it would probably be unwise to consider building one, because it might become bit-rotten fast.

Argh wrote:... or because nothing has been done because nobody has described what we need it to do (in which case, I may find time to describe a business case) and established some agreement with everybody?

No, it's because that's ALL most people ever do.

Well, I've got a simple solution (had a smoke, and voila):

Get rid of the front-end entirely, and run an unsynced Lua Gadget callin called FrontEnd(gamemode) where the gamemode is whatever we want to define, but by default 0 is stock behavior for "developers", 1 is for MP.

Voila. Leverage jK and zsxwg's work on UI and frontend development under Lua, get some decent graphics built for a stock design, and voila, we could have something decent inside a month that people could fork for whatever they want, and it'd no longer be an engine developer problem to solve.

Other than the callin, I think all we need is for FrontEnd to simply return true when whatever else needs to happen (user input, etc.) is done, and until then, let everything go through a stock-standard DrawScreen() loop. While it returns false, the game remains un-started. So MP games could just pass it an argument of 1 (i.e., go straight to return true, do not pass Go) and everything else could do whatever it wanted. Add an engine argument for what to pass FrontEnd when a shortcut to Spring is double-clicked, and there we go. It wouldn't be a lot different than what zxwsg's done for the KP UI, except that it wouldn't involve a weird-looking (from an end-user's POV) restart of the engine, and it wouldn't be prone to bit-rot due to engine changes.

I like this solution, because it would get it out of the engine-developer area and into working-model area with a minimum of fuss and argument, because if X project doesn't like Y feature, they can fix it themselves without having to build the engine or ask permission from anybody. So, no more pointless arguments about what we want it to do or how we want it to look, the Devs can safely abandon this area to us annoying people who actually build the games, and most of the tech is already available, in the language we'd want to use to do it.

Anyhow, there ya go- business case is for freedom and lack of engine-side implementation, which has led to a frustrating lack of new development, largely because nobody can agree on the business case beyond the basics, which are not impressive.

I'd be happy to contribute time to provide a skin (I would like to see a stock UI that simply reproduces the current frontend's behavior for this that picked a skin at random, so that instead of an Official Skin, multiple artists can contribute without the usual self-defeating forum wars) and maybe some coding time to this.

koshi wrote:I absolutely agree. In fact all my boxes have their locale set to en. From my experience around colleagues and friends I'm in a tiny minority with this though.

same here!
even most guys i know from the uni, which all had their 7+ years of english classes, to a great proportion still prefer translated applications and games.
Maybe that is cause we in the german speaking area are spoiled by generally quite good translations, like with all the movies, for example. Actually, i often like the german version better then the original english one (movies).

I think translated software is mostly ok as long as it is done by professionals. I dont have a problem for example with a german Windows or Office. But it is quite obvious for the user if the translation has been done by the coders which is probably the case for most smaller projects. In this case better stick to the english version if you dont have a graduate translator at hand who can do it for you. IMO.

very_bad_soldier wrote:I think translated software is mostly ok as long as it is done by professionals. I dont have a problem for example with a german Windows or Office. But it is quite obvious for the user if the translation has been done by the coders which is probably the case for most smaller projects. In this case better stick to the english version if you dont have a graduate translator at hand who can do it for you. IMO.

This is very true. As someone who works very closely with a Translation agency owned by a 74 yr old german lady, I've seen the horrible translations that get pushed around. Also, there is a difference in the style used by north germany as opposed to south germany. Iirc, south germany uses a lot of neuduetch (spelling?) which is kind of a mishmash of english and german used for terms relating to computers and the like, whereas north germany is more "aristocratic" in the style used (I might have the north/south thing flipflopped, but yeah, the point is there).

VBS wrote:I dont like most translated programs. The translations often sound strange (and you have to guess what they mean by translating it back to english).

I share the feeling.

Even native speakers have trouble steering away from english style and wording when translating from english. I mean, they'll pick words that are phonetically close to the english word, but unusual even if technically somewhat correct. They'll construct sentence in a way that's grammatically allowed, but not how they'd have expressed themselves if they weren't in the context of translating from english. It's subtle, and ends up giving a feeling of oddness without any particular translation error to pinpoint. Amateur translators too often forget that translation is not about replacing each word with its equivalent, but that each language has its habits, its quirks, its history, its preferences, its usual expressions.

For technical stuff, there's also the issue that some words have very precise meaning, and that you have to understand what the software really does and to know both jargon of the field to translate appropriatly.

Smoth wrote:Again and who would populate all the translations?

When I said lots of work, I didn't mean the translation effort itself. I mean it would be lots of work to simply put the mod in a state where it is translatable, that is, where every bit of text is neatly marked as such and easily swappable.

I feel all of it is a lot of work z, it seems like it would add on the the pile of shit already eating up my time.

Realise that chickens is not something you can shove in and say 'we have singleplayer!' its not even the same game mode

No one said it is. The projects that are using chickens built in also have zwzsg's mission code . Singleplayer missions in a proper campaign form are just one of those "shit that is on the bottom of our list"

SpringRTS for the Masses

Markets:

RTS Gamers
RTS Gamers who are also Developers
RTS Gamers who are also Developers who are also Game Designers
RTS Gamers who are also Developers who are also Game Designers who are also Artists
Gamers who are also Free Open Source Software Enthusiasts

So as you can see, if we can target Gamers we should, theoretically hit everything else we need.

Stickiness:

We need to make both our Product(s) and our Message consistent and palatable. We need to make ÔÇ£springÔÇØ stick in peoples brains like a bad Internet meme so they pass the disease onto others.

Ideally, this is how I want Users to ÔÇ£get intoÔÇØ spring.

1) PersonS tells PersonN about a awesome free game they play (AFG).
2) PersonN looks into AFG, sees that it is indeed both free and awesome (screenshots, feature list etc.) and downloads and installs it from a page specific to that game. The installer will inform the user that the shortcut for the game will be in a start-menu folder called ÔÇ£springÔÇØ and that the game will be installed in a directory called ÔÇ£springÔÇØ as that is the engine the game uses.
3) PersonN plays a single-player campaign for AFG which is fun and entertaining while teacheing him how to play itself.
4) PersonN is now ÔÇ£ConvertedÔÇØ to spring, even though they donÔÇÖt realize it yet.
5) PersonN decides they know how to play AFG well enough and chooses the ÔÇ£MultiplayerÔÇØ option from AFG and it loads up a lobby client first time ÔÇ£selectorÔÇØ screen which informs them that the project is supported by a few different lobby clients etc... when they pick one it will add new start-menu items for the lobby and one to change lobbies.
6) PersonN will (hopefully) see a game of AFG hosted in the games list... something like

Installed Games
-Awesome Free Game (version 8.9) <- most recent installed version
--game room1information
--game room2information
--game room3information
--game room4information
--game room5information
-Awesome Free Game (other versions) <- these would be green for installed, red not
--AFG8.8 - game room1information
--AFG8.6 - game room2information
--AFG8.6 - game room3information
--AFG8.5 - game room4information
--AFG8.8 - game room5information
Other Games
--CA8.2 - game room1information
--GRTS0.1 - game room2information
--XTA7.9 - game room3information
--ETC - game room4information
--ETC - game room5information

(note that this implies that our ÔÇ£promotedÔÇØ game installers only install lobbies that support this ÔÇ£formatÔÇØ... which should be trivial)

7) PersonN plays online matches of AFG and perhaps eventually thinks about trying the other games, simply double-clicking on a room for a game he doesnÔÇÖt have prompts to install that game and adds a single player short-cut specific to that game to his spring start menu.

At any point in the process if PersonN becomes more interested in the project then as ÔÇ£justÔÇØ a gamer, he can easily come to this site and find out more about us.

koshi wrote:Maybe a CA dev could comment on why they chose the translations approach they did, instead of gettext for example? With gettext support you could leverage a lot of already existing toolchains. Also there's http://www.transifex.net/ which I've moved SpringLobby's translations to from launchpad.net a short while back. Transifex allows for very easy integration of contributed translations.

Currently the only translations in ZK (CA) are unit help texts. Those are defined in the unitdef files. Anyone can join the project and add translations.

Here's an old pic I posted on the forum a while ago: