DON'T SPAWN AT WILL DURING GAMEPLAY!!!!!!!!!!!!!!!!!!!!!!
Okay now that that's out of the way, just don't. It is a blind leap of faith that can cripple your program and destroy user experience. Sure it may seem obvious but lots of you might not even consider this.
What you should be doing is set everything that you can up during loading screens or periods of player inactivity/waiting. Why? Laaaaaaagggggggggggggggg obviously. Or at the very least to avoid stuttering.
Cupcake Escape has taught me a lot about the structure of a game under the hood, and I've learned lots of good things, and after gitting gudder as a programmer, lots of mistakes I made.
One of them is, as you might have guessed, spawning objects during gameplay.
So the way my game works is you jump over obstacles that come at you at random. My mistake was creating a system that spawns objects during game play, and then despawning them. Lots can go wrong. If you are constantly spawning things without despawning them, you will eventually crash your game because you ran out of memory due to nasty leakage. You also close up memory and resources that can be used by other classes/methods/programs/OS/etc. When you're spawning new objects and your engine has to allocate resources for that new object, your players might feel it with stuttering or lag. I don't know if you can see it if you play Cupcake Escape (check my portfolio), but I see it and it kills me inside. But I didn't know better back then. Now I know better.
So like I said above, spawn when there's no real important gameplay going on, or stream in the background if your performance allows it, but do your best to not sacrifice runtime performance.
One way to do this, if you have to spawn a bunch of things repeatedly, is to just set up a factory.
The way that works is basically you have an array that stores a number of instances of an object you want to use many times. So when an instance is to be destroyed (player kills it, breaks it, specific context action here), instead of actually destroying that object, you deactivate it. When you spawn an object, you reset it, move it to where you want it to be, and then activate it again!
What this does is keeps your resources constant, because you aren't really spawning anything, and you don't have to worry about memory leaks and losing track of objects. You know where your objects are at all times, and resetting and moving your deactivated object to recycle it takes constant time. No stuttering or lag, no leaks, no problem.
This has been used in many old games and continues to be a useful technique today. Especially in environments that have limited capacity (coughconsolemobilegamescough), this technique can create the illusion of endless enemies without breaking the performance bank.
Thursday, December 15, 2016
Wednesday, December 14, 2016
Programming - Random Weighted Selection
For Cupcake Escape (which is now playable again), I used a weighted system for selecting random objects off a list. By that I mean each object from the list can have different probabilities.
Suppose we have the following objects we want to summon.
Cookie
Pie
Turkey
Cranberry
Bran muffin
Natto
The way that is done is by first assigning each object a number from 0-100 and then creating a sum using each object's number. Then you basically divide each object's number by the sum in order to get a percentage. That percentage is your object's probability of spawning. You don't necessarily have to divide within your program, but I did it for the sake of human understanding using floats. However, I do not recommend using floats, as they take up more memory than ints do. Not to mention keeping track of floats is a pain... So I would recommend just sticking to ints.
Cookie - 100
Pie - 50
Turkey - 50
Cranberry - 25
Bran muffin - 25
Natto - 10
Group Sum - 260
(It's fine to use the above set of information for the next part of the algorithm)
Approximate probabilities
Cookie -38.5%
Pie - 19.2%
Turkey - 19.2%
Cranberry - 9.6%
Bran muffin - 9.6%
Natto - 3.9%
Note that these items are ordered in accordance to weight/probability. You don't necessarily need this to be ordered. I just have them in order for the sake of being organized.
So you have your probabilities and associated objects stored somewhere. I used an array in my game. The next part is to randomly spawn those objects in accordance to the probabilities assigned to your objects. So first you need to generate a random number within the range of 0 and the sum we previously calculated. That random number represents your selection choice.
To figure out what you need to spawn, you now need to go through the array and check against your generated number.
To do this, you go through the array. You also need a temporary variable to keep track of were you are in the array so far. So the way this works is that you check each item in the array from smallest to largest. You add the current probability to the temporary variable and check if your variable is bigger than your generated number. If your generated number is bigger, you move to the next item in your array and add it to your temporary variable. If your generated number is still bigger, you do it again. When your temporary variable is finally bigger than your generated number, you simply return the object you just added and you have your selection!
For example... let's say our generated number is 159. This int was randomly chosen from a range of
0 and 260 (or 261 if non inclusive) using an RNG.
We have our temporary variable int SumSoFar (set to 0) and we start with Natto, because it's the smallest and the first item in the array. Natto has a probability of 10, so SumSoFar is 10. Since our random number is 159, SumSoFar is smaller, so we move onto the next item.
Add Bran Muffin
SumSoFar = 35
35 < 159
Add Cranberry
SumSoFar = 60
60 < 159
Add Turkey
SumSoFar = 110
110<159
Add Pie
SumSoFar = 160
160 !< 159
Return Pie
So why does this work?
Suppose you have your range laid out on a line
NBBBCCTTTTTPPPPPKKKKKKKKKK
All you are doing is picking one of the letters above. Each letter represents one of your possible choices. The number of letters represents the probability of picking that letter. Suppose you randomly pick a spot on the line and you are looking from left to right. Every range to the left of where your finger fell is not below your finger. The range that is below your finger is your selection choice. No matter where your finger falls in the range of K for example, it will still be K. Your finger did not fall in the ranges of P, or T, or C, or B or N, because your finger already went past all of them. However, your finger did not pass the range of K. Your finger fell within the range of K. So, because your finger went past the end of all previous ranges, but did not pass the end of range K, you landed on K. This is the principal which the algorithm above works on and is the reason why it works.
Because of the loop involved, it might be difficult to use this weighted probability selector during run time if your selection group is large. The reason being is because this loop will run on one frame, and if the delay is big enough because your group is large, you will pay for it in your frame rate. I cannot necessarily say this explains why my game stutters a little bit (it might be because of my factory setup), but it can certainly be a negative factor in theory. So limit your selection pool size.
When you are creating your sum, do that loop on awake or before the player has control. Calculate it, and do not set the sum manually because this allows for flexibility. If your designers want to tweak the weight/probability because something was appearing too often, they can simply change that number and you don't have to go back into your code to change anything. It's convenient for everybody!
Suppose we have the following objects we want to summon.
Cookie
Pie
Turkey
Cranberry
Bran muffin
Natto
The way that is done is by first assigning each object a number from 0-100 and then creating a sum using each object's number. Then you basically divide each object's number by the sum in order to get a percentage. That percentage is your object's probability of spawning. You don't necessarily have to divide within your program, but I did it for the sake of human understanding using floats. However, I do not recommend using floats, as they take up more memory than ints do. Not to mention keeping track of floats is a pain... So I would recommend just sticking to ints.
Cookie - 100
Pie - 50
Turkey - 50
Cranberry - 25
Bran muffin - 25
Natto - 10
Group Sum - 260
(It's fine to use the above set of information for the next part of the algorithm)
Approximate probabilities
Cookie -38.5%
Pie - 19.2%
Turkey - 19.2%
Cranberry - 9.6%
Bran muffin - 9.6%
Natto - 3.9%
Note that these items are ordered in accordance to weight/probability. You don't necessarily need this to be ordered. I just have them in order for the sake of being organized.
So you have your probabilities and associated objects stored somewhere. I used an array in my game. The next part is to randomly spawn those objects in accordance to the probabilities assigned to your objects. So first you need to generate a random number within the range of 0 and the sum we previously calculated. That random number represents your selection choice.
To figure out what you need to spawn, you now need to go through the array and check against your generated number.
To do this, you go through the array. You also need a temporary variable to keep track of were you are in the array so far. So the way this works is that you check each item in the array from smallest to largest. You add the current probability to the temporary variable and check if your variable is bigger than your generated number. If your generated number is bigger, you move to the next item in your array and add it to your temporary variable. If your generated number is still bigger, you do it again. When your temporary variable is finally bigger than your generated number, you simply return the object you just added and you have your selection!
For example... let's say our generated number is 159. This int was randomly chosen from a range of
0 and 260 (or 261 if non inclusive) using an RNG.
We have our temporary variable int SumSoFar (set to 0) and we start with Natto, because it's the smallest and the first item in the array. Natto has a probability of 10, so SumSoFar is 10. Since our random number is 159, SumSoFar is smaller, so we move onto the next item.
Add Bran Muffin
SumSoFar = 35
35 < 159
Add Cranberry
SumSoFar = 60
60 < 159
Add Turkey
SumSoFar = 110
110<159
Add Pie
SumSoFar = 160
160 !< 159
Return Pie
So why does this work?
Suppose you have your range laid out on a line
NBBBCCTTTTTPPPPPKKKKKKKKKK
All you are doing is picking one of the letters above. Each letter represents one of your possible choices. The number of letters represents the probability of picking that letter. Suppose you randomly pick a spot on the line and you are looking from left to right. Every range to the left of where your finger fell is not below your finger. The range that is below your finger is your selection choice. No matter where your finger falls in the range of K for example, it will still be K. Your finger did not fall in the ranges of P, or T, or C, or B or N, because your finger already went past all of them. However, your finger did not pass the range of K. Your finger fell within the range of K. So, because your finger went past the end of all previous ranges, but did not pass the end of range K, you landed on K. This is the principal which the algorithm above works on and is the reason why it works.
Some Things to Note
Because of the loop involved, it might be difficult to use this weighted probability selector during run time if your selection group is large. The reason being is because this loop will run on one frame, and if the delay is big enough because your group is large, you will pay for it in your frame rate. I cannot necessarily say this explains why my game stutters a little bit (it might be because of my factory setup), but it can certainly be a negative factor in theory. So limit your selection pool size.
When you are creating your sum, do that loop on awake or before the player has control. Calculate it, and do not set the sum manually because this allows for flexibility. If your designers want to tweak the weight/probability because something was appearing too often, they can simply change that number and you don't have to go back into your code to change anything. It's convenient for everybody!
Monday, December 12, 2016
Pressing on
Hello Everyone! I am back after a very long hiatus. So much has been going on in my life, but I'm glad to say that I've gone back to school to finish my degree! And even better yet, I am doing better than most of my peers. It's been a big psychological and financial game to go back, but it's worth it. I'm studying Game Programming, and the degree is structured like a specialized computer science degree, which it essentially is.
Besides that, I recently noticed that my previous file sharing site Dropbox has stopped serving html files to browsers, instead prompting users to download the page. This is a problem because my games cannot be accessed that way. The solution was to use itch.io to publish my games as HTML5 games so that they are still playable in the browser, because most people won't want to take the time to download a zip and set the game up. It's much faster and more convenient.
The first game has been ported over, Cupcake Escape. I plan to make a few more posts diving deeper into the design of the game itself and how things were implemented, along with how things could have been optimized, and why things were implemented the way they were back then (spoiler alert: lack of good code fu skills). Hopefully this will help you employers understand my knowledge and my skill, and help you readers learn how to optimize your programs better.
Well that's the first post of many. My goal is to try to make daily contributions from now on. School and work permitted. See you tomorrow!
Besides that, I recently noticed that my previous file sharing site Dropbox has stopped serving html files to browsers, instead prompting users to download the page. This is a problem because my games cannot be accessed that way. The solution was to use itch.io to publish my games as HTML5 games so that they are still playable in the browser, because most people won't want to take the time to download a zip and set the game up. It's much faster and more convenient.
The first game has been ported over, Cupcake Escape. I plan to make a few more posts diving deeper into the design of the game itself and how things were implemented, along with how things could have been optimized, and why things were implemented the way they were back then (spoiler alert: lack of good code fu skills). Hopefully this will help you employers understand my knowledge and my skill, and help you readers learn how to optimize your programs better.
Well that's the first post of many. My goal is to try to make daily contributions from now on. School and work permitted. See you tomorrow!
Tuesday, September 1, 2015
Recent Developments!
Hey everyone! Sorry for being off the blog for so long, but I've been a little busy.
Saturday, April 11, 2015
Cupcake Escape v1.1 update
Development is in its final stretch for the game. I am currently struggling with finding someone to do the audio, but hopefully I get a response for that soon. I changed a lot, so if you want to go take a look, check out my portfolio on the right! >>>
Wednesday, March 11, 2015
Cupcake Escape v1.1
If you haven't played Cupcake Escape, go do it! It's in my portfolio, linked to your right hand side somewhere that way. >>>>>>>>>>>>>>>>>>>>>>>>>
Currently it is sitting at version 1.0, but there's a lot missing from it. Therefore I've been hard at work at version 1.1!
Here's a list of what's to come:
-Improved Spawner with the ability to change object probabilities to control how often something shows up
-Improved game design, because it was never balanced before,
-Better buttons for visual pleasure
-Story mode! Because cupcakes need a reason to escape
-Something for tutorial, because controls aren't inherently clear
-Credits to show who made it
-Music because a game isn't always interesting without sound
-Version number just because
-Minor minor improvements
So that's what's to come in the next iteration. I might have more to come later since these are all things I listed off the top of my head, but please look forward to it!
-------------------------------------------------------------------------------------------------------------------------
P.S. I did extremely well on my interview! I hope I get the job, because I not only want to make some money, but I also want more professional experience as a game developer. Working in isolation isn't good. Plus many people who work at the company I applied to love food! As do I!
Currently it is sitting at version 1.0, but there's a lot missing from it. Therefore I've been hard at work at version 1.1!
Here's a list of what's to come:
-Improved Spawner with the ability to change object probabilities to control how often something shows up
-Improved game design, because it was never balanced before,
-Better buttons for visual pleasure
-Story mode! Because cupcakes need a reason to escape
-Something for tutorial, because controls aren't inherently clear
-Credits to show who made it
-Music because a game isn't always interesting without sound
-Version number just because
-Minor minor improvements
So that's what's to come in the next iteration. I might have more to come later since these are all things I listed off the top of my head, but please look forward to it!
-------------------------------------------------------------------------------------------------------------------------
P.S. I did extremely well on my interview! I hope I get the job, because I not only want to make some money, but I also want more professional experience as a game developer. Working in isolation isn't good. Plus many people who work at the company I applied to love food! As do I!
Wednesday, March 4, 2015
Updates and more
Sorry for not writing in a while. I've been super busy recently, especially with GDC going on this week. So I'll quickly go over GDC experiences (even though I'm not there in person), updates, announcements, and what's to come ahead and such.
Subscribe to:
Posts (Atom)