I have been experimenting with the TASpring code and would like to implement a feature.
I thought it was best if I asked first, for suggestions.
Here is my proposal:
Spring Cinematic Camera Mode
Aim: Create a new spectator-only camera mode that automatically follows the most interesting parts of a Spring game.
Purpose:
- To be able to use Spring as a screensaver (in conjunction with global AIs and an auto-restart feature when games end). This could be fun for eg. PC shops which often have boring screensavers running, or swapmeets where vendors wish to demonstrate the power of computers.
- To make it easier for spectators to watch replays / games
- because it would be cool
Design:
Stage 1: Create a new map mode similar to radar/metal views that indicates how interesting areas are.
Stage 2: Implement a camera mode that automatically moves between areas of high interest.
Ideas for stage 1:
- break map into segments
- interest++ if change in health (small bonus if increasing)
- interest++ if moving units (bonus if weaponised) * total health
- interest++ if opposing teams are in close proximity (attempt to predict battles before they happen
- balance factors for each
- balance based on total health of units (based on the assumption that more interesting units have more health)
- interest decays over time (keep 3 calculations in a queue)?
- recalculate only every ten seconds to keep cpu usage down
Ideas for stage 2:
- move camera to points of interest
- rotate camera around points of interest
- looking at an area reduces its interest for a certain amount of time
Implementation plan:
1.1: New map mode (all constant value)
1.2: Map mode displays total possible health for each sector (ignores current health)
1.3: Design decent class structure for next stages
1.4: Moving Units give bonus to interest value for sector
1.5: Opposing teams in close proximity give bonus to interest value for sector
1.6: time factor - Interest accumulates for a certain amount of time and is then discarded
2.1: camera position adjusted automatically (rotation/zoom unchanged, similar to overview mode repositioning)
2.2: looking at a sector reduces its interest
2.3: camera rotates around areas of interest (stays focussed on one point and pans around it to observe from all angles)
2.4: camera transitions smoothly between areas of interest
Feature Proposal: Spectator Camera Mode
Moderator: Moderators
Eek. That sounds an awfully lot like a fairly intensive AI running in the background.
I don't mind the idea per se, but for goodness sakes, it must not run by default and should require some specific command-line command to start. That's all I ask. It's a good idea to increase interest in Spring, etc., and could even be expanded- "greatest hits of my recent replays", etc.... but if it runs without being asked explicitly, it'll suck up CPU in NanoBlobs so fast it'll melt people's poor processors
I don't mind the idea per se, but for goodness sakes, it must not run by default and should require some specific command-line command to start. That's all I ask. It's a good idea to increase interest in Spring, etc., and could even be expanded- "greatest hits of my recent replays", etc.... but if it runs without being asked explicitly, it'll suck up CPU in NanoBlobs so fast it'll melt people's poor processors
Sounds good, but a few bugs ive already spotted:
Say you have two areas of interest, one at 100 and the other at 110. Naturally, interest centers around the 110 area, although its interest quickly goes down as its being veiwed. When interest reaches 100, the program makes a random decision between the two scenes, and switches between them. and then it keeps switching, backwards and forwards, not settling anywhere because of the similar scores.
To solve this, you could add in some hysterisis on the scoring calculations, so that the camera doesnt switch till the score is considerably lower than other scores around it.
When creating things like fusion farms, quite a large amount of health would be centered around one spot. This could really skew the calculations, especially if armys are still at that specific moment. As they have such large health, and nothing is moving, interest would center around the fusions, which are really, REALLY boring to watch...
Dunno how you could fix this, besides carefull weighting of the values as to favor units with weapons more than units without weapons. Perhaps if nothing is really moving or firing, the camera could just scroll around the map, showing off the scenery?
Someone fires a nuke at the enemy. As the nuke is not a unit, your current scripts would not detect it, therefore the camera would not snap to the location of the hit untill AFTER the nuke explodes, damaging everything and setting off the health lost alarm.
To fix this, you could add another watch to the code, to see if weapons are fired, and work out where the weapon will hit, watching there if nothing else is going on.
Say you have two areas of interest, one at 100 and the other at 110. Naturally, interest centers around the 110 area, although its interest quickly goes down as its being veiwed. When interest reaches 100, the program makes a random decision between the two scenes, and switches between them. and then it keeps switching, backwards and forwards, not settling anywhere because of the similar scores.
To solve this, you could add in some hysterisis on the scoring calculations, so that the camera doesnt switch till the score is considerably lower than other scores around it.
When creating things like fusion farms, quite a large amount of health would be centered around one spot. This could really skew the calculations, especially if armys are still at that specific moment. As they have such large health, and nothing is moving, interest would center around the fusions, which are really, REALLY boring to watch...
Dunno how you could fix this, besides carefull weighting of the values as to favor units with weapons more than units without weapons. Perhaps if nothing is really moving or firing, the camera could just scroll around the map, showing off the scenery?
Someone fires a nuke at the enemy. As the nuke is not a unit, your current scripts would not detect it, therefore the camera would not snap to the location of the hit untill AFTER the nuke explodes, damaging everything and setting off the health lost alarm.
To fix this, you could add another watch to the code, to see if weapons are fired, and work out where the weapon will hit, watching there if nothing else is going on.
- break map into segments
- interest++ if change in health (small bonus if increasing)
- interest++ if moving units (bonus if weaponised) * total health
- interest++ if opposing teams are in close proximity (attempt to predict battles before they happen
- balance factors for each
- balance based on total health of units (based on the assumption that more interesting units have more health)
- interest decays over time (keep 3 calculations in a queue)?
- recalculate only every ten seconds to keep cpu usage down
I would simplify it to the following:
- Break map into segments
Sum metal costs and total health of units per segment. Store this sum, as say sum1[].
Sum metal costs and total health per segment again, call it sum2. Subtract it out from the previous, sum1[], and divide this result by sum2[]+sum1[].
The biggest percentage change should receive the current focus, but don't switch focus until the current focus has gone on for at least 8 seconds or so.
Rinse and repeat.
Thanks everyone for your comments.
Argh: It won't run by default. I was planning to have it recalculate areas of interest every 5sec. Hopefully it would not be a particularly intensive calculation anyway, apart from possibly detecting units that are close to opposition units.
Maelestrom:
Hystersis sounds good. My first attempt won't include time-based stuff, but that hysteresis thing definitely sounds like a good idea. Also, in most battles, I expect the situation would change before the camera had switched back and forth too many times, although I suppose even one switch back would be weird.
I'm not going to worry about nukes for now.
Cool idea for later (maybe for nukes as well): I was considering a sort of Matrix effect where occasionally when a big gun is fired (say a Bertha), the camera follows the projectile until it crashes and then zooms out to watch the damage.
I'm going to bias the weighting pretty heavily towards units with weapons, to the point of ignoring units without them. Partly because I don't want the camera to care if there are two metal makers next to each other - "interesting" ~~ "fighting" for this little feature.
diggz2k:
I like that idea! Switching on demand would be cool, and good for debugging initially. Thanks!
(Not forgetting the eventual aim of being able to enjoy watching it unattended).
Dragon45:
That sounds nice and simple :) Perhaps I'll try that first.
Argh: It won't run by default. I was planning to have it recalculate areas of interest every 5sec. Hopefully it would not be a particularly intensive calculation anyway, apart from possibly detecting units that are close to opposition units.
Maelestrom:
Hystersis sounds good. My first attempt won't include time-based stuff, but that hysteresis thing definitely sounds like a good idea. Also, in most battles, I expect the situation would change before the camera had switched back and forth too many times, although I suppose even one switch back would be weird.
I'm not going to worry about nukes for now.
Cool idea for later (maybe for nukes as well): I was considering a sort of Matrix effect where occasionally when a big gun is fired (say a Bertha), the camera follows the projectile until it crashes and then zooms out to watch the damage.
I'm going to bias the weighting pretty heavily towards units with weapons, to the point of ignoring units without them. Partly because I don't want the camera to care if there are two metal makers next to each other - "interesting" ~~ "fighting" for this little feature.
diggz2k:
I like that idea! Switching on demand would be cool, and good for debugging initially. Thanks!
(Not forgetting the eventual aim of being able to enjoy watching it unattended).
Dragon45:
That sounds nice and simple :) Perhaps I'll try that first.
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
-
Lemm1w1nkz
- Posts: 16
- Joined: 26 Jun 2006, 21:07
-
Lord JoNil
- Posts: 47
- Joined: 28 Dec 2005, 03:20
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
It's starting to work!
(Screenshot at Stage 1.2 of the Interest map drawing mode. The red square represents the most interesting square; the whiter squares show more interest. At the moment all it's doing is summing health. )
(Screenshot at Stage 1.2 of the Interest map drawing mode. The red square represents the most interesting square; the whiter squares show more interest. At the moment all it's doing is summing health. )
Last edited by jnnnnn on 03 Nov 2006, 07:46, edited 2 times in total.
Try http://www.photobucket.com it will let you link directly to images.
Oh nice work, already this far, its looking good!
With interest maps that low res, what happens if you have a largish army of small units that cover 2+ squares? The interest points will be spread out over a larger area, so the area wont appear as interesting, even though it has a huge mass of units, just not concentrated.
Dunno how to solve this, besides increasing the resolution of the interest map, but you still potentially have the same problem, just at a lower scale.
Or maybe take say a 3x3 block of interest blocks, add up the interest in them, and use that to define where is good to look at? These larger 3x3 blocks would over lap, so you wouldnt get the same problem, and i doubt you would get armies larger than 3x3 interest blocks big.
With interest maps that low res, what happens if you have a largish army of small units that cover 2+ squares? The interest points will be spread out over a larger area, so the area wont appear as interesting, even though it has a huge mass of units, just not concentrated.
Dunno how to solve this, besides increasing the resolution of the interest map, but you still potentially have the same problem, just at a lower scale.
Or maybe take say a 3x3 block of interest blocks, add up the interest in them, and use that to define where is good to look at? These larger 3x3 blocks would over lap, so you wouldnt get the same problem, and i doubt you would get armies larger than 3x3 interest blocks big.
You could have overlapping interest blocks. (You could think of it as one layer of tiled squares, and a second layer of tiled squares offset by half the square length in each dimension.) So every unit is actually counted twice, but it prevents "border separation" issues since a mass will more smoothly transfer between blocks. Of course, you could really go nuts and have many simultaneous pseudo-random tesselations, virtually guaranteeing smooth transitions between interest zones.Maelstrom wrote:Dunno how to solve this, besides increasing the resolution of the interest map, but you still potentially have the same problem, just at a lower scale.
Here's the 1.2 patch.
To try it, press Ctrl+Shift+i to enable the interest mode drawing.
There is also a Cinematic camera mode that will follow the most interesting square if the mouse is at the right of the screen.
Code is probably awful; I've never tried serious C++ coding before.
At the moment, "interest" is worked out as "what is the second-greatest total health of an ally team group in this square?". This means that squares containing only one ally-team are not interesting. It's just a start.
Patch file at http://www.cs.mu.oz.au/~jnnewn/spring/S ... ge1.3.diff .
More readable version at http://www.cs.mu.oz.au/~jnnewn/spring/S ... ge1.3.html .
To try it, press Ctrl+Shift+i to enable the interest mode drawing.
There is also a Cinematic camera mode that will follow the most interesting square if the mouse is at the right of the screen.
Code is probably awful; I've never tried serious C++ coding before.
At the moment, "interest" is worked out as "what is the second-greatest total health of an ally team group in this square?". This means that squares containing only one ally-team are not interesting. It's just a start.
Patch file at http://www.cs.mu.oz.au/~jnnewn/spring/S ... ge1.3.diff .
More readable version at http://www.cs.mu.oz.au/~jnnewn/spring/S ... ge1.3.html .