#or fuck even 3D for software constraints

[evening-rose-309]

In the words of Haversam of Novac,

Smootheskin–

but no, seriously, where is? the wrinkle? the melting sphynx wrinkle? where is the "poorly skinned chicken" vibe? where is the "the old flesh was rend off the bone to make new from under a much hardier carcass to show for the current state of the world"? thing? "we may look dead, but we've yet to let go of life and it won't let us the easy way anyhow" feel? where? is the sex appeal charm???

I mean this with every fiber of my being but whoever was in charge of designing the “ghouls” for the Fallout tv show should be jailed and given a life sentence with no chance of parole

Look at how they massacred my beautiful ghouls! Deadpool looks more ghoulish than him! There isn’t a wrinkle on this mfs body! This is just a man who lost his nose!

The writers are cowards for not giving us gross looking ghouls!

[jakey-beefed-it]

godspeed to all of you who have bought, are buying, or will buy a 3d printer and learn how to use it. to me it just seems like so. much. hassle.

like, would i fucking LOVE to be able to print custom minis for d&d and warhammer and just fucking painting for shits and giggles? hell yes! i’d even probably subscribe to a patreon or two giving me access to monthly themed bundles just for shits and giggles. things like that are super cool! i’d love that!

however, i would NOT love spending several hundred dollars on a machine i do not know how to use, with a steep learning curve to even manage the hardware, much less the complicated software for adding supports and whatnot, and likely wasting like a fucking gallon of resin before i got something even slightly useable. feeling like a big stupid ogre is one of my LEAST favorite feelings, and learning anything entirely new is just about guaranteed to make me feel like that.

so yeah i’m old i’m set in my ways and fear of feeling like a big stupid idiot (and poverty and space constraints) is keeping me from joining the 3d print revolution. but at least i’m not inhaling resin fumes in my own room. that’s something, right? i mean i would be if i could afford to buy big expensive resin models like the ones from forge world, but i can’t afford that either, so for once poverty is PROTECTING me from hazardous materials. whee.

paint fumes, however, remain my constant companion as a mini painter.

[sikegames-blog]

Iteration, iteration, iteration...

************************************************************************************************

         !!! PART 1!!! :D ************************************************************************************************

Hey there, this is Mike. I've been wanting to do a blog post for a while buuut I get distracted and things come up constantly from numerous different sources.

Being a generalist on a game makes things really tough, it's one of the hardest things I've ever had to try and manage in my life. I've invested time into learning to draw, paint, model, (horribly) rig and animate, compose and play music, arrange video clips, design a 3D UI, learn basic physics, learn basic linear algebra and programming, the scripting kind as well as the lower level/messier kind.

I've learned so many different software packages that it drives me nuts how I can't ever become accustomed to any single one any more like I used to. Back in the good ol' days when things were so much simpler being content with just having to improve my drawing and painting ability. I had the luxury of developing a sweet set of custom hotkeys for photoshop that I could just memorize nearly every operation I would ever have to EVER operate, and I would just play with those hotkeys switching them around every few months trying to figure out the perfect combination.

NO LONGER!!!

Sounds like a fantasy land nowadays.It's hard for me to imagine the feeling of how I used to live, practicing one thing over and over and over and over and over and over and over again every day. Ironically I don't really do much drawing any more, but I always remember the fundamental lessons it has taught me, and that is.

You never. get. it. perfect.

ITERATION!!!!!!!!

Key ingredient to anything sweet and savory in the games business and most component parts that make up great games. It takes time, oof, it takes effort, owieee, and most of all it takes persistence!

So, what is this post really about? Well let's talk about it.

Part 1, we've already completed, I wanted to create a little intro about myself so I can never talk about it again on here.

Part 2, the meat and potatoes, I want to provide some value to anyone who might do the same stupid things that I did over and over and over when I was initially learning how to program games!

so, on to part 2!!!(... of part 1 of the article series.... don't worry about it)

************************************************************************************************           !!!PART 2!!!D: ************************************************************************************************ This post is primarily geared towards programmers using the Unity game engine. If you are not a programmer, or you are an experienced one, I do not think you will get much out of this post. This is all about me going from a total noob to a somewhat less of a noob. BUT if my assertion is incorrect and you do in fact find something of use, then GREAT, i'd love to hear about it.

So, what do I mean about iteration anyways?

Such a broad topic, applies to everything, so lets narrow it down.

The first alpha version of super nut ball I thought I had done a pretty decent job. It wasn't the very first thing I had ever programmed, but it was the first real serious attempt at trying to create a piece of software I could feel proud of. It was fun, I enjoyed it, but towards the end of the first cycle I had felt a bit stressed whenever I had tried to tackle any changes to the codebase. It was a total fucking mess and I was delusional. I really believed I had done something pretty good and it was a very good thing I hadn't shown that code to anyone who I'd wanted to impress!

People played the game, gave a positive reaction in general and I was happy, they were happy. Who cares if the code is messy?! The game is fun!!!

WRONG

This is a horrible way to perceive a project as the developer of it, especially one that has no real deadline. Ideally I would like to think that I always do the best I can and give myself credit for trying to do the right thing and make the best possible decisions given what I know at the time. Buuuuuut, for some reason that's just not how things seem to work. So let's look at some code.

(This is making my skin crawl just as I break open the dusty old windows folders)

Here's the link to a tiny github repository I created for this post:

https://github.com/SGMike/SuperNutBallBlog_01 We're going to be taking a gander at the PlayerController.cs script.

I'll take some code snippets and post them here as well.

Please keep in mind that while the newer one is updated and much improved, this is an honest-open look into the development of our game in it's current raw state. I didn't want to clean it up beforehand to give a false impression of, 'look how great and clean and super tight Mike's code is!, what a jerk!' Unfortunately no, even with a lack of tight deadlines there is still way too much to get perfect and I am constantly iterating on this as I go and hopefully one day it will be perfect!

But if I would have waited until I made this script perfect to create this blog post then this post would have never existed, so I had to just commit myself to finally get to it.

So lets start our journey inside of PlayerController_OLD inside of void FixedUpdate() on line 83. This is the gist of what is going on in there....

if (pressThing) {                                                                                                    if (thing2Happend || thing4IsHappening  && (!thing6MightHappen)) {             moving = false;                                                                                                 flying = true;                                                                                                  }                                                                                                                            else if (thing5HasYetToHappen) {                                                                           DoThing32();                                                                                                     turnOffMe = false;                                                                                         if (otherSuperFunThing == !true && playerStunned) {                                              moving = true;                                                                                                  flying = false;                                                                                             }                                                                                                                             CountDownTimer66();                                                                                              }             }

JESUS CHRIST. What kind of squirrel crack was I smoking when I wrote that. I honestly have no idea, it's pretty horrible and a perfect example of what no developer should ever EVER EVER do. It saddens me to still see, to this day, some of my fellow classmates create code that looks similar to this and even worse in some cases.

I would like to think that this is a typical programmer noob mistake so that I am not alone, I feel like I have seen it quite a few times and that is:

Failing to understand the concept of encapsulation. IE. sticking freaking everything into Update.

If you ever can help it, at any place possible, abstract code that is related to one single task into a single function. Ideally the function called Attack() contains every piece of logic necessary to carry out an attack. Now, realistically this is just not feasible, functions are very limited on their own, but utilized in combination with classes they can be extremely powerful and flexible. We will get to that later though, back on topic.

Digging through my memory I believe that I ended up with this because when I had started to create the game I had placed a few items inside of update, you know, general stuff when starting out like. When I press left, move left, when I press right, move right. It's just 4 if statements right? What's so bad about that? I hear this kind of thinking CONSTANTLY it's bad bad bad.

Get in the habit of doing the right thing, even if you think a change will be really quick

If you're more experienced writing code, then this is obvious when it's okay to futz around and do some quick stuff. But in almost every situation, I end up having to rewrite the crap code I put down because I soon get excited at the possibilities and start to chip away again at this growing tangled hairball of logic.

Looking at both scripts, you might notice that in the new version I managed to encapsulate the logic to the point where I do not even need an Update() function. This is me striving for a more event-based approach to the design. Most game logic is event based. You have on key pressed, on key removed, on player stunned, on player jumped, on player landed. You can really break everything down to simple to understand events, everything else is simply a simulation.

I do have a few things inside of FixedUpdate for slightly more efficient updating.

//  Update Particles  // UpdateParticles();

//  Update Movement  // MoveHorizontal(m_controlAxes.x);

//  Update Recently Stunned Timer  // UpdateRecentlyStunnedTimer();

Looking at it now, I probably don't even need the last function in there. I'm sure there was some constraint that led me to use FixedUpdate() instead of a coroutine, which in simple cases is often the right choice for handling timers.

Earlier this year I did a near complete refactor of the entire game, because the game overall is pretty small this took about a week of not doing much else other than rewriting the game. The resulting code is what you see here. Overall things are far more encapsulated, clean, super simple to understand, and the total amount of code is less than it was before(Not in this particular script however). There are a lot of changes and things I'd love to talk about in depth but I am already going much farther than I had originally planned which is why I have broken this post into multiple parts. I'll probably find some images to spice up the article as well.

The code from before was a massive pain to work with, I would literally get anxiety when I would think about making changes to it and feel my heartrate increase. Not a great way to have fun creating a game designed to be fun. Now, the code is awesome, I love working in it because it's so simple and straightforward and iteration is lightning fast compared to how it used to be.

If Sophie tells me something like, You shouldn't be able to dash when you're holding the nut, literally all I have to do is go to this script,

hit Ctrl+F,

type 'dash(' and I am immediately there.

I add a piece of code that says

if (m_nutGrabber.IsHoldingNut())     return;

FREAKING AMAZING!!!

Just take a look at FixedUpdate() from the old script and imagine how much of a huuuuge pain it was trying to sort through that mess, can you imagine why I used to get anxiety from it!?

Now this is all well and good but, what is going on outside of this script?!?! Surely there is an Update() call SOMEWHERE, otherwise how am I getting input?

And you are absolutely correct, the big major difference is that ALL of the update logic is handled in one encapsulated script I have called InputController which handles all of the logic for the player whether that is through a controller or mouse/keyboard. It is important to note that while yes, this does take more setup up front, but once it is set up, you have a nice system in place for handling these things and it makes further iteration a breeze.

Now let's say you actually want to write some test code, just throw it into a private function and call that function from Update. This way you'll get the same instant gratification from doing quick and messy test code but you'll still retain the ability to quickly sort through the test code and the code you still want to actually keep working from before. The danger here is that you end up writing a second private function called from within the first and you start to build up this heap of private functions. If you ever find yourself starting to follow this pattern it means that what you're doing is probably going to actually be implemented to some kind of significant degree and is no longer test code. If this is the case, then it should be designed and encapsulated properly. In this situation I would remove that function call from Update() and stick it into InputController's Update(). Simple, it only took a few seconds and it maintains a consistent and clean architecture that we've built up. Take the time to do things right, you will almost always be thankful you did later. This is especially true when programming a game in pure C++.

Unity shields people from a lot of the real messy work that is involved when rolling your own tech and having to deal with software architecture. They provide a framework with these nice functions like OnTriggerEntered(), Awake(), Update() and FixedUpdate(). Functions like Start() and Awake() in particular can be really nasty traps awaiting nooby programmers who don't plan ahead. Unity also utilizes C# which has Delegates and Events built into the language, as well as garbage collection built into the VM. These tools are massive boons that free you as the developer from having to worry about hardcore and messy architecture design that is undoubtedly contained within Unity's engine code. These things are great but this convenience comes at a cost, and that cost is missing out on understanding how to properly structure code, which can be an extremely difficult skill to cultivate.

The ability to architect a good solid codebase is a fundamental skill of computer science and one that you can refine for the entirety of your lifetime. The issues related to good architecture are extremely difficult to solve, the best option is almost always unclear and fundamentally difficult to figure out because the best solutions are those that are contextual. In almost every single situation you do not know beforehand the best architecture because you haven't attempted to build it yet. It's after you have failed that you realize what the proper approach should have been, and even then it's not always clear.

Well, it's nearly 4AM again and I've been writing for a while, in the future I'm planning on creating more posts that go further in depth on these kinds of topics. I've barely scratched the surface of what I really wanted to talk about and I want to get to some more theory on what I believe makes for a good architecture. This will include a discussion on the kinds of issues that have cropped up while working on Super Nut Ball and how the game's components are architected and composed.

If you made it this far thanks for reading, I hope you got something out of this first messy post and drop us a line to let you know you exist!

-Mike