Template Space Combat Kit (VSXGames) [RELEASED]

I like it!

 

Thanks @danreid70, let me know if you think of any suggestions for what could be added. As stated, it's scheduled to be finished this weekend, and I'm pretty much at the stage of script-checking and writing a quick guide.

Next after this is the spaceship control, and since each thing is being done in a modular way (reducing the complexity of each package), I'm probably going to be adding newtonian physics as an option in the first release.

It's a lot easier for me to release modularly so that I can get some early feedback as to how much of a hassle it is to set things up, and optimise that experience. At the moment it's interfaces along with example scripts, so you can either implement the interface in your current code, or just use the provided script.

 

Radar package is on track for this weekend.

Lately I spent some time with the profiler doing optimisation. Found some weird performance issues with Unity's UI on a world space canvas so ended up moving the 3D radar entirely to non-UI components (SpriteRenderers and LineRenderers) and got much better performance. The demo runs now at about twice the speed (60-70fps with 200 targets on my laptop) which was actually pretty much the goal.

One performance problem initially was setting the distance text values on all the targets (ToString() operations with inevitable garbage creation - about 30KB worth per frame) so I created a lookup array with 100km worth of elements at 100m precision, which should be good enough for most uses, and can easily be modified to suit.

Still a couple of changes to make to polish performance, but I'm pretty happy with it now. I get 200fps with a reasonable scenario of 50 targets.

 

Latest web demo is up.



Check it out and let me know what you think.

Hoping to release tomorrow, very happy to be finally getting something finished for you guys!

 

If you're not careful, you're going to end up making a game.

 

Actually that's why I decided to split it up into parts, I was losing a sense of how all the systems fit together and focusing too much on art and demo. I was starting to patch stuff together in an unorganised way just to make the demo work better.

Apart from UI textures, this radar asset has only the ship (which is one I made for the asset store some time ago) and the skybox as art assets. And it feels right because even those are things I just added at the last minute to make the demo more expressive.

So 99% of the work I've done in this just recently is designing and iterating the code framework which I think is really what's important to people buying this. I can make asset packs later on. And it was always my idea to make a point of creating code in a modular way which, while it's not necessarily efficient for your own game, is absolutely necessary imo if other people are going to use it on stuff they've already worked on. Splitting things up and selling them individually is my way of enforcing that, since they will all ultimately have to work together cleanly.

 

The Vehicle Combat Radar package has been submitted for review!

Try the updated Web Demo.

The package includes a zipped .pdf User Guide to help you get up and running and give you an understanding of how it all works. I look forward to your feedback and reviews!

Next:
Spaceship Controls with options for arcade, atmospheric and newtonian physics. ETA for submission - 2 weeks.

Stay tuned and thanks for stopping by!

 

Hello everyone, I just wanted to make a quick cross-post about my new game WIP - an attempt to make a mobile space combat game in just three weeks. Not only is it using a lot of stuff that I've already made for this kit, but it will (and already has) made me realise some things about code I've written for it that was really difficult to work with. I want to not only finish my first complete game but also get an overall perspective on making a kit for this genre.

In the end I will likely strip out all of the art and build up the core of this game directly into an asset store product that is feature-complete, at least at a basic level, including things like AI.

 

@Billy4184 Hi, it's for a while, quite a long wait I wonder when will this space kit on AS? How modular each sub-system is? Because I want to use your Radar, Targets Tracking, AI sub-systems only for now.

 

Hi, the radar package has been submitted to the asset store ^^ and is pending review at the moment, I can't tell you exactly if or when it might be approved but hopefully within the next week or two. It covers 3D radar, dashboard holograms and screen-space target tracking with a variety of details.

As for the whole kit, believe me, I'm well aware it's taken quite a long time and that I haven't hit the deadlines I've announced, not by a long shot. It's not fun for me to have people paying attention and waiting and then not having it done. In the end, it's mainly a question of lack of good self-management which I hope I've corrected by now. The worst thing has been rewriting the whole project multiple times for no particularly good reason, and usually ending up in the same place.

Also, creating the game that I linked to above is hopefully going to give me perspective on space games in general, and I chose it partly because of how it feeds into this. I've wasted a lot of time trying to meticulously figure out the best way to design space game stuff and maybe I lost sense of what it would be to be actually making a space game.

Anyway, as for the modularity, that's something that I'm hopeful I've done right. The radar module is designed to be stand-alone (you'll have to be able to implement simple interfaces to get it working with your weapons and such) and all of the major sub-systems (engines, weapons, shields, power management) will be designed the same way.

As for AI, that's going to be last in development as I want to create the core kit that I advertised first, and then add peripheral stuff like AI. So probably not for a couple of months still. However if you want to discuss AI just pm me and I will tell you all about what I know of it.

 

Wow, that such a good news. I can't wait to check out your Radar system. Right now, I had my eyes on this Radar system, called "Pro Radar Builder", which supports both 2D, 3D radar. But, its Editor is DLL close-source. And, I tend to stay away from DLL, still waiting to check out your radar system

I know it's such hard-work to write good code for a starter kit. So many assets out there, are written badly, ignore the whole performance practices. So, take all your time if you needed too.

There are no good, flexible, & performant 3D Space AI on the asset store now. So, I hope you give it a try, a good local avoidance, formations, target detection would be awesome. I still don't know how you get a best performance cost for a fight between 100s ships.

 

Although I also stay away from DLLs, I can see why they are attractive for making user-friendly tools. It's extremely hard to write something that is pleasant to use both from a user perspective and a code perspective, and retains flexibility while not crowding the code with stuff you won't actually need. That's why I'm trying to make this very, very modular, so that it's easy to remove stuff you don't need without it leaving loads of code in there that you will never use. But it's definitely a challenge. Several times I decided to pack it in and just write the whole kit without modularity, and while it was pleasant for a while, as soon as it began to get complicated I just didn't want to deal with it anymore. So I'd rewrite it again to be modular. And so on..

The radar system should be very performant, I had it running at about 200fps I think with 100 targets on my laptop. I spent a lot of time in the profiler reducing garbage collection and increasing speed, so it should be a good tool even for mobile.

To be perfectly honest, I should have done the AI/obstacle avoidance first, since over time I've gotten the feeling that's what most people are missing the most. But now I have to finish what I started and get the core space game kit done since I'm sure some people have been waiting for it for quite some time now.

PS about performance with loads of AI, I think the main thing to keep in mind is this: space is huge, and the times that you actually have to be watching out for collisions is incredibly small. It would be much, much harder to write AI for something like Strike Vector compared to something like Elite Dangerous because in Elite, you're hardly ever going to run into things. So for example I'd begin by setting up obstacle alertness zones around stations and asteroid fields, possibly with nav waypoints, and during combat simply compare positions of ships with eachother as a pre-optimisation for checking if you really need to ray- or sphere-cast for a collision. Things like that. Also have a buffer system for easily splitting up stuff like raycasts between frames. You have to be ready to hack things and not get all hung up about being authentic since the times that you actually need to ping your environment are not very often.

 

Very nice thoughts on AI optimizations

 

@Billy4184 hi there, any news on the Radar/Targeting system yet? will it be on the Asset Store soon?

 

Hi! It was rejected a couple of weeks ago for various specific reasons, one of which was that my website at the time was almost nonexistent. So I put it on hold until the website was done.

Having just added the mining system to my game I found a couple of ways that it could be improved and that's what I'm working on right now. It will be submitted again this week, hopefully all goes smoothly this time. I'll let you know when I've sent it off.

 

Although I agree in principle, the problem is that in space combat games, things are typically flying directly at other things, dramatically increasing collision opportunities. Also, while space may be huge, game space is not, or things would become very dull very quickly. "Go mine that asteroid: flight time, eight months, ten days." In particular I found good (and relatively frequent) collision-avoidance tests are very important in dogfight scenarios. And then I found that it was easier to just do the tests all the time rather than trying to decide if they should be done.

In one of my many abandoned projects, I originally did the same type of thing by checking position before raycasting. However, I found that raycasts are so cheap, the optimization effort and additional complexity didn't make sense. I typically had perhaps 100 to 200 collision-related things flying around and I've read that Unity should be able to manage thousands of raycasts and colliders per frame on typical hardware. Even so, scheduling them across frames still "felt" right to me, if only because it's so easy to do. On my somewhat mid-range laptop I was able to run the numbers into the thousands for testing purposes without any issues.

One thing I found very interesting: the accepted wisdom that square magnitude is faster than true distance is apparently not true on modern PC-level hardware. In fact, I have seen tests were Vector3.distance is something like 50% faster than Vector3.dot -- apparently square roots are very highly optimized these days. I don't pay any attention to mobile and obviously that may not hold true there, but it may be worth considering for your optimization efforts. It was nice from a coding-convenience standpoint to be able to use .distance without sweating the impact too much.

Combining that with AI passes scheduled across frames (instead of per-frame) was really all the optimization I needed.

 

Oh yeah, one trick that worked well was to automatically adjust the number of AI passes based on frame rate. Time.deltaTime isn't exactly high-resolution but you get it for free and it worked well enough for me.

My project attempted to use "realistic" aerial-combat-style maneuvers (split-S, etc.) and following those routes took quite a bit of processing to make the waypoint turns look reasonably "natural" (i.e. even though you're in space, aircraft-style movement looks more natural to most people), and after adding that adjustment you could actually see the fighters get more or less sloppy depending on how busy the scene got (especially ramping it up artificially for testing purposes).

 

Well yes and no I think - there's going to be a huge difference between collision detection in the average Elite Dangerous battle (usually quite empty space) compared to Strike Vector or something like that. It's a given for me that the AI should position-track its target but if the battle is well spread out, the likelihood of it running into a third party, let alone getting stuck with it, is probably small. But I do think you make a good point particularly because space games are generally funner when the environment has more influence on the fight, and for collision purposes capital ships are definitely the 'environment'. So good collision detection is definitely a pressing need.

The problem with raycasts is that as you say they are quite cheap, but in my experience they're also quite worthless - it's very hard to navigate an asteroid field with a single 'ping' raycast and the issue gets more complex the more detail there is in the surface of the objects around (particularly concave surfaces). It's like a robot with one of those sonar sensors, always getting stuck in corners etc. The question is how to build up relevant information over a period of time that will enable the AI to understand why doing something in the short term is a waste of time in the long term.

I do think that having the AI agent gather and correlate all it's information by itself is probably a waste of time - all you have to do is look at robots in real life trying to navigate anything of any complexity, sporting multiple dedicated computers and you can see that it's sort of beyond the scope of games to do things so realistically.

I haven't implemented it but I would like to try some sort of vector field navmesh system where, if the AI gets stuck, it simply strengthens the effect of the field on itself until it is basically clamped to the middle of the navigable space - I think this would be relatively straightforward compared to the AI trying to build up some huge map of an environment that has likely already changed.

Sounds good what you've done with the dogfighting stuff, did you try generating splines at all? I found them to be very useful in some simple experiments but that was about when I decided to create it as a separate project after this kit. I hear that they're hard to recover onto when the ship gets knocked off it, especially if the spline doubles over a lot, but I didn't get that far.

 

I used splines to design them but didn't actually use the spline data during processing, it was way too much overhead. I still kept the spline data since it was useful for designing and tweaking the sequences (via a simple editor extension. They were nothing but ordered lists of GameObjects for target waypoints and hints for position and orientation, so the maneuver data itself was very lightweight.

I had planned to convert them to ScriptableObjects, but they ended up not being very useful in practice. It looked cool but only if you watched it from afar, they were expensive to process, and it was surprisingly hard to align and scale a new instance of a maneuver sequence properly to employ them (though I was making good progress on that problem just before I gave up on them).

With all the hinting, the only time they went badly awry was (ironically) as a result of collision-avoidance. Mostly getting back into position was messy only if they were close to any complex sequences of hinting -- too far out of position or alignment for the sequence to help. I experimented with looking for further-away waypoints if the deviation was too great and that worked reasonably well. I also considered taking a stab at PID control but never got around to it.

Given the way real-world aerial combat maneuvers work, using them actually greatly increased the frequency of collisions.

Trying to process the splines real time is what led me to make the scheduler adjust by deltaTime.

 

Well with splines I think a PID controller is necessary otherwise it'd be impossible to get the ship to do what you want. It's quite easy in practice, proportional is what we do anyway and derivative is just a braking coefficient based on how fast the ship is approaching the correct orientation. I never added integral because I didn't really need it at the time, but again, it's just a wind-up coefficient that accumulates the corrective force until the ship is oriented. PIDs are really good for preventing the cockroach look (zig-zag) while staying responsive.

I think I had some algorithm for calculating the shortest distance to the spline, if you'd like to see it pm me and I'll see if I can dig it up.

 

Yeah I used PID for my flight controls, I meant I was considering a secondary stronger PID when it got too far off track.

 

Well for dogfighting it probably doesn't even make sense to recover a spline, maybe just translate and orient the spline regularly to the current position or something like that. I didn't look into any performance stuff but I'm a bit surprised to hear it was so heavy..

 

You're probably right about that, when you botch the maneuver, the maneuver is likely the wrong response going forward.

I don't remember the details but for all I know, I was probably recalculating the whole thing or something equally stupid. I'd only stored the control points so I was at least having to recalc the segment -- but realized I could get by only needing hinting + PIDs long before I had the spline-following completed so I didn't put a lot of effort into it. To get the turns right with spline-only I was having to do a lot of look-ahead that felt wrong. Plus I was very new to Unity at the time so it's possible (likely!) I was doing other things completely wrong at the time.

Dogfighting worked a lot better (for me) with a simple seek/evade type of system, and it turned out to be easy to tweak to create a wingman behavior that was often visually very interesting (by which I mean it felt realistic).

I posted this elsewhere, I can't remember if you were in the thread, so I'll drop it here, too. I found his "less is more" approach to space combat AI pretty interesting. My thinking evolved along similar lines but confirmation is always nice.

https://www.gamedev.net/topic/604440-space-combat-game-ai-problem/#entry4825820

 

Yeah I saw that quite some time ago, one of the very few bits of info floating around on the topic. I think it's useful in many ways, but it doesn't go any further than to assume that your target is pretty much the only thing you're dealing with. I think it can be taken a lot further.

For example, the OOAA method sounds good, but - Observe ... in there he's pretty much just focusing on the target itself. What about the environment, what about teammates, etc? How do you observe that in a useful way - let's say you're making AI for strike vector or something like that?

I do agree with the idea of the AI as a single entity being reactive. Overall it's useful to have a higher entity controlling the battle imo, but this higher entity should generally just set the AI's variables - such as their target, the combat area they should stick to, etc - the information passed should be totally digested from a tactical point of view.

EDIT: somehow I skipped over the part about capital ships, went back because I knew there was something else there! So yeah there's a little bit of info there on attacking capital ships, dividing space up into quadrants - I think for certain situations it can be a too simplistic approach but it very much depends on the situation.

 

That's exactly how I'm writing the tactical battle AIs for my turn-based game. The controller assigns everyone to groups with one of several basic tasks, and they do their own thing after that.

 

Spent the last couple of days chasing a bug in the custom inspector, finally licked it and I've pretty much made the changes I want to. However I still need to test everything properly, polish up the scripts and add a little bit more to the documentation as there's some more stuff you can do now. So probably couple of days or so it will be re-submitted.

Basically the biggest problem when I used it for my game was that it wasn't versatile enough for a variety of things like waypoints and mining locations, because a lot of functionality was tied together and wasn't compatible with one or the other uses. So I decided to:

• Separate out all the settings for each type of trackable object (e.g. ship, waypoint etc) - whereas before it was only a few style settings that were individualized;
• Communicate with the tracking widgets via interface so that you basically have a free reign over how it will appear and animate, with only the functionality dictated.
  
• Join the selected/unselected target tracking code which had too much in common.
• Fix up the custom inspectors.

Let you know when it's been sent off again.

 

The updated Vehicle Combat Radar package has been sent off for submission.

WEBGL Demo

In the demo there are less control options than before, but that's because all of the settings that were there have been separated for different trackable types. Also, with the widgets now being controlled through an interface, you have the ability to totally customize your own widgets and still be able to use them easily.

@ikemen_blueD @MV10 @Steve-Tack @danreid70 and others...

I've decided to get the ball rolling and offer a copy of the package for free to anyone who has participated in this thread so far - I imagine some of you are keen to have your hands on it by now! In return, I would appreciate detailed feedback on how the integration of the asset with your project went, the ease of use of documentation, and anything that you would like to see improved or added. Feel free to post the feedback here or send it to me via PM.

To get your copy, PM or reply to the thread. Looking forward to finally setting this package loose, and helping to get your projects further along!

 

@Billy4184 Wow, thanks. To be honest, I'm not sure I'm going to have radar in my current project, but it sounds like something cool to check out. Could be useful in a future project.

I have continued to lurk in this thread. Any time space combat AI topics come up, my ears perk up. It doesn't seem like there's all that much content around.

I've had some success just this week with using a PID controller for rotating NPC ships using torque instead of direct rotation (I haven't been cheated on linear motion; that seems easier). Doesn't look dramatically different, but it's a bit more natural looking. It mostly just feels better to use the physics engine properly. I'm also considering a PID controller for linear motion to be able to match a target's speed.

I also created a "canned moves" system with around 20 different moves that can be kicked off, like Immelmann, split S, strafing runs, corkscrews, weird moves involving lateral and vertical thrusters, etc. Have only tested a few, but so far it looks good. Those are mostly for visual variety, but a few of them are "active" moves and continue to track their target. Like the strafing run would be kicked off if/when the ship is close to its target and is closing in relatively fast. Then it'll kill its own linear drag and go into sort of a circle strafe move for a few seconds.

Got a ton of other AI stuff I want to look into, like coordinated attacks, formations, more robust target prioritization, and easier stuff like patrol routes. So I'm looking forward to further discussion on those topics and your AI assets for direct use or just inspiration.

 

I too have been closely watching this thread and look forward to seeing the radar project. I will also admit I just had to look up PID, so now.. I am of course extremely proficient

The demo runs smooth on my iMac - even at max targets

 

Haha, well I was super lazy and just plugged in a $1 asset for PID rotations:
https://www.assetstore.unity3d.com/en/#!/content/40096

Probably could have figured it out on my own, but it's kind of nice to start with working code.

There are some great threads on PID controllers right here on the Unity forums. When I first read about them, I had done a basic test with a 2D spaceship flying in a straight line. You set a target velocity and it uses forward and reverse thrust to hit it smoothly:
http://www.stevetack.com/unity/PIDController/Test1/index.html

I'm thinking I could use that approach in 3D for matching a target's velocity at least.

At some point I may go ahead and start a new general thread on space combat AI. Lots of stuff to talk about.

 

@Steve-Tack, if you'd like to take a copy of your project and see how it feels with radar added in, let me know!

The main thing I need to be certain about is how easy the code is to work with. It uses for example a couple of interfaces for which only dummy scripts have been created (such as weapons) as well as a few custom editors which resize lists of information based on enums in other scripts. I believe for someone who has a good understanding of the whole system, it will be extremely intuitive and well-organised but it'd be great to see how easy it is to approach, and whether the documentation I have is enough.

@GregMeach glad to hear the performance is great! Let me know if you want to grab a copy as well.

 

Yeah there's not a lot of stuff around. I believe this is because AI is one of those things where it's quite easy to get 50-75% of the way there and then it just exponentially gets harder! So a lot of people just stick with the usual hit-run-repeat since it looks quite OK - that's all I have in my mobile game so far.

In larger battles I think, it's quite easier to see the anatomy of higher-level AI and whether or not there's sufficient stuff there, since when a lot of ships are doing exactly the same sort of thing or are generally uncoordinated it starts to look a bit superficial and messy.

I think a more AI-oriented (and fun) scenario is where you have something like the space battle in Rogue One (great movie unlike the other recent SW movies, definitely should see it if you haven't already!) where there are specific objectives to attack/defend, ships with clearly separated capabilities and purposes, and some kind of ability to communicate to the player on an ongoing basis as to what to do. In that scenario you have the ability to set up high-level tactical moves and counter-moves whereas in the usual scrapper/brawl its probably wasted effort.

One on one space combat usually just ends up in a turning battle, and something like five on five is probably just going to be a brawl, but specifically when you have around two npc attackers or defenders, there's opportunity for some nice individual AI/teamwork that doesn't get lost in the mayhem. And I think a lot of feedback is key - for example you might have an 'intercepted' communication between enemies that are working together against the player.

So overall I think the main thing is to build a scene or context which calls for deeper AI before implementing it - and that's kind of what I'm going to do when I work on that area of my space kit again. Probably going to set up a coordinated attack on a space station or something which calls for different roles, and try at all costs to maintain the clarity of what's going on to the player - keeping squadrons of ships with different roles in tight formation, using clear approaches and retreats by these groups, adding some voice communication to further underline what's going on, etc.

I think there's some parallels with strategy games here, if you've played Homeworld you'll see that the different groups stay in formation and use clear approaches etc in the interests of keeping it clear to the player what's going on - and it's at that point where you can begin to think about introducing subtle and complex AI on the player because they will actually be able to identify it and respond.

 

While we're on the topic of AI/3D navigation, I dug up some old work on spline paths and made a video (sorry for low res and fps).

You can see how the spline is regenerated through the obstacles as more are added, and the ship (using PD controller) is re-acquiring the spline after returning to the start.

I'm going to try to work on it regularly (although probably slowly for now) as it seems to be a popular thing and is very fun to work on.

 

I would like to check it out. In the meantime is there any thought to factions?

I have some development plans around a capture the flag type (it's totally not anything to do with a flag but you get the idea) where a player or group of players work together to accomplish a task but at some point something will trigger all neutral ships to become hostile.

 

Sure!

 

I've seen Rogue One twice. Really enjoyed it, though it *does* have some legit issues. I super dug The Force Awakens too, but whatever.

Yes, I've started having those sort of thoughts. A more dynamic battlefield isn't just a "nice to have", it's actually critical for things to look reasonable at all.

Indeed. I started with a super basic AI that was functional enough to test gameplay systems and worked well for that. But now that I've got the RPG elements in, the UI done, most of the systems complete, the ships and structures set up, weapons functional, and the game world navigable, I'm ready to move on and actually try to build some fun combat.

I've started to build the final mission first. I figure that will put most of the gameplay systems to the test and be the ultimate test for the AI. If I can get that working well, I'll be in good shape to work backwards from there and remove elements until the first few tutorial-style missions have very little going on. I've got 12 missions designed and a story skeleton, but I want to keep the design pretty loose and do some "bottom up" design. If I need to tweak the fiction to fit, so be it.

I had the same sort of thoughts. Even a simple setup where there is a flight leader and one wingman could be interesting. Like they could stay in tight formation when away from any direct threats/targets, but split up when close. One could try to stay in front and do evasive moves while the other tries to move in behind for the kill. That sort of thing.

You can go a step further and do Wing Commander style taunts directly to the player. I have that for a handful of "named" ace pilots. I also have a few choice words from allies if they receive friendly fire from the player. I like the idea of listening in on enemy conversations too.

Sounds great. Having radio comms is pretty important. I remember in X-Wing, there were message from allies too, like when a transport docked with a disabled enemy ship, there'd be various messages about troops taking over while you had to continue to defend. Gave missions a nice flavor.

 

Wow, that is sick. Especially the last 10 seconds. Very cool.

 

There is an enum called Team, which at the moment has just Friendly and Enemy. Although the custom inspectors will automatically update for things like the widget color for each team when this enum is modified, some of the code especially is designed around a simple binary faction system.

Looking at the code I should have had (and already began unconsciously doing this with the target selection) two layers of distinction - Hostile/NonHostile, and the different Teams(or factions). That way the player could move in and out of alliance with different factions throughout the game and the radar would update automatically.

This is the kind of reason I needed to get the package out and about, since I often wonder whether something I'm adding is going to be essential to a lot of people or simply complicate the code.

PM'd you with a download link.

 

Yeah it's a little bit modern, but I think the fact that certain elements of it had already been determined in the old days prevented it from becoming too much of one of those silly modern movies like Avatar (the most beautiful content-free movie ever made!).

Sounds like a great idea! I'd also keep a test scene for really pushing the performance, you never know what you might be able to accomplish with some tweaks here and there.

Yeah, I definitely think that there's a lot of room for making fantastic battles with only a few ships, for example the player might get ambushed by one of the story antagonists with a wingman, and you could really stylize it to be more than people usually expect from space combat.

Definitely, it really pulls together the atmosphere of the game when you have radio communication, I quite liked the way Starlancer did it and it really fit the atmosphere of being part of an elite team. I also liked X2, especially the annoyed aliens who would sometimes not help you when you wanted to know how to get somewhere. Really adds that much-needed characterisation.

Glad you liked the nav splines. I hope in not too long it will be useable. If you have specific requests on functionality I'd be glad to hear them.

Sent you a download link via PM.

 

System Info: macOS 10.12.2 w/Unity 5.5f3
FEEDBACK:
* The package installed into one of my existing projects just fine with zero warnings / issues. Opened the demo scene and it too ran without issue.
* Code is easy to understand and seems well thought out - great job!
* Documentation is also easy to understand and very well done.
Overall great job - I will pick it up once it hits the store.
Thanks for letting me evaluate it.

-----
Now I will see how easy I can break it / hack it to best suit my needs

 

Thank you for testing! I'm very glad the code is agreeable to you, since I designed it to be a modular asset that will probably necessitate some understanding of the interface code and the 'paths' of data throughout the code, for example to hook it up to a weapons script.

Before you hack it, I'd very much like to know what else you might be looking for that isn't there - I may be able to either implement it myself or suggest the best way to add it.

Unfortunately I identified a couple of issues with the prefabs not having been updated correctly with the stuff I added recently, and I've had to cancel the current submission. I expect to resubmit tomorrow.

For anyone who desperately wants it now, I am happy to have some more testers! Of course the asset belongs to you and you can immediately begin adding it to your project, but I hope that if you find it useful you will buy it from the store when it arrives (also so that you stay up-to-date with new features and bugfixes).

 

Nothing specific yet but to get more familiar with the asset I'm dropping it into Sky Arena and seeing what changes I'd need to make. So far, very little (increased the scale exponent to 14 to make the legs more pronounced*) but as I've found with nearly all the assets I have from the store (450+) scaling is almost always an issue.

* No idea if that's the correct way.

 

I would be interested to test this if possible I plan to pick it up on the store once available , I have a target future pos prediction system for weapons , how easy would that be to implement?

 

Hi Mcg, thanks for stopping by! The radar package has lead target position calculation as well as missile locking, since these are essentially the function of the radar. However it does not contain an actual weapon script - you need to hook up your weapon script through an interface called IWeaponInfo which will pass relevant information such as the projectile speed and the missile locking time to the radar.

I'm getting the package ready for resubmission today (had to cancel the last one because of some bugs) and will PM your shortly with a download link.

From now on I'm probably going to be offering the test package to those who have been following this thread for some time and have put up with the delays in the kit, as I have enough feedback now to know where I need to go in terms of updates and overall improvements.

 

The correct way to increase overall scale is by increasing the zoom of the radar, which is exposed in a public method and is shown as a UI slider in the demo.

The scale exponent makes the radar display the position of the target according to an exponential power, meaning that the distance resolution of the radar is greater for nearer targets, and smaller for further targets. This enables the player to see more clearly on the radar what is going on close by, without restricting their ability to identify targets at further distances. If you've played Elite Dangerous they have this sort of display.

 

That sounds great thanks , just curious do you do any calculations based on rigid body velocities?

 

Yes, everything in the space combat kit that this radar package is part of is physics-based.

In the radar package, the ITrackable interface (which identifies an object as being trackable by radar) requires a rigidbody, and the demo script for making an object trackable will assign one if it is absent. It's necessary for the lead target calculation in particular.

 

i'm highly interested in the 3D radar package! When will it be availabe in the store? Is it usable for mobile (android), too?

I'm looking forward to it!!

Thanks a lot!

 

Hopefully I will resubmit the asset tonight. From the valuable feedback I got from those who tested the package, I found some things that needed to be fixed. Also I thought of a way to make the setup even easier than before.

It should be quite performant on mobile - I've spent a lot of time on performance optimisation though I haven't really tested on mobile yet. I have a really bad phone (literally the cheapest thing you can get with a touchscreen) and I will test the demo on there, and let you know how it goes.

Thanks for stopping by!

 

Hi everyone! I finished fixing and improving the package and just re-submitted to the store.

Thanks to everyone who tested the package and provided valuable feedback. I hope all of you who use the package will continue to help me improve it so that it's as useful as possible.

Aside from bugfixes, over the last couple of days I made some changes to make it even easier to set up radar in your project. It should be a question of dragging a couple of prefabs and scripts into the scene, and I have totally avoided the need to set any fields in the inspector.

So that you get a better idea of how the package works, here is the documentation I have provided - it's a little brief but I think it covers everything you need to know to get started:

UserGuide.pdf

This is the latest demo as it is in the package I just sent off.

WEBGL DEMO

I've yet to test on mobile as promised, but hopefully that will happen tonight and I will post the results when I have them.

Now for the rest! Since it coincides with my game, and seems to have spawned the most discussion on this thread, I will next focus on player controls as well as AI, obstacle avoidance and navigation.