Programming And Probability Project
Summary
The overall point of this project was to develop an understanding of probability and randomness to apply in a game that we would then code. Most, including myself, used an online program called StarLogo Nova to easily input probability concepts into a simple programming atmosphere. Was it real coding? No. But the point was to give an idea of how a computer logically interprets commands.
Benchmarks
Benchmark.1Deciding upon concepts for our games, name, goal, expected outcomes, etc.
|
Benchmark.2A detailed description on how the player/s would interact with the game and how probability will be implemented into the game.
|
Benchmark.3Benchmark 3 was a point at which our games had to be completed for the purpose of display during exhibition.
|
Benchmark.4In Benchmark 4, we analyze our games' values to come up with all possible combinations and calculate the chances a certain action would occur.
|
Benchmark.5 |
|
This benchmark was in fact, the completion of this page, describing benchmarks, giving reflections and feedback, as well as outlining my own work.
|
|
Concepts Learned
ProbabilityBefore this project I was aware of probability, but in during this project, we really went into depth at the math behind Probability (Pr[Action|Condition], for example), and learned about different ways to interpret data.
|
Programming Logic I can't say programming is new to me, as I've used Arduino, HTML, etc in my projects before, but this project was a good time to get some experience using some of the new tools SLN provided, especially those of which that encompassed new math concepts.
|
Executing Benchmarks 1-5
Benchmarks 1-2 were quite simple to do, as there was no wrong answer, but the difficulty that lied in them was that our game had to follow those principles we laid out. The overall game theme was a top-down space/air shooter. I laid out a procedural-type of game where enemy locations and skill varied randomly. In between Benchmarks 2 and 3, I developed the actual game on SLN. One of the most prudent difficulties I had was the simulation of a beam weapon. For some background, I really like Star Trek, and in the light of STO support being cancelled on Mac, I tried to create a sudo space shooter. To match my Star Trek theme, I needed to develop some phasers. SLN is based off of a Turtle System, meaning almost all actions are executed by a visible entity. At first, I tried to create a chain of orange "bullet" entities, whose edges would be blended together by each-other. Problems with this system included extreme lag by the sudden creation of 100 turtles, and the effect created was more similar to a flame thrower than a laser, in conjunction, these two struck out this idea. The second idea was to create 2 entities "bullet" and "cleanup", and instruct "bullet" to move x paces forward, all the while "painting" the ground orange. "Cleanup" would be created at the same time as "bullet" but would wait 2 seconds and erase the paint mark made by "bullet". Problems with this system were that the entities were 3D, forcing the viewer to see grey and orange spheres move across the screen, there was no way to limit the shots time-wise, allowing the player to spontaneously create a new beam every game tick, and the player could still move during the period of shooting, leaving the possibility of shooting and moving away from the source of the shot, creating an odd visual. I ended up scrapping the beam function and stuck to cannon-like projectile..
Reflection
I think the project went well for myself, aside from the beam fiasco, resulting in a product worthy of exhibiting (at least for the time frame). As far as time utilization, I didn't know how to use SLN at the beginning of the project, so I made sure to utilize the time given, and at home, to complete this game, 100%. The thing I'm most proud of would be the randomness employed by my entities that really made the game more difficult, and the added function of a selected difficulties. With programming, it's very important to Be Systematic because programming is famously known for going wrong somewhere. Whenever something didn't work, you had to be very careful of what you change and to take note of that change. In addition to being systematic, it was important to Be Organized and staying that way. Similar to the last point, losing track of a single variable and how it interacts with your system can be the make or break factor in your game. Another skill that is very important in the development of programs is the ability to Conjecture and Test. Without this skill/habit, it would be impossible to perfect your program via other methods. Branching out and exploring new ways is integral whether you are coding or otherwise.