Spring RTS Engine

combine always win:

http://www.youtube.com/watch?v=FIYkV2t6o4M#t=3m35s

Well from a modeling perspective, I would simply make an outside model that replicates the interior of the map. Then have some sort of border structure in the mesh itself (cliffs, walls, or even trees etc). This way you aren't dealing with any bit of the literal map itself. I believe someone in an earlier post mentioned R.U.S.E. It would be somewhat like that, but taken further (aesthetically anyway.)

The model itself could promote non-square borders. Simply have the edge based border structure be within the map itself. So if you had a round map, you'd have the border structure be a circle within the square/rectangle edges. Anything beyond the borders could be blocked off using whatever preventing pathing map spring uses. (I forget what that is.)

Once the model is done, you'd scale it and center it to the map. In my mind, I don't see any reason to even look to the map structure itself for anything outside of the walkable map. The map structure works the way it does because it needs to function with the units itself, so when you take out the functionality, why look to the structure with that function if it is so limiting?

EDIT: For reference, look at what supreme commander 2 had. Though, it's a bit different, as the pathing is based on predefined and separated mesh structure. From the artist's perspective, in terms of practicality, it would be the same process without having to model/texture the interior.

Using alpha channels, it would be extremely easy to transition between the mountains and the terrain. The mountains would all be separate mesh.

And for everyone about to ask the obvious, "what about texture tiling": isn't it fairly easy to implement uvw tiling?



And furthermore, note the blackened edges. This would be faded out the closer you get to the ground with the camera. (It's a really helpful art asset.)

I think we may be making maps in general wrong. Personally, I think the map should be modeled along with the outside model; then separated later, and baked for heightmaps etc.

[LOeT]Zinn wrote: For I am no artist here is the next best* thing I found to illustrate what I am talking about:
Where the Spring-solution needs to have the walls adapted to the maps height so there are no blind spots while watching from a low angle.

Something like that seems cool to me. It's simple and very intuitive as to where the playable area ends. And have the board edge be of a angle <90° so it won't hide units on the map edge.
Sure it doesn't make it look like realistic terrain anymore than before, but I don't care about that per se. A gaming board floating in space is a great aesthetic improvement over piece of terrain with ugly edges floating in space, even if some maps might want a different look.


Though there really shouldn't be anything forced by the engine or games into old maps I think, just include the mapedge beautifiations into new maps so it can be decided on a map to map basis, what kind of look the mapper wanna go for.

hunterw wrote:

Pako wrote:I opened the code and it was so sickening I threw up this to my keyboard.
http://springrts.com/phpbb/download/fil ... ew&id=6636

I don't prefer this method. It is confusing as to which areas are playable.

Ingame I did not find this to be a problem.
The unplayable areas have no detailtexture, no grass, no features, no shadows etc, all that is subtile but makes it easy to see where the playable area ends.

I like the blackbox widget by Argh.



Makes the borders look nice and neutral on any map.

However, there's a problem with hills in the map edges:



Looks quite horrible. If this was fixed though, the widget would be an elegant solution imo.

The blackbox widget is attached below.

Look at the latest stable version of evo (v1.9) for how I fixed the problem (I don't have the ability to load it up and take a screenie right this moment).


Edit:

Do y=y/(distance from map).

Beside texture, what is different to
http://i5.photobucket.com/albums/y195/K ... egrid3.jpg and
http://h4.abload.de/img/noise_map_edges_29ogl.jpg ?

beautifull .. Forb.. do those white lines have a gradient from mapcolour to white?

knorke wrote:Beside texture, what is different to
http://i5.photobucket.com/albums/y195/K ... egrid3.jpg and
http://h4.abload.de/img/noise_map_edges_29ogl.jpg ?

Forb picked a more aesthetic texture, which is important. He's also better at taking screen shots.

a fence

PicassoCT wrote:beautifull .. Forb.. do those white lines have a gradient from mapcolour to white?

No, no gradient, but it's all just an illusion. The extent of what I did was take that map gadget that does that grid texture, and change the texture so that the grid was much larger and instead of transparency, made it solid black.

It looks the best out of any solution I have seen so far, and I'm very happy with it. Have a look at it ingame and see for yourself. It works really really well.

smoth wrote:

looks pretty good to me

Forboding Angel wrote:It looks the best out of any solution

same shit different day


still didn't fix the main issue, still probably not done at preunit.

I need to sit down and:
- write code to cover the holes(fence or underlying color)
- fix it to be preunit(not a simple switch something wierd is going on)

the black box code fails because:
- has distortions at angles..
- is not preunit(as in effects and stuff are rendered beneath it such as the lasers coming up from the evo mexes)
- when changed to preunit the black outside goes away.
- doesn't follow contours.

still the most glaring gap in logic is not filled.. why cant i go outside map :D

a sudden mindfield and airstrike, + well hidden fortified stations appear ;D

IMA NOUNCIN MAH MOD

So, when a map include its own solution for map edges, how does it tell the mod-side code that draw Forb's grid to switch itself off?

the part of smoth's post that was relevant:
(no idea how to duplicate posts so here it is again)

smoth wrote:Zwzsg:
Forb could add a trigger file to have the widget not turned on unless the map includes say enfranchiser.txt.

-----------------

still unsolved
trigger file seems bad, global widget variable (WG.allowGameToDrawMapEdges=true/false) seems better.
Or a real config file that also allows the game-widget to read some things from map like grid color, texture etc.

That is what I mean though, say like gundam's feature placer.. it can contain values but if it is not present at all, then the widget does nothing because it's config was not found..

Never has a new mod announcement been so unloved =(

Maybe the mod-side widget could check the map archive for traces of Lua, then disable itself if it finds *.lua or a LuaRules or a LuaUI folder?