Template Space Combat Kit (VSXGames) [RELEASED]

The GroupManager scripts, which amongst other things distribute targets to each of the ships in a team evenly, have been coded to simply check of the target is not on the same team, but should also check if they are neutral.

Open the GroupManager script and change this line (should be line 114):

Code (CSharp):

1. if (allTargets[i].Team != groupMembers[nextToAssign].GameAgent.Team)

to:

Code (CSharp):

1. if (allTargets[i].Team != Team.Neutral && allTargets[i].Team != groupMembers[nextToAssign].GameAgent.Team)

 

That should make the default AI a little less Klingon. Thanks.

 

can you adding camera lean and evade rolling system like airrivals ?

 

What do you mean by camera lean? I will consider adding roll evade to the kit when I get around to updating the AI/maneuvring.

 

That multiplayer is kickin ye butt isn't it? lol

 

There's some stuff to get through, but nothing too difficult just yet. I must admit I was a bit optimistic about the time. Main problem is that debugging is 10x longer when you have to build the project every time you tweak, and lately I've run into some stuff that took me a while to sort out.

I spent the last two days getting to grips with the physics sync/prediction - which I thought was good enough before but lagged way too much at high speed, and pretty much nailed it. Right now during combat the prediction model is pretty much dead accurate (I test by simulating a network data stream every 0.2 seconds - so the test results are working from real data that's >0.2 seconds in the past). I'll put up a video of it tomorrow, while I continue to hammer out the rest of the multiplayer stuff asap.

 

Here is a trick for your debugging time : you can open 2 unity editor instances , you need to duplicate the project and either use a tool to synch folders or if you feel adventurous, make an "asset" symlink in project 2 that points to the real assets folder of project 1.

I did those 2 things, it works fine, of course you need a decent amount of ram.

 

Thanks for the tips. Part of the problem is that I'm used to messing around a lot (tweaking/recompiling etc), but with a bit of careful design and thinking up some nifty ways to test things on a single machine, I'm getting better at it, and it's probably giving me better habits!

 

Here's a vid of the prediction model in action. The white 'ghost' ships are what would appear on other clients in multiplayer. It's a simulation that involves creating a continuous prediction from rigidbody data captured every 0.2 seconds.

 

Please anyone who tried this kit using as aerial combat (above some surface), please post a video If, such experiments exists by someone. Thank You.

 

It shouldn't be too hard to implement this. In the AIFighterControl script, before you send the steering target position to the Maneuvring.TurnToward function to get the steering values, raycast down to the ground and clamp that steering target position to some margin above the ground.

 

Still alive there Billy? We hunger for more updates =P

 

Still alive! Couldn't work on it much last week but it's coming along well right now. Sorry for the delays, but I want to make sure it finds the right balance of efficiency and simplicity. I'll update in a few days when I have a better idea of when it'll be ready.

 

Hoping you're doing well! Any progress so far?

 

It's coming along well. There's a bit of a learning curve to coming up with an architecture that feels flexible and extendable the way that the kit needs to stay.

For example I had a lot of PhotonView components on different modules at one point, and then decided to rip it all out and send everything through one PhotonView on the vehicle parent, to make things easier to set up and more efficient. This meant that I have had to go through and re-do the events that are called on the modules and module mounts to be able to RPC the right data at the right time. But I think the advantage is that this way the multiplayer code it's much less invasive and easier to debug. Things like that.

At the moment I am quite happy with the basic methodology for syncing the ships systems and modules, and I've got drop-in/drop-out scene syncing happening as well as the basic format of a drop-in team deathmatch game. Now I'm going through all of the interfaces (e.g. ITriggerable, IHealthGenerator etc) and sorting out the network syncing of each.

 

Did you think about releasing multiplayer as an addon package, to give you (or even someone else) the opportunity to release a UNET version (or steam networking or whatever networking solution people want to do ! )

 

Yes it will be a separate package. The reason being that it comes with its own set of difficulties and challenges as well as being useful to only those who want to make multiplayer games.

It will be possible to upgrade for free at first, and then it will be a paid package on its own.

 

Will you also be upgrading the multiplayer part after it's release? Maybe more modes, lobby types, etc? What future plans do you have for both assets, separately and together?

 

Absolutely. One of the things that I'm doing now is creating parts of the multiplayer that are flexible to use for different types of multiplayer games.

For example, I could just make a team deathmatch where everyone controls one ship, and the game starts when everyone joins. This would make syncing the vehicles between clients quite easy, since I could store information for a single vehicle in player properties on each client. But instead I am making something which will sync vehicles for new players dropping in anytime, regardless of whether these vehicles are being used by players, AI or even just sitting there not being used.

My approach is to look at every part of the multiplayer as a separate problem without any specific context, so that what works for one purpose will probably work for another, as well as the fact that it makes my life easier to deal with issues that are self-contained.

The idea for the multiplayer package specifically is simply to develop it alongside and in step with the main package. The only reason I want to separate them is because multiplayer is a completely different level of difficulty, and I want to be able to manage it on its own in terms of customer support, documentation and stuff like that.

After I finish the team deathmatch multiplayer, I intend to:

• Expand the space kit with a capital ship demo.
  
• Integrate first/third person characters.
• Develop different kinds of vehicles, maybe as separate packages or within one big package.

These are the medium/long-term targets, but of course there is work to do to improve the kit in its current state, especially including better obstacle avoidance, AI and several parts of the kit that aren't quite up to scratch yet.

 

Maybe you could have split screen mode in the basic version ? That will prove your code is well designed, modular and ready for multiplayer.

• Integrate first/third person characters

I recommend GKC because it's sci-fi oriented, very well designed (the split screen idea comes from there and the author is hard working and friendly, he would probably collaborate with you on the integration.

integrating Opsive TPS is a waste of time now as the version 2 that merges TPS and UFPS is coming in the next months.

Then the 2 other big ones (ooti and invector) make sense for your sales, and they are modular so it should be easy.

What you should check is compatibility with Space Graphics Toolkit and Space for unity , should be ok but worth testing and writing on your store page that it works ( I assume you use a namespace in all scripts, but sometimes the other guys leave a class named Utility or something like that in the global namespace and it F***s up your utility class even if you have a namespace !) Maybe make sure everything is fine with multi-camera setups.

Cheers

 

Thanks for the suggestions. It would be nice to have a tight integration with all the other cool packages on the store, but at this point the main thing is to resolve the transition between character and vehicle control in a fairly standardisable way. Once I've provided a clear path for achieving that, I will go through and perhaps create more complex integrations with some packages that I consider to be stable and sufficiently well-designed. However I don't want to be spending all my time resolving issues with integrations of packages that other asset store sellers are updating, since there is a lot more stuff I want to make for the store that will take plenty of work, besides my own game.

So to put it another way, I intend to integrate the Standard Assets first/third person controllers first in a way that will hopefully work with all the other controllers out there without too much trouble, and go from there.

 

That would be cool. I miss the days of playing multiplayer with your buddies and socializing in the same room.

Yeah, I'm working with the ootii controller, and it's awesome, really modular and straight forward. Integrating it with this probably wouldn't be too difficult, and would be really cool. There's a pretty neat combat system across the add on packs that would be great if it could get along with your system. Probably shouldn't be too hard either.

 

I have one question:
if i add the DemoTrackable script on a GameObject and also select to not disappear in the distance,
this doesn't seem to be the complete solution, since the waypoint isn't appearing in the radar if it's far far away.


What I need is a waypoint for example to a homeplanet which is always displayed in the radar.

Do you have an idea what to do for that?

Thanks in advance and keep on with your super asset!

Best regards
Jürgen

 

I need a little help with the power system.

1. Unless I'm mistaken, it looks like beam weapons always draw power, without checking if firing or not. See WeaponControllers/BeamWeapons.cs, line 322. In ProjectileWeapons.cs 215, you wrapped the entire update with a conditional on firing, but the beam has several interesting states so that might not work as expected. Suggested fix?

2. I would like to add a "DrawStoredPower" for thrusters based on throttle and boost. I thought Engines.cs would be the obvious choice, but I don't see an easy way to access the vehicle.power, since it doesn't have moduleMount like the weapons do. Please advise on the recommended place to wire this in.

Thanks for your help.
Best Regards, Richard

 

@JFI66 @Keywise I'm going to make an update (not including multiplayer) with a lot of bugfixes within 48 hours, including those you mentioned.

The correct place is SpaceVehicleEngines.cs.

The Engines component is essentially just a bridge to a component implementing the IVehicleController interface, which is where all the real stuff happens. This is to make it easy to create lots of different control systems for your ships.

 

Wow, thanks a lot!!

 

Quick scope creep request for the update: would you expose starting number of units to the missile? Makes HUD bars displays possible if the max is known.

IMissileModule.cs, line 25
int StartingNumUnits { get; }

MissileWeapons.cs, line 62
public int StartingNumUnits { get { return startingNumUnits; } }

I could make this change ever time there is an update, but if the change makes sense to you it may help others as well. Thanks.

 

Will do.

 

Thank you, very much. Here is a image of my missile ammo bar (in orange). I'm having a lot of fun with the kit. Keep up the great work.

 

hi i want to make it use in vr and want to ask how i can use the targeting in worldspace, i try scince 2 days to mange it myshelf but i get wierd results. what is the best way to archieve a worldspace canvas in my ship and let it show the direction of ships?

thx for any help!

 

There's currently a bug in the HUD that might be responsible for messing things up, which I am in the process of fixing right now. The next update should be sent out later on today.

In the meantime, take a look at the radar documentation I've attached (which I am merging with the rest of the space kit documentation) which details the process of switching between world and screen space canvases.

If you have any more trouble after following the steps in the documentation, let me know.

 

Not sure if its possible in this kit (ive yet to find it myself), can you target different modules of other ships ? Such as targeting an engine module or weapons module which in turn affects there speed/weapons.

This is probably more aimed for larger capital ships e.t.c but curious if it can be easily done.

 

Let me put it like this: things have been designed with this in mind, but there's some stuff to add to make it work. I am about to send off an update, but in any case since I will put it in for the next one. In the meantime here's how I would do it.

First of all, the kit has been designed to have multiple colliders on a ship. The example ship has two - one shield and one hull collider. On each of the collider gameobjects is a HealthFixture.cs script, which basically identifies a damageable collider, and contains delegates that you can attach functions to in order to do something when hit or collision events occur. This means that you can attach subsystems component functions to these events to modify subsystem properties (such as power, speed, weapon energy etc) in the event of the collider being hit.

Note that it might be preferable to modify the subsystem properties based on the health generator itself rather than the health fixture/collider - so that you don't have two different pieces of equipment sort of working blindly in parallel. In that case you would extract the health generator information from the Health subsystem component, and modify the subsystem properties based on the health generator's health level.

In terms of the HUD, that's a bit more tricky for me to implement for you guys, as designing the UI experience of targeting a subsystem is not a standardisable thing. The main thing however is simply making a hierarchy of targets (targetable subsystems as 'child' targets of the targetable ship). I think the best way would be to create a hierarchical system within the ITrackable interface, such that you can have a list of all 'child' trackables from a 'parent' trackable, which each could technically have children of their own (although that might start getting a bit busy!).

If you have more questions email me and I will go into things in more detail.

 

When the player's vehicle enters an area they can dock in, I'm using a trigger to display a "Dock Now" UI button. I want to limit the trigger to only the player's vehicle so other ships or projectiles will not trigger the dock area's collider. I'm considering setting the "Player" tag that the script on the area's collider can verify the event was actually the player's vehicle.

1) Would the best place to apply the "Player" tag to the player's vehicle's HealthFixtures' children be in
PlayerSpaceFighterControl Initialize()?

2) Or, is there a better approach instead of using a tag?

 

The fastest way to get a reference to the Vehicle from a collider is to first see if the collider has an IDamageable component. This component has a reference to the RootGameObject which is where the Vehicle component can be found (if it is a vehicle). You can tag this with "Player".

In case your player will enter/exit different ships I recommend instead checking the game agent that is operating a vehicle to check if it is the player. The Vehicle script has a property GameAgent, and the GameAgent script has a property AgentID which you might set to "Player". This way your player can be tracked no matter what vehicle they are in.

 

Thank you for the guidance.

Looking forward to the update. How is it coming along?

 

I just sent off a bug-fix update. There's no multiplayer in it yet, but should deal with all of the bugs turned up so far. Multiplayer is up next.

 

I don't know if this has been mentioned here (search don't find anything), but for all your docking,landing, mounting, moving platform problem, unity has introduced this:
https://docs.unity3d.com/2018.1/Documentation/Manual/Constraints.html
This to me is huge, it makes unity more of a game engine than an engine with which you makes game. BUT I haven't try it for myself yet.

It allows to "parent" to many "sources" with only part of the transform (scale, rotation, position) with an assigned weight you can programmatically changed.
I hope internally they used it to travel through order of update, that's one big issue with working with multiple parents. And does it handle loops?

 

Thanks for the info! I'm mostly trying to stick to physics in this kit, but that looks very handy for all sorts of things.

 

I share it here, because you have the inevitable person who want to dock his fighter on a freighter lol
It does fall into physics but I get what you are saying (flight control not collision)
It was first mentioned in the game kit controller thread, because of trying to land a spaceship on a freighter and moving with a car like vehicle on it.

 

The update is available in the assetstore...

 

Are there plans to support the asset "Space for Unity"?

 

I'll take a look at it. What are the aspects that need integration?

 

For example in the Space asset, there are two camera systems. One for the ship and one for the background.

 

@JFI66 The spacetoolkit you just need to assign the players camera at runtime to the scene cameras tracker script. There really isnt anything the dev for this package needs todo.

I will try to post more detailed screenshots in a bit once I am back at my desk.

 

I was talking about this asset:
https://www.assetstore.unity3d.com/en/#!/content/7095
Do you mean this by spacetoolkit?

 

As you can see just add the hud camera to the space scene cameraand you need to play with the layers and depth but nothing the dev of this kit really needs to do for you to make it work...

 

Wow! Cool, I'll take a look into it.

Thanks a lot!

 

Sure thing, happy to help. PM me if you have any issues setting it up.

 

Are ship acceleration and turn rates determined by ship mass and engine power (f=ma) ? I would like to have larger ships that perform like they are heavier than the small lighter ships.