RTS Toolkit

So if the default one works fine, I guess the best idea is to find what are the differences between the default scene and your project. I suspect that there might be something weird going on with these spawn points. If you didn't included spawn point to spawn units it might be that something is setting up not properly, as spawn point script is also changing some parameters and then feeding spawned units into BattleSystem.cs. If this is the case, there might be 2 approaches to get it working as you want to. 1) [easy] set things as much similar to original version as possible and reduce spawning time that it would look as instant object placement onto terrain. 2) [harder] if you really want to avoid usage of spawn points, you can try to build your own script, which would set parameters in a similar way like spawn point does and feed units into BattleSystem.cs. If it's not the case about spawn points, probably the best idea as I said is to check what are differences between your project and original scene. To do that you can pause the game play while in editor play mode and in inspector check how parameters for military units looks like. Let me know if this will or won't work out...

 

Keep up the good work chanfot, love the system.

 

Thanks a lot, new update with mainly AI's will be quite large

 

uRTS update with all new AI systems finally goes live today! I kept previous version package as well in order if somebody would prefer to use earlier and simpler approach.

Next big question is finally upon us - multiplayer. Todays Unity 5.1 release allows easier multiplayer support and uRTS will be looking forward to this. In upcoming few weeks it should become more clear how uRTS can use multiplayer.

There are also great news from Facebook API as they starting to support Unity 5 WebPlayer and WebGL builds. So these are great news for uRTS based online game "Tales of Eightrivers" as scores should get working soon.

WebGL is also working with current approach, but it loads scenes only with small number of trees. I hope to nail this out at some point as well.

Hope that the day, when we can start doing some great evening RTS matches, is closer than I thought!

 

thanks for the effort ¡¡¡¡¡

This would be amazing

 

There are some interesting news about using RPG like camera with uRTS:

 

Here I made some tricks to get dynamical texts and grids working properly; fully resizable menus will be a start for preparing uRTS for mobile platforms:

 

Something more fresh coming for terrain environment:

 

nice ¡¡¡

 

So here are some news for UI and terrain updates coming soon:

P.S. Facebook game "Tales of Eightrivers" also get updated.

 

Here I made a small roadmap for upcoming uRTS updates:
Big goals
1. Save/Load system
2. Mobile input
3. Formations
4. Fires
5. Dynamical buildings
6. Multiplayer
7. Sounds
8. Improved pathfinding:
stage1: move units manually instead of SetDestination(), keep NavMeshAgents for collision detection
stage2: NN detection within certain R and complete removal of NavMeshAgents
stage3: dynamical pathfinding tests&research: direct terrain data in path search, steepnesses, NavMesh working principals.

Average tasks
9. Catapults and Balistas (modelling needed)
10. Town development AI - add unused buildings
11. Horses and wild animals (modelling needed)
12. TreeGen polygon geometry revamp

 

Hi chanfort.

I vote for formations. They are a must if you want to make a serious strategy game.

I managed to compile a c++ kdtree library and was around 8x faster then the c# version you use but gave slightly different results.

So I will convert the c# version in c++ and see what comes out.

 

Ok, formations seems to be getting close, but at the moment they are coming in a bit strange way: they are coming like a grouping and decisions tree rather than just making things in "classic squads". In other words, I am coming closer to higher lever battle decisions system, where grouping and clustering taking place. When talking about formations, I may be interested to check not just quads, but also lets say circle, triangle, crescent or any kind of assumed shape of formation. Do you have any good references for that?

Interesting about kdtree. I managed to tweak out with performance in a bit different way - I better redistributing targets for attackers now, so nearest neighbour searches runs less frequent. It also improved overall battle efficiencies, as most soldiers getting redistributed targets rather than tens or hundreds would be waiting for a single target.

I noticed that since Unity 5 NavMeshAgents update is very heavy - in profiler it's the most CPU eating thing.

 

So here I made first look into quad formations. At the moment distance between grid cells is free to choose: I used 4 x (unit size) to keep larger gaps.

However, there are plenty of things needed to tweak up here:
1. Align formation to the direction from where units came from (easy).
2. On un-walkable terrain calculated grid cells needs to be moved to the edge of formation, where terrain is walkable
3. If distance from formation cell to center is much smaller than the walkable path from cell to center, there is obstacle (like mountain or steep terrain), separating center from this cell and cell may not be included into formation.
4. Non-quad formations (rectangle, circle, "arrow", crescent, initial shape, etc).

 

a very interesting point is mobile input

 

Is there a reason why use NavMesh over A* Apex Path? I'm just curious ...

 

Because NavMesh ships together with Unity out of the box; you don't need any other assets to run uRTS and use all it's features!

 

has anyone benchmarked between NavMesh and A* to see which one is better suit for massive AI control yet? I'm planning to buy A* for uRTS. Any feedback on this is very appreciated.

 

I doubt if anyone got so far yet. But I tried last year Aaron's A* with grid navigation. However, I was disappointed that it was only ~300 units working on terrain at 40 FPS, while Unity's NavMesh allowed to use over 2000 at this time. But I guess you can try to tweak a bit with resolutions, distances to units from camera and visibility to camera if these assets allows to do this easy.
However, you may need to tweak up also uRTS parts, where are calls to "SetDestination" and NavMeshAgents used.

 

Formations finally are here:

 

Good progress!!

Now you tempt me to work more with urts.
The texture mask for the formations rocks!

 

nice to hear, however, formations are just a way to distribute units at the moment, they may come in their better role when battle systems and AI's settles to the strong and unified standards

 

chanfort, it is great that you update the project!

I have the following problem: when I zoom the camera and 3d models replace sprites they are larger than sprites and are floating above the terrain. Is it possible to regulate the height of 3d models regadless of sprites?

The formation system is inaccecable at the moment? Is that right?
It will be nice to add the following feature - if a player clicks a single unit in formation he will select all units of the formation. It will be also great to preload the "staffed" formationin in scene and not to form them manually.

 

Hi bangoo and thanks for a question. Yes, I noticed also that sprites looks a bit smaller. I didn't looked deep into this issue yet, but I suspect that real model pivot is following navmesh, while 3dSprites probably are following navmesh in terms of sprite centre. I shall look at some point at this and get it fixed.

The new version of formations is not yet published - at the moment I am testing if everything works fine with new Unity 5.2 and will probably be releasing it after a weekend.

Umm, so with selecting all units if player lets say spawns 17 archers and 31 knights, which ones you think would be good to select if player clicks i.e. on knight unit?

What do you mean by "staffed" formation by the way?

 

In some RTS games you need formations to be manoeuvred en masse rather than as individuals. The squad is a unit but not a single soldier.
That's why sometimes I need to group the formation before the game loads.

 

Interesting point. I may think how to quantise spawned units into formations, which would never disintegrate. However, it will also need thinking how to keep players freedom to manually disintegrate formations if they want to.

 

I would love to see this implemented also. This would significantly increase the amount of soldiers, but still reduces greatly update calls from each soldier.

 

I don't think it would increase anything in terms of performance, except the way how players controlling units. Performance may benefit in 2D games, where you looking from top-down camera and you do not need to re-shape formation when it moves over terrain. In 3D cases the shape of formation is always changing when soldiers are on the move (otherwise it looks kitschy).

 

Currently in the 4 nations example and generated currently are displaying the build options. It selects the Nation Center. it Displays its icon and health. But that's it. Nothing else pops up. It might be that I am currently using a cheap laptop (Which is very much below min unity specs). Currently updating unity on my desktop. Will respond once I can test it whether it worked.
But one thing that has always disappointed me about RTS games is when dead units vanish. I would love to see persistent remains of dead enemies and allies. But that is far more cosmetic then anything. But I might be tempted to try and create something like that.
Then thank you for making this project. I have a massive project of my own I am starting and this is a very useful base.

 

Hi, currently there is a bug in Unity 5.2 when you select a castle the menu, from which you could spawn new buildings does not appear. This is related with Unity's updates for GridLayoutGroup, which does not work with my system anymore. As a result you can't open build menus. Try to use Unity 5.1 and probably in around a week I should get this one fixed.

Now vanishing dead units looks very interesting for me. One quick option you can do with uRTS is to make SinkPhase to be much longer. Another thing which I was always interested would be to add "rot" animation. This would be completely different animation from all existing ones, as it would require deforming human mesh. First stages of such animation would be just laying warrior on the ground. Later it's tissues should start to decay and fall from bones, while finally only bones and some rusty armours should remain on the ground. I was looking for a long time how it would be possible to make such animation (i.e. in Blender), but didn't found anything on the net about them. So if anyone know about it, then it would be a great pleasure to know.

 

Ahh, there is a quick fix for these grids if you want to keep it with Unity 5.2. In "GUIElements.cs" class find the following lines:

Code (CSharp):

1. ScrollRect sr_gridGo = gridGo.AddComponent<ScrollRect>();
2. sr_gridGo.elasticity = 0f;
3. sr_gridGo.content = scrollContain.GetComponent<RectTransform>();
4.  

and comment them out. Then on RTSCompiler click CleanUp button to clean old set-up and Generate button to recompile uRTS.
P.S. Make sure you have backup in case if something messes up that there would be possible to restore.

Alternatively you can still wait while update will be approved and released.

 

So first what is the eta for this update you speak of.
SO I assume you use blender, good so do I. But In terms of the decay, mind if a try and work something up. (I will regardless but might as well be polite)
Finally how do you turn off the sprit thing?

 

Well, update is the point when asset is being updated by bug fixes or implemented new stuff

It's still not very clear about decay animation. If you have some online links, just drop them here.

In SpriteLoader.cs script, which is attached to each unit is set BilboardDistance = 35f by default. If you want that all your units would be not on sprites, but rendered as real models, change this to very large value. If you want the opposite (that only sprites would be rendered), use very small values.

 

Sorry there are no links on a rot animation. But I would take a look at Warcraft 3 and how they handled rot. It might give you a good idea of how to construct a basic system. When the death the unit collapses, a skeleton is created in the same position as the unit. Then the unit sinks and exposes the skeleton. Then the skeleton sinks at a far slower rate. So there is a simple system.

 

Interesting. Thanks, I will check W3, quite forgot it for a while

 

I have made my own unit, but its animations have different number of frames. If animation changes from walk to attack the attack animation is running improperly. It seems to me that the properties of an animation material do not change.

The other problem is that the attack animation has 200 frames and if I set it as a default animation in prefab it runs too quickly.

 

Interesting point. I didn't checked how it works with different number of frames, so probably I missed some playing rates for playing sprites. Thanks for this, I will look at them.

 

Today uRTS brings one of the biggest updates, which includes procedural terrains, formations and start of more manual crowd system. The last component is not fully implemented and it will take a while for it.

However, enthusiasts can start playing around. At the moment crowd system is manually moving units along their paths, like Unity agents do. It also checks if unit would be moved, if nearest neighbour don't become closer than the critical distance. If it is bellow critical distance, units is not moved. However, this approach produces "trapped" units, which never moves if in the front of their paths are other units standing. I tried there to turn on carving with obstacles for standing units that units would walk around. But obstacle carving only takes place at next update frame and probably re-path is needed here. This manual crowd system probably won't bring large performance at the early stages, but it will bring much more control and I suspect that after some optimisations it can become much better in terms of performance. Anyone, who will be poking around this or has any ideas, let me know.

 

Here is one more feature introduced: unified grouping and formation system. So it became finally possible to spawn units in formations and be able to select entire formation by a click on a single unit, while not contradicting with any other previously used features and keeping UI simplicity for players.

 

Sprite bugs (misalignment when switching between 3d object and 3dSprites; "too fast" animations while in sprite mode) are now fixed and will come to uRTS in v3.4. There are still some small level of misalignment exist, but it's should look much better now.

Another thing is that ToER (the primary online Facebook game for uRTS) finally got score system working. Scores are being saved online and loaded each time player comes back to play later. Player gain scores for most of activities. Score system is quite well balanced, so enthusiasts can start playing with their most likely activities (you can also check how sprite bugs are fixed, as ToER update includes this).

 

"Wonderers" should be "Wanderers."

Thanks,

 

Haha, indeed, need to fix that

 

Do you have a bugtracker set up?

 

What exactly you mean?

 

Some place for users to submit bugs. Axosoft has one.. there are a ton online.

 

Well, users can just write me email or message if they find something strange or not working.

 

can you replace SpriteManager with unity's sprite system ?

 

I am thinking about it, but still do not find proper way to bring all features, which SpriteManager allows to do just with built-in sprites or particle systems. I was also recently looking about making SpriteManager to run multithreaded if your point is about performance. But threads are not working with WebGL, but it's another question.

 

Just got saving and loading system working. So now - no longer need to lose longer game play, players can save and come back to continue playing later where they left:

 

First steps towards mobile support: here is how "uRTS" looks like on my Nexus 7 (2012) tablet:

I like that menus and buttons fits automatically - no need to redesign UI after this dynamical menus implementation.