Spring RTS Engine

I don't run into zoom height limits when I'm playing..

Gabba wrote:

Google_Frog wrote:Isn't mouse position already taken into account by zoom?

How does the 'flick of a mouse wheel work'? Does it just detect when the wheel is moved faster than normal? That could be a bit of an annoying feature when you want to zoom out partially and it's easily(I think) luable.

Seriously, try it, it's only 32$ on impulse (the game+expansion), and it's a great lesson in interface design (if nothing else). I haven't even mentioned building templates.

I believe that zooming in is faster when you're more zoomed out, so that's how they achieve the "flick" effect. AFAIK nothing changes if you move the wheel slower or faster.

And as far as the mouse position you do it (more or less) when zooming in, but not so much when zooming out. Someone described it rather well in a past thread that I have a hard time finding. But it was in the Feature Requests forum.

I have supcomm. I found the interface much worse than my Spring interface(not default) and the game felt very dumbed down; few units, simple techs etc... but that's not relevant to the interface. Also I don't think you're able to change pitch in supcomm but I can't remember.

I have no trouble with zoom speed, maybe you need to reconfigure your zoom speed. I can see variable zoom speed working although I think it would be a personal preference so some kind of option would be needed.

Spring zoom already zooms to the mouse when zooming in and zooms from the centre when zooming out. The exception is when you hit the map edge which I agree is a problem and needs fixing.

The rest of the interface I'm not saying is bad. I'm saying that the interface items would be game specific so devs should implement them themselves instead of putting more hardcoded interface in the engine.

@Google_frog: the FA interface is better than original Supcom's, are we talking about the same one?

You can toggle the free cam in FA, but for playing the default works perfect. It even angles slightly as you come really close to the ground, so you can appreciate the units better.

I'd appreciate if you could post a screenshot of your own interface. But if you kept the grid-style build menu, for instance, it's hardly better than FA where units are sorted by importance, and grouped by "theme" instead of being just uniformly distributed. There are a lot of similar little details that they got right.

In any case, as long as your mega-awesome interface is not a default in most popular Spring mods, I'll continue to complain .

Also, read what I put in bold in my answer to Lurker:

@Lurker:

lurker wrote:I don't run into zoom height limits when I'm playing..

Are you in all my threads?

What Gota means in that quote, and that I've just verified, is that max zoom out in Spring doesn't center the map on screen like it does in FA. i.e. in Spring max zoom out with the wheel doesn't give the same result as pressing tab, and it should. There's no point in zooming out to see a lot of blank space.

On top of that, in FA the cursor stays at the right place to allow you to zoom right back to where you zoomed out from. This allows you to make a quick overview and resume what you were doing. Try the same thing in Spring: scroll the mouse from max zoom in to max zoom out and back several times, you'll see that you're traveling along the map. Also count how many times you need to scroll to go between both extremes. In FA, it's maximum 2 times - for the largest maps, and unlike Spring, you get perfectly smooth zooming.

Have I convinced you yet?

Games provide their own UI. Forged is superior to the generic Spring UI in a number of ways, as above noted, but it is unlikely to the mimicked wholesale for the generic because it doesn't meet the demands of all content packages... and the mods hardly matter anyway.

This thread isn't about replicating the forged alliance UI, its about taking a handful of things it does which are badly needed in spring and requesting them.

The problem witht eh draggable orders widget is that although it works its also a load of rubbish. You cannot use it unless your told it exists and how, it doesn't even change the cursor when moving to signify your moving an order, or which orders are movable!

Its a prototype thats got an APALLING interface, counter intuitive, and it isnt obvious that the feature even exists at first glance.

This is shown by the fact that most people requesting this feature are players of BA, which bundles this widget in already!

neddiedrow wrote:it doesn't meet the demands of all content packages...

This is becoming an argument to reject wholesale any improvement requests.

Maybe name current content packages that wouldn't want proper zoom, or proper waypoint dragging, and so on? Seems better than a generic argument about theoretical content packages.

Spring would gain a lot from having a nice default interface that satisfies 90% of the user base, so game creators don't have to mess too much with lua if they don't want their interface to look like shit.
Furthermore a pile of lua code developed by a bunch of random people and assembled by a mod maker clueless about coding [we need to attract artists] doesn't stand a chance of being as integrated as what you core developers can achieve.

6. Elective information change which can't be accurately and efficiently implemented for weapons with three-dimensional ranges.
7. Not all games use the resource system as presented, many which do use the metal map display this already game-side through lua. See 1944 or SW:IW.
8. Transport design will vary from game to game.
9. Fight move.

I must concede the other points, because I don't have an objection to their functional inclusion. However, every advancement in generic UI design reduces the pressure for specific UI design within a particular subcommunity, even though a title will always suffer from a generic, and I'm more than a little irritated by this trend. Amid the dozens of general UI advancement request threads this is one of the few that actually requests useful changes which are not mod-specific or mod-limited, but since I read every post on the forums in the course of fulfilling my responsibilities here I initially skimmed and wrote it off. That was my error.

The zoom thing can be done via Lua, more or less. There are certain features of the way it works in SupCom FA that would present some difficulties, but it can be done. Including the final zoom-state, where it's low-rez bitmaps and icon-wars, with a pretty border, yes.

The waypoint-dragging feature is pretty cool for RTS designs that allow Patrol, but is something that can be done nicely in Lua... it's just nobody's done it really cleanly yet. It's not a feature the engine needs, though. I have no real interest in writing this atm, because it's a fairly marginal use-case, but that's something worth discussing, in terms of "want" items- maybe write a proposal about how it should function, show pictures, etc. to help your argument for this?

Spring would gain a lot from having a nice default interface that satisfies 90% of the user base

Ah, now we're talking about what you really want. Keep dreaming- neither the game designers nor the engine people want to do that. The more hard-coded UI we have, the more limited the game designs become. UI is one of the key things that puts "can't do so-and-so" limits on an engine, in a big way.

The fact that some games look like a patchwork quilt visually and are clearly using a bunch of thrown-together stuff doesn't mean that that is how it has to be. They can, if they want, have a UI that is unified in design, and looks professional. It just takes a hell of a lot of work.

Well, wait, we can offer the functions and then include them in the default GUI without forcing them upon developers or users.

I must respectfully disagree.

Such a UI would be entirely pigeonholed around one game's gameplay, and would be a large amount of wasted effort from the start. It's just how these things work.

Good UIs are invariably game-design specific.

I, and everybody off the standard path already know what huge problems are caused by the things that Spring already does, UI-wise, and we had to ask for a lot of things (console, for example) to be able to be disabled, just to build halfway-decent UIs. I would prefer that Spring got out of the UI business entirely, now that there are credible, operating alternatives in Lua for every feature except the Minimap.

I'm well aware of that, but merely including the functions doesn't mean you need to use them. You forget that I'm working on UI for a few titles here myself. Things can be implemented through the engine and then modified in use through lua.

You're not getting it. Let me put it more clearly.

If we write a UI that is game-specific and is designed for one of the games that can be legally redistributed with this engine, then our choices are S'44, which already has an interface and doesn't use OTA stuff, Forb's thing, which is building one, KDR's projects, which don't need one, CA, which is building a very nice one... and NanoBlobs, which nobody actually plays.

The primary projects that would really benefit from a UI project would be... hmm... the commercial game made with this engine (assuming that the UI rocked more than the one I have now) and the game that already dominates MP in the Lobby.

Do you see why this is a really dumb idea yet, or what? Projects should be responsible for building their UIs. Period. There is a lot of source available at this point, and if you take my route, it's not even rocket science.

neddiedrow wrote:6. Elective information change which can't be accurately and efficiently implemented for weapons with three-dimensional ranges.

Are you sure? In FA, when showing combined ranges including indirect fire (artillery), they do seem to take 3d terrain into account, i.e. the range isn't just circular, and doesn't stop at the base of mountains.

7. Not all games use the resource system as presented, many which do use the metal map display this already game-side through lua. See 1944 or SW:IW.
8. Transport design will vary from game to game.
9. Fight move.

Fair enough.
I would be nice to assign an easy shortcut to Fight move (free up alt-click for that?), and to make reclaim-capable, weapon-less units reclaim stuff on the way when doing a Fight move. Right now they just behave as with a normal move.

Argh wrote:The zoom thing can be done via Lua, more or less.

I don't really care in which language they write it, I just believe it should be a core engine feature written by core developers.

The waypoint-dragging feature is pretty cool for RTS designs that allow Patrol, but is something that can be done nicely in Lua... it's just nobody's done it really cleanly yet. It's not a feature the engine needs, though.

I disagree with you completely here. If it benefits everybody, it should be in the engine.
And it's for dragging move/patrol/attack/transport waypoints, as well as any number of placed unit blueprints. You can't live without it once you have tried it, so unless you absolutely want Spring games to suck compared to the competition...

I have no real interest in writing this atm, because it's a fairly marginal use-case, but that's something worth discussing, in terms of "want" items- maybe write a proposal about how it should function, show pictures, etc. to help your argument for this?

I'm not gonna pretend that it doesn't exist and that it has not been near-perfectly implemented in FA. Blueprints are for non-existing stuff, and many people here already own that game.

Spring would gain a lot from having a nice default interface that satisfies 90% of the user base

Ah, now we're talking about what you really want.

No. I really want the individual features too. It's just I wish they were also integrated in a coherent whole.

Keep dreaming- neither the game designers nor the engine people want to do that. The more hard-coded UI we have, the more limited the game designs become. UI is one of the key things that puts "can't do so-and-so" limits on an engine, in a big way.

There's already a hardcoded GUI that can be disabled when lua UIs take over. But notice that most Lua UIs and games don't stray far from that default layout. We really need a push for a higher standard. As neddiedrow hinted to, this default GUI could be very modular, and game developers could disable and replace the parts they don't like. But you know what? 90% of them won't if the default is good.

The fact that some games look like a patchwork quilt visually and are clearly using a bunch of thrown-together stuff doesn't mean that that is how it has to be. They can, if they want, have a UI that is unified in design, and looks professional. It just takes a hell of a lot of work.

This. I don't think it needs to be that way. I haven't tried P.U.R.E., but I imagine you made a rather nice interface for it. But does it really need to be that hard, especially for people who don't have your skills or willingness to learn?

If a good default (FA-inspired?) GUI is made, at least we'll probably see BA, CA, BOTA, NOTA, EE, *A, and maybe (?) Evolution RTS, Gundam and Star Wars Spring adopt it with few modifications, thus instantly improving the image of Spring. Or, we can wait for something decent to slowly standardize... which sounds better?

Edit:

Argh wrote: If we write a UI that is game-specific and is designed for one of the games that can be legally redistributed with this engine, then our choices are S'44, which already has an interface and doesn't use OTA stuff, Forb's thing, which is building one, KDR's projects, which don't need one, CA, which is building a very nice one... and NanoBlobs, which nobody actually plays.

The primary projects that would really benefit from a UI project would be... hmm... the commercial game made with this engine (assuming that the UI rocked more than the one I have now) and the game that already dominates MP in the Lobby.

Well, exactly. Instead of waiting for the mythical IP-free project that everybody will play, let's give the most popular games a good-as-hell GUI. It's the best way to attract new players and new developers.

And you're forgetting that some features added along the way (FA-style zoom and waypoint dragging, for instance) will benefit everybody.

Argh wrote:

You're not getting it. Let me put it more clearly.

Right back at you, tiger. I'm saying the functionality suggested might be worth adding engine side so custom UI can use it without having to implement it from the ground up.

I'm designing the 1944 UI. I'm designing two others. A.N.T.S. has a UI. CA has a very convoluted and psychologically troublesome one. SW:IW has a UI which might actually pass as decent. KDR's projects are some of the most needful projects, since they all have alternative play structures.

I know that projects should be responsible for their own UI, I've been saying it at length in every thread for months, but adding functions for any UI to take advantage of engine side is a win-win.

And you're forgetting that some features added along the way (FA-style zoom and waypoint dragging, for instance) will benefit everybody.

Air Raid does not require these. Neither does Com Shooter.

luckywaldo7 wrote:

And you're forgetting that some features added along the way (FA-style zoom and waypoint dragging, for instance) will benefit everybody.

Air Raid does not require these. Neither does Com Shooter.

Don't pick at details, many projects, if not all, would potentially benefit. We all know Chess and Fissure wouldn't either, nor War Evolution.

Argh wrote:The primary projects that would really benefit from a UI project would be... hmm... the commercial game made with this engine (assuming that the UI rocked more than the one I have now) and the game that already dominates MP in the Lobby.

Yes... This games that ALREADY are the most played, can't be allowed to get better because its directly away from the proper games...

Gabba wrote:Fair enough.
I would be nice to assign an easy shortcut to Fight move (free up alt-click for that?), and to make reclaim-capable, weapon-less units reclaim stuff on the way when doing a Fight move. Right now they just behave as with a normal move.

clicking the f for attack move shouldnt really hold you down at all i think. And you can assign your own keys however you like, many games dont really have much use for attack move because units can move&fire. And reclaim/repair/assist with fight/patrol happens already.

neddiedrow wrote: I'm saying the functionality suggested might be worth adding engine side so custom UI can use it without having to implement it from the ground up.[...]
I know that projects should be responsible for their own UI, I've been saying it at length in every thread for months, but adding functions for any UI to take advantage of engine side is a win-win.

Exactly.

I'd be satisfied by this approach, but I still think it's smart to gear the default layout, shortcut keys and stuff towards a TA-style game, so this stuff gets tested, adopted and massively used, fast. Without putting any restrictions on game developers, of course.

JohannesH wrote:

Argh wrote:The primary projects that would really benefit from a UI project would be... hmm... the commercial game made with this engine (assuming that the UI rocked more than the one I have now) and the game that already dominates MP in the Lobby.

Yes... This games that ALREADY are the most played, can't be allowed to get better because its directly away from the proper games...

CA already has a lot of IP-free models and seems on the right way.
Some other *A will follow when a larger free unit base is available. Anyways people flock here mainly because they want a TA-remake, and will probably for the near future. Closing your eyes to that isn't a very good idea.

And reclaim/repair/assist with fight/patrol happens already.

Hmm, you're right, I tested it again and it works with fight. My bad.

Yes... This games that ALREADY are the most played, can't be allowed to get better because its directly away from the proper games...

If they want to get better, it should be through their own effort, in this area. This isn't a feature request that benefits everybody equally, and therefore is dubious from the start.

But does it really need to be that hard, especially for people who don't have your skills or willingness to learn?

It isn't that hard, tbh. Some newbie took my source and made an alternate BA-friendly UI as a first-project thing.

And if... perchance... it rocked, and was really that much better than my current (not seen yet) UI (which frankly, I doubt very much)... it'd just benefit me and the games that are keeping to the two-resource model.

The devil's in the details, basically. How it looks, how well it performs, how much it screwed up other games who don't want it. And if it's really good, it pushes games towards keeping their designs contingent upon its features (with the end result being more games with different art and the same basic design, which we don't want). If it's so-so, then nobody will use it.

Anyhow, that's pretty much all I have to say. Specific functionality, like waypoint dragging or strategic zoom (which I have done, but not entirely like FA, for the next version of P.U.R.E., btw)... is something that can and should be Widget design.

If it's great, people who need it will use it.

A large-scale makeover, though... just benefits the games that need it least, and would be a controversial project the whole way through, to say the least. Just thinking about the arguments that would ensue over the "official skin" gives me a headache in advance.

This. I don't think it needs to be that way. I haven't tried P.U.R.E., but I imagine you made a rather nice interface for it. But does it really need to be that hard, especially for people who don't have your skills or willingness to learn?

If a good default (FA-inspired?) GUI is made, at least we'll probably see BA, CA, BOTA, NOTA, EE, *A, and maybe (?) Evolution RTS, Gundam and Star Wars Spring adopt it with few modifications, thus instantly improving the image of Spring. Or, we can wait for something decent to slowly standardize... which sounds better?

PURE, GundamRTS, SWIW, and the test version of CA all have purdy custom ui's already (evo also uses IceUI as default iirc, and its not half bad) They are all quite different as well. Gundam uses a completely different resource system, CA has a radial menu, etc... etc...

I would be nice to assign an easy shortcut to Fight move (free up alt-click for that?), and to make reclaim-capable, weapon-less units reclaim stuff on the way when doing a Fight move. Right now they just behave as with a normal move.

F + click is too hard?

Well, exactly. Instead of waiting for the mythical IP-free project that everybody will play, let's give the most popular games a good-as-hell GUI. It's the best way to attract new players and new developers.

Didn't the latest version of BA have lolui as default? It is simple, but very nice.

Waypoint dragging is possible. Just download the widget.

I don't really care in which language they write it, I just believe it should be a core engine feature written by core developers.

Why the hell does it matter where it comes from if it already exists and is working perfectly now? Why waste developer time on things that have already been done fine. No use re-inventing the wheel imo.

Now In addition to some of your points that weren't already implemented, I find it disappointing that you cannot queue up a factory, and then select the ghost and queue units from that fac (before it has started building). (it would also be awesome for that same thing to be done with constructor/engineers)