Lightweight development, the quick follow-up

Time for a quick follow-up on my post on “Lightweight development“. So far, it’s worked great. Some conclusions, in no particular order:

  • GitHub is great
  • BitBucket is awesome too. I use it for some of my closed-source projects at the moment.
  • Git-tooling for windows is ok, even more devs should give it a shot
  • TypeScript is the best thing to happen to javascript in a long time. Don’t “but it’s microsoft!”- me, fire up npm and install the node package!
  • I didn’t like AngularJS because it felt to restrictive and complicated.
  • KnockoutJS is still my favorite lib for client-side databinding

There are so many libraries and frameworks in the open source ecosystem. Don’t waste too much time finding “the perfect fit”. Just pick something that feels natural and helps you to get stuff done.


My platform game engine using MonoGame

I would like to present the hobby project that I’ve been working on for a while now. It’s open source, and the repository is located at

It’s a proof of concept of a multiplayer platform game, built using MonoGame, the (pretty awesome) open-source XNA port. The main idea here is to play around with the POC until I have a solid foundation for a game. After that, I will start to develop the ‘real’ game (design document is ready, I’m looking forward to implementing it!).

I work this way because I often tried to do a lot of things at the same time in the past. Eventually, all these attempts failed miserably, so that’s why I’m taking the step-by-step approach now. And it’s working out pretty good so far.

When it’s completed, the engine will feature:

  • LAN network play for two to eight players (using the Lidgren network library)
  • Basic AI bots (allows up to 16 players in total)
  • In-game console
  • Full debug mode
  • Tiled level editor
  • Horizontally scrolling levels with parallax backgrounds
  • Multiple characters
  • Multiple game modes
  • Multiple weapons
  • Different tilesets and level backgrounds
  • Unit tests
  • Compiled to run at many platforms (“everything monogame supports”)

Some of these features are already partially implemented at the moment. But I still have a lot of work to do, and because of my limited time, it will take a while before everything is done.

Anyway, it’s in no way meant to be a one-size-fits-all game engine. It’s just a pile of code for my own use, but I hope somebody else can use it too.

In a while, I might post a video of the game in action, and also some follow-up posts about this project. All depends on the interest of course, so make sure to follow the project on GitHub or comment/tweet. That’s the best encouragement for a lazy developer 😉

Finally, here’s a screenshot of what the thing looks like now. Please note that I used some free graphics in combination with my own uber-sucky photoshop skills. The result: It looks like crap 😉

Don’t worry, the final game will feature graphics by a designer.

My first project on GitHub!

In my recent post Showing off code is hard I concluded that I wanted to focus more on sharing, the community and open source code.
A few days ago, I took a first step in the right direction. I created my very first GitHub repo! I forked this repo. It’s a simple demo of a multiplayer game using HTML5 Canvas for rendering, and SignalR for the network communication.
You can find my repo here. It’s called ‘Jetpack demo’, and builds on the foundations laid out by the original project. My goal with this project is to experiment with scalability, performance and manageability of games built on this simple stack. It’s not a real game, rather a proof of concept. At the moment, it only allows players to connect and fly around in the canvas. That’s about it 🙂
I really like the GitHub workflow so far. I’m using both GitHub for Windows and TortoiseGit. Putting small projects like this one online has a lot of advantages:
  • Instant backup
  • Can instantly show my creation to the guys at work 🙂
  • Maybe it helps/inspires someone
  • …and also…
…it puts some structure in my workflow!
Contrary to my projects at work, my personal projects tend to turn into a mess quite often. I start over a hundred times, throw code away only to realize I want it back, and I try to implement too much features at once. Working with Git (or any other version control system) makes me work more structured, even for mini-projects like this one. I do small, incremental updates with clear commit messages instead of dumping big-bang boatloads of code. This is a nice experience, so I’m going to put a lot of projects on GitHub in the future!
Specifically for this project, I have no real clue where it’s going. Worst case: it just sits on GitHub and gets abandoned. No harm there. It’s better than sitting on my harddrive.

But I might put some cool stuff in. Next things I might implement:

  1. Integrate a lightweight javascript game framework. Current #1 option for me is, but I’m considering other options as well (let me know if you have a good one!). This abstracts away some of the canvas-related stuff and allows me to have an efficient and clear game loop.
  2. Experiment with simple physics, using server-side simulation and client-side motion prediction

Footnote: I often have the ‘my code is not good enough to release to the public’ syndrome. But more recently, I stopped giving a damn. If everyone thought that way, we’d still be in the stone ages of information technology 🙂

Showing off code is hard

I recently created a Dribbble ‘follower’ account. Dribbble is a great website where designers show off small slices of their work.
I could spend hours just browsing and enjoying the nice stuff other people created. It’s nice that designers just need a few pixels on your screen to show off their work. Almost everyone can relate to their work and has an opinion on it. But if you write code for a living, like me, it’s a lot harder to show off your work.

People that don’t write code themselves have no clue what you’re doing in the first place. It’s just a bunch of lines in a language they don’t understand. Of course, the people using the web applications you create have a few ways to directly notice the impact of your code. For example, they can tell that it ‘it works smooth’, ‘never crashes’ etc. But that’s just the top of the iceberg, and most of the time, visitors and customers just take these things for granted. You only hear them when something bad happens, like crashes, data loss or downtime 🙂 It’s a pattern; front-end developers get more of the praise when something good happens, and coders take more heat when things go downhill. Devs might get a pat on the back for delivering solid code within the deadline. But in general, code is often regarded as a commodity instead of a craft, while I still find the thought process of creating software inspiring, fun and challenging.

But it gets even more complicated. It’s pretty difficult to show off code to our fellow devs as well. If I want to post some code snippets here, I’d have to add a lot of context before it starts making sense. I can’t just copy-paste some lines out and get ooohs and aaaahs for elegant LINQ-queries or tightly structured methods.
Open source projects are great – it’s common for a developer to have a Github account with a few open source projects in them. But creating and maintaining a decent open-source project takes a lot of time, determination and inspiration. It’s not something you do in just a few hours of spare time.
Sharing with colleagues is great, but we’re the www-generation so we want to share with the whole world.

At the moment, 90% of the work I do goes unnoticed. It’s buried in a codebase that’s silently buzzing on a server somewhere. It’s not very satisfying to write code and then forget about it. I know there’s more value to be gained from the work I do. But the process of extracting knowledge we can share and appreciate out of ‘anonymous’ codebases is hard and takes a lot of time. It’s difficult to put structure in our thoughts and create and share thoughts, snippets, libraries, patterns and projects. Personally, it even takes me way too much time to write a single blogpost. But even if it’s hard, quitting or whining is not an option. Progress starts with ourselves. Blogposts, open-source projects, conferences – we’re doing this stuff after our hours to create a community where we can share. I really appreciate the time people put in sharing, because I know how hard it is. Some people write thousands of great blogposts, and great new initiatives, projects and communities arise everyday. I’m confident that things will always get a bit better.

For me pesonally, staring at my feet was a mistake I made too often in the past. One of my goals for the future is to spend slightly less time coding, and a little more time sharing. If we don’t ‘market’ our work to our managers, our coworkers, the community and our clients, it might as well not exist. We have to show what we do and make clear why it matters. The key investment is time, and lots of it. But I’m convinced that it’s a good investment to make in the long run.

If you’re a developer, you probably experienced the feelings I’m describing here in some way. What’s your take? How do you show off your code? Comments or follow-up posts are appreciated 🙂