As a class, we are nearing the finish line of our educational game PBM assessments. Everyone has turned in the current state of their game and we are now in the stage of creating a second, updated, iteration based on peer feedback and suggestions. Although, admittedly, mine as more of a placeholder than anything and isn't a project I am proud of, at least it is working. I consider that a win over Unity. My game, as it was, had many problematic areas that were not "turn-in" ready. For example I still hadn't solved the issue with my respawn/teleport-upon-death script and my player controller was a bit clunky to move around with. The colors being spherical also surfaced some problems with traversing across the parkour aspect of the game, which was more difficult than if I'd used a polygonal shape. I have worked through some of the issues and revamped a lot of the major aspects of my game. For starters, a simple but effective change I made was to use a top-down camera perspective from a locked birds eye view. This helps the player move along and see the colors far more intuitively than using first person controls which wasn't very compatible with my game concept. Another one of those changes, which took significantly more time, was completely redesigning the color shapes to be squares and then re-applying all the materials and rigidbody components. I also decided to make the spacing between them a bit less difficult, to keep the focal point on color learning. Lastly, and most importantly, is that I was finally able to get a working respawn script. I had to sift through the comments on various youtube videos illustrating how to create a respawn until I finally found the bug. It made me want to laugh, while also cursing out the *people* who designed the Unity Game Engine. It all came down to a little unnoticeable and super specific setting under the engine physics system which required me to enable some sort of syncing. It didn't really make sense but it worked! I also had to apply the respawn point I created and the player object to the "Death" plane that I made, which is transparent and encompasses the bottom half of the map, so that a respawn is triggered when the player collides with it. In a nutshell:
0 Comments
Following my previous post about plotting out a manageable game concept, and how that was going to be the most conducive to my success, I have begun implementing parts of my idea in Unity. Above is a progress photo of me arranging the color sphere platforms, which has been monotonous and aggravating, but most of all it has been remarkably boring. I have had to make micro-adjustements while aligning every color sphere to be an appropriate distance away from the next so that the player can reasonably jump between them. I also created a rudimentary player movement script which allows the player to move with simple WASD/arrow commands and the space bar. Through this script, I also have more control over the players' physics, specifically a menu of their speed, jump force, and gravity which I can numerically adjust. I applied rigid bodies to various spheres along the "correct path" so that the player doesn't fall through when choosing the correct orb. By the same logic, I did not add rigidbody components to the incorrect ones so that the player can't continue forward and will fall to their death. However, in its current state, the player isn't forcefully respawned in the same instance of the game; it requires the player to refresh the play page to try again at the level. This is a problem and I am working on fixing it by creating a simple on-trigger respawn script with an invisible death platform that initiates the respawn to a designated respawn point. However, despite my following of youtube tutorials step-by-step I have had difficulties getting my script to work. Overall, I have made strong headway creating my game, but I am still working on designing a second level as well as implementing a respawn into my game which is essential for the proper functionality. I was able to align the colors by tediously adjusting their location, and I assigned specific RGB values by using an online picker tool and transcribing those values directly in the albedo of custom materials by inputting the numerical R, G, and B coordinates. In conclusion:
To start, I will be utterly candid; getting reacclimated into Unity Game Engine has been a pain. So much of the focus revolves around planning to circumvent issues rather than solving them head on. This is because when Unity presents problems, it can be devastating and will suck away all hope like a dark spiraling vortex. That single problem could be arising from a plethora of different sources and it might be nearly impossible for an amateur to diagnose, yet would halt the entire game. Essentially, it all comes down to the concept that I apply to my game and how I strategize about avoiding potential complications. Planning for a large task and executing it are two opposite ends of the spectrum, with the difference between them further aggravated by the clunky utility that is Unity Engine. Creating a game is - without a doubt- very nuanced and requires a lot of thought from the designer. Ideally, the creativity would come as the forefront of creating something new and creating it would be without any huge knowledge or experience barriers. However, that is not the case; there is a large and deterring disparity between the opportunity of a developer that knows the ins-and-outs of Unity from years of experience versus someone trying to take it all on at once. Because of my limited experience, it is important how carefully and holistically I approach conceptualizing my game and translating that into a smooth extension of gameplay. As of right now, I have decided to do a color meshing educational game, similar to games such as Little Alchemy and an online color picking tool I played around with, which are relatively simple, but feel more like clicking rather than the player actually engaging and instilling knowledge from trial and error. Combining parkour-like gameplay with overarching color puzzles that teach a new perspective of viewing colors, color theory, and blending, creates a far more immersive and educational experience. Also, colors are simple and by doing my format of gameplay, it will be limited on coding and compiling; I can avoid a heavy amount of scripting by using object components and various controllers ingrained into the native unity assets. For example I plan to take advantage of rigidbodies rather than create a complex respawn mechanism, so the player simply falls through when they jump to the wrong color. Conclusion statements:
My game idea is for the player to navigate through three different levels which are essentially in an "Obby" format and involve jumping or moving between obstacles. The player will begin by jumping clouds which will be spaced apart to where the player will have to time their launch/release perfectly. The jumps will get harder and harder as the player progresses through this stage. They will then be at the top of a mountain/volcano. Their next steps will be to jump across the ledges inside of it in order to make it across without falling into lava. They will then make their way down the other side to reach an underground facility or "evil layer" which will involve various obstacles in the dark. Their final goal is to reach a "Lift" at the end of the facility and then surface back onto land, having gotten across the volcano. The players controls will be limited to basic movements (left, right, forward, etc) and jumping.
My design is meant to traverse multiple environments rather seamlessly, with some whimsical and fun aspects. I felt like a volcano would be a good parkour environment and a neat centric obstacle. Overall, I'm pretty happy with my level concepts and ready to bring it to fruition! Although in the past I have delved into some ideas and aspirations of what I might want to pursue in the future- especially in the game design industry whether it was as a writer, concept artist, or character artist- I had not yet been fully been versed in, or introduced, to another potential option; programming. At first it seemed appealing to be able to lay the groundwork for a game and truly give it functionality, as well as explore a field that would challenge me intellectually. However after learning some of the fundaments of C# in Unity Learn, I have learned that programming often comes down to memorization, using and compiling resources, constant experimentation/testing, and spending hours just trying to identify and fix a single issue - leaving you despondent and mostly agitated for not seeing the issue sooner. Or at least that's how it was for me. I can not say that I truly understood much of what I was doing and it was much more enticing to precede with superficial knowledge and mostly work off of what other people already had done rather than waste hours doing it completely on my own even with full comprehension. I would rather be creating something original and creative, rather than using/working off of what other people with way more experience or smarts have already done. I also did not feel the "reward" aspect of completing a code as much as I had hoped or envisioned, but rather it felt like a super long and demoralizing process that I did not understand full or do completely on my own. After this experience, I think I can cross programming off of my list of careers that I would like to further explore and endeavor upon. Main emphasis:
|
AuthorMy name is Quinn Peterson! I will be reflecting about my art work in this blog! Archives
May 2022
Categories
All
|