The code for the second game (more of an interactive novel) I made from scratch consisted mostly of a nightmare chain of eighty-something if statements. Let that sink in. Obviously I considered every method I could conceive of to not do that, but with the start of production bearing down on me, I conceded to the ugly solution (in my defense, it did work). I have, however, learned some things about efficiency: code reuse. It doesn't usually refer to copy-pasting bits of code, though I've done that too. Take one of the most recent tutorials I've worked on as an example: there were three types of enemies, with different health, attack damage, and score values, but they all did basically the same thing. Now, it would have been perfectly possible to make all three different objects in the code, but considering their similar functionality, that would have been, frankly, stupid (I say, remembering the time I did exactly that on a project from last year). Instead, make a single enemy object in all the scripts, and make three copies of the enemy manager script with different models and values set in the inspector, as they all use the same functions. Another way to do this is with classes. If they use a lot of the same functions and variables, make a class and have the objects inherit from that. Essentially, if you can use a larger template to manage smaller assets, you should. Another way to reuse code is to create function calls. I could have made a scene transition function and called it several times during my many if statements in that one notorious project instead of rewriting the code to enable and disable the necessary objects every time. Creating a new function allows you to edit the details in one place instead of, say, twenty, or fifty, or a few thousand. There are also Dynamic Link Libraries, which I am not familiar with, but the gist of it is a set of already written programs to make your life easier. I hope to look into this in the future. Of course, I said this wasn't about copy-pasting, but I will admit to looking back over old projects to see how to get a camera to pan properly or a background to scroll. No sense in figuring things out over and over when I can quickly jog my memory looking at how I've already done it. So, to summarize:
Citations:
Zeeshan, Ahmad. “What Code Reuse Is and Why We Use It.” C# Corner, C# Corner, 28 Mar. 2015, www.c-sharpcorner.com/UploadFile/201fc1/what-is-code-reuse-and-why-we-use-it/.
0 Comments
This was my was one of my first handheld games (I think it was the first), and for some reason I decided to dig it out again after a couple years of not touching it. The basic premise of the game is to take care of a variety of fantasy pets. This is done via three minigames, one for feeding, one for play, one for grooming. A fourth mini game (known as the "magic world"), unlocked when all needs are filled, allows the player to unlock new pets if they score high enough. It's either one of two types of obstacle course or one of two types of "bullet storm" games, depending on the pet's "element" (there are four). The feeding minigame requires the player to color in as much of the food item as possible in the time limit, with a time penalty for drawing outside the lines. The grooming minigame requires the player to spray the pet with a hose (or similar) while they run around, jumping in what are apparently interdimensional portals in an attempt to hide. The playing minigame has the pet transforming into essentially a living basketball hoop (I was somewhat alarmed the first time this happened) as the player attempts to throw the toy into them with the stylus. No explanation is given for why any of this works the way it does. The minigames (at least the play one and the magic world) get harder the higher on the progress tree your pet is. I'm not usually much of a minigame person myself, but for some reason I enjoy these. I think they require just enough effort to keep me interested. More about progressing: the player starts with a choice between two eggs, which will hatch the first creature. Completing the magic world game unlocks two more eggs. This is organized on a chart similar to an outcome tree. The end goal is presumably to hatch all the eggs and unlock all the pets. It makes sense, but despite incentives to stay on a single pet for a while such as discovering a pet's "favorites" (toys, food, etc), it can be tempting to just race through the tree–and it gets pretty easy to do so after you've practiced. The pet care minigames do get dull after a while. The aesthetic design of the game is very good in my opinion. The graphics are decent, but what it lacks in shiny hyperrealism it makes up for in creativity. The eggs are cool looking (a must if you want the player to be eager about hatching them), and the pet designs are charming and unusual. There are a few recognizable creatures–dragons, flying horses–but most of them are just weird fuzzy animals. My first pet was a lion with wings. Not a griffin, a lion. With feathered wings. At any rate, they're cute. They come in four varieties, presumably "elements" (though it's never stated directly). These appear to be sky, fire, water, and earth, but of course this is never explained either. This mainly affects the type of magic world minigame they play and their appearance as a living basketball hoop. I have not noticed any correlation between element and favorite items. The obstacle course magic world games are definitely better looking than the bullet storm games, if only because of the fantastical 3D landscapes. The sound design is good but nothing extraordinary. Overall, the game is fun for a while, but it can be very tempting to just rush through, as it gets repetitive. It's a good way to kill time, and considering the way most real-time mobile games are played, I think it serves its purpose. So, to summarize:
We've been working in 3D games for some time now. Time to reflect on that. One of the immediate things I've noticed is that 3D is the default, which means a lot of things are easy to manage because I don't have to go looking for the 2D version, or making special accommodations to let the 2D physics work. It seems pretty clear to be that Unity is really meant for 3D. Of course, I do have to take another axis in to account, but it's not nearly as big of a deal as I had expected. Another thing I noticed immediately was the difference in how the game environment is set up. Three dimensions make it easier to lose objects (though you'd be surprised how easily I've done that with only two), and there are things like skyboxes and different camera angles to worry about. One perk of 2D is that it's generally easy to keep everything on/off screen as needed and not accidentally show the viewer the vast and terrifying expanse of the rest of the scene. That was a point of particular irritation for me when working on the Survival Shooter tutorial, as getting too close to the edge of the screen would reveal a bright blue and white horizon, which did not at all fit in with the aesthetic of the game, nor did it make any kind of sense, and in my opinion distracted from the experience. Unfortunately I never got the chance to see if I could turn it to something more fitting, like a dark purple void. Something I noticed further along was that when you take away sprites and start dealing with 3D objects, things get a lot of complicated. I didn't know what a nav mesh agent was last year. I knew what a 3D material was but never realized Unity used them. Lighting and sound are more affected by the environment. It unlocks a lot more potential (unless I'm underestimating the power of 2D), but it's a lot more to keep track of. With great power comes great complexity...and great length of component lists. So, to summarize:
|
AuthorI'm moving on to my 4th (and final) year as a Game Art & Design student at Durham School of the Arts. I'd like to call myself an artist, but I'm a programmer at heart. Archives
February 2020
Categories
All
|