A Strange API
And so we start.
When creating a game, from a programmer’s perspective, two things will be most important:
A friend of mine once said, and I quote:”Building any significant project in Java is akin to attempting to reach the top of Mt. Everest in a single jump.”
Java is a rather … static language, and so all projects you want to do will have to be planned to a certain degree, or else you will end up in what I would like to call eternal-prototype-loop-hell, in which your project will never be finished and will stay in a constant state of “prototype“.
Sidenote: This is essentially true for any language, but for Java more so.
Traditionally, in software engineering, you look at what is required to solve the program and encapsulate a solution in a set of procedures.
As you progress you will find that different problems require you to adjust, augment or even re-invent your program as you go along.
The real-world situation
My first big mistake was a rather obvious one: I underestimated the scope of the project.
I just started to code without any real guideline, hoping that after enough prototyping I would reach a point in which the API was mature enough.
My main fault was that I wanted to create a API which would enable anyone who wanted to, to extend the game itself in any direction effortlessly.
This in itself is not that bad, the problem lay in that I hadn’t thought about what kind of game I would present as the core gameplay.
Which, in the end, made me realize that I was working backwards by first creating an abstract API, and then creating the game rules with it.
And so I ended up learning this particular 2-cents wisdom: One should not make the goal suit the means, but the means suit the goal.
Also should be noted, that at the beginning of the project, I had exactly 5 months of programming experience.
And in the following years I learned techniques I wanted to introduce into the core of the game.
I scrapped almost all the code, wrote a general core gameplay document and then started to write down a set of levels.
Each level would introduce a new gameplay feature on top of the core gameplay. As I forced myself to think of new aspects to the game, I started to see which parts of the API should be abstract and which ones not.
Afterwards, I presented the document to some friends and asked for feedback and new levels.
I urge you to ask for feedback from your friends/family, as it will give you valuable insight from a different perspective.
As the game design document neared completion, I could move on to planning:
As Caravel was meant to be/is a summer project, one thing will be crucial: Planning.
For programmers are nothing if not slackers, and during summer even more so.
First you’ll need to a rough description of the aspects of your program, and estimate how much time each will take.
(Be strict, and realistic. See which aspects you consider boring and set harsh deadlines for them, then reward yourself if you can meet them.)
Next make four categories: Alpha, Beta, Pre-Final and Final, and divide the aspects among them.
Alpha and Beta stages are for prototyping, Pre-Final is for game-content, and Final for balancing.
Afterwards start up your favorite planning software, and create a Gantt chart of all the sections you just created.
You’ll end up with something looking like this:
Congratulations, you just made your first real step in completing your project.