Blog

It’s interesting when you’re working as a programmer / designer on a video game as opposed to looking in from the outside, because so many things are kind of intrinsically viewed from a different perspective. For instance, the decision to make floating water in a game (IE water that has its own gravity and just floats up there above the ground) might seem kind of weird, or creative, or *insert something else here* to an outsider. But see, that perspective carries with it the assumption that it was an active decision to make floating water, and in my case I certainly never actively made a decision to make it… it’s just kind of easiest for me to program most of my environmental pieces to not have any gravity and then place them wherever I feel like it. So the way my stuff works, the only way to NOT have floating water is to place it right on top of land. And of course while I’m placing stuff I’m just dragging and dropping it into the screen quick before positioning it, so even if my original plan was to have water work in traditional ways, there would still be that brief moment where it would be sitting there on my screen floating and I’d be like hmm… why not? Not that I’ve necessarily made the decision to have floating water in the final version of the game. But it’s there if I want it.

Speaking of environmental fluids, I’ve been thinking a lot about how to define them in my game. For instance, I now have water, quicksand, and lava created. From a programming perspective they’re all very similar and essentially running off of the same code with the only differences being the visual side (which is all placeholder junk I made) and a handful of variables used to create their distinct features. But there are a variety of directions one can go with these. For instance, in the 2D Mario games you can swim in water, but in the 2D Mega Man games you cannot… although it does slow you down and let you jump higher. In most games you can jam the jump button to jump yourself out of quicksand… but upon reflection, how much sense does that even make? I mean, what are you standing on to jump off of? It’s a convention, and one that I’ll probably stick with, but it’s worth questioning. As for lava, generally in games it slows you down like water does but also drains your health. A part of me wonders if that is enough though. Shouldn’t falling into freaking LAVA be a much bigger deal? What more would I add though? I don’t want to do insta-kills. Even more restricted movement? And if my character can swim in water, should they be able to swim in lava or not?! Hmm.

It’s easy to not think about the hundreds of tiny little decisions that go into every game. There isn’t always one obvious answer, and even when there is, it’s worth looking in a few other directions first before you settle on it.

Anyway, it’s been awhile but things are still coming along pretty well. Our favorite artist Infinitywave has created an early character design / run animation that is looking pretty sweet. We’ll probably hold off a bit on showing off art though, want to get some more done first.

Every time I try it just turns itself into a full-blown song.

Trying to decide what to name the variables that would represent both quicksand and waterspouts… as well as anything else that can push you up or pull you down at a defined rate. “thiscanpushyouuporpullyoudown” wasn’t quite going to cut it. It might not seem like a huge deal, but picking the right variable names can save a lot of headaches in the future. Nothing is more annoying than looking through old code and going “wait, WTF does this even do?!” I suppose I could comment my code better. HA HA HA HA YEAH RIGHT.

Anyhow, things are still coming along nicely. Sometimes I even get stuff working too fast, and then I have to scramble to come up with something else to work on to fill the rest of my planned working time. Not a bad problem to have, I suppose. Beats the alternative.

Probably will be about time to start making a concept stage or two soon. I have enough “stuff” working now, but I still need to get a better sense of the bigger picture…

Well, strictly speaking the soundtrack is probably not the most important part of a video game, but in some ways it feels like it is to me. I’ve been writing music for years, and to be totally honest, a huge part of why I decided to make my own game was to have a place to put my music. Alone, my music is nice and all, but it just sort of… exists. As the soundtrack to a game though, it feels like something bigger to me. And making music and gameplay work together is a pretty exciting challenge.

Writing for a video game requires me to do something that I pretty much never did with my music in the past, which is to actually have some kind of idea of what type of song I’m going to make before I start making it. In the past it never really mattered what kind of song I made next, a song is a song, it can be whatever. But when you have a specific part of a game that you want to create a specific mood for, you need to approach your song-writing differently.

Of course, I still fall into old habits. A few nights ago I decided to create a simple and quick “title screen” song. In my mind this song would be about 30 seconds long, because that’s more than enough for a title screen, right? Well, here I am a few days later, and the “title screen” song is over 2 and a half minutes and growing, because gosh darnit how do you control what happens with a song? Songs have a voice of their own, and when they’re screaming for you to take them in a certain direction, sometimes all that you can do is hold on for the ride and see where it goes. I’m going to have to reel it in sometimes with the lengths on these songs. When I used to be in bands my average song length was probably a good 5-7 minutes. But to write songs that long is rather pointless for a 2D platformer type soundtrack.

I’ve been making some progress on the actual game as well. And running into a few (hopefully temporary?) roadblocks. It’s coming along.

I’m kind of doing two things at once in Unity at the moment… A. Teaching myself the basic mechanics (plus whatever random stuff I come up with) needed to create 2D platformers and B. Teaching myself specific mechanics needed to create specific things that I have in my design document for a very specific game that I want to make. These two things often overlap, but not always.

Yes, I do have a design document. But it’s still fairly barebones, and has a lot of vague ideas in it. My logic at the time of creating it was… why get too specific before I figure out what I’m even capable of? So I came up with a concept that I believe is highly scalable, and decided to focus on getting the most basic version working before adding a bunch of bells and whistles. But, minor pitfalls aside, I’m finding that I’m capable of quite a lot, so now I’m starting to think about the bells and whistles more.

I’m not going to get too deep into my design here yet, I’d rather wait until I have stuff to show… which will probably be soon enough. Soonish enough. But I will say that something at the core of my design is “choice” through, for lack of a better term, “collectibles”, yet I didn’t have the clearest idea of how exactly the collectibles would be worked into the moment to moment gameplay. However, while messing around with “A” above, I stumbled upon something that I thought would be relevant to my “B”, and that kind of instantly opened up a whole new mindset regarding collectibles that feels like it has near-endless potential… as much as my creative mind can come up with, anyway. I still need to work out the details and build a lot of specific mechanics surrounding this approach. But I feel like I’m on the right path now, and my general game concept feels a bit more concrete.

Now that I’m thinking on this path, I’m also realizing how much inspiration I can pull from the Mario games, especially the newer ones and some of the more interesting things that they have done with coin collecting… including one the New Super Mario Bros. Wii / U coin battle mode… such an awesome mode…

Where should I put my blanket to make it work accurately and consistently… Update or FixedUpdate? I have some issues.

Speaking of Update, I’ve been thinking about some of the differences between web programming and video game programming and how I am having to adjust my thinking moving from the former to the latter. One of the biggest ones differences to me is that web programming is, generally speaking, something that you can think about in a relatively linear fashion. At least, the way that I was doing it was. You have the code do X, and then it does Y, and then it does Z. Sure there are loops and this and that, but I rarely had any reason to have two functions running simultaneously. With video game programming, however, you kind of need to have a lot of stuff running simultaneously, and it isn’t always running in the same fashion either. Some stuff might be updating every frame, other stuff might be on a timer, other stuff executes based on context, etc. and all of it may be running at the same time. It’s not overly complicated to the point of confusion or anything, but it is definitely a departure from the way that I have been programming all of these years.

There is another difference too, not related to the code per se but to the interaction with the users. When you program for a website with hundreds of users, there is both immediate gratification and immediate stress involved when you finish a new feature and post it live. I can literally get an idea, execute it, put it live and have a bunch of users giving me feedback on it within the span of a couple of hours. I suppose this would be true in video game programming once you have a final product and are doing updates, but at the moment I’m mostly doing this stuff in a void, so I don’t get that immediate gratification of getting to show everyone what I’ve done and have people use it right away and tell me how awesome is is (lol?) and such. But, as stated above, I also don’t have the constant stress of wondering if the new stuff (or old stuff, for that matter) has bugs and, since it is now live, worrying about having to fix the bugs ASAP so as to keep the end user experience flowing nicely. So I guess there are pros and cons.

“Problem in InvokeRepeating. Apparantly, you can’t set 0 as start time. change it to 0.1f for example and it will work properly.

P.S. Your code is a MESS. Seriously, do not show it to anybody… ever.”

Ha ha, can’t say that I disagree at the moment. Just sort of frantically trying to get stuff working and leaving all kinds of junk all over the place.

So up next on my to do list was to get both a power-up and a hazard working. I figured out the power-up pretty quickly… for the most part. The hazard took a bit more. Specifically, I made a fire which immediately upon entering would start decreasing health at a regular rate (1 unit per second, won’t be the final rate but works for testing) until you exit the fire. Simple enough, in concept, but the OnTriggerEnter2D and OnTriggerExit2D functions were not working *quite* how I thought they would / should work. Specifically OnTriggerEnter2D was triggering multiple times when I entered the fire… I thought it should only be triggering once… and this complicated things a bit. I mostly got it worked out but I feel like it’s kind of questionable code, and it’s not perfect… it still randomly subtracts 3 units of health on entering before going to the regular 1 per second while in the fire. Not sure why. Figuring that out is on my “to do” list, but at least the fire is mostly working as it should be.

I’m still getting some physics interactions that I don’t want with this stuff though, both the power-ups and the hazards are slowing my character down a tad bit / etc. I really don’t want the power-ups to affect my character’s physics at all, they should simply disappear when acquired. And the fire well… IF I decide to make it do something like, for instance, slow down the character a tad bit as he runs through it, I want to control that slowdown rate myself… so I need to figure out where the current physics these objects are placing on my player are coming from so I can scrap them and implement my own at will.

Hmm, what else? I freaked out for a bit when my game started to run uber laggy despite not having much of anything going on yet, worrying that I had a bunch of inefficient code all over, and strictly speaking that was correct. But the inefficiency wasn’t any required code or anything, it was me overusing Debug.Log for testing purposes without realizing how quickly it could destroy performance. I thus learned a very important lesson about not overusing Debug.Log. Removing a bunch of those got everything back in shape fast.

Still, it brought an interesting question to my mind which was… how will I know when performance issues are my code versus my terrible, outdated laptop which sucks to play video games on? I suppose that the more serious I get about game development, the more I will have to really consider buying a brand new computer with decent specs for gaming. Still, I’m making a sprite-based 2D platformer and trying to use minimal physics and all, so hopefully I don’t exceed my current machine’s reach anytime soon.

I was going to get into some theory here but this already ran a bit long so I suppose I will hold that off until next time…

Before jumping into Unity 4.3, I honestly had no idea what to expect, since outside of music production I had never done anything related to game development before. I was talking with a (sometime) game developer friend and told him that if I can get a character moving around on screen within 3 to 6 months I’d be happy. Well, it only took about 3 to 6 hours. I’ve worked on a lot of other stuff since then, including entirely redoing the way I was handling movement and collisions… twice… but the fact still remains that I did get him moving pretty quickly. He still needs some work, but I’m content for now. The point is that things are happening much faster than I anticipated, and now I have my character walking and running, double jumping, switching gravity, etc. None of this is animated yet, so he is just kind of sliding around, but hey, the basic mechanics are there.

However, the more that I dug deeper into the (C#) code, the more that I became reminded of the fact that I haven’t actually had much experience with object-oriented programming. I’ve done the majority of my programming in PHP which, yes, is an object-oriented language, but I managed to do it for 13? years while mostly avoiding making my own classes, objects, etc. It seems like this would be a bad way to approach C# development in Unity, so I decided to take a little pause and focus a bit more on figuring out some of the basics of C# and object-oriented programming before pushing the game programming forward. So that is how I have spent the last few days, although I’ve also spent some time on small things such as getting used to the GUI class and such.

I also decided that I should organize better before moving forward, because my one massive Word document wasn’t cutting it, so I signed up for Trello and transferred everything from said document to a more dynamic format that works better for development ideas / issues / etc. It’s not a perfect solution, and it kind of bothers me that I have no way to back up anything I put in there, but it is simple and easy to use, so I’ll roll with it for now.

I think I feel a lot more comfortable moving forward now. Time to get back to making actual game stuff!

PS. I’m only referring to my character as “him” because right now I’m using a Mega Man sprite as a placeholder graphic. Once I add in actual characters I’d like to get gender options if feasible. But I won’t be making the art assets (I’ll be doing everything else, I just suck at art, know your weaknesses and such) so that will be up to the friend from above, an awesome pixel artist who has jumped on board the (loosely defined) project, as well as my girlfriend if she wants to do add in some sweet hand-drawn stuff.

On the one hand, I implemented a working double jump on my own, which made me feel smart and stuff. On the other hand, I started at 1 am thinking I could throw it together in an hour or so and instead it took me a bit over 5 hours because I made the poor assumption that my character was actually grounded and “isgrounded” would return true whenever he was, you know, standing on the ground… I found out too late in the process that this was not the case. So I had to throw together a hack to take into account the fact that isgrounded seemed to be in a weird state of near constant flux.

I guess I need to work on my character / platform hit detection and get that nice and tight so important things like whether my character is touching the ground return true consistently before I go much further with everything else because I really don’t want to rely on hacky code. But… my hacky double jump does appear to work as it should so far so yeah, ultimately I consider it a success.