With the upcoming release of Unity 4.3 and their new 2D pipeline, I figure it's finally time for me to settle in and learn me some Unity for a greater good.
I have an extensive programming background and I understand the basics pretty well (component-based design, fuckyeah), but there's really no good guides that I can find on how to properly architect a Unity game. Like where do you shove your main game loop, keep track of game state, transition between menus and game and such? In components? That's so weird, but that's what I keep seeing in all the tutorials.
I get the feeling that Unity suffers from PHP disease: It's so easy to work with that the quality of the popular tutorials ends up being low because they are written by people without sufficient experience.
Yeah, I'm thinking the same thing, perfect time to get into Unity. I can't find any good tutorials though.
You search for them and you get random threads from 2011 that direct you to "awesome" tutorials made for Unity 2.6. There are a bunch of them for various versions of Unity 3. But at the same time I'm not sure I trust most newer tutorials I can find, a lot of them seem very amateur. Hard to know who is giving authoritatively good advice and who is just throwing together something in a hack job to make it work.
I'm midway through the "stealth" tutorial from the unity site, that might be a good place to start. Problem is it frequently just has you do things without explaining what you're doing, but it'll certainly teach you some of the basics. I got bored at the end of chapter 3 and have been just dicking around with whatever takes my fancy since then.
I've put my project on hold until the new version comes out; I don't want to spend time implementing functionality that will be obsoleted, or worse, incompatible, with the new stuff. Luckily most of the work has gone into getting the character "physics" working correctly, which shouldn't really be affected unless they actually end up putting in a 2d character controller.
With the upcoming release of Unity 4.3 and their new 2D pipeline, I figure it's finally time for me to settle in and learn me some Unity for a greater good.
I have an extensive programming background and I understand the basics pretty well (component-based design, fuckyeah), but there's really no good guides that I can find on how to properly architect a Unity game. Like where do you shove your main game loop, keep track of game state, transition between menus and game and such? In components? That's so weird, but that's what I keep seeing in all the tutorials.
I get the feeling that Unity suffers from PHP disease: It's so easy to work with that the quality of the popular tutorials ends up being low because they are written by people without sufficient experience.
Yeah, I'm thinking the same thing, perfect time to get into Unity. I can't find any good tutorials though.
You search for them and you get random threads from 2011 that direct you to "awesome" tutorials made for Unity 2.6. There are a bunch of them for various versions of Unity 3. But at the same time I'm not sure I trust most newer tutorials I can find, a lot of them seem very amateur. Hard to know who is giving authoritatively good advice and who is just throwing together something in a hack job to make it work.
I'm midway through the "stealth" tutorial from the unity site, that might be a good place to start. Problem is it frequently just has you do things without explaining what you're doing, but it'll certainly teach you some of the basics. I got bored at the end of chapter 3 and have been just dicking around with whatever takes my fancy since then.
Right after I posted I went looking again and found that, it does look very nice.
EDIT: According to comments though, it looks like it requires Unity Pro...?
Exactly how safe are random objects in the Asset Store?
I'd kind of like to download some freebies, but I don't really want to destroy my PC doing so...
I've never heard of an unsafe asset store object. If you have a link to any story about how something was exploited please share. My GoogleFu didn't come up with anything except for an ssl exploit for android and I don't believe is unity related.
Most things on the store look like they aren't exploitable in that way. You can see all files that the package contains and they're textures and models etc., not executables.
My current project will rely heavily on the 2D stuff, but since I Don't Know Jack about Unity, I'm just messing around with the current version, doing arbitrary 3D stuff to get comfortable in the editor. That, and writing a lot of text. And physical prototypes.
Using Unity. A bit of a long rambly post, sorry about that.
I've gone through a bunch of tutorials online but they always seem to fall just a little bit short in terms of mildly complicated design. Which is fine for tutorials I guess. They will generally show how to do some very specific interaction, but not always in a reusable, modular way.
Perhaps my recent reading of the Pragmatic Programmer has caused more confusion in my head when dealing with Unity than is necessary. I'm really trying to think about reusable design for my components. So I've come up with a fairly (I think) simple interaction that I'm having trouble designing in a way that feels right.
I want an entity with an Attack component that can deal damage to entity with Health and/or Shield. The Attack deals damage to the Health as you would imagine in a straight forward way. It also deals damage to Shield in a basic way except when the Attack has a ShieldPiercing property. Any damage the Shield takes should reduce the damage to the Health.
Something like this description:
Attack
- damage number
- pierce shield bool
- sends messages something like "OnAttack" to a Target
- message has as parameter the Attack object, or possibly some more basic parameters
Health
- max hitpoints number
- current hitpoints number
- listen for "OnAttack" message, reduce hitpoints
- if hitpoints fall to 0, send "OnKilled" message back to the attacker
Shield
- max shield number
- current shield number
- listen for "OnAttack" message
- if attack is shield piercing damage the Health rather than the shield
- otherwise damage the shield but any overflow damage is dealt to the hitpoints
- eg. 1 shield left, 2 damage done. Shield reduced to 0, hitpoints takes 1 damage
- if shield falls to 0, send "OnShieldDestroyed" message back to the attacker
Ideally an entity could be given a Health component and not Shield compnent and vice versa. Perhaps the idea of giving an entity a Shield without giving it Health is weird, but I think it would be ideal if I could design the components in such a way.
Now I can do all this but what I'm really looking for is a good way. The way I listed this in the description of messages above it won't actually work nicely. I need some way to have the damage funneled through the Shield component if it's there, I can't just listen to the "OnAttack" message in both the Health and Shield. Everything just seems so tied together however I try and design it. Ideally I'd like to change the Shield for example with as few cascading changes to other components as possible. Or add some new thing, a component that sits on top of Shield, "Armor", that works like the Shield does. Giving the interaction Armor->Shield->Hitpoints for soaking up damage.
I've thought of perhaps making some kind of DamageController, or AttackedController, that might take the "OnAttack" message from the Attack (rather than the Health or Shield directly). And that would then decide the ordering of what gets damaged. Perhaps that's OK, but something about it feels weird. It would mean anytime I add in a Health it would have a requirement of that component to also have a DamageController.
How I would design it ... Attacker would trigger an event on the target passing in needed variables such as attack type and basic attack strength (base damage) and maybe a chance to hit. I would leave it up to the target to calculate how that damage is absorbed. This way you can do things like damage multipliers based on the target's properties without the attacker object needing to know anything about the target other than it is attacking it.
Going to a UnityDev meetup in Toronto tomorrow night. A friend of mine works at the company hosting the first night, so it's kind of fortuitous.
Hopefully I'll get some time tonight to actually sit down and fart around with it for real, so I'm not as terribly confused tomorrow as I otherwise may be.
How I would design it ... Attacker would trigger an event on the target passing in needed variables such as attack type and basic attack strength (base damage) and maybe a chance to hit. I would leave it up to the target to calculate how that damage is absorbed. This way you can do things like damage multipliers based on the target's properties without the attacker object needing to know anything about the target other than it is attacking it.
I think I've got that basically covered with how I listed above. The part about the target calculating the damage is where I'm unsure about what a nice reliable, reusable design would come in for Unity. Ideally a Health component and a Shield component could be put onto different entities, but not all entities would necessarily need both to function. This would let me create units that have hitpoints but no shield, shield but no hitpoints (maybe an energy field or something). I can do that, but I'm interested in the design aspect because I want to create the pieces in such a way that say adding a third component "Armor", would act similarly to hitpoints and shield but wouldn't require a ton of refactoring if I were to ever add such a thing.
How I would design it ... Attacker would trigger an event on the target passing in needed variables such as attack type and basic attack strength (base damage) and maybe a chance to hit. I would leave it up to the target to calculate how that damage is absorbed. This way you can do things like damage multipliers based on the target's properties without the attacker object needing to know anything about the target other than it is attacking it.
I think I've got that basically covered with how I listed above. The part about the target calculating the damage is where I'm unsure about what a nice reliable, reusable design would come in for Unity. Ideally a Health component and a Shield component could be put onto different entities, but not all entities would necessarily need both to function. This would let me create units that have hitpoints but no shield, shield but no hitpoints (maybe an energy field or something). I can do that, but I'm interested in the design aspect because I want to create the pieces in such a way that say adding a third component "Armor", would act similarly to hitpoints and shield but wouldn't require a ton of refactoring if I were to ever add such a thing.
Seems like you're overthinking this. In my project I have CombatUnit components that store their weapon information and health information as fields. CombatUnit objects have a TakeDamage(amount, type) method that handles all the logic of modifying and assigning the damage. Any changes I make to the health and damage system of the game only requires that I look at that one method. Adding shields, armor, temporary buffs, what have you. I'm actually intending to upgrade the method to TakeDamage(amount, type, location) at some point further down the line but I know it'll be simple so it's not a problem.
If you want to have units that have health but no shield, or shields but no armor, etc. then you can just set their remaining shield or armor fields to zero.
JesDer, I'd recommend against an approach like that. You should split tasks into as few functions as necessary. In your code each OnAttack will only make a single call to NormalHit, ShieldPierceHit, DamageHP, and/or DamageShield, which indicates that it should just all be rolled into one function. You are obfuscating the behavior of the code by putting unnecessary doorways in the process that make it much clunkier to understand at a glance.
I suppose you could make a proxy component that accepts OnAttack() messages and then forwards the damage to other sub-objects in the right order, but I would only do that if you're really invested in working out a good modular system using Unity Components and messages. If you just want to prototype some simple gameplay then IMHO you should start with a simple implementation. Just write a single component with health/shield that implements OnAttack(). Since the interface is fairly well-defined in this case, you can always replace it later with a more comprehensive solution. You may find that you don't need anything more complicated after trying out some gameplay.
JesDer, I'd recommend against an approach like that. You should split tasks into as few functions as necessary. In your code each OnAttack will only make a single call to NormalHit, ShieldPierceHit, DamageHP, and/or DamageShield, which indicates that it should just all be rolled into one function. You are obfuscating the behavior of the code by putting unnecessary doorways in the process that make it much clunkier to understand at a glance.
For this case i totally agree with that. However I was thinking of a much more complex system where the original case statement would be much larger. I don't like putting much code in case statements since, for me at least, it tends to get messy. The reason I break out the Damage functions from these is to make it more maintainable. If I had 20 Attack types and decided to change how Damage drains shields, I would only need to edit the one DamageShield function.
I suppose you could make a proxy component that accepts OnAttack() messages and then forwards the damage to other sub-objects in the right order, but I would only do that if you're really invested in working out a good modular system using Unity Components and messages. If you just want to prototype some simple gameplay then IMHO you should start with a simple implementation. Just write a single component with health/shield that implements OnAttack(). Since the interface is fairly well-defined in this case, you can always replace it later with a more comprehensive solution. You may find that you don't need anything more complicated after trying out some gameplay.
You may be right about over designing at this point. I am familiar to a point with Unity and have used it to do some stuff already so I've done some simple implementations of things. Just trying to think a little about what some good and usable design patterns could be applied for situations like this.
Ah, I see what you mean. Yeah, you don't want giant case statements, especially if that would mean redundant code. I still think it'd be better to have a linear process so it's easier to understand what exactly happens to Input X to generate Result Y.
I think a decent way to get that for this issue would be to split the baseDamage value into local variables that are modified by the switch statement, followed by linear damage processing code. That way your actual damage assignment code is still grouped in the one function without requiring duplication for multiple cases.
i.e.:
public void TakeDamage (float dmgAmount, DamageType dmgType) {
float dmgToShields = 0f;
float dmgToHealth = 0f;
// Process damage assignments according to the type
switch( dmgType ) {
case DamageType.STANDARD :
dmgToShields = dmgAmount;
break;
case DamageType.PIERCING:
dmgToHealth = dmgAmount;
break;
default:
goto case DamageType.STANDARD;
}
// Apply processed damage amounts to Shields
if (shieldsCurrent > 0f) {
if (dmgToShields > shieldsCurrent) {
// Shields broken by this attack, transfer excess damage
dmgToHealth += dmgToShields - shieldsCurrent;
shieldsCurrent = 0f;
}
else {
shieldsCurrent -= dmgToShields;
}
}
else {
// No shields; all damage is transferred to health
dmgToHealth += dmgToShields;
}
// Apply processed damage amounts to Health
healthCurrent -= dmgToHealth;
if (healthCurrent <= 0) {
// This unit has died!
}
}
I suppose you could make a proxy component that accepts OnAttack() messages and then forwards the damage to other sub-objects in the right order, but I would only do that if you're really invested in working out a good modular system using Unity Components and messages. If you just want to prototype some simple gameplay then IMHO you should start with a simple implementation. Just write a single component with health/shield that implements OnAttack(). Since the interface is fairly well-defined in this case, you can always replace it later with a more comprehensive solution. You may find that you don't need anything more complicated after trying out some gameplay.
You may be right about over designing at this point. I am familiar to a point with Unity and have used it to do some stuff already so I've done some simple implementations of things. Just trying to think a little about what some good and usable design patterns could be applied for situations like this.
I would say not to think too far ahead. There's always stuff you discover during implementation that alters your plans a bit, and damage applying code isn't really complex enough to warrant a massive preplanned modular system. So long as you are properly limiting your damage-dealing functionality to one location in code, refactoring major changes should be straightforward at any point in the project.
Jonathan Blow gave a good talk in 2011 about indie development that goes over excessive modularity and optimization, among other very useful topics:
I think a decent way to get that for this issue would be to split the baseDamage value into local variables that are modified by the switch statement, followed by linear damage processing code. That way your actual damage assignment code is still grouped in the one function without requiring duplication for multiple cases.
That works too and solves the bloated case statement issue. I still wouldn't call it reusable. I was going for more of a base class. This way I can inherit from it and override sections in the derived class as needed.
Either way .. I think together we are gave GogoKodo some ideas about how to approach the problem. You also reminded me I need to remember to use -= / += more.
I suppose you could make a proxy component that accepts OnAttack() messages and then forwards the damage to other sub-objects in the right order, but I would only do that if you're really invested in working out a good modular system using Unity Components and messages. If you just want to prototype some simple gameplay then IMHO you should start with a simple implementation. Just write a single component with health/shield that implements OnAttack(). Since the interface is fairly well-defined in this case, you can always replace it later with a more comprehensive solution. You may find that you don't need anything more complicated after trying out some gameplay.
You may be right about over designing at this point. I am familiar to a point with Unity and have used it to do some stuff already so I've done some simple implementations of things. Just trying to think a little about what some good and usable design patterns could be applied for situations like this.
I would say not to think too far ahead. There's always stuff you discover during implementation that alters your plans a bit, and damage applying code isn't really complex enough to warrant a massive preplanned modular system. So long as you are properly limiting your damage-dealing functionality to one location in code, refactoring major changes should be straightforward at any point in the project.
Jonathan Blow gave a good talk in 2011 about indie development that goes over excessive modularity and optimization, among other very useful topics:
Cool, thanks for the link, I'll definitely check out the talk. I will say that I have actually have programmed on some games already, a couple that actually had some good success. Haven't done anything big in Unity or using component/entity system before so I was trying to look out for some good design direction in a new system.
In my limited experience overengineering kills projects dead.
Make the main requirements work first, then when you have additional requirements add the code to handle them. Refactor on the fly as you add additional requirements. Got something working great but want to rewrite it to make it prettier and handle more stuff that is what sequels are for!
I realized something on the drive home today that's somewhat related to this. When a unit attacks in my game, there's a comparison of the attacker's power and the target's armor. My current formula is to make the actual damage swing between 60% and 140% of the stated amount of the attack. The multiplier is calculated independently of the attack, and looks like this:
That's in a static function that takes the user and target. What I'd prefer to do is handle damage calculation and mitigation separately, so that the mitigation portion can be moved into the target object. That way it can account for things like support abilities that reduce damage.
userVigor(baseDamage) - targetArmor(baseDamage) = 1 when the difference between vigor and armor is 0
userVigor(baseDamage) - targetArmor(baseDamage) = 1.4 when the difference between vigor and armor is 10
userVigor(baseDamage) - targetArmor(baseDamage) = .6 when the difference between vigor and armor is -10
Is it possible to even figure out what the mathematic functions userVigor and targetArmor would be?
stuff added
-- breakable bricks! (pretty sweet)
-- dustcloud when you hit stuff or stuff hits each other
-- siege engines with distinct ballistic characteristics
-- functional main camera! (that you never use)
-- moat!
-- timer for scoring
With the upcoming release of Unity 4.3 and their new 2D pipeline, I figure it's finally time for me to settle in and learn me some Unity for a greater good.
I have an extensive programming background and I understand the basics pretty well (component-based design, fuckyeah), but there's really no good guides that I can find on how to properly architect a Unity game. Like where do you shove your main game loop, keep track of game state, transition between menus and game and such? In components? That's so weird, but that's what I keep seeing in all the tutorials.
I get the feeling that Unity suffers from PHP disease: It's so easy to work with that the quality of the popular tutorials ends up being low because they are written by people without sufficient experience.
Yeah, I'm thinking the same thing, perfect time to get into Unity. I can't find any good tutorials though.
You search for them and you get random threads from 2011 that direct you to "awesome" tutorials made for Unity 2.6. There are a bunch of them for various versions of Unity 3. But at the same time I'm not sure I trust most newer tutorials I can find, a lot of them seem very amateur. Hard to know who is giving authoritatively good advice and who is just throwing together something in a hack job to make it work.
I'm midway through the "stealth" tutorial from the unity site, that might be a good place to start. Problem is it frequently just has you do things without explaining what you're doing, but it'll certainly teach you some of the basics. I got bored at the end of chapter 3 and have been just dicking around with whatever takes my fancy since then.
Right after I posted I went looking again and found that, it does look very nice.
EDIT: According to comments though, it looks like it requires Unity Pro...?
No, I'm not using Unity Pro and its all worked so far.
In my limited experience overengineering kills projects dead.
Make the main requirements work first, then when you have additional requirements add the code to handle them. Refactor on the fly as you add additional requirements. Got something working great but want to rewrite it to make it prettier and handle more stuff that is what sequels are for!
I certainly agree with that - as long as the game does what it's supposed to then it doesn't really matter how neatly programmed it is. The user couldn't care less about the state of your code!
I've finished porting the Apple Jack games to PC now and I'm looking forward to starting on something new, probably a stealth game. The AI and pathfinding requirements of such a game are pretty daunting though. At the moment I'm looking at some kind of node-based method where enemy 'guards' have waypoints to travel between to get from one part of the level to another. They'd have a certain amount of freedom to explore the area between nodes, but will always come back to a node if any true pathfinding is required.
Does anyone here have experience with that kind of stuff?
I realized something on the drive home today that's somewhat related to this. When a unit attacks in my game, there's a comparison of the attacker's power and the target's armor. My current formula is to make the actual damage swing between 60% and 140% of the stated amount of the attack. The multiplier is calculated independently of the attack, and looks like this:
That's in a static function that takes the user and target. What I'd prefer to do is handle damage calculation and mitigation separately, so that the mitigation portion can be moved into the target object. That way it can account for things like support abilities that reduce damage.
userVigor(baseDamage) - targetArmor(baseDamage) = 1 when the difference between vigor and armor is 0
userVigor(baseDamage) - targetArmor(baseDamage) = 1.4 when the difference between vigor and armor is 10
userVigor(baseDamage) - targetArmor(baseDamage) = .6 when the difference between vigor and armor is -10
Is it possible to even figure out what the mathematic functions userVigor and targetArmor would be?
(I am no math expert) Unless you have Min/Max values for each, it seems like any calculation would need both since they are relative to eachother. If you have Min/Max values you can simplify thing by calculating a slope for Vigor and Armor (store them as values someplace so they aren't calculated every hit).
The way I handled that stuff in my tactics game I thought was pretty elegant/overengineered.
Each unit had a "mods" list which encompassed every status it could have. Each buff or debuff had a mod object which was added to the unit's list when it was applied. Then at the appropriate time I looped over the mods list to see if there were any that were relevant to the current operation.
For example I had a "increase attack range" mod. When the battlefield called the unit's "getattackrange" method that method polled the mods list looking for mods that affected the range of the currently selected attack. Same for attack damage, same for receiving damage, and same for gaining debuffs. Some mods would pop up a message when they activated which was stored in the mod class.
This was extensible because I could always add more mods of different types without touching the code.
Example XML code that added mods to commander "spells".
<Passive name="Alacrity" target="squad">
<Effect magnitude="1" type="move">
<ModInfoString>(alacrity: +1 move)</ModInfoString>
<ModInfoStringColor>lime</ModInfoStringColor>
</Effect>
<Description>Increases movement for your squad by 1 until the end of the round.</Description>
</Passive>
The commander had a list of passives, each of which had a list of effects in the form of mods. When the passive was applied the mods were added to each unit in the target group. In this case the passive targeted the commander's whole squad and applied the "Alacrity" passive to all of them.
0
Sir CarcassI have been shown the end of my worldRound Rock, TXRegistered Userregular
I have a lot of C++ experience and have messed around with various ASCII based games (mainly using libtcod) over the last couple of years. I recently started messing around with Unity (after watching some of the 3DBuzz tutorials) and am really liking it. I tried XNA when it first came out, but 3D has always been really daunting to me. I'm sure I'll be popping into this thread a lot asking dumb questions.
One I have off the top of my head since I haven't gotten that deep into Unity yet is how deep can you get in regards to stuff like terrain created in Unity? Specifically, can I do something like create a level and then turn it into tiles, each with their own attributes?
Also, I've only messed with the terrain editor a little, but is it possible to create things like caves or cliff overhangs?
From what little I know about terrain you can't make overhangs or roofs. My understanding is that you would make the "ground" portion and possibly the walls as terrain, then create a mesh to be the roof and place that on top.
Unfortunately my laptop is pushing 5 years old and appears to have a bug in the video card where I get shutdown crash whenever I try to edit a terrain in Unity .
0
Sir CarcassI have been shown the end of my worldRound Rock, TXRegistered Userregular
From what little I know about terrain you can't make overhangs or roofs. My understanding is that you would make the "ground" portion and possibly the walls as terrain, then create a mesh to be the roof and place that on top.
Unfortunately my laptop is pushing 5 years old and appears to have a bug in the video card where I get shutdown crash whenever I try to edit a terrain in Unity .
That makes sense. I'm wanting players to have the ability to dig mineshafts so this is going to require some creative thinking.
From what little I know about terrain you can't make overhangs or roofs. My understanding is that you would make the "ground" portion and possibly the walls as terrain, then create a mesh to be the roof and place that on top.
Unfortunately my laptop is pushing 5 years old and appears to have a bug in the video card where I get shutdown crash whenever I try to edit a terrain in Unity .
That makes sense. I'm wanting players to have the ability to dig mineshafts so this is going to require some creative thinking.
I would look for a voxel terrain library in the asset store, unless you are feeling hardcore enough to code it yourself. Found this one in a quick google search, im sure there are more: https://www.assetstore.unity3d.com/#/content/9180
In my limited experience overengineering kills projects dead.
Make the main requirements work first, then when you have additional requirements add the code to handle them. Refactor on the fly as you add additional requirements. Got something working great but want to rewrite it to make it prettier and handle more stuff that is what sequels are for!
I certainly agree with that - as long as the game does what it's supposed to then it doesn't really matter how neatly programmed it is. The user couldn't care less about the state of your code!
I've finished porting the Apple Jack games to PC now and I'm looking forward to starting on something new, probably a stealth game. The AI and pathfinding requirements of such a game are pretty daunting though. At the moment I'm looking at some kind of node-based method where enemy 'guards' have waypoints to travel between to get from one part of the level to another. They'd have a certain amount of freedom to explore the area between nodes, but will always come back to a node if any true pathfinding is required.
Does anyone here have experience with that kind of stuff?
The monsters in the game I'm working on (in my sig) basically behave like you describe. I have enough nodes that there is no point in the level that is out of sight of a node, and then the AI is free to move around as it likes chasing after the player etc. Whenever it gets lost or can't walk directly somewhere it wants to go it just looks for the closest visible node to where it wants to go and walks to it and pathfinds from there.
I'd never done AI in 3D before, so getting the basics working was fairly straightforward, but sorting out the details that hadn't occurred to me at the start like allowing creatures to follow eachother, pathfinding after moving objects and working out reliably if a creature can walk across a section of floor was really hard work. It was extremely satisfying once it all started to come together though.
Its probably not as difficult as you would imagine, but also probably more work than you would imagine basically.
I think the hardest part about stealth gameplay is tuning the enemies to behave like they are alive and smart, but also be intuitively predictable and dumb. The predictable bit is giving me a lot of trouble, they just do weird stuff sometimes and my gosh there is so much code I couldn't say why for sure.
0
Sir CarcassI have been shown the end of my worldRound Rock, TXRegistered Userregular
From what little I know about terrain you can't make overhangs or roofs. My understanding is that you would make the "ground" portion and possibly the walls as terrain, then create a mesh to be the roof and place that on top.
Unfortunately my laptop is pushing 5 years old and appears to have a bug in the video card where I get shutdown crash whenever I try to edit a terrain in Unity .
That makes sense. I'm wanting players to have the ability to dig mineshafts so this is going to require some creative thinking.
I would look for a voxel terrain library in the asset store, unless you are feeling hardcore enough to code it yourself. Found this one in a quick google search, im sure there are more: https://www.assetstore.unity3d.com/#/content/9180
That looks awesome and exactly the kind of thing I need, but ouch $75
Gives me something to research, anyway. Thank you!
My HTC One seems to run my game better than my laptop. That makes me sad.
On the other hand, the ease of getting the game onto my phone, and then implementing touch controls, is phenomenal. I just wrote a function that detects touch swipes to control the camera, and it's 12 lines long.
So I've got my AI-controlled enemy units wandering around random directions like energetic farm animals now. Even with something that simplistic, seeing enemy units pop into and out of my visibility while "ENEMY MOVEMENT" glows at the bottom of the screen is giving me chills. So pumped! Hopefully I can get them chasing down and actually shooting at player units by Monday.
So I've got my AI-controlled enemy units wandering around random directions like energetic farm animals now. Even with something that simplistic, seeing enemy units pop into and out of my visibility while "ENEMY MOVEMENT" glows at the bottom of the screen is giving me chills. So pumped! Hopefully I can get them chasing down and actually shooting at player units by Monday.
That wonderful moment where you realize AI doesn't have to be smart, it just has to give the illusion of being smart.
Posts
I'm midway through the "stealth" tutorial from the unity site, that might be a good place to start. Problem is it frequently just has you do things without explaining what you're doing, but it'll certainly teach you some of the basics. I got bored at the end of chapter 3 and have been just dicking around with whatever takes my fancy since then.
Right after I posted I went looking again and found that, it does look very nice.
EDIT: According to comments though, it looks like it requires Unity Pro...?
I've never heard of an unsafe asset store object. If you have a link to any story about how something was exploited please share. My GoogleFu didn't come up with anything except for an ssl exploit for android and I don't believe is unity related.
I've gone through a bunch of tutorials online but they always seem to fall just a little bit short in terms of mildly complicated design. Which is fine for tutorials I guess. They will generally show how to do some very specific interaction, but not always in a reusable, modular way.
Perhaps my recent reading of the Pragmatic Programmer has caused more confusion in my head when dealing with Unity than is necessary. I'm really trying to think about reusable design for my components. So I've come up with a fairly (I think) simple interaction that I'm having trouble designing in a way that feels right.
I want an entity with an Attack component that can deal damage to entity with Health and/or Shield. The Attack deals damage to the Health as you would imagine in a straight forward way. It also deals damage to Shield in a basic way except when the Attack has a ShieldPiercing property. Any damage the Shield takes should reduce the damage to the Health.
Something like this description:
Attack - damage number - pierce shield bool - sends messages something like "OnAttack" to a Target - message has as parameter the Attack object, or possibly some more basic parameters Health - max hitpoints number - current hitpoints number - listen for "OnAttack" message, reduce hitpoints - if hitpoints fall to 0, send "OnKilled" message back to the attacker Shield - max shield number - current shield number - listen for "OnAttack" message - if attack is shield piercing damage the Health rather than the shield - otherwise damage the shield but any overflow damage is dealt to the hitpoints - eg. 1 shield left, 2 damage done. Shield reduced to 0, hitpoints takes 1 damage - if shield falls to 0, send "OnShieldDestroyed" message back to the attackerIdeally an entity could be given a Health component and not Shield compnent and vice versa. Perhaps the idea of giving an entity a Shield without giving it Health is weird, but I think it would be ideal if I could design the components in such a way.
Now I can do all this but what I'm really looking for is a good way. The way I listed this in the description of messages above it won't actually work nicely. I need some way to have the damage funneled through the Shield component if it's there, I can't just listen to the "OnAttack" message in both the Health and Shield. Everything just seems so tied together however I try and design it. Ideally I'd like to change the Shield for example with as few cascading changes to other components as possible. Or add some new thing, a component that sits on top of Shield, "Armor", that works like the Shield does. Giving the interaction Armor->Shield->Hitpoints for soaking up damage.
I've thought of perhaps making some kind of DamageController, or AttackedController, that might take the "OnAttack" message from the Attack (rather than the Health or Shield directly). And that would then decide the ordering of what gets damaged. Perhaps that's OK, but something about it feels weird. It would mean anytime I add in a Health it would have a requirement of that component to also have a DamageController.
Hopefully I'll get some time tonight to actually sit down and fart around with it for real, so I'm not as terribly confused tomorrow as I otherwise may be.
I think I've got that basically covered with how I listed above. The part about the target calculating the damage is where I'm unsure about what a nice reliable, reusable design would come in for Unity. Ideally a Health component and a Shield component could be put onto different entities, but not all entities would necessarily need both to function. This would let me create units that have hitpoints but no shield, shield but no hitpoints (maybe an energy field or something). I can do that, but I'm interested in the design aspect because I want to create the pieces in such a way that say adding a third component "Armor", would act similarly to hitpoints and shield but wouldn't require a ton of refactoring if I were to ever add such a thing.
I honestly haven't played with Unity much .. but this is how I would start building it in c# .. obviously this wouldn't be useable code..
class MyBaseMonsterClass { private int _Health = 1; private int _Sheild = 0; public void OnAttack(object sender, AttackEventArgs e) { switch (e.AttackType) { case Normal: NormalHit(e.BaseDamage); return; case Pierce: SheildPierceHit(e.BaseDamage); return; default: NormalHit(e.BaseDamage); return; } CheckLife(); // make sure you are still alive or whatever updates } private void NormalHit(int Damage) { if (_sheild > 0) { Damage = DamageSheild(Damage); // DamageSheild returns the remaining Damage } DamageHp(Damage); } private void SheildPierceHit(int Damage) { DamageHp(Damage); } private void DamageHp(int amt) { _Health = _Health - amt; } private int DamageSheild(int amt) { if (amt < _sheild) { _sheild = _sheild - amt; return 0; } else { amt = amt - _sheild; _sheild = 0; return amt; } } } class AttackEventArgs : EventArgs { public string AttackType; public int BaseDamage; }Seems like you're overthinking this. In my project I have CombatUnit components that store their weapon information and health information as fields. CombatUnit objects have a TakeDamage(amount, type) method that handles all the logic of modifying and assigning the damage. Any changes I make to the health and damage system of the game only requires that I look at that one method. Adding shields, armor, temporary buffs, what have you. I'm actually intending to upgrade the method to TakeDamage(amount, type, location) at some point further down the line but I know it'll be simple so it's not a problem.
If you want to have units that have health but no shield, or shields but no armor, etc. then you can just set their remaining shield or armor fields to zero.
For this case i totally agree with that. However I was thinking of a much more complex system where the original case statement would be much larger. I don't like putting much code in case statements since, for me at least, it tends to get messy. The reason I break out the Damage functions from these is to make it more maintainable. If I had 20 Attack types and decided to change how Damage drains shields, I would only need to edit the one DamageShield function.
You may be right about over designing at this point. I am familiar to a point with Unity and have used it to do some stuff already so I've done some simple implementations of things. Just trying to think a little about what some good and usable design patterns could be applied for situations like this.
I think a decent way to get that for this issue would be to split the baseDamage value into local variables that are modified by the switch statement, followed by linear damage processing code. That way your actual damage assignment code is still grouped in the one function without requiring duplication for multiple cases.
i.e.:
public void TakeDamage (float dmgAmount, DamageType dmgType) { float dmgToShields = 0f; float dmgToHealth = 0f; // Process damage assignments according to the type switch( dmgType ) { case DamageType.STANDARD : dmgToShields = dmgAmount; break; case DamageType.PIERCING: dmgToHealth = dmgAmount; break; default: goto case DamageType.STANDARD; } // Apply processed damage amounts to Shields if (shieldsCurrent > 0f) { if (dmgToShields > shieldsCurrent) { // Shields broken by this attack, transfer excess damage dmgToHealth += dmgToShields - shieldsCurrent; shieldsCurrent = 0f; } else { shieldsCurrent -= dmgToShields; } } else { // No shields; all damage is transferred to health dmgToHealth += dmgToShields; } // Apply processed damage amounts to Health healthCurrent -= dmgToHealth; if (healthCurrent <= 0) { // This unit has died! } }I would say not to think too far ahead. There's always stuff you discover during implementation that alters your plans a bit, and damage applying code isn't really complex enough to warrant a massive preplanned modular system. So long as you are properly limiting your damage-dealing functionality to one location in code, refactoring major changes should be straightforward at any point in the project.
Jonathan Blow gave a good talk in 2011 about indie development that goes over excessive modularity and optimization, among other very useful topics:
http://the-witness.net/news/2011/06/how-to-program-independent-games/
That works too and solves the bloated case statement issue. I still wouldn't call it reusable. I was going for more of a base class. This way I can inherit from it and override sections in the derived class as needed.
Either way .. I think together we are gave GogoKodo some ideas about how to approach the problem. You also reminded me I need to remember to use -= / += more.
Cool, thanks for the link, I'll definitely check out the talk. I will say that I have actually have programmed on some games already, a couple that actually had some good success. Haven't done anything big in Unity or using component/entity system before so I was trying to look out for some good design direction in a new system.
Make the main requirements work first, then when you have additional requirements add the code to handle them. Refactor on the fly as you add additional requirements. Got something working great but want to rewrite it to make it prettier and handle more stuff that is what sequels are for!
1 + (user.GetEffectiveStat("Vigor") / target.GetEffectiveStat("Armor")) * .04);
That's in a static function that takes the user and target. What I'd prefer to do is handle damage calculation and mitigation separately, so that the mitigation portion can be moved into the target object. That way it can account for things like support abilities that reduce damage.
userVigor(baseDamage) - targetArmor(baseDamage) = 1 when the difference between vigor and armor is 0
userVigor(baseDamage) - targetArmor(baseDamage) = 1.4 when the difference between vigor and armor is 10
userVigor(baseDamage) - targetArmor(baseDamage) = .6 when the difference between vigor and armor is -10
Is it possible to even figure out what the mathematic functions userVigor and targetArmor would be?
Project is here if anyone wants to steal stuff/make it better
stuff added
-- breakable bricks! (pretty sweet)
-- dustcloud when you hit stuff or stuff hits each other
-- siege engines with distinct ballistic characteristics
-- functional main camera! (that you never use)
-- moat!
-- timer for scoring
No, I'm not using Unity Pro and its all worked so far.
In my Limited experience, I tend to over engineer everything
I certainly agree with that - as long as the game does what it's supposed to then it doesn't really matter how neatly programmed it is. The user couldn't care less about the state of your code!
I've finished porting the Apple Jack games to PC now and I'm looking forward to starting on something new, probably a stealth game. The AI and pathfinding requirements of such a game are pretty daunting though. At the moment I'm looking at some kind of node-based method where enemy 'guards' have waypoints to travel between to get from one part of the level to another. They'd have a certain amount of freedom to explore the area between nodes, but will always come back to a node if any true pathfinding is required.
Does anyone here have experience with that kind of stuff?
(I am no math expert) Unless you have Min/Max values for each, it seems like any calculation would need both since they are relative to eachother. If you have Min/Max values you can simplify thing by calculating a slope for Vigor and Armor (store them as values someplace so they aren't calculated every hit).
Vslope = MaxVig / .8
Vigorcalc = baseDamage * ( 1 + (Vigor / Vslope) )
Aslope = MaxArmor / .8
Armorcalc = baseDamage * ( 1 - (Armor/ Aslope ) )
Final Damage = (Vigorcalc + Armorcalc ) / 2
I think you are better off doing the whole calculation in one pass on the target by passing in the needed variables from the attacker.
Each unit had a "mods" list which encompassed every status it could have. Each buff or debuff had a mod object which was added to the unit's list when it was applied. Then at the appropriate time I looped over the mods list to see if there were any that were relevant to the current operation.
For example I had a "increase attack range" mod. When the battlefield called the unit's "getattackrange" method that method polled the mods list looking for mods that affected the range of the currently selected attack. Same for attack damage, same for receiving damage, and same for gaining debuffs. Some mods would pop up a message when they activated which was stored in the mod class.
This was extensible because I could always add more mods of different types without touching the code.
Example XML code that added mods to commander "spells".
The commander had a list of passives, each of which had a list of effects in the form of mods. When the passive was applied the mods were added to each unit in the target group. In this case the passive targeted the commander's whole squad and applied the "Alacrity" passive to all of them.
One I have off the top of my head since I haven't gotten that deep into Unity yet is how deep can you get in regards to stuff like terrain created in Unity? Specifically, can I do something like create a level and then turn it into tiles, each with their own attributes?
Also, I've only messed with the terrain editor a little, but is it possible to create things like caves or cliff overhangs?
Steam Support is the worst. Seriously, the worst
Unfortunately my laptop is pushing 5 years old and appears to have a bug in the video card where I get shutdown crash whenever I try to edit a terrain in Unity
That makes sense. I'm wanting players to have the ability to dig mineshafts so this is going to require some creative thinking.
Steam Support is the worst. Seriously, the worst
I would look for a voxel terrain library in the asset store, unless you are feeling hardcore enough to code it yourself. Found this one in a quick google search, im sure there are more: https://www.assetstore.unity3d.com/#/content/9180
The monsters in the game I'm working on (in my sig) basically behave like you describe. I have enough nodes that there is no point in the level that is out of sight of a node, and then the AI is free to move around as it likes chasing after the player etc. Whenever it gets lost or can't walk directly somewhere it wants to go it just looks for the closest visible node to where it wants to go and walks to it and pathfinds from there.
I'd never done AI in 3D before, so getting the basics working was fairly straightforward, but sorting out the details that hadn't occurred to me at the start like allowing creatures to follow eachother, pathfinding after moving objects and working out reliably if a creature can walk across a section of floor was really hard work. It was extremely satisfying once it all started to come together though.
Its probably not as difficult as you would imagine, but also probably more work than you would imagine basically.
I think the hardest part about stealth gameplay is tuning the enemies to behave like they are alive and smart, but also be intuitively predictable and dumb. The predictable bit is giving me a lot of trouble, they just do weird stuff sometimes and my gosh there is so much code I couldn't say why for sure.
That looks awesome and exactly the kind of thing I need, but ouch $75
Gives me something to research, anyway. Thank you!
Steam Support is the worst. Seriously, the worst
On the other hand, the ease of getting the game onto my phone, and then implementing touch controls, is phenomenal. I just wrote a function that detects touch swipes to control the camera, and it's 12 lines long.
That wonderful moment where you realize AI doesn't have to be smart, it just has to give the illusion of being smart.