Spring RTS Engine

Download link: Here (r321)

Homepage (Wiki, Bugtracker): Homepage

Please report any problems/crashes/questions/suggestions etc. you find here, or within the bugtracker.

There is a basic tutorial inside the wiki, but you may add better ones.
Please read the Readme, or look into the FAQ they contain valuable information.

NOTE: Current archive contains some Features from the "Feature Resource"-Thread. Please pay your credit to the respective owners.

Assets (Features, textures, etc): AssetPack r3
Note: AssetPack currently does not include any licence/readme. This will be fixed soon. Basically it is a collection of stuff found inside this forum, just packaged nicely.

Prefabs (Pre-fabricated Tiles):
PrefabPack 64x64 r2
PrefabPack 128x128 r2
Note: PrefabPack currently consists only of Tiles made by KaiserJ.
Pay your credit

Source:
Mercurial repository at:
http://frostregen.org/hg/SpringMapEdit
Just clone this url.



There are some more images attached to this post.
A developement log which shows the various stages of this editor may be found at http://frostregen.darkstars.co.uk/.

attachment placeholder

VERY VERY AWESOME, I CANNOT WAIT TO TRY IT TOMORROW!

this idea is made of win; i'd love to give it a go and provide testing / feedback

i've downloaded the latest java version (working w/ windows xp) but where do the library files go? in the folder with the map maker?

thanks for making something so awesome, +1 internets for you

own

How hard would it be to take this and replace the components with the swing GUI kit and integrate it into battlehub? You've written a veritable gold mine of utility classes and functions.

AF wrote:Integrate it into battlehub?

integrate how much you want, but I think a mapping tool is out of place in a lobby so I'd still want a standalone version released

@KaiserJ: On Windows it should run out of the box.
The needed library files are already inside "lib_win32".

@AF: I did switch to SWT on purpose:
1. It is has native widgets on many OS's.
2. But far more important: I can control the message loop -
have it run on the thread I want it to.
3. The how-to-use of SWT seems more natural to me.
4. GLCanvas in SWT is somewhat faster than in AWT.
I guess because you have to (are able to ) manage the GLContext on your own.

That said, what exactly do you intend to use for BattleHub?

@Brain Damage:
I do not think AF wants to integrate the full editor. Maybe a 3D Preview of some sort. (Which would be theoretically possible, as loading SMF comes soon, and with reduced LOD the memory requirements are acceptable.)

-Frostregen

hmm with swing you need to run everything in the event dispatch thread anyway which helps separate GUI logic and program logic anyway.

The point being swing can be skinned and manipulated visually far easier than SWT since its not a heavyweight component.

Eitherway the two can be mixed but I have no experience mixing SWT and swing components

cool stuff.

btw WICED supports placing roads on a spline path - could you do something similar? it works like this - you draw a spline path on the map and select a texture; it is then painted along the spline. they're applied as a layer, so you can turn them on/off in the editor (they're baked into the final texture.)

@AF:
This is the same in SWT too, but you can create the threads yourself.
Decide to spawn new Threads for every window, or keep some windows in thread 1, and some in thread2. (I separated the renderwindow from the rest of the GUI to keep it rendering when using the GUI).
It is just that I know where my threads are in SWT, and in AWT i do not

Hmm, I never made a skinnable GUI, so no experience here.

If you explain, what part you want to use, maybe I can help you better.

@imbaczek:
This is on my TODO list. including setting the typemap below to a specific value :)
The on/off feature won't be there though, since it is not only a texture thing. The path will also be flattened based on some maxSteepness value.

Im unsure what exactly I want to use (and with swing everything is on the dispatch thread, its single threaded from the java side of the API (note swing != AWT))

imbaczek wrote:cool stuff.

btw WICED supports placing roads on a spline path - could you do something similar? it works like this - you draw a spline path on the map and select a texture; it is then painted along the spline. they're applied as a layer, so you can turn them on/off in the editor (they're baked into the final texture.)

wiced couldn't handle intersections though and that failed HARD

smoth: intersections are a HARD problem, that might be the reason.

Eh, I am sure they could have come up with something. Think about how you would generate an intersection in teh shop..

if you want to be lazy you make a simple asphalt(picking asphalt because it is harder than a dirt road) block as the center. You cut 8 triangles for a 4 way intersection each one draws a center line man fuck, I'll explain this poorly without illustration and I am posting during compile time.

I think it is doable. If waves that contour the shoreline can be done, intersections can be done as well. When I generate an intersection I just cut along axis lines, I suspect this can be done programaticaly.

@AF: Then get sure what you want to use first
I just noticed my MapRenderer class just requires a GL instance.
This means it is independent from the used GUI System anyway, so no problem here.

About Roads:
Ok, intersections require to specify all roads before calculating the textures.
So the system will be like:
1. Specify all paths
2. Maybe save them to disk
3. Finally bake them into texture/heightmap
The baking would always be a single(the last?) step.
4. If you don't like the outcome-> reload map, modify them, bake again.

intersections at right angles could be made automatically rather easily, anything else is still doable but hard. shorelines are easy since they blend well, roads can but need not to (stripes and whatever else is there on a road.) I'm not a photoshop pro, so don't know how exactly I'd do it by hand either if it wasn't a right angle intersection.

Frostregen wrote:
About Roads:
Ok, intersections require to specify all roads before calculating the textures.
So the system will be like:
1. Specify all paths
2. Maybe save them to disk
3. Finally bake them into texture/heightmap
The baking would always be a single(the last?) step.
4. If you don't like the outcome-> reload map, modify them, bake again.

sounds cool to me!

Hey, this looks really cool. Couple of comments:

1. The World Builder Editor can already do placement / playback of Units and Features alike, and it's fast and reliable. I'm not sure that that's an area where you should spend a lot of time, because adding new things to World Builder and to the Editor is trivial, whereas it may or may not be for you, and maintaining World Builder is a lot easier. Also, World Builder already has the Lua stuff necessary to make a lot of useful things happen.

2. I'd really like to see a "paint with splats" and "paint by texture fill" added to this. I think that trying to produce a full-featured paint program is probably doomed due to the complexity involved, but just being able to click and lay down splats and dump-fill an area with a given tile would be very nice. Neither requires complex layer handling, etc.

The only catch, imo, is that you need a good, clean way for people to import their splats (probably TGA or PNG images, although I personally would prefer TIF, as it's basically RAW). Also, it would probably be nice if splats could be enlarged / shrunk dynamically, so that you can use them in different contexts, and an "airbrush" mode where you can use any texture you want, and it dynamically makes the edges soft.

I know that's asking a lot, but if you're going to do real road-building code, then a lot of this would be recycling that code as well, and the code for doing stuff like the "airbrush" is widely available- if nothing else, GIMP's source could be consulted, for a fast algorithm.

3. Can you maybe integrate RogerN's erosion stuff into this, if that isn't already done? It's slow, but the results are fantastic.

At any rate, please don't look at what I'm doing, which is going to end up with similar basic capabilities, as "competition".

I'm trying to solve the problem of editing a map's content for final gameplay, but I certainly don't anticipate being able to develop a working map-painting environment, etc., nor do I think that I'm going to be able to produce a really good set of tools for doing specialized tasks like erosion, etc.

So I look at tools like this as part of a "daisho", where World Builder Editor is for final rigging of gameplay elements on a map, and stuff like this is for getting the map ready to get to that final series of steps. I think that World Builder Editor's going to be a more appropriate way to place Units and Features, because I can hook into stuff via Lua, and do things such as record paths for Units that I've given Move / Patrol commands, for example, whereas this probably won't be a good place to do that. That, and it's a lot easier to add to the list of "smart props" in World Builder than to try and shoehorn them into this, imo.

At any rate, do whatever seems cool to you, of course. I'm just saying that on some of this stuff, I wouldn't bother reinventing a wheel I've been working on for quite awhile. I think that the engine is the best place for final editing of elements, basically, while a tool like this is best for getting the initial setup done. I'm really looking forward to having time to mess with it.

I do not see worldbuilder as an answer to feature placement argh and think he should keep the feature placement. Feature placement is a good thing and I hope he continues with it. Not everyone wants to use your worldbuilder tool/thingie. You are happy with world builder but I know I am not the only one who is not using it and I mean no offense, I am glad you took my feature placer thing and did something with the idea I tabled. Thing is I think placing the features in an editor like this still has a relevant place.

I do not agree that the feature placement should take lesser priority, I think it is very important. There is nothing wrong with people having other options beyond your tool.