Posted on September 12, 2018 at 4:21 PM
(Finding a good title for a blog is surprisingly hard)
I finished The Oyster Mirror, that puzzle game of mine, yesterday. You can play it on Itch.io (https://jani-nykanen.itch.io/the-oyster-mirror). The source code is available on Github (https://github.com/jani-nykanen/the-oyster-mirror). The source code is actually more relevant in the point of view of this blog.
Here I would like to share something about the project if we consider it as a programming project and ignore the game part. The project had two initial goals, let's call them the minor goal and the major goal.
Write a game in Java. I haven't done that in almost five years. And now I did it. Woohoo.
This goal needs a short introduction. It's possible I'll graduate within a year (and by graduation I mean master's degree, bachelor is almost worth nothing here). Okay, what do I do then? It's either army or the civil service, but what about then? I need to apply for a job, naturally. But what kind of job? Well, I think trying to get a job in a small "computer company" - you know, something that codes something, could be a game company as well. That could be a good starting point for my possible career. So let's say I'll find a company where I would like to work and I'll decide to apply there. Of course they want to see what kind of code I can write. Since I'm a math major I don't have a degree to show that I can code. Clearly this means I need a portfolio of projects that show my programming skills.
The thing is, I don't have any project to share yet. All my projects on Github were not designed this goal in mind, so I would not like to share them. So this means I have start programming projects where the main goal is to write good code I would not "shame" to share - or let's projects I would dare sharing - in my portfolio. Note that my goal is to try to join smaller companies, hopefully game development focused or companies that consist of "hobbyists", not professionals of software engineering. I could never reach that level of code quality. And I don't care about software engineering, it sounds boring.
Anyways, if consider this major goal, how did my project fare? Well, not as well as I had hoped. I would not put this to my portfolio unless I had say three or four other projects there. There is still a lot of room for improvement, but I'm positive that this project has better code in overall than any other project of mine. There are less repeating code and less spaghetti than my previos projects, although it's a little unfair to compare C and Java projects since in C you have to write a little more repeating code unless you go dirty and use macros.
The biggest problem was that my object-oriented programming skills were a little - or a little more - rusty when I started this project, so the code does not always feel very coherent since I learned how to do things more efficiently during the development. Also, I hadn't done a "big" coding project - by big I mean a project with over 10k lines of code - since... The Last Minute Dungeon? two years ago, so the code did get a little messy near the end. Still, the code structure was mostly good. I could add new features to my game very easily, unlike in some of my older projects.
Of course there are some smaller details I'm not happy with - a few overlong methods, poor variables names etc. - but they are less relevant. There are always small things you can improve, but if you don't see the big picture, it's hard to really improve your code. There is one minor detail I think I should try to keep in my mind in my upcoming projects, and that's error handling. I usually do it in lazy way - why use multiple exception types when you can just use Exception? -, and not only in Java, but in other languages as well.
I tried to comment the project as much as possible, and even though not everything is easy to understand, I think the project is decently commented. It does not exactly need more comments, maybe better comments or something, who knows. And yes, I did write those Javadoc documentation comments above the methods, but I never bothered to try if the documentation can actually be compiled. I did not do those "unit tests" or whatever they are called. In those two programming courses I took in university we were told to always do them, but I'm not actually sure if they are very common in game development.
I still had something to add but I forget what it was, so let's move to the next thing. What to do next? Write smaller games. Smaller games mean less code means the code keeps coherent more easily and don't fall apart. I'm not going to do another Java project for a while. Java isn't bad but it certainly is not my thing. Maybe I'll try to write "correct" Go code one day. I probably should try to learn new things like online multiplayer programming.
But this is not what I'm going to do "next next", you know, literally next. The Oyster Mirror has one big problem: it wasn't particularly fun project, it felt more like work. And I don't want to spend my free time - which I don't have that much now since a new semester just started so I have school stuff to do - to do something that feels like work. I think I'm going to make a few smaller arcade games or game prototypes or tech demos and ignore the code quality. Maybe write another software renderer with fixed point arithmetics this time. Or make a mobile game with Html5 with the default Html5 rendering functions instead of WebGL this time, so I wouldn't need to worry about writing the rendering routines and shaders first. DOS development could be fun for a change, too.