Spring RTS Engine

IRL, radars come with advantages and disadvantages. The big problem right now in P.U.R.E., as I see it, is that in the first released version, radar was extremely important to gameplay. So, revealing active radar sources (and hiding them if they were turned off) would have been a really big deal, and might have been a considerably cool feature, not just a minor add-on.

Now, it's almost irrelevant, because you can scout so far with 1024 sight distances that it's almost pointless, and practically all combat occurs within sight distances. I'm going to have to deal with that somehow, because this doesn't really represent what I wanted the game to feel like.

The best way to deal with that, without losing what people wanted (i.e., longer sight distances) is going to be to increase the range of the StrategicPlasmaCannon and MortarTank, who were both supposed to be major parts of big-map gameplay, and maybe add some new weapon system / Unit that can be used for warfare at radar ranges, but not at the extremes (think ranges between 1100 and 1600 or so- far enough that it actually matters during group engagements, not quite artillery). While I am pleased that longer, more realistic sight distances work without dragging Spring's performance down too much, changing that had a lot of unintended consequences, and now I'm going to tighten this part of the game design back up (and, um, while I'm at it, I'll fix the Overmind Commander's buildpic, which escaped my last set of minor fixes).

Argh, you should have made your LOS ranges depend on the unit and gameplay ideas instead of what you think the CPU can handle. In CvC I have all kinds of LOS ranges, from the nearly blind drones to the "see everything" ACV. LOS is an element of the gameplay, CvC's Trireme was so powerful against drones because no drone could get LOS on the thing before dying. The issue with relying on radar is that radar is inaccurate, it tells you who is where but any attacks will be highly inaccurate so you need scouts for actual combat. The problem with Pure .5 was that AFAIK there were no scouts so combat was forced to be radar vs radar which sucked for anything except large AOE weapons. With radar you either wait until the blip hapens to move over the enemy (unreliable and random) or you micro your units to shoot where you think the enemy is (can be done).

KDR_11k wrote:Argh, you should have made your LOS ranges depend on the unit and gameplay ideas instead of what you think the CPU can handle. In CvC I have all kinds of LOS ranges, from the nearly blind drones to the "see everything" ACV. LOS is an element of the gameplay, CvC's Trireme was so powerful against drones because no drone could get LOS on the thing before dying. The issue with relying on radar is that radar is inaccurate, it tells you who is where but any attacks will be highly inaccurate so you need scouts for actual combat. The problem with Pure .5 was that AFAIK there were no scouts so combat was forced to be radar vs radar which sucked for anything except large AOE weapons. With radar you either wait until the blip hapens to move over the enemy (unreliable and random) or you micro your units to shoot where you think the enemy is (can be done).

To be fair, Argh based Pure on TA's gameplay, and TA has that feature too. A lot of TA mods are simply a bunch of radar dots shooting at each other. Not saying it's a good thing, but that's his source.

Argh based Pure on TA's gameplay, and TA has that feature too.

Quoted for truth. I actually liked how, in OTA, you had to force-fire a lot during micro, if you were an expert player. For example, you force-fired Bert / Tims almost exclusively, if you knew what you were doing, and routinely did stuff like force-fire at chokepoints.

That was a major feature of high-level gameplay, and while I'm not sure how intentional that was on the part of OTA's designers, I want it in P.U.R.E.- speculative fire, probing fire, and sensor wars really appeal to me, because they're a major part of how real tactical warfare works. How I'm going to achieve that goal is still up in the air, but that was my initial thought on these issues.

Beta 0.55 released. 0.54 has been removed.

Changelog:

Looks like another kitbash from here (mortar tank turret, rocket/autoturret base?)

LaserCannon base

Haven't had time to build new stuff from scratch... looks all right in-game, for now. If you get bored, though, I'd love a new model for the MetalMaker and MegaFusion...

the new com is much nicer argh.

Yeah so all my shit is ├é┬® licensed to GZ Games too so...fuck you too :D j/k

How come a GPL'ed game is copyrighted? kinda an oxymoron?

Gah you still can go to hell, i'll figure it out my self...

disclaimer: I was not actually insulting the author, I was 'messing around'

GrOuNd_ZeRo wrote:How come a GPL'ed game is copyrighted? kinda an oxymoron?

Err, the GPL enforces its license terms through copyright. If there was no copyright you wouldn't have to GPL your own changes.

Well I realize that but isn't the point of GPL free distribution as long as it isn't sold for monitary gain? or am I confused?

Ahhh you know what they say in Mexico....Fuggit...

GrOuNd_ZeRo wrote:Well I realize that but isn't the point of GPL free distribution as long as it isn't sold for monitary gain? or am I confused?

Ahhh you know what they say in Mexico....Fuggit...

Yeah but if you use gpl in your project, your enforced via copyright to gpl yours to protect the gpl code you used.

GrOuNd_ZeRo wrote:Well I realize that but isn't the point of GPL free distribution as long as it isn't sold for monitary gain? or am I confused?

Free distribution and modification as long as you let everyone else do that as well. The GPL does NOT prevent you from selling the material for money.

Such an easy thread derailment there, almost effortless.

Argh I like the new unit and I look forward to future updates. keep posting images, most mods are suspiciously devoid of good imagery. The BA unit worship, or the kernel panic broken links, or the starwars/Gundam showcase pictures. Yours are actually showing mixed bases and structures, and thats very useful as its highly reusable content.

Argh, I played a game of the new version of PURE, and some points came up:

• -The econ seems a bit skewed, i don't really know how to frame this, it just seems too easy to build. I don't really feel that the super-fusion is similar to the fusion in TA, where it was an achievement to make.
  
  -The uber assault tank leaves no wreck. fixx, this makes it OP!
  
  -Defensive structures are too good atm. It may be because we played SSB, an admittedly porcy map, but the lazer towers and long ranged towers combined where murderous. I'd say up the price on the good defense and make the long range tower reload slower.
  
  -Repair is too fast. In said defensive line, a few build-turrets could repair at uber speed.
  
  -Air seems a bit unbal. The interceptors are strange, I had 5-10 of mine (not coming at once tho) killed by about 3 of the enemy, because they basically 1 shot each other.
  
  -In late-game, there are some mad cpu-spikes, which make the otherwise ~20 fps drop to 1. Also, when my opponent self-d'd, my game actually froze for about 1 min.
  
  -It would be nice to have a superweapon or something to break the porc-tie.

Otherwise good work, we need more balancing matches though, with human v human action.

@BaNa: thanks very much for your results in play!

-The econ seems a bit skewed, i don't really know how to frame this, it just seems too easy to build. I don't really feel that the super-fusion is similar to the fusion in TA, where it was an achievement to make.

I'll think about that. I guess that my perspective on this is that I wanted a faster-paced game than in TA in that respect. MegaFusions represent more-efficient power generation in the same amount of real-estate. That's why you build them.

Keep in mind, people- I designed P.U.R.E. with small maps (competition-grade) in mind... not giant maps like Comet, with almost unlimited room to build your base in. If you play P.U.R.E. on a map like that, it's a very different experience... so is any TA mod.

Suggestion: BaNa, next time, play on a 1 vs. 1 map that's smaller. It's not the chokepoints, it's the timing- on small maps, you should probably not ever see UltraAssaults before it's over

-The uber assault tank leaves no wreck. fixx, this makes it OP!

I can see your point there. I'll get that fixed up.

-Defensive structures are too good atm. It may be because we played SSB, an admittedly porcy map, but the lazer towers and long ranged towers combined where murderous. I'd say up the price on the good defense and make the long range tower reload slower.

Well, did you solve that problem with MortarTanks? That's what they're for...

-Air seems a bit unbal. The interceptors are strange, I had 5-10 of mine (not coming at once tho) killed by about 3 of the enemy, because they basically 1 shot each other.

Then next time, you should probably build them in groups, eh? Single-streaming planes in PURE is a huge waste of resources, frankly. They're meant to be hoarded.

-In late-game, there are some mad cpu-spikes, which make the otherwise ~20 fps drop to 1. Also, when my opponent self-d'd, my game actually froze for about 1 min.

See notes on system requirements. I don't think your machine even reaches the lowest levels. I can't fix that.

-Repair is too fast. In said defensive line, a few build-turrets could repair at uber speed.

I'm thinking you're probably right there- I'll lower the RepairSpeed on BuildTowers a bit, we'll see how that goes. I like the idea of somewhat self-sufficient mini-bases, though.

-It would be nice to have a superweapon or something to break the porc-tie.

I have yet to see a defensive line that MortarTanks can't gradually reduce to rubble, if force-fired on a point. It takes awhile, but it eventually works out. However, I could put a nuke-equivalent into the game, I suppose, although it'll take some balance.



License Stuff

How come a GPL'ed game is copyrighted? kinda an oxymoron?

The game is not GPL. It is (C). Don't confuse the game, which is P.U.R.E., with the game engine, which is Spring.

Gah you still can go to hell, i'll figure it out my self...

It's not that hard Use XTA or CA's or even NanoBlobs's code as a starter for FX. Maybe you could just put up a post asking for some specific FX you're wanting, or maybe even a more general thread about this topic... lots of people here know at least as much about FX coding as I do, frankly. If you just want to talk about the general challenges and approaches, start a thread, it might be useful for everybody, and I'd be happy to share some source and my perspective on this. However, there are tons of other people who make great FX around here, it's not like I have a lock on that or whatever.

What I've been finding out, though, is that 99% of the difference between a good FX and one that's just mediocre is the quality of the bitmaps used. The physics of explosions are pretty straightforward to simulate- making it all look good with very few particles requires good bitmaps. I dunno why everybody keeps wanting to steal my code for this shit, when it's not the code that makes it look so good

Such an easy thread derailment there, almost effortless.

No, this had to get dealt with, at some point or another.

So, why is P.U.R.E. (C)?

1. Because it was never supposed to get released in this early state. Period. I hate releasing something that's less than half-done. I hate even more that it's getting plundered of all of my techniques before it's even finished yet- kind've ruins the surprise value

2. I don't have any really compelling reason to GPL it yet, because the technologies I really need don't exist yet. The only thing that would convince me it'd be worth the trouble is if the LUA stuff I need ever shows up, under GPL. While there is a lot of very tempting stuff out there, it's missing some crucial pieces that I need.

Argh's LUA Christmas List

So, what do I want? I figure, hey, it's Christmas, why not ask:

A. Simple, scriptable methods of placing Units onto a Map, controlled by Gaia. We're 95% of the way there, people. We just need a way that we can run a simple script via Gadget that will place stuff and take map proportions into account, either by placing more stuff, or by increasing the space between things. Preferably, either / or.

Why do I want this? Simply put, so that I can have a system to replace Metal and Energy, that requires map control, and does not require some funky map format.

B. A working, generic economic code that is configurable to allow variable interactions of certain simple kinds out of the box. Costs / benefits, calculated per-unit, through LUA. Displays with bars updating per frame, reflecting states of costs and benefits.

Isn't it about damn time to have multiple resources, and free ourselves from OTA, as well as providing an escape hatch to allow us to finally ditch a major chunk of Spring's original main loop out've C++ and into LUA, where it properly belongs? Yet, aside from some specialized work on this topic, I don't see this problem getting solved.

Solve A, so that resources and other gameplay elements (walls, cities, forests, flags... think!) can be spread on a map generically via Units... solve B, and make it easy enough to work with that we mere "content people" can use it, and voila- you'll see games that look like Starcraft, games that look like AOE, games that have growing "forests", etc..

I doubt seriously that most of this is even hard. It's just not "sexy", and from what I've seen, everybody messing with this just wants to dick around with special solutions for very specific game designs. However, just as with everything else I've asked for... give it to me, and watch what I can do with it... and what everybody else will do with it, 5 minutes later. C'mon, LUA people. Do something that makes the big promises come true. Do something more fundamentally interesting than graphics tricks. Because I'd like a game like P.U.R.E. to become something really cool, and I can't get there without this stuff.

C. A working solution for building whole units of multiple troops from a single build-order.

I pretty much know how to solve that one, and I need to write up a document about it. I studied how the Dawn of War guys did it- you're all going to find it grimly hilarious, methinks. But it worked!

Argh wrote:A. Simple, scriptable methods of placing Units onto a Map, controlled by Gaia. We're 95% of the way there, people. We just need a way that we can run a simple script via Gadget that will place stuff and take map proportions into account, either by placing more stuff, or by increasing the space between things. Preferably, either / or.

Why do I want this? Simply put, so that I can have a system to replace Metal and Energy, that requires map control, and does not require some funky map format.

Well, what's stopping you from coding that? Last I checked there's no hurdle except that a default placement won't be suitable for most map topologies. I'm spawning neutral, capturable buildings in Fibre already. Really, what needs changing there?

B. A working, generic economic code that is configurable to allow variable interactions of certain simple kinds out of the box. Costs / benefits, calculated per-unit, through LUA. Displays with bars updating per frame, reflecting states of costs and benefits.

Isn't it about damn time to have multiple resources, and free ourselves from OTA, as well as providing an escape hatch to allow us to finally ditch a major chunk of Spring's original main loop out've C++ and into LUA, where it properly belongs? Yet, aside from some specialized work on this topic, I don't see this problem getting solved.

Yeah but that's a major rewrite because of the sheer amount of hardwired crap. I just got mostly done with implementing a custom resource system with storages and all that, no big deal. Ripping the code out of Spring will be a lot harder considering we're not allowed to break compatibility with existing mods. Implementing the Universal Weapon would probably be a lot more useful and break less.

C. A working solution for building whole units of multiple troops from a single build-order.

I pretty much know how to solve that one, and I need to write up a document about it. I studied how the Dawn of War guys did it- you're all going to find it grimly hilarious, methinks. But it worked!

If in doubt just make a meta unit that spawns a bunch of smaller units or maybe a unit that spawns its squadmates automatically? Really, these are simple things.

Well, what's stopping you from coding that? Last I checked there's no hurdle except that a default placement won't be suitable for most map topologies.

The big problem is that I have yet to figure out how to get it to resize or add more groups per map size. I don't think there's any magic solution for topology issues, short of having objects spawned this way re-arrange topology on the fly.

If I can get this dealt with, then I'd just be a hop-skip-jump-and-upgrade-code away from being able to build a lot more interesting gameplay, by forcing players to scout and find stuff that could be used for upgrades, and protect stuff that might not be in ideal places.

Implementing the Universal Weapon would probably be a lot more useful and break less.

I agree, in the short term. Long term, the economic code and the main loop are the prize. If nothing else, when you consider how much faster Spring would run if elements of what is now the main loop were all optional...

In the case of P.U.R.E., it's not really necessary. I'd like to have a third resource, just to have one, but it's not life-or-death.

If in doubt just make a meta unit that spawns a bunch of smaller units or maybe a unit that spawns its squadmates automatically? Really, these are simple things.

It's not that part that's the trouble- we had working code to do that sort of thing over 6 months ago. The trouble is getting them to act as a unit. I think I have a solution to that one, but I'm not sure how to get it working, because it involves some heavy math, which I suck at.

Oh, and I just tested MortarTanks as late-game deadlock breakers... um, if you build them, and your opponent can't find them... they're toast. They eat ArtilleryCannons for breakfast. They demolish infrastructure. Build 'em!

SVN now has global constants that tell you the map size, from there on it's just thinking of how you want to adjust things to the size. Even without that you could just have used the distance between the start points to determine some placement.

Gutting the resource system wouldn't make the performance much different, resources are fairly easy to deal with. Pathfinding and collision are bigger CPU hogs. If you want to rewrite the pather, feel free.

As for having groups act together, I've got that in Fibre. Of course if you want a fixed formation you can just make a main unit that pathes with a huge footprint and then have other units stay in a fixed position compared to the main unit.