playMaker

Author Topic: Disaster Tactics: Part 1 - 1GAM 12/14  (Read 3872 times)

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2484
  • Yup.
    • View Profile
    • Cleverous
Disaster Tactics: Part 1 - 1GAM 12/14
« on: December 05, 2014, 08:16:51 PM »
///////////////////////////////////////////////////////////////
Update: Submitted for #1GAM.

1GAM Build (weaksauce!)
Onegameamonth.com Page

It's really not where I wanted it to be, but I learned a lot and despite it being short on content, I'm pretty stoked about the systems I made in the background and how they perform.

///////////////////////////////////////////////////////////////
I'm generally working on Brevis: 3D action space shooter and first person puzzler VR title. This is pretty daunting, to be honest... the assets need to be high quality and there are a lot of complex integrations to make happen which sometimes can sap the fun out of development, even despite the most vigorous of focused dev bursts. I personally think I've accomplished a lot, but recently with switching to Unity 5 it's been really tough just to make basic progress and has been demotivating.

So, I decided a break is in order and I'm taking some time off of Brevis to work on a something much simpler and target a few weakpoints I feel that I have with Disaster Tactics. It's an experiment in the opposite, a couch co-op top down shooter similar to Risk Of Rain and other familiar titles in that gist. Target is PS4 if it actually proves to be a decent concept.

That's roughly the idea. At a high level, I need to move away from all this complex stuff overloading me and work on some fresh, easier stuff. The only reason I'm starting a thread for it is because in the first day making this I've covered some new topics like Controller support and want to go ahead and devblog the experience for everyone else, maybe it'll be useful.

TL;DR: This is my #1GAM.
« Last Edit: January 01, 2015, 02:57:32 PM by Lane »

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2484
  • Yup.
    • View Profile
    • Cleverous
Re: Experimental Break Project...
« Reply #1 on: December 05, 2014, 08:29:22 PM »
Progress on:
  • Navigation
  • Controller support

NavMesh setup..
It's easy enough to bake the NavMesh and use the Playmaker actions to tell an Agent to seek a target gameobject. Set your meshes to Static and bake, then add an Agent component to the enemies and find the player at runtime. Easy peasy, works fine for now but... Customization? Well, we'll see.

Controller Setup..
I opted to use InControl, it has great reviews and actions for it so why not. So far it seems fairly good. I'm exploring more to find its full capability mostly in terms of finding multiple players at runtime and configuring their Inputs properly, then how do I spawn player characters that respond to those specific inputs. Interesting, and seems quite plausible with InControl. So far, with one player I'm using a PS3 controller basically problem free.

Progress GIF

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2484
  • Yup.
    • View Profile
    • Cleverous
Re: Experimental Break Project...
« Reply #2 on: December 08, 2014, 11:11:37 AM »
Progress on...
  • Databses / Stats / GoogleFu
  • Templates
  • Leveling up, XP, etc..

Databases and Stats
Problems and challenges:
If players and enemies do not have any Stats (ie STR, AGI, DEX, END) then damage is a flat number per projectile and very simple to integrate. Projectile hits enemy, Health is subtracted... However when you want Stats then you have to build a Damage Calculator to compute the incoming stats and damage against the host entity's stats, then figure any specifial modifiers or debufs, then subtract the health. This is, needless to say, more complex.

Now when you think about scaling on this more complex system you start to see a LOT of variables on a LOT of different objects and it is NOT friendly to maintain... Enter databases! Currently I'm using GoogleFu which allows me to 1) maintain a spreadsheet on Google Drive, 2) pull from it all of the stats for every enemy, player, item, pickup, weapon and perk into the game in a very tidy fashion, 3) then at runtime attach those values to each 'thing' so everything basically has at a bare minimum a single call to the database to retrieve its personal information. This is condensed to one single playmaker action for each thing's stats. Maybe in the future I can do this in the editor and alleviate the runtime overhead for it.

I'll attach some screenshots of how this works later tonight.

Templates
The fun thing about templates is that they do the same thing for every object that they are on so when you think about some almighty generic Health template you have to plan that whatever happens it can handle it equally well for enemies, players and inanimate objects. This has actually led to be building some really cool generic processors that handle incoming information and work in almost any scenario you throw at them. When its finished it will include all of the damage, modifier and debuf handler states and work on any object with Health.

The other thing is that everything has to be cohesive to work with it, generalization and templating has a high demand for rules sometimes. For instance currently I have it so that I process the stats for the Player and his projectile into a total damage, pass that into the projectile, then when it hits something it passes that to the Health system of what it hit, where then the Defense stats are computed against the incoming damage and other modifiers.

And you thought this would be easy! ; )

Leveling up and Scaling
This is a huge topic. The ratio at which stats and general values grow as the game progresses is critical to the fun/difficulty/addictiveness of the game. For instance if you scale the character with the enemies at the same rate, but then later increase the spawn counts and introduce special modifier items to alter stats, are they offsetting enough to maintain sufficient difficulty?

There are piles of articles talking about it, and since I'm just getting started on it I'll leave the topic at that for now, but it's going to really expand soon once I learn and test this more.

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2484
  • Yup.
    • View Profile
    • Cleverous
Re: Experimental Break Project...
« Reply #3 on: December 10, 2014, 04:00:38 PM »


Currently the templates in use are..

  • Health
  • Stats_Players
  • Stats_Enemies
  • PlayerWeapon
  • Controls



Health template works for any enemy. I just need to apply Stats_Enemies and Health to the prefab for the enemy to be able to work in the scene. It will startup, pull the database information and start playing. I haven't made an AI, Navigation or Locomotion template yet but I think I'll end up making unique AI's for each enemy type so that doesn't fit into the template discussion and Locomotion is going to vary quite a bit. I might be able to templtae the Navmeshing, but I'm not that far along yet, and only have 3 weeks til the end of the month.


Stats_Enemies/Players are different because I didn't want to have a flood of variables in the same FSM all with various names. The enemy database has base stats and relevant information for enemies, and likewise the Player database has similar information but different other stats. Level up works, but I need to polish it where it has a isDirty flag that tells the other FSMs to update their stats. Technically, I could make enemies level up too but that is silly, since they don't gather XP.


PlayerWeapon will figure out what character you're using and assign the proper weapon types, projectiles and sounds. There are only a few states and it should work for almost every weapon. It works fine with the first weapon, loading the stats and everything with zero input from me other than it reading the name of the character it is assigned to. You can do a lot with string compares in this regard, just try to link everything up with variables so you don't screw things up. I currently only have one possible link that breaks everything and that is a discrepancy between the database name and the prefab name. Otherwise, it just works.



Conclusion of the day..
What I have in the gif isn't really the cool part, whats cool is that everything is very organic. At this point I can add enemies to the database and just make a basic prefab for them with a couple of templates and they'll gather all of the needed data when they spawn and go to work! If I were on a team of developers, this would greatly segregate the workload so that different people could design in chunks and it would come together very easily.
« Last Edit: December 10, 2014, 04:04:13 PM by Lane »

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2484
  • Yup.
    • View Profile
    • Cleverous
Re: Experimental Break Project...
« Reply #4 on: December 12, 2014, 09:58:15 PM »
Now with....

Multiple Players On Multiple Devices With Multiple Coolness!
Camera Frustum Player Containment!
Dynamic Camera Target By Players Position Averaging!
UI Main Menu With Controller Support!


Whoa! Buzzwords! Long sentences to describe features! Pip-boy 3000! Science!.... Lets look at the lineup for today.

Multiple players

This is actually one of the more difficult things to nail down and polish.. There are a pile of reasons for it.. One being that devices are notoriously hard to identify on windows and using the basic list of devices as the player list is dangerous because it could be recompiled if you disconnect a device, which means the players could swap characters O_O ...

Anyway, this took the most time on this update, I'm still looking into ways to do this reliably and cover my butt on all the gotchas that might happen but overall with InControl it was fairly easy to just throw the player id on the controls and make it multiplayer.





Camera Frustum Player Containment GIF
Make some boxes, put them on a "frustum" layer or something, move them to the extents of your camera, define on the collision matrix that they can only collide with the Player layer.

Tada! Player Containment!

Problems could be if the aspect ratio isn't static. I'm using 16x9 for example but if it was played on a device that was not 16x9 then the players wouldn't stop at what appears to be the edge of the screen. We'll need to do something fancy to find the frustum intersections with the floor layer and build walls from there straight up. Using the actual frustum matrix doesn't really work because of the steep angle (on perspective cameras, ortho would be fine) so you have to do some extra work to ensure the colliders will be vertical and the players won't be crushed as they're pushed back... Weird things could happen m'kay....




Dynamic camera target by player position averaging GIF

Fancy sentance translation:
Get all of the player positions added together and divide the result by the number of players...

Eh, yeah, there ya go. Thats the spot where the camera should look.



UI with controller support GIF

Not that hard really, took a while to find the stupid #if !Unity 4.6 line of code added to the InControl script that helped with this feature, but eventually after a while I managed to start wondering if being on 5.0 was a thing.. Then I found the script and purged the second most annoying line of code I've seen this month.

Anyway its pretty gravy on that too, InControl takes care of most of the lifting here but I'm still looking into making unique navigation per player rather than just a single player navigating the menu. I mean.. What about character selection? Player1 can't choose the cool dude and give his buddies the crummy ones. That wouldn't be cool. It needs to be a race to the most badassest of characters in the UI.

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2484
  • Yup.
    • View Profile
    • Cleverous
Re: Experimental Break Project...
« Reply #5 on: December 19, 2014, 08:46:22 PM »
Stable Build!

Link to Build002

Requirements:
Controller Device with working drivers (Xbox360, XBO, PS3, PS4, etc...)

Controls:
Standard Dual Thumbsticks
Right Trigger to fire
Triangle to pause (broken by timescale with new UI)

Known issues:
  • Only Tom and Maverick are selectable. All others fallback to Tom.
  • Maverick's rifle sometimes does not fire.
  • Explosion AoE damage does not work.
  • You are invincible.
  • Tom doesn't do enough damage.
  • Maverick does too much damage.
  • Pause menu doesn't work
  • Max 2 players
« Last Edit: December 19, 2014, 08:49:23 PM by Lane »

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2484
  • Yup.
    • View Profile
    • Cleverous
Re: Experimental Break Project...
« Reply #6 on: December 20, 2014, 03:59:57 PM »

Updates:
  • Character Profile HUD with Stats. (some bugs, but figures out who how many people are playing, who they are, then displays their active stats like STR/AGI/Level, Avatar, etc..
  • Healthbars on enemies.
  • AoE Damage. This is actually an new FSM template which collects the units in an array and nests another FSM to apply the damage for each enemy in range..
  • Death FSM Template to handle dying, modularized away from the Health Template. Figures out what its attached to, dies appropriately when necessary.
  • Bugfixes for the Sniper Rifle (its bug free now!).
  • Better FX for the Sniper Rifle
  • Laser Sight FSM Template (comes default with Maverick, can add as perk with other characters)
« Last Edit: December 20, 2014, 04:02:40 PM by Lane »

Fahrettin

  • Junior Playmaker
  • **
  • Posts: 62
  • Noob
    • View Profile
Re: Experimental Break Project...
« Reply #7 on: December 21, 2014, 02:51:39 AM »
I remembered Phobia3. It was perfect game. Your game will be perfect too

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2484
  • Yup.
    • View Profile
    • Cleverous
Re: Experimental Break Project...
« Reply #8 on: December 25, 2014, 02:15:22 PM »
« Last Edit: December 25, 2014, 02:33:45 PM by Lane »

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2484
  • Yup.
    • View Profile
    • Cleverous
Re: Experimental Break Project...
« Reply #9 on: December 25, 2014, 10:34:37 PM »
I wrote a blog post on the topic of #1GAM and how it has benefited me so far.

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2484
  • Yup.
    • View Profile
    • Cleverous
Re: Disaster Tactics: Part 1 - 1GAM 12/14
« Reply #10 on: January 01, 2015, 02:50:06 PM »
1GAM Build

It's still pretty broken and doesn't have much content but I learned a lot when making all of the systems. Really feel like this was worth it, despite the lack of content and weak final product.

I'm considering scaling it up and making something more polished for next the Jan #1GAM.

justifun

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 227
    • View Profile
Re: Disaster Tactics: Part 1 - 1GAM 12/14
« Reply #11 on: February 06, 2015, 07:34:38 PM »
Did you ever come up with a solution to handling multiple simultaneous players with incontrol?  Any fancy template you could share?


Graham

  • Sr. Member
  • ****
  • Posts: 282
  • I Love Playmaker!
    • View Profile
    • Portfolio
Re: Disaster Tactics: Part 1 - 1GAM 12/14
« Reply #12 on: February 14, 2015, 07:31:16 AM »
Thanks for sharing this info with us Lane. Some pretty neat systems at work here.

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2484
  • Yup.
    • View Profile
    • Cleverous
Re: Disaster Tactics: Part 1 - 1GAM 12/14
« Reply #13 on: February 14, 2015, 08:00:13 AM »
Did you ever come up with a solution to handling multiple simultaneous players with incontrol?  Any fancy template you could share?

Not really a good solution, theres a lot of discussion about how it can be done correctly and its often just tricks. Using the list of devices is not good enough but you can design your menus in a crafty way that doesnt make it so obvious what you're doing. For instance choosing characters by device number one at a time to identify what device wants which character or something to that effect but its still not perfectly ideal.

Rewired actually handles this extremely well, but has a much more complex interface and probably more groundwork to do before you get something rolling whereas InControl is basically plug-n-play in about 10 minutes.

Thanks for sharing this info with us Lane. Some pretty neat systems at work here.

Thanks :) I think there are some big advantages to using systems like this and I'd really like to take the project a little further and explore them more. Seems like I went through the trouble of doing the whole back end but didn't actually fill it with content so its a little difficult to recognize the value in the design foundation. I'd love to do more tutorials and explanations along the lines of designing like this, it makes scaling things up so easy.