Top Menu


In this week’s episode I start off by apologizing for this not being a weekly podcast. Oops. But then I quickly(ish) get into my progress with Unity, with C#, an update on my newest game project, and I even have time to talk a bit about what a game engine is (see, the title of this episode isn’t just a trick).

Subscribe via RSS or iTunes.

Highlights:

  • I’ve finished the C# Fundamentals for Absolute Beginners course!
  • I just finished lecture 80 in the Learn to Code by Making Games Unity course on Udemy!
  • The importance of a game design document
  • What is a Game Engine?
  • My game dev roadmap

Mentionables:

Music credit: “Rhinoceros” Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 http://creativecommons.org/licenses/by/3.0/

3 Comments

  1. Hey man, sorry I didn’t comment on this one before. I did listen when you first posted but ‘got busy’ and was sort of waiting for your next episode to add some more thoughts. So, just checking in and I hope you are still on your learning journey!

    I am still on Block Breaker, though very close to the end. I really took my time with it, partially because it’s the most complex thing we’ve done so far and they introduced a lot of stuff that I ‘sort of’ got, but not really, and I always meant to go back and do deep dives on at the end of the module. Partially I also inadvertently introduced bad code into the game when I occasionally tried to get fancy and customize some things. And, lastly, because I got a little burned out so had to occasionally step away.

    In addition to doing this Unity stuff after work every day, I also got back into playing guitar in a serious way – by which I mean, I went back to it after years of not playing, and now I am focusing on very dry technical exercises to develop proper technique, as opposed to just playing something that sounds ok to the uninitiated but is very mediocre.

    Why is this relevant? Well, I feel like a lot of things I have been working on in my spare time have been latent interests that I never bothered to explore in a deep way and even though I typically only play guitar for 30 mins a day during the week, I feel like that practice time has become sort of a holistic self-improvement project that touches other areas of my life. I often don’t feel like playing. But once I force myself, within 5 mins I am feeling ok, and usually by the time the 30 mins are up (which is super fast) I am SO glad I did it, and I am really seeing my technique improve, almost daily. This theme of consistently showing up for something is really a big part of my life at the moment, and I think the idea is applicable across all areas of life. Giving attention to things really helps you accomplish so much, and it;’s a virtuous cycle where by getting better at something, you feel better about that thing and enjoy it more, which motivates you even more. So, it’s not about being perfect, or being the best, but there’s something about just ‘showing up’ for whatever it is you are tackling that is both very intimidating (like when you are coming home burned out from the office and and playing guitar for 30 mins feels very threatening in a deep way because you just want to turn off your brain) and very liberating, because you’re making a commitment to something beyond your rollercoaster emotions and whims. I don’t know if I explained it right, or perhaps over-explained it, but that’s been on my mind a lot. I feel like the Unity stuff has bee nthat way too.

    Again, it’s not about being perfect and never missing a day, but being as consistent as you can be without obsessing, being like the tortoise, is really powerful emotionally and psychologically. I guess that’s what builds confidence; the feeling that if you just keep doing a little bit every day, you’re gonna get there.

    Obviously I am bringing this up because the Unity journey at times has burned me out, yet I keep coming back to it because there’s things I’d like to do creatively, that knowing the tool would allow me to do. Express creative ideas, immerse myself in worlds, communicate to people some theme or picture or feeling through a game.

    Getting back to the technical stuff, I am on Lecture 88 and my game is starting to feel like a real game, but I am still not satisfied because I don’t feel like I could recreate it from scratch on my own. Probably the outlines, the menu system, etc. But I really want to go back in select Lectures and dive deep into the fuzzy concepts I still haven’t grokked. I did go through about a quarter of the C# fundamentals course, though I eventually felt like I got a few basic things I needed and decided to go back to the regular Unity course.

    Last night I was looking at the manual online and trying to figure out more about the relationship between objects, components, and scripts, and how those relate to classes. Actually one little insight I had is that (I think) all components ARE scripts. It’s just that many components are pre-made by Unity and others have to be added. I made some headway, but I’m still looking for a sort of ‘unified field’ theory of all the entities we deal with in the Editor and in MonoDevelop.

    Another thing I was trying to understand is why they use a Level Manager object to load levels, as opposed to just putting a script against the Button object, for example. In general, that whole connection between the Editor and the code such as between the Button and the Level Manager script is still hazy to me. I understand what it’s doing – it’s associating the Button OnClick () function (the code for which lives somewhere in the background of Unity and all we see is the Editor version of it) with the Level Manager object in the hierarchy, and it’s then grabbing the LoadLevel function from the LevelManager script to pass the Level name. It;’s the layering of functions within functions within objects and the fact that some of those things are visible to us in MonoDevelop and others aren’t, that drives me a little berserk. So that’s why I was looking through the architecture in the manual to try to figure out how something as simple as Debug.Log works, where the Debug.Log function comes from, and where Debug, the class itself, comes from… It’s really like going down a rabbit hole!

    Well, long story short, hope you are continuing with your learning. Maybe you are on to Zombie Runner at this point?! If not, hope you stay motivated and keep us up to date on your journey!

    Cheers!

  2. Don’t apologize at all! I appreciate any time you give, no matter when or how much. I’m still plugging away (I know, it’s been too long since the last episode). I’ve been getting back into actually playing games lately. I haven’t played video games in a while, so I thought it would make sense to re-approach them knowing what (little) I know now about making them. The goal–which seems so far to actually make sense–is that I would be able to recognize the organization behind a game as I play it. Plus, it’s an excuse to play. What I’m learning is that so much of coding seems to really just be very elaborate ways of creating if/else statements. Honestly, it seems absolutely everything can distilled down to triggers and colliders which then can be covered. Not sure that makes sense, but it seems to make sense to me (if, of course, it’s even correct). I know that not everything is literally an if/else statement, but that simple idea of yes/no, on/off really makes sense to me.

    Getting back to the technical stuff, I am on Lecture 88 and my game is starting to feel like a real game, but I am still not satisfied because I don’t feel like I could recreate it from scratch on my own.

    I feared this too, but then after talking with some developers I work with, it turns out that most developers couldn’t build things from scratch. Being a developer is in many ways just being really good at filing away and organizing references. These developers are probably in the Stack Overflow forums about the same amount of time they are actually coding. It takes some of the pressure off knowing that.

    Last night I was looking at the manual online and trying to figure out more about the relationship between objects, components, and scripts, and how those relate to classes. Actually one little insight I had is that (I think) all components ARE scripts. It’s just that many components are pre-made by Unity and others have to be added. I made some headway, but I’m still looking for a sort of ‘unified field’ theory of all the entities we deal with in the Editor and in MonoDevelop.

    I know EXACTLY what you mean. Yes. I’m actually planning to create my next episode around this. When building the Block Breaker game something clicked for me. I finally began to understand how scripts work together. Coming from an SEO background, I’ve always stressed that my developers use as little code as possible. Less code = faster loading (a general statement, I know). Therefore, when taking the Unity course I was so averse to creating new scripts every time I wanted to do something seemingly simple. I thought “why can’t I just bundle all of these functions into a single script? Wouldn’t that be much cleaner and easier? Well, I’m learning that it’s okay to have many scripts. I’m getting comfortable with the idea. This shows, I think, with my block breaker game which is definitely the most off-tutorial (ie, I did a lot of things beyond what the tutorial instructed) making for a game development process that taught me so much. You can check out the game here if you’d like: http://www.calebjross.com/game-dev/games-and-prototypes/

    Another thing I was trying to understand is why they use a Level Manager object to load levels, as opposed to just putting a script against the Button object, for example. In general, that whole connection between the Editor and the code such as between the Button and the Level Manager script is still hazy to me.

    This is still confusing to me, too. I began to think of game objects (at least the empty ones) simply as a tiered folder structure like you’d see with any computer operating system. This helped me see them not as some mysterious entity, but as a simple organization structure. So specifically about the Level Manager, I think they were “future proofing” the game. They knew there could be other elements to associate with levels (maybe sound effects as levels load, for example), so they created a game object to “house” the script to keep things organized. I’m not sure though. That might be a great question for the forums.

  3. Hey, the game looks great! Like the low-fi retro feel. Also, the colliders on the sides of the game screen to create additional bounces were a good idea. I’ve definitely run into some boring gameplay in my demo, even when I adjusted the velocity. Also, thanks for the ideas on the game objects. I’m gonna give it a try to think about it that way.

Comments are closed.

Close