Spring RTS Engine

http://www.youtube.com/watch?v=sqerUDPg ... re=related

How hard would it be to implement this in spring.

At a random guess harder than making a new engine.

It all depends on how much you want of this, but pretty much.

isnt there already a thread on this?

viewtopic.php?f=10&t=18281

It's not quite the same. That thread is about how awesome that time travel rts game sounds. This thread is about telling gota how unfeasible implementing it in spring is.

I think it's more feasible than you'd suspect.

World Builder saves the contents, positions, and current angles of everything in a gameworld quite quickly (less than a second), and I think you could update every minute or so to provide "time points".

Only trouble would be that you can't erase projectiles in motion, so if your enemy launches a nuke, it's going to hit even if you go "back in time".

That, and there would be enormous issues, in terms of making the game reasonably fun, and you'd have to write a custom AI, probably a modified C.R.A.I.G., to handle the weird things that would happen.

IOW, I think it's technically feasible, but it would be a huge amount of work to make it fun.

Thats if you send every player back in time when someone travels, basically saving and loading the game.

Well, IDK how else you'd do it, without breaking things all over the place with serious paradox problems. Seems like the only way to be fair about it is to only allow travel backwards as well, otherwise I can see various stupidity resulting because things would have to run in some simulated way that would basically just be "auto-battle" and would suck.

Buzzword #49125 will not allow two players to be at different points in the timeline at once. This is not feasible (though probably possible by reimplementing half the engine's logic in lua) in spring.

Muahaha controlled desync.

Argh, go watch the video please.

There'd be no desync, if it was planned correctly. Hell, World Builder doesn't cause desync, on anything reasonably modern. And that's the kind of operation we're talking about here- just storing unit types, positions and angles, and reading them back when a user wants to "travel in time".

But if that's a major concern, use very low spec on units (so that loading time per mesh / texture is fast), and phase the time-travel over a second or three, by storing the state in a table and working through a few entries per frame.

Should be doable, I've been meaning to code that for World Builder for some time now, it's just a low priority since the game's not really designed for low-end hardware anyhow.

Interesting, you're not responding to the video, you're not responding to the posts around you, you're just kind of picking out words, guessing, and then saying you know what to do.

A few points:
Rewinding time globally isn't close to the desired effect.
I was talking about deliberatly desyncing.
Loading time has nothing to do with desyncing.
Meshes and textures have nothing to do with desyncing, and nothing to do with the time to replace all units.

No, I'm saying that I saw the video, that I think that their idea won't work very well when people play it, and proposed what I'd do instead.

Time travel in one direction only, no paradoxes, and it'd work.

Forcing both players to move at the same time and discarding pretty much every single other interesting gameplay mechanic related to the concept of time travel in an rts. Cool story bro.

Of course it would work, and would be downright simple, but who wants a multiplayer game where you can rewind time like that? I think you underestimate the potential their game design has.

Argh wrote:I think it's more feasible than you'd suspect.

This line seems to be talking about what the video does, not mere rewinds.

<sigh>

TBH, I think their game will be another Perimeter- well-loved by jaded game critics, but really horrible when you sit down and play it.

Meh, I forget, this is the Forum where you guys didn't understand my analysis of Spore, which still hasn't paid for itself, btw.

At any rate, get back to salivating over that prospect if you wanna. You're right, it's impossible to do that in Spring. But who wants to? It would just create horrible paradoxes, and whatever rules are used to wrap them up will probably end up dumbing down the gameplay.

You just got a major micro victory, with some surprise involved? Oh, your opponent can move backwards in time to the start, then forwards through that crucial bit, forcing some sort of auto-battle or (depending on how they handle that) you'll be forced to do it all over again, but without the element of surprise. I didn't watch enough of the video to see how they supposedly resolve that- my guess is that it's probably the issue that's making them sweat the most. And it'll end up being the Achilles heel.

Sorry, I know that people hate it when I point out the obvious, but meh, I don't think it's a good idea and I don't think it will be a good game unless you can only go backwards.

Imagine playing a battle with a very restricted amound of time power, precious elixer that if used just to shift a small clash will screw you over later.

Sounds dumb, to me. Did your opponent rush you on the West? Go back in time, and have your forces placed right to win.

No matter how they balance that... it'll either be a totally useless gimmick, or a game-wrecker. And going forwards in time will be even worse.

Argh wrote:totally useless gimmick, or a game-wrecker

Oh you.