Adventures in making a game. Weeks 1-3?
I’m probably going about making a video game in the entirely wrong way. I’m probably going about this whole learning process the wrong way. Instead of writing a design document, sketching out all the parts of my game, and then starting work slowly, I’m jumping into figuring out how to make different systems work (like getting the box to move around the screen). Instead of starting with Pong (a game a lot of developers apparently start by making) I’m starting with making something that doesn’t have a specific template. I’m also not doing this full-time. I have a mortgage and I like food, so I’m keeping my day job and doing this in the evenings and on weekends when I have time (it helps that I love my day job, so I’m not exactly itching to quit). This sounds very much unlike what a lot of other indie developers do, from the bits I’ve read on the internets. I’m trying to get all the parts about how I’m approaching this wrong out of the way upfront. I might change my methods in the future, but right now this is fun, and it’s working for me (mostly).
I’m not looking to necessarily move into game development full-time, I just want to make something. But I also want to learn new things. I didn’t want to do everything from scratch, so when I thought about making the game I started the search through the different tools I could use. At first I thought about GameMaker Studio, a tool for making 2-dimensional (2D) games that has been through many iterations. It seemed easy to use and many games have been made in it (Gunpoint, the first pixel-y Spelunky among them). But I didn’t get very far into investigating GameMaker before I came across Unity. Lots of indie developers are using that engine right now, and best of all, it’s free if you aren’t going to make a bunch of money or target much past the PC. But if I do want to target other platforms I have an easy-ish way forward. I wanted something that didn’t need everything to be done in code, but would allow me to get in there and monkey with that if I wanted to. And I wanted to be able to use a language that I already knew (preferably C#, but I also know Python and a bit of Javascript). Unity falls nicely in there too, as it uses either C# or Javascript (among others). And, to top it all off, Unity just released their 2D tools in the 4.3 release. So that pretty much sealed it for me.
So now I’d chosen Unity; it was time to start playing around in the engine. I found a couple of sites that had some tutorials (http://learnunity2d.com being a really great one), and Youtube became my best friend. After watching and reading some tutorials on Unity2D I started the process of making my own game. I didn’t have a specific game in mind, but more of a general “I think top-down something or other” feeling. That gave me enough of a way forward to start work.
I created a little red box and started to figure out how to move him around the screen. I started by moving it around directly using the WASD keyboard keys. This introduced me to the term Lerp, which is apparently used here to be linearly finding a point between two other points. Might not make a ton of sense to everyone, but in essence you want this because it should give a smoother sense to the movement around the screen. Instead of warping from point to point, when those points could be far apart, you are moving to points in between. Makes sense, right? I got that working, and then quickly got rotation to work as well. Now the little box will turn to face the mouse, wherever it is on the screen. That was fun, but then I thought maybe I wanted the character to actually move to where the mouse clicks. This was super informative because I was introduced to the difference between the world of the game, and the screen, in terms of what a point in each is. The world is the entirety of the level in Unity (a scene) but the screen is what the actual user sees, so you have to have some way of taking where the player clicks, and finding that same point in the “world” of the game.
From there I decided to have the camera have the ability to follow the character around. I found a piece of code (a script) at http://wiki.unity3d.com/index.php/Scripts which showed me a bit, and I looked at the script in the 2D tutorial put out by the Unity team for even more information. With those two I was able to get the camera script working. Now wherever the little box moves, the camera will follow.
Also, I had a heck of a time thinking about pathfinding through obstacles. I had to make sure that if the user clicked on the other side of a bunch of obstacles the little box would show some sort of smarts and find its way through them. Instead of trying to think of a way of doing it myself, I downloaded A* pathfinding, which has a free version of their pathfinding package available (http://arongranberg.com/astar/). With the assistance of their tutorials and demo in the package I got the box to move around the screen around a bunch of obstacles.
I tried getting grid movement to work (where the character will always snap to a grid position, like he’s on a chess board), but I couldn’t get it to look quite right, so I decided to move away from that, and mouse movement altogether, and go back to direct control. Not a complete waste of time though, because if/when I want to implement other non-player characters I can put the pathfinding to use there. Moving back to direct control, with obstacles meant I found something else out. Colliders, the things that let objects in the game hit and bounce off each other, in Unity only collide when you’re using physics to move the character around the screen, at least if you want the built-in physics to do the work for you. So from there I started working on using physics (math and science!) to move the box around the screen, instead of giving it specific points to move to.
Physics taught me something else about Unity. This is getting very much into coding territory, but I found it interesting. There is a big difference between FixedUpdate and Update. I had no idea at first what the difference was, but basically Update is called every frame, and FixedUpdate is only called a specific number of times in a given amount of time. I can’t remember the specifics, but let’s say your game is running at 30 frames per second; Update is called 30 times, and FixedUpdate might only be called 15. FixedUpdate is better for physics, so I moved to that. This caused serious jittering whenever my character moved. I thought I had done something wrong in the movement. But no, that wasn’t the case. Apparently having the camera move itself in Update while the character has stuff happen to him in FixedUpdate is bad. It goes to show, there can be a lot to learn on the technical side when you’re going to try to adapt stuff you found on the internet.
Ok, now I have a character (box) who can move around the world, hitting obstacles using physics and spins around to follow the mouse. Now I wanted some basic interaction with other objects. I looked at the text object in Unity, called GUI Text, and how to get them set to only appear when you are close to an object and press a button. This taught be a bit about trigger colliders (those things I mentioned previously, except they don’t actually stop a character) and that when you have GUI Text it is tied to the screen, not the world. This might not seem like a major revelation, but when I first thought I’d be tying text to objects I thought I could just put the text object by them in the level and that's where it'd appear. No, that doesn’t work. You put the text in the screen, and then it appears there when it’s enabled. The text moves with the camera, in essence. It isn't static in the world. So now I just have the object set the text value and enable it when the player clicks a button and is close to the object.
So, at the end of this part I have a moving character, some physics and some really basic interaction with objects in the world. I was hoping I’d be further along, but maybe that’s just what happens when you are tired from working all day and you don’t always want to program. I also tend to pick up new programming concepts slowly, it takes me a long time to absorb any of it. Probably comes from me really just starting to program on a regular basis. And sometimes I just want to play video games.
That was a long post. I didn’t think I’d have that much to say, but obviously there was more there than I thought. I tried to keep it non-technical, but sometimes that’s just how my mind works, so that’s where it ended up going. Future posts probably won’t be as long, and I’m hoping to have both some technical and non-technical content as well. I’ve never made a game before, and all the creative projects I’ve started before this have fizzled into nothing as I either lost interest or got distracted by other things. Hopefully by starting this blog, and trying to dig deep and find the drive I can get this much further.
Maybe next blog I’ll have an actual game idea.
