Questioning life in general...
Monkey Archive Forums/Monkey Discussion/Questioning life in general...
| ||
Bet you came in here thinking I was about to talk about , well life... well your right I am , but I'm talking more about the life that we give to our game actors, objects, items or things and as life I mean the value that represents how healthy that thing is.. So, do you Int or Float your life variables, answers on a post card please also give a reason why.. |
| ||
Awwww... Disappointed. :/ HA no well. Will have to think about this... |
| ||
Depends... if its a 3 life game I use Ints:Field lives:Int = 3 But if I use an life bar, it needs to be a float to be able to reduce smoothly. Field lifeBar:Float = 100 |
| ||
You could use int for your life bar as well. Just let it go up to 10000. ;) |
| ||
It truly depends on the game. Usually Ints give tighter control over how much effect damage does, or health potion, especially if you're doing a dice based game. |
| ||
Yeah I tend to go the Int route and up its value as Xaron said but I think a better option would be to use a float, I was thinking that a float 0-1 would be enough as it essentially has infinite decimal places between, Therevills any reason you use 100 ? |
| ||
100 = 100% :) |
| ||
No, 100 % = 1.0 (because the % basically means 1/100) :-P |
| ||
I was thinking the same as ratking on that one, I plan to play with this topic in my little shooter project, at the moment I'm dealing with my bullets power and in turn damage dealt with Int's as a result I'm having to constantly tweak and increase my asteroid's and aliens hit points, but if I switch over to using a 0.0-1.0 float then an asteroid's health is always going to be the same and I only need to alter the amount of damage that a specific bullet deals.. Should give a lot more flexibility, I also want to introduce critical hit chance, I will experiment with it and see what I like to work with more, high ints or floats, at the moment I have no preference either way. |
| ||
If you want the player to micromanage it (as often in a classic roguelike) ints are probably best. If you want to have loads of continuous status effects altering it (could be in an action roguelike like Diablo), floats have their advantages. |
| ||
I also use Ints as 0 to 100 for a life bar, for lives, 0 to 3. If you need more precision, you can always use 0 to 1000 and divide by 10 to get a percentage number. It could be good to use floats if you have something that causes damage over time such as fire and you want it to be smoother. Or say you have something that does more damage at first and then trickles off...such as poisoned or bleeding... Another thing you can do is use Floats for the actual number, and another variable for displaying the graphics, like this: LifeBarDisplay%=LifeBar# DrawLifeBar(LifeBarDisplay%) This way 18.7% life (LifeBar#=18.7) will display as a 19 pixel wide (LifeBarDisplay%=19) image...if that makes sense? |
| ||
Normally I prefer floats but in some cases it might be better to use integer values. Since different processor architectures may compute floating point values differently, you should use integers for network multiplayer games (see also: this article). |
| ||
Zer0 thanks, not sure why I never thought about fire or damage over time for my project but now that you bring it up it's actually something that should fit really well, will need to do some tests and see if I can come up with some new gun types or powerups that can utilize DoT's.. |
| ||
Normally I prefer floats but in some cases it might be better to use integer values. Since different processor architectures may compute floating point values differently, you should use integers for network multiplayer games Networking your game comes to mind here. I use integers for scoring, damage, shield levels and alike. Positioning an actor can be either a float or an integer, but as suggested above floats can be 'slightly' different on different devices. In some cases this can be a problem but my experience in using floats over UDP is generally OK (although integers are the most accurate) and at most the actor position might be off by a pixel. I know from testing 2D actor positions based on floats across different OS's and devices has not been an issue. But this really depends on the networking architecture for example I use an authoritative server model. |
| ||
In addition to what's already written I often prefer integers because I can compare them in a simpler way, i.e. without any epsilons. |
| ||
Yeah I can see why floats might not be optimal with networking in mind, but that being said when their used in the context of life I wonder if the variance or potential variance is really enough to cause issues, the only real issue I can think of might be where a small decimal variation due to network travel would mean life or death for an actor, but then in that case you could also just throw along a boolean for alive or dead just to enforce it. |
| ||
The problem with networking appears when you have too much data to send all the information over the network. The linked article described the case of an RTS game. It is impossible to send all unit data (live, position, …) for some hundred units to everyone. The solution in this scenario is to run the same simulation on all machines (using the same random seeds) and only send the user input over the network. Using floats could lead to problems like one unit dying on only one machine because an arm based device computed some floats different than an x86 machine – which would lead to completely different simulations/games on both machines. This problem could also affect other aspects of a game like path finding. |
| ||
Worst case scenario for floating point is if it doesn't conform to the IEEE standard. Otherwise it's guaranteed to have identical behavior if compiled with a strict conformity flag, and is on the same processor architecture. Beyond that, you don't have any guarantees. I've been looking into this issue recently, and the best solution in a client server architecture is for the server to reconcile any sync issues if they come up. You can create a CRC / hash of all the values in your state which is sent to determine whether stuff syncs up with the canonical state. If they don't match, you run the simulation for the frame on the server side. In a peer-to-peer system, it may get a bit hairier, but would work similarly by adjusting the clients state to the majority value and requesting a full state from another client that has the majority value. Another option is to have floating point values which are synchronized to the lowest expected precision by rounding off those values before a packet is processed. Yet another option is to keep snapshots of the last few frames and rewind it if the users go out of sync. You can mix and match some of these approaches where it's appropriate for your game depending on the level of real time synchronization necessary. |
| ||
Are you saying I should put my life into a single Int? I've always wanted to be a float! |