Deftly - Flexible Top Down Shooter System

is there any plan to support fantasy action style.??. sword and magic..

 

Melee is already working, spells would be under the generic ability system which is on the roadmap but I haven't started building it yet.

 

i tried to use it with my third person shooter system but i couldn t be able to make the spawn triggers work any idea what i should consider i even used the same prefabs but didn t work out

 

Variable Damage Types

Now up to 10 Damage Types can be labeled in the Options window and later assigned to Projectiles. Subjects have a slider for each damage type to define how resistant it is to that damage type. When a projectile hits a Subject and it processes the damage it match its multiplier value for that damage type and adjust the damage accordingly.

There is a maximum of 10 types of damage for now. In my general researching I found that very few devs wanted more than just a small number of these damage types or elemental types unless they were doing an extremely complex and confusing system for elemental damage which is not something Deftly is slated to offer. So let me know if a max of 10 is suiting your needs and why it might need changing. IMO this is enough to support complex game mechanics, but few enough to stay simple in design.


Options Window (define the types)





Projectile setup






Subject setup (multiplier response to Types)



Show above could be some ice enemy which takes no cold damage but takes 3x damage versus Heat. The sliders are capped between 0 and 3, but this could be modified based on your input. For instance negative values would actually heal the Subject when receiving damage of that type which is pretty interesting.

 

Nicely done! This weekend I was going to record and post some multiplayer footage with the new frustum constraints, but I'll wait until I've removed my hacked-in damage type code and set this up instead.

 

Sweet, I'll try to get a package with the latest to the internal group tonight along with release notes.

 

Damage Types appear to work as advertised! What do you think of omitting the Hit Reaction sound if the Subject takes no damage?

I forgot to mention this about frustum constraints: If one player pushes against the top or left edge of the constraint, he can nudge the camera in that direction, dragging the other players with him.

 

Thanks for the feedback!

Yeah I can make an on/off toggle for playing the hit reaction sound if the damage is zero. I'll look into improved control for the frustum constraints, is it a fairly big issue or more of a nuisance?

 

It's hardly even a nuisance; just something I noticed.

 

Is it possible to have the character torso moving in an indipendent way from legs with your system?

For example:
I want your character to move the torso on an angle from +60 to -60 degrees while moving forward, after these angles I want it to turn around with legs too and keep moving in this new way.

Is this doable at the moment in an easy way? Can it be interesting to have this included in the package?

 

Not right now. The Animator will need the angle value and that isn't provided by the controller script yet.

 

0.7.1 is live on the Asset Store

You can check out the release notes here.

Cliffnotes:

• Intellect wandering and patrolling
• New options back end (scrapped xml, using SerializeableObject now)
• Damage Types
• Non-Humanoid rig support
• Camera Frustum Constraint system

 

Raycast and Raycast Piercing style weapons

Ready for pew-pew.




Since ray effects need to be integrated with some kind of effect system or kit, I've gone ahead and supported basic line renderers for now if you want to roll your own and I'm working on sending messages with relevant data to scripts so you can generically target a script to use the firing information and create its effect.

UV animation is built-in for the Line Renderer and pretty flexible since its using Animation Curves.

For now, this was made with a few dialed in changes to the inspector and a noise image I made in 10 seconds.

 

I'll confusingly cross-quote you from another thread, since the OP there didn't seem to appreciate me derailing his thread:

That's a shame . I've been on and off contemplating making a topdown mech shooter myself. Stumbling over your thread here it seems like you are implementing quite a lot of functionality that would be useful for a game like that. I'll keep an eye on it and will focus on making other things for now. If I can get enough assets done and can get procedural level generation going, Deftly might be able to fill in enough of the gaps to actually make it a game some day.
I want to have a more complex aiming mechanic, where you mark the exact point you want to aim at (probably raycast on the floor plane, ignoring other colliders) and the mech tries to aim at that point with different restricting factors on firing arcs for different weapon mounts and turn speed for torso and arms. I'm pretty sure I can get that going with FinalIK. I'm less sure if I'll manage to do the procedural walking properly with a 2-legged mech. Did you experiment with 2-leg setups or did you go for 4-legged straight away?
What I don't like about typical topdown shooters is that they feel so highly abstracted and simplified. I hope that things like the accurate placement of legs on the environment (like you showed in your mech video), more complex aiming mechanics, and lots of physics interaction with the environment, could help make it feel more immersive.

 

Any chance of getting a preview copy in the beta group? I'm going to have a chance to work on my Deftly-based project a little tomorrow.

 

Sure I'll push something up tonight.

 

How easy would it be to add an inventory system to this? is there any asset that works? im wanting to make a game like frozen state http://store.steampowered.com/app/270270/

 

There hasn't been any official support for an inventory or crafting system so you'll have to dive in and integrate your own into Deftly. That should be pretty straightforward but depends on how friendly the inventory asset was designed to be.

 

Inventory Pro is a good choice. As with any inventory system, you'll have to do a little coding to integrate it, but it's designed well to plug in your own code without having to directly modify any Inventory Pro code. For example, you can add an ISelectableObjectInfo script an item object and have it do something in Deftly such as adjusting Deftly stats or switching weapons. And it also integrates nicely with the Dialogue System if your game needs conversations, barks, or quests.

 

Root Motion first pass

Root Motion movement is working, although there are some caveats with it at the moment. There is a really complex way to implement it by overriding Mecanim or a simpler way of letting Mecanim have all the control. We're doing the latter for now.

• Rotation is still handled the same as before, for now.
• Rigidbody settings seem to play a big part in how Root Motion effects the character. eg rb's with high mass/drag are extremely slow or do not move.
• You need a fantastic set of Root Motion animations and a well designed Animator for it to look good and feel right. Neither will be included so you'll have to set this up on your own. I'll probably make some videos about it later but I really recommend you be familiar with rolling your own Animators and using Root Motion or you'll probably end up frustrated. I tested it with Pistol Animset Pro and was it worked as expected.

 

Would you consider releasing your animator controller for Pistol Animset Pro? It would be a huge timesaver and a strong draw for people like me who will also be using Pistol Animset Pro.

 

Yeah I can put up a separate download link for it while Root Motion support is in this state. The reason I don't want to include it right now is because there's still things I need to do to PlayerController to support something like Pistol Animset Pro properly since its such a full feature asset. I don't want to say it is totally integrated unless I'm actually using it to the full, but I'm fine with sharing the controller separately until we get to that point. I'll keep you posted.

 

Procedural Recoil

It's here! Uses a Vector3 and an Animation Curve for some inputs and a speed curve. Was easier than I expected to get in. =)

 

Finally! Thanks for that. I'm also using Pistol/Rifle animset pro and would be happy to have some integration package included.

 

@LaneFox With this asset would i be able to create a standard rpg not top down
Will just changing the camera view work

 

I wouldn't recommend that, the camera, controls and weapon system is designed around being top down. Unless you're comfortable editing the code it would probably be more trouble than it's worth.

 

I have my own models, animations and projectiles like arrows. Just wanted to check its easy to integrate them to create a midevial style survival game

 

Reskinning the demo characters and weapons is pretty easy. If it's a top down RPG you should be able to integrate an Inventory system and necessary elements to make it an RPG. A basic scaling stat and level system is in place but it doesn't fully affect character behavior yet.

Just keep in mind that it isn't and rpg kit so you'll have to do leg work to the core of the kit to get what you want as an rpg.

 

@LaneFox i just want to create an endless survival game with countdown timer, continuously spawning enemies, powerups. I would like to save game at several points during the count down timer so user doesnt have to start all over again.

I dont need quests. Would that be possible.

 

Yeah thats pretty easy actaully, there is a built in spawning system but you'll need to add a save system. The demo scene shows how the spawners can be done.

 

@LaneFox will probably buy this asset next month.
how can i add save system. Sorry but i am doing this game out of passion. Zero coding knowledge
Can you please guid me on tgis.

 

Accuracy is no longer a flat number! You have the option to curve it over time if you wish. A default curve will be replacing whatever value was there so you can adjust it as needed. If you want legacy, just make a flat line at the value you want and it will behave the same.

This only truly applies to Full Auto weapons because it uses the amount of time you've held down the fire button.

 

Local Co-op and Misc

I started an experimental project (basically a 1GAM type thing) to go from start to finish using Deftly so I could find all of the gaps in the framework.

So far I found a bunch of things that needed to be adjusted and have made a lot of small changes all over the place. I also made some new scripts for local co-op support that I'm working on polishing into the framework more cohesively. At this point it requires InControl and assumes you're all using controllers. It works from start to finish, though. Hot-joins work, menus work, character selection works, scoreboard works.

Here's a quick video I took by myself to show where local co-op is at. I'll try to make a better one with a friend soon.

 

Cool Co-op stuff.

Is that something to be in next release ? What kind of ETA you're at now ??

 

Its stable but I'm working on integrating it a bit better so it's easier to setup. I'd like to submit something next week but 2+ weeks is probably more realistic.

The biggest hang up is the unity input event system doesn't really work for multiple controllers in the ui so any character selection or ui setup is rather complex. The solution above is kinda hacky, so I'm looking at a smarter grid system that is more practical for other applications. Other than that, its it's pretty solid.

 

Your InControl support works great for my 4-player multiplayer prototype. I haven't had time to touch the project since January, but this is the prototype that I playtested back then. (We just played a few stand-in levels to test gameplay and concept. The video below isn't a polished level.) The testers felt like the input system worked pretty well:

It uses two components: PlayerManager and CharacterManager. CharacterManager is just a roster of prefab characters and their stats (which are saved in PlayerPrefs):



PlayerManager associates an input device (-1 for key/mouse, 0+ for InControl device numbers) with a character in CharacterManager. As players join (by pressing an input on a device), it uses an available slot in the Players list and assigns the corresponding device number. This lets players join with any device, rather than requiring that player 1 use joystick 1, player 2 use joystick 2, etc. In the Join scene, they can scroll through the characters to choose the one they want to play. The character also gets assigned to the player's slot in PlayerManager:



Other notes: When a PC dies, a pod drops down to deliver a new clone (i.e., respawn). If all PCs die at the same time, the level ends.

 

Nice! So yeah I've basically added a some optional scripts and demos that do that for you so you don't have to. It's all still kind of 'first pass' and I'm still using the device id for players. I need to do a slick player manager going like you've got there.

Most of my grief was making UI's that could be navigated by multiple players. What I was saying above was improving character selection to be a generic grid navigator. At the moment I'm using the inputs to change an int and move the UI object position to make it look like you're moving a selector around. I don't really like the workflow as it is and want it to have more "drag your grid elements here, and the other thing there, then it works" stuff. So I'll be polishing that up til it's as easy as I can figure it to be. That way, at the very least someone has a working demo for controllers with a common grid character selector that will work out of the box and have reuse value.

 

Sounds good! Also count me in with all the people who'd like access to your Pistol Animset Pro animator controller. That's actually the biggest feature I'm looking forward to, since it would be a huge timesaver over putting together my own animator controller and tweaking it to look right with Deftly.

 

Just picked Deftly up and I am really impressed with the depth of this asset and I look forward to seeing more updates coming. Now to go learn about a million things.

 

any updates on this?

 

Running behind! Co-op demo is stable but I need to clean up the inspectors on the scripts, update documentation, package the Pistol Animset animator setup example separately, and package the whole thing for an update on the store.

 

I'm going to upload the current version to the beta group in a few hours, almost done cleaning up the co-op demo.

Found the source of a bug I've been trying to track down - the floating away bullets. The way I use IgnoreCollision() to work with the Layer Mask on Projectiles is after-the-fact of the physics engine computing the collision between the objects so they would still hit, respond, then run the OnCollisionEnter() code and basically just float away. Its amazing that upwards of 95% of projectiles worked as well as they did (actually, kind of scary that the Physics engine leaked that much)

Anyway, the Standard Type Projectiles technically never float away anymore but Unity will still process the first collision between every object before they're identified as something that should be ignored. The projectiles will act correctly, but anything they hit will receive the force input. Making projectiles very low mass will hackishly resolve the problem for the time being. Also make sure your Projectiles and Characters only have one collider, and ideally your equippable weapons have none, all of that together will really make things smoother.

 

You've added some really nice updates in this beta version! Are you still planning to package the Pistol Animset animator controller in the final version? It'll be a huge timesaver for those of us who want to use the Pistol Animset.

 

Yes, I'll include it when I upload to the store. Did you check the animator controller out yet?

 

Not yet. I'll try to carve out a little time this week to give a quick test of the beta.

 

Cool beans, let me know if anything explodes =)

 

I've had a go installing the beta briefly and it threw an error at the lack of InControl straight away. Figured id leave it for a bit

 

Thanks, can you post the error? I dug around and found that I forgot the comment out `using InControl;` in the stock PlayerController.cs. Maybe that is the only problem.​

 

What would you think of using conditional compilation (e.g., #if USE_INCONTROL) in the same PlayerController.cs file instead of maintaining two parallel files for UnityInput and InControl? I'm sure that, more often than not, I'll forget to reimport the InControl support package when I update Deftly.

 

Yeah I'm looking into other ways to do that - such as a define macro and/or an extension class with overrides - since exporting a bunch of packages with different files is less than ideal and something gets left behind more often than not.