[Reposted from Medium]

For more information on what Video Game In a Week is, you can consult this post. If you can’t be bothered to do that, think of it as a week-long solo game jam.

For last week’s post, click here.

Game 1 is finished!

After (more than!) a week of development, I have finished my first (roughly) weekly game. You can download it at the bottom of the article.

Here, I’ll reflect on the process of developing the game, as well as the Game in a Week project as a whole. I won’t delve too much into the game itself — you can experience that for yourself.

Looking back

Looking at what I’ve built, I think it’s leaps and bounds above the first game I made, at least visually. The camera moves smoother, the environment is vibrant and colorful, and the character is more complex. That being said, there were a lot of parts of my original vision that I had to cut off.

I had planned to create environmental traps that the player could activate to destroy enemies more efficiently. This was scrapped for time constraints, since I did want to release this game within a time span (roughly) resembling a week.

Also, you’ll quickly see that all the platform tiles are the same. This does look very repetitive and takes away from the overall aesthetic of the game — if I come back to this game after Game in a Week is finished, this will be the first thing I fix.

Overall though, I like what I’ve made. I already have a ton of ideas for other levels that could be built into this game (though I’ll be moving on for now).

It always takes longer than you think

Gauging your progress while developing a video game is always tricky, because your game may look like it’s 75% complete when it’s really 25% complete.

Here’s an example of what I mean: You import all your sprites, set up the physics engine and have your character running around in a naked environment. Your game looks like…a game. You feel really good. You just went from empty canvas to something that resembles a finished product in a few clicks.

But really you haven’t made much progress at all. Importing sprites and setting up Rigidbodies is maybe the first 1% of building a game — it just feels like you’ve made a ton of progress.

The inverse of this can also be true. Simple tasks that you might estimate will only take 1% of total development time might take 10%, or even 25% instead. Take displaying text above a sprite, for example. In the previous engine I used this was a really simple affair, so I assumed I could finish this in maybe 10 minutes max. Unity is a lot more finicky, however. First of all, I discovered there was a difference between UI text and text that’s displayed in the game world itself. Then I found out I had to use a different text class for my purposes, and then I found out that the latest update of Unity might have broken this functionality. Once I got the text working, it was unacceptably blurry, so I had to search for a fix to that as well.

All in all, what I thought was a 10 minute affair ended up being a 1 hour one.

In summary, if you do something that takes a minute and your game suddenly looks really good, celebrate, but don’t spend too much time kissing your own ass over it either. Likewise, have a healthy amount of respect for even the simplest of tasks — because they might not actually be that simple.

Work smarter

Cheesy title, I know, sounds like something you’d read out of a book written by a self help guru. But when I ended up spending 2 minutes playing through my game after every iteration of my code to fix a bug, it became evident that it was a lesson I had yet to learn.

Finish your building blocks before you use them. I built each element of the game one at a time, and started assembling the level before I had finished building each individual element. This meant if I was currently building a jump pad, and there was a jump pad in the middle of the level, if there was a bug with the jump pad I would need to play through half the level every time I attempted to fix the jump pad. Obviously, not very efficient.

I didn’t log my time working on this game very strictly, but I easily spent 3 hours a day on it, and around 6 today polishing it. Much of that time was spent just playing through the game to try and fix a bug, which is far from the most efficient way to debug.

Also, it’s surprisingly easy to get pulled into just playing your own game instead of developing it, even if it is half finished, especially if you’re avoiding the pain of fixing a particularly difficult bug.

Did “Art First” Development work?

I think the general idea works. But in this specific case, I drew all my art up-front and then worked on my code. Personally, I don’t like to switch between drawing and coding, and since I’m working on my own, this typically means I’ll finish all my art before I start coding. However, I only drew one platform, which meant this one platform was repeated throughout the level. I think it looks ugly.

On my next project, I’ll be more careful to draw enough assets to begin with.

For now, as an answer to the title of this section, I’ll give a tentative “yes.” I think the game will look great after I add some variety into the platforms.

Final Thoughts

Overall, I don’t think I could have pumped out this much game in a week if it wasn’t for this project, so I’m counting this as a success. As to what I’m doing next, I’ll probably spend the next day or so brainstorming for my next weekly game, and probing these ideas for viability. Expect a brainstorming blog post in the next few days.

If anyone’s interested in the technical aspects of how I got anything done, just ask. For reference, here are the things I found the most difficult:

• Moving the character into the background in the last section of the level
• The Jump Pads, surprisingly
• The fade from black at the start of the level, also somewhat of a surprise