I have been working on my first video game for over a year now!

I had planned to make a sort of “It’s been exactly a year since I started making my first video game!” update post on the anniversary of the release of Unity 4.3, also known as the day I got into video game development. But I guess I managed to miss that anniversary (November 12th.) Close enough.

First things first time has, of course, gone by very, very quickly. But that doesn’t surprise me. In fact, it is one of the (many?) themes of my game. I’ve tried to stay on top of things despite this being a pretty intense year that included two moves and two new jobs (which puts me at three part-time jobs that add up to a bit more than one full-time job currently.) Also my computer died and it took me a good 1-2 months to get a new one and get everything up and running again. Still, I think I have made a fair amount of progress, especially since I honestly had no idea what to expect when getting into this. A big part of me thought I would try it out, find out it was way too difficult, and walk away. But nah. It’s not that bad. Not that there haven’t been plenty of nights staying up until 5 in the morning trying to figure out what the F was wrong with my code…

So where am I at with this runner which is definitely not an endless runner even though everyone keeps referring to it as one? It’s really tough to say. But I think it is at the point where a lot of the basic controls and mechanics are, if not quite done, close enough that I can put them in the “mostly done” category and move on. Which means focusing on content. I probably bit off more than I should have for a n00b developer in the sense that my design calls for something like 20-30 different types of platforms and 50+ enemies / hazards / etc., not to mention a lot of stage unique stuff, but I’m getting there. I have maybe 10-15 platform types done and about the same amount of enemies / hazards done. I have around 1 1/2 “demo” stages finished. This might not seem like a lot, but I actually knock this stuff out pretty quickly when I get to focus on it… it’s a lot of the behind the scenes basic structuring of the controls, game mechanics, basic tools I use to build things, etc. that has taken up most of my time.

The soundtrack, which I am doing myself because honestly half of why I decided to make a game was to have a place to put my music, has around 15 songs planned and I have around 12 finished (another reason my game isn’t further along is I took a month or so off from it to focus almost exclusively on the soundtrack.) I was listening to the Xenoblade soundtrack the other day, which is around 5 hours long, and it sort of cracked me up that the soundtrack for my game which will probably take about an hour to finish (maybe a few hours if you keep DYING a lot) is 1/5 the size of the Xenoblade soundtrack, a MASSIVE game which took me over 120 hours to finish.

I’m using “done” / “finished” loosely here, of course. There is still a LOT of polish that will have to be added to pretty much everything I have worked on for me to be happy.

I still have a longggggggggggg ways to go, so no rest for the weary. I do hope to have a playable demo ready soon, in fact I basically have one almost ready right now, just a few little tweaks I need to make (including fixing one very nasty bug) and some art that needs to be made (by someone who is not me and has a lot of other commitments so I can’t reasonably rush him) and then you will be able to get your hands on this sucker. I guess I should probably come up with some kind of name for it huh?

I project this thing will take another 2 years at least. Maybe more. And after that… I’m making a smaller game next! Or so I say. Anyway, here is a character design / animation that the artist has put together. Expect to see a demo stage soon.

Up until 5 AM last night metaphorically beating my head against a wall

Apparently the way that I was getting the length of an animation works in Unity’s editor but not at run-time, something that was not immediately evident because the animation length was *almost* a second long and, since it couldn’t grab the length at run-time the way that I was trying to make it, it just threw a 1 in there instead for some reason. Which led to the things I was basing off of that animation time to be *almost* working right but not quite, and me taking way too long to finally pinpoint why this was the case and fix things. Well, hopefully fix things, although it was 5 in the morning and I was barely awake when I finally got it working so I didn’t really bother testing it all too well. I guess I will see today if it actually works correctly.

I think sometimes people hear that I am making a game and they’re like “Oh wow, that sounds fun!” and well… they’re half right. It’s fun for sure, and I’m very glad that I’m doing it, but it’s not all conceptualizing and level designing and such. It’s also a lot of annoyingly frustrating bug fighting nights as well, the kind that make you doubt your skill… and sanity.

It’s been awhile. I’m still working hard. The game is taking form.

Which means I need to stop calling it “this runner game I’m making about life which is totally not an endless runner since those mostly bore me” soon, right? But I’m definitely not ready to pick a final name yet. So I gave it a code name: The Memory Project. Because to call it a game about life isn’t quite accurate. It’s probably more accurate to say it is a game about perception, and how we tend to remember things our own ways for our own reasons. Well, actually it’s a game about running around collecting GOODTHINGS and avoiding BADTHINGS and such. It can be two things!

Anyway, after tons of working on new code and reworking old poorly written code and such, I now have things set up to semi-efficiently? spawn a bunch of the stuff I need on the fly and get rid of it when I no longer need it, essentially limiting what is running at any given moment to what is on-screen (and slightly off-screen.) AND I built a whole “stage” with this new code that, unlike my old attempts at building stages, runs fairly well, even on my garbage old laptop with stuff flying all over the screen. Not as much stuff as I intend to have flying all over the screen in final stages, but enough for what would be an early stage in the game. This is progress.

I put “stage” in quotation marks above because I didn’t really bother overly much with that whole “level design” thing, I just kind of wanted to get SOMETHING put together to make sure all of this new code works well. Still, it’s getting to the point where I might be able to show off some stuff soon.

…ish. Soonish. I’ll keep you posted.

Looking in from the inside?

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.

And the toughest part of the programming today was…

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…

Getting back into the most important part – the soundtrack

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.

It’s nice when things finally “click”

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…

Woke up a bit chilly in the middle of the night, and my first thought was…

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.