Next engine features poll

Next engine features poll

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
ivand
Posts: 295
Joined: 27 Jun 2007, 17:05

Next engine features poll

Post by ivand »

Wanna do a short poll to gauge the state of mind of those whom I don't speak directly too.
This poll is only for major or lead spring game devs, who can speak on behalf of the game interests they represent. Only one reply per game please.

Reply 1,2,3... respectively to questions below.

1) Name the spring game you represent.
2) If you were to make binary choice: preserve player-base fully or gain measurable performance advantages (in rendering) by sacrificing small percentage of players. What would you pick?
3) Are you interested in moving Lua widgets (where applicable) to more performant drawing methods (requires certain rethinking of the way widgets are written and rewriting of the code)?
4) If (3) is "no-ish". What obstacles do you see / reservations you have?
5) Describe your expectations from future engine versions. Or anything you want to say (strictly regarding engine development).
User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7040
Joined: 16 Nov 2004, 13:08

Re: Next engine features poll

Post by zwzsg »

1) Kernel Panic (playerbase: 0)
2) I would prioritize preserving backward compatibility over performance advantages.
3) The engine is already open source. So, if anyone wanted extra performance in exchange of more complex code, it was always possible, by writing C++ in the engine instead of Lua gadgets/widgets.
4) The whole point of Lua is to be much easier and safer to write for game-devs. And already many are struggling.
5) Spring has had a nice run, I expected it to die slowly. Hopefully no-one will break everything just before, as it would be very nice to be able to still run old Spring games.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14670
Joined: 17 Nov 2005, 02:43

Re: Next engine features poll

Post by Forboding Angel »

1: Evolution (What is this "playerbase" you speak of? Weirdly, I have more than a small amount of people who play singleplayer either in sandbox or vs scavs/ai ... ???)
2: Performance (because this is far more useful for the future of spring)
3/4: This is a REALLY prickly question. I know what this question entails and the long and short of it is that games with large dev teams like ZK and BAR have zero issues while the rest of us basically get stuck with discarding large parts of our games in order to update to the latest engine when some developer makes a change that we can't live without, restricts autohosts or lobby server, etc. Thankfully, with skylobby and taiserver, chances are that I won't be ever forced into this position again after it happening multiple times over the past 14 years.

So for an actual answer to 3, I would say ONLY if you and others are going to take the large time investment that would be needed to help the rest of us get our games working again.
The engine is already open source. So, if anyone wanted extra performance in exchange of more complex code, it was always possible, by writing C++ in the engine instead of Lua gadgets/widgets.
I don't think that this assessment is a fair one, but I agree with where z is coming from. I also disagree with his implied opinion that spring is dead/dying. If anything I've seen a ton of interest int he past couple of years form completely new sets of people. This is a GOOD thing!

5: If some engine functionality is removed in favor of LuaIT(tm), then write that gadget/widget and release it alongside the new engine release. This is what Tobi used to do and it was awesome. He would be like "ohay guise, I removed xyz because it was better in lua but don't worry, here is a gadget that you can drop in so that your game isn't screwed". Be more like Tobi.

Please, for the love of fuck, stop with this fantasy that spring is something an end user should be installing. Cater to games that are needing to release tailored standalone packages. If someone wants to install Springlobby or Skylobby and play the traditional way, then goodonyer, but the ENGINE should cater to being included as part of a game package. It shouldn't be so damn hard to make a game package, but currently you have to deal with stupid behavior after stupid behavior and after 14 years of workarounds and frustration and repeating myself for the millionth time, here I am, again, hoping and praying that for just once, someone will listen.

Along with the above, SPRING SHOULD ISOLATE BY DEFAULT. Currently if you want to properly isolate spring, not only do you have to add isolated.txt to the datadir, you have to add isolated.txt to the folder where the damn engine is too!!! Which poses unique issues if you don't want to include the engine in your game package and instead download it via a lobby or launcher or something, because then you need something external to write the isolated.txt

Spring needs to write every single god damn value to springsettings and stop fucking removing an entry if it happens to match the default. If spring stops this absolutely idiotic behavior, then all of a sudden including a proper default springsettings.cfg won't have to be done by trickery and resorting to using lua widgets to write values that don't fucking suck on first load. Currently, if someone downloads evo from springfiles, launches it in springlobby, thanks to dogshit default values, the game is going to look like ass. Whereas if they download from itch, I force a springsettings.cfg and the game looks really pretty. I cannot express how infuriating this stupidity is to deal with.

Let me reiterate, spring (the engine) should NEVER touch springsettings. Springsettings should only be touched by widgets/gadgets/lobby settings pages/etc. I hope the developer who made the decision to have the engine remove values from springsettings steps on a lego barefoot everyday for a month.

Thank you for attending my TED rant.
raaar
Metal Factions Developer
Posts: 965
Joined: 20 Feb 2010, 12:17

Re: Next engine features poll

Post by raaar »

1) Metal Factions (playerbase: over 9...thousand)

2) Preserve player base. I can change to the newer version at a later stage.
Players with decade-old toasters or low end laptops will eventually upgrade in a few years

3) Depends on how significant the gains are and the difficulty of implementation

4) Obstacles/reservations
- does the change break compatibility for some players?
- does the change break compatibility with existing content?
- more performant ways of doing things may be harder to build on and maintain

5) Expectations / miscellaneous thoughts

- keep the basics working : current broadly compatible engines being available for download/use on the official infrastructure
^---------IMPORTANT

- in case of compatibility breakage (GL dependency or deprecating legacy formats), allow maintenance branches so we can eventually fix/improve some things and have new versions of old engines available to download from the official infrastructure

- improved support for game-specific settings to avoid conflicts between games as the defaults suck and games override them in conflicting ways
(this applies to visual settings but also stuff like keys)

- improved pathfinding and the way the units move across steep slopes (at the moment they zigzag weirdly) or how groups of vehicles should move together more naturally to a far position instead of converging/sliding

- more control over weapon aiming behaviour (the builtin aiming behavior is weird and it's suboptimal to have gadgets spending time redoing calculations to figure out what to target)

- improve consistency of weapon attributes for different weapon types (range volume inconsistencies and altitude scaling)

- improved physics for units : better support for jumping or air units losing power and falling to the ground or being pushed around, improved interaction with water layer
(I know this is vague, but there's some weird behavior as gadget-triggered movement wrestles with the engine)

- improved usage of multiple cpu cores
perhaps spring could let game devs mark gadgets that can run out of order without breaking sync to run on a separate thread (lua AI might be a good candidate)

- more CEG options, like passing area of effect or a color modifier, or whether they stick to the emitting vertex as it moves if the unit/feature/projectile still exists
CEG visibility options could also be improved : as of 105.0, an invisible projectile that relies on CEG trail needs to be either always visible or disappears whenever it enters the fog of war
It's hard to get good looking trails for fast moving projectiles

- allow higher resolution base map texture

- improve the way map mesh detail works. Currently even at max detail, sharp edges look broken when zoomed out.
perhaps there could be a way to force the map mesh to max detail on some areas (an optional extra image similar to typemap) as it's harder for an algorithm to automatically figure out which details matter
what's "max detail"? type "/wiremap" and "/mapmeshdrawer 1" and "/grounddetail 7" and see how the grid changes as you zoom in and out compared to "/mapmeshdrawer 2" and "/grounddetail 100"


- have clear examples on how to do graphical stuff the "proper" way (like draw 2d or 3d UI stuff and effects on the map, on units, etc.)
I remember running into issues when trying to make something glow, getting proper weapon trails or drawing translucent planes through a map gadget for fog,lava, etc. and finding out that they'd act as opaque for units and projectiles but not terrain
Google_Frog
Moderator
Posts: 2452
Joined: 12 Oct 2007, 09:24

Re: Next engine features poll

Post by Google_Frog »

1) Zero-K
2) Sensitive to the actual numbers. 2%? Probably. 10%? Probably not. I don't think it is purely a question of performance vs. users though, since I think we may be starting to see hardware that is too new to run openGL 3.x code as well as it could run more modern stuff.
3) I am not personally interested nor do I have the time. I have learnt that I dislike graphics code, probably because it seems to be very stateful. I like functional programing, ie no side effects, and don't care enough about the end product (better graphics) for it to motivate me. Getting past this probably involves a large time investment to learn it properly.
4) See above.
5) I don't expect anything from future engine versions. To update the engine I must first personally invest a lot of time into finding the worst bugs and regressions, going through the rigmarole of reporting them - then repeating. My impression of current engine dev is that the engine is going through a phase of feature addition so it doesn't seem useful to expect stability at the moment. I would have to be right on top of the feature development, and I don't have the time.

My best guess at the future is that the engine will continue to have graphical changes focused around BAR. Hopefully this will stabilise at some point and BAR will contain readable code that can be used as a guide or simply copied across, such as for chili and CUS. The failure state is if engine development or the engine itself merges so closely with BAR that the engine is no longer practically usable for other games. The fork seems to already include a few BAR things such as a different icon system, so given a few more years I would be concerned with BAR either optimising away engine features that it doesn't use, or only having reasonable performance with the BAR feature set enabled. For example, a new icon system isn't useful if its parameters are hardcoded to the particular design of BAR, and the danger is that the old icon system will bitrot.

My dream engine update would pluck a bunch of low hanging fruit simulation-side in the form of fixing broken things that are hacked around in ZK (or I wish I could hack around) and moving expensive and generic gadgets to the engine. For example, resource proration didn't work last time I checked, the raw move gadget in ZK is an improvement on how the engine handles move commands, and the engine-default target priority behaviour is pretty bad.
Post Reply

Return to “Engine”

cron