Making Games
One of the trickiest parts of breaking into the games industry is that a lot of the jobs want applicants to have prior game development experience. I know that this is not always a hard and fast requirement–a lot of them will accept candidates with experience in non-gaming fields. The problem was that, at this point in my career, I didn’t have any professional experience, gaming or non-gaming. I decided that it would be a good idea to get myself some experience developing games.
I had read and fairly thoroughly researched the options available for a solo game developer and ultimately decided to attempt to make a game with Unity. Also, I had used Unity in a game development class when I was at university so I was fairly familiar with the interface and workflow. I tinkered around for a while and completed several online tutorials, but since I had no real direction, I never completed a project or even ended up with anything resembling a proper game.
Moreover, I may have been a bit too ambitious. I think one of my early projects was meant to be a 3D re-creation of The Curse of Azure Bonds. I spent most of my time modeling a full-scale copy of the town of Tilverton using primitive meshes before I eventually got discouraged and quit working on the project. Maybe, I thought, I should start a bit more simply. Once I dialed back the scope, I was actually able to complete a couple of simple windows console-based games.
Game of Life
The first of these was an implementation of Conway’s Game of Life. While it’s not really what I would consider a game (since there’s no way to really win or lose), it was a fairly easy project to ease myself into game development. The Github repository for this project can be found here.
As you can see, there is not a whole lot to this one. The main thing that I learned on this project was how to use a second thread for input handling. Under normal circumstances, I don’t think that would be necessary, but in this case it made sense because we are clearing and re-drawing to the console on loop iteration. This could lead to user input messing with drawing the board correctly.
Tic-Tac-Toe
Next, I coded up a console version of Tic-Tac-Toe. My initial implementation was for a standard 3×3 tic-tac-toe board and would just brute-force check for a win (or full board) after each move. I extended the program to accept user input for width, height, and win length. This caused the win checking to be a bit more complex, but I’m fairly pleased with the results. The checking is still entirely un-optimized and there are definitely some bugs in this code. For instance, there is no bounds checking for the width, height, and win length inputs (negative numbers are accepted with potentially disastrous results) and it is possible to input a win length that is longer than the width or height of the board. Also, in my refactoring, I forgot to re-implement the check for if the board is completely full and there is no winner.