Programming and Probability (P&P)
In this project our class learned about probability analysis, as well as programming skills. Our final product was a probability based video game, and a probability analysis of the game we made.
Benchmarks
To help tackle a project as big as this, we split it up into benchmarks.
Benchmark (BM) #1 was an initial idea for our game, we would tell our teacher, Dr Drew, the basic idea, and he could help us weed out any ideas that were either to easy or to difficult to make.
BM #2 was an in depth description for how we wanted our game to work, and what we expected our probability analysis to be. This was important because, without an outline, making a video game can become really complicated really quickly. By thinking about the systems beforehand, we can make things a lot easier in the long run. Thinking of our probability analysis was also important, so that we would remember that that portion of the game should not be removed (you can't do probability analysis on something that doesn't have chance involved).
BM #3 an even more in depth review of exactly how we wanted things to be coded. We listed the variables and classes we needed, and what all of them should do. If we weren't sure how to do something, we made sure it was possible to do, etc. This was crucial, because it meant nailing down exactly how the game would be played, and squashing a lot of bugs before they even occurred.
BM #4 was the actual probability analysis of our game. Because this project was about probability, this was essentially what all the other steps we did were leading up to. I've posted my BM #4 below, if you want to see what I did.
BM #5 was programming the game itself. Aside from BM #4, it's probably the most important. Luckily, if you did all the previous benchmarks (which I did), and have some basic knowledge of programming (which I do), this benchmark was actually pretty straight forwards. The only real challenge was bug-fixing, and fortunately most of my bugs were small graphical errors.
Our final BM is what you are reading right now: the DP update. Without it, none of the cool stuff I made would ever be seen by anyone.
Benchmark (BM) #1 was an initial idea for our game, we would tell our teacher, Dr Drew, the basic idea, and he could help us weed out any ideas that were either to easy or to difficult to make.
BM #2 was an in depth description for how we wanted our game to work, and what we expected our probability analysis to be. This was important because, without an outline, making a video game can become really complicated really quickly. By thinking about the systems beforehand, we can make things a lot easier in the long run. Thinking of our probability analysis was also important, so that we would remember that that portion of the game should not be removed (you can't do probability analysis on something that doesn't have chance involved).
BM #3 an even more in depth review of exactly how we wanted things to be coded. We listed the variables and classes we needed, and what all of them should do. If we weren't sure how to do something, we made sure it was possible to do, etc. This was crucial, because it meant nailing down exactly how the game would be played, and squashing a lot of bugs before they even occurred.
BM #4 was the actual probability analysis of our game. Because this project was about probability, this was essentially what all the other steps we did were leading up to. I've posted my BM #4 below, if you want to see what I did.
BM #5 was programming the game itself. Aside from BM #4, it's probably the most important. Luckily, if you did all the previous benchmarks (which I did), and have some basic knowledge of programming (which I do), this benchmark was actually pretty straight forwards. The only real challenge was bug-fixing, and fortunately most of my bugs were small graphical errors.
Our final BM is what you are reading right now: the DP update. Without it, none of the cool stuff I made would ever be seen by anyone.
Video Game
|
For this part, while we were assigned to make the games in Starlogo Nova, I decided to make mine in unity as I already had experience with it. I actually made two video games. One was more focused on probability, and the other was just for fun. The probability game was based off an idea my brother had. It was a 4-player game where each player took control of an adventurer racing to complete dungeons before the others. Completing a dungeon was based on RNG, but you could raise your odds by collecting equipment. The main conflict was deciding whether to spend time collecting enough equipment to give yourself a near 100% chance, or to try your luck as soon as possible. Use WASD to move.
|
The second game was an expansion of Bowling Simulator 2017, an online multiplayer game I had made a while ago, but which didn't have a single player mode. The game already had a planet hopping gravity system (pretty cool if I do say so myself), so I decided to take advantage of the code I already had and made the enemies giant spaceships. To destroy the spaceships, you had to land on the like a planet, and run around to hit their back, all the while dodging fire from other spaceships. The randomness element was the enemy AI. They would stay in one spot for a while (to give you a chance to land on them), but would occasionally pick a random spot in the world and fly there. This turned out to be really useful when doing the second part of the project. Use WASD to move, P to stop momentum, Mouse1 to shoot and Mouse2 to switch planets.
|
|
Part 2: Probability Analysis
I decided to do my probability analysis on Bowling Simulator, simply because there was a probability dealing with that game that I thought would be useful to know. There isn't anything in the code telling the spaceships not to fly into planets; it's not game-breaking, but it's worth knowing how often it will happen. Specifically, spaceships are rendered useless if their cores are inside planets (as they can no longer shoot) so I wanted to know the chances of that happening at least once in a 10 min play session.
My result was that such a bug would only show itself about half the time, which I've concluded isn't often enough to warrant the time to fix it.
Reflection
I think I was very successful this project, not only compared to my other school projects, but also to my other programming projects. The main reason for this was that I made a goal for myself to stay organized. The benchmarks helped a lot with this, and it caused my code to look a lot more deliberate and concise. Overall, It sped up my process, and allowed me to add other things, Like sword animations or multiple enemy spaceships. However, there's always room for improvement, and I wish that I had collaborated with and listened to some one else. While a lot of people teamed up in this project, I decided to stay by myself because I couldn't think of a way two people could work on a project like this at the same time. Turns out, other people weren't trying to do this either, they just wanted another pair of eyes. Having someone there to help me solve problems and think of things to add would've been really useful, so next time I'll defiantly try looking for someone's help. Overall, even though I knew this project was coming even before the year began, and I had high expectations, I think it exceeded the hype.