Coming up with an idea and then turning it into reality is difficult. Anything over the simplest idea can quickly become a challenge, and once extra features start getting added it becomes even harder. It's a constant battle to make something that's a working piece of software and something for people to play.

Haywire didn't really turn out very well. Although it was no fun to play, it got me back into the game development mindset and reminded me of how to do various things. In the end I used lot of stuff from it in newer projects, so I count the overall experience as a positive one.

Don't get me wrong, it's still difficult to make things, but having the library of code and the experience of solving certain problems has been a tremendous help.

Knowing that I'm building a small project, and that I have to keep it small, has helped me focus on building useful stuff without getting too bogged down in the engineering aspect. There are projects I've been working on for years that would have seriously benefited from being built alongside a bunch of smaller test projects. I can't believe it's taken me this long to figure that out.

#1GAM hasn't brought in a whole bunch of traffic to the site. Google says about 50 visitors. I've had about the same traffic from Twitter, and about 100 players from Ludum Dare #29. Granted, I'm not doing this for fame or fortune, but it's still a little disheartening to create something that nobody plays.

There are a lot of games out there, and getting seen isn't easy.

I like the technical challenge of building a game. I like figuring out how to get things moving on screen in a way that I want. I like building an experience for someone else to play, and then seeing that they play it in a totally different way from how I expected.

However, this is only part of the story.

For the last 10 years or so I've been trying to recreate the experience I had when I first started building games for the PC. I wrote two of the best game demos I've ever made. They were fun, people liked them, and I got them built in a couple of months of super-productive coding. It probably shows how much I enjoyed it that even after all this time I still think very fondly about it.

So far I have not been able to recreate that experience.

I've gone though a bunch of phases and emotions. Maybe I was just a better programmer back then? Or now I'm too old to really dedicate myself to it? Maybe I'm just not trying hard enough? Or am I too easily distracted? Or just not good enough?

Perhaps they're all true to some extent, but looking back I think the biggest mistake I make at the moment is developing in a vacuum. I don't want to show any work unless it's "perfect", so I show nothing. Part of what made that time so special was that I didn't do it alone. I showed off what I was making, but I also looked at what everyone was creating. We all encouraged each other, and made what we wanted to make.

The funny thing is that now there's even more chance to interact with other developers. There are way more forums and sites dedicated to it, not to mention the likes of Twitter, Facebook, Instagram, Google Plus, App.net and everything else.

This might not sound like something positive, but a key part of me writing the game was to find out where my own code and process was below-par.

Needless to say, I found plenty of places to improve, and building a quick project really highlighted them. Some areas of code are poorly written, and there are other areas of functionality are missing completely. I never really realised how much of a help Flixel is, so it was certainly an eye opener.

One part that went absolutely right was the custom entity framework. I used a very simple version of component-based entities when creating Ineptia, and even though it was crude it really helped. This time around I used an entity system approach, and it worked out better than I ever could have hoped.

In previous iterations I have used components that have data and behaviour mixed together. It works well enough, but one thing that always bothered me was deciding which component should do what, and how they should communicate. With entity systems, the component is just data and systems are just behaviour. It makes breaking down data and behaviour much easier, and because systems can access multiple components at once there is rarely a need for them to communicate with other systems.

With this approach, systems are added to the World and can then register their interest with one or more components. For example, you can have a system that only cares about entities with a PlayerComponent attached. Like components, systems can be added and removed at runtime, so new behaviours can be added dynamically.

There's a couple of gotcha's, and it requires a slightly different way of breaking things down, but it works rather well.

Although it wasn't very polished, but the main reason for keeping the build private was the use of copyrighted graphics. Now I'm pretty sure the lawyers wouldn't have come to get me, but you can never be too careful.

I moved house at the end of May, and the various bits of move prep spilled into June. Coupled with work deadlines it didn't leave me much time or energy for game development, so I didn't start until very late in the month. If I had started earlier I would have been able to change out the graphics and release something.

Although I enjoyed figuring out the technical aspects of the project, the idea of cloning Space Invaders didn't really trigger my imagination. I've always felt like I spend more time trying to solve software problems rather than gameplay ones, so I wasn't really expecting this.

I'm writing this two weeks into June, so I guess I failed that already…

This one speaks for itself really.

Space Invaders was fun, but technical challenges alone don't motivate me as much as I thought they would. There needs to be some creative aspect in order to inspire me to build something.

I was a little hesitant to enter this time around, especially after my failure to finish LD #27. Needless to say, I'm very happy I managed to complete something time around.

There's a full loop of gameplay, a title screen, game over screen and even an online high score table. Code-wise it's a mess, but it works.

Figure 1: The original concept

Figure 2: The finished product

I deliberately kept my original plan as simple as possible, and I think it paid off. Normally I get a bit carried away and end up only finishing about 10% of what I want. Taking the simple approach allowed me to finish the core game relatively early, so the end result has a few extra features I hadn't intended on doing.

The graphics started with silhouettes. Then I added some bubbles. Then the explosions. Then more bubbles and a nicer sinking animation. This went on through the whole game. I would start with the feature, get it working, and then polish it until I was happy.

It wasn't just graphical changes either. Originally the ship would sink as soon as a missile or bomb hit it. I thought it would be more fun to have the ship start smoking when damaged, so I added health and smoke/fire particles to indicate the current status. Even though it was initially a graphical idea, I think it makes the later levels more enjoyable.

Normally I just splat a whole bunch of ideas down and pick whatever takes my fancy. This time around I created a giant "todo" list, and then organized the tasks into milestones. Each milestone only had a few tasks in it, but I forced myself to finish each task before moving to the next one.

Ticking each milestone made a huge difference to my motivation levels, and was also a good way to prevent me from getting sidetracked. Here's the milestone for the "mine dropper" feature (complete with time tracking data):

*** DONE Milestone 9 [6/6]
    CLOCK: [2014-04-27 Sun 09:19]--[2014-04-27 Sun 10:01] =>  0:42
    - [X] Random plane that drops mines
    - [X] Mines float (with a little y-axis wobble I guess)
    - [X] Mines explode after a certain time
    - [X] Mines should flash as they get closer to exploding
    - [X] Exploding mine should sink ship
    - [X] Hitting a mine should sink the ship

Nothing fancy, but it definitely helped.

My idea wasn't really that exciting, which stunted my enthusiasm a little. By Saturday night I had most of what I wanted finished, and didn't really feel like getting up early on Sunday to work on it. The feeling subsided once I got started, but normally by Sunday I'm panicking about how to get everything finished.

The first 8 stages are pretty much the same - destroy some submarines and don't run out of time. It's only once mission 3 rolls around that more interesting elements (enemy subs firing back, mines, sonar etc) get added. I wanted to make the learning process gradual, but Ludum Dare games are all about grabbing the player's attention as soon as possible. I failed pretty badly there.

I made an announcement post before the compo started, but that's about it. Must try harder next time.

I tracked time on each task, and it wasn't until Sunday morning that I tracked individual milestones. Not a huge mistake, but it would have been nice to graph each milestone by time taken/code written etc.

I think I said this last time, but it's worth repeating. A lot of what makes Ludum Dare so special is the community around it. Sharing ideas, early sketches and progress all add to the experience, and I really missed out (again) this time.

Keeping the graphics, sound and gameplay simple helped it all came together much more quickly than usual. There was a slight panic at the end to get things finished, but for the majority of the time development was pretty smooth.

Everybody is different, but I'm more motivated to work on something when it excites me. Splodey Boats is not a very exciting game.

Keeping each milestone small kept me focused, and stopped me from getting bored or frustrated. If there was a task I wasn't enjoying, I would put a fun task in the next milestone. Knowing I had something enjoyable to do next pushed me through the parts I didn't like.

This is my 7th Flixel game, and I think it's starting to show. There were still plenty of things I didn't know how to do, but I was able to figure them out due to my previous experience.

I feel a bit silly for not figuring this out earlier, but having any experience really helps. Even the things I learnt from Haywire and Zap made a big difference to how quickly I could get things done.

Lesson learnt: experiment more. Much more.