Ludum Dare is upon us once more with its fair share of games and the post mortems that come with them. And in this time of holiday traditions it is with great pride that we wish to share with you our very own contribution to LD40. But what would a good post mortem be without a link to our game?

https://ldjam.com/events/ludum-dare/40/space-dominator

Space Dominator is a game about colonizing a Solar System and managing its resources before the population growth gets out of hand. It’s a strategy game and a clicker and here are our impressions on what went right and what went wrong!

First the good stuff. Our team included developers Quentin Chevalier, Fabien Kalinowski, Loïc Siquet and Nicolas Aubinet. Nicolas Lorent was our own dedicated game designer while I worked on the art in the little time I had to offer with some help by Vincent Schneider who also managed to do his own game, solo. https://ldjam.com/events/ludum-dare/40/tentagraba

Let’s get organized:

This wasn’t the first game jam for most of us and one thing where we feel we’re learning, each time, is organization. We were working from different locations over France, Belgium, and Germany with Vincent living in Canada, so it was crucial, not only for communication to go smoothly, but, most of all, to be able to efficiently assign all the different problem-solving tasks that making a game implies. Especially when we’re working over different time zones, the slightest miscommunication can lead to the loss of precious time. Any tool that helps in that department is probably a good tool. In our case we communicated using Slack and we shared documents and spreadsheets using Google Docs to help us stay organized, listing tasks and their different priorities.

Hit the ground running:

Knowing what everyone’s role is and being able to set a clear goal really helped us to hit the ground running and we quickly settled on an idea that got everyone excited. Our most recent additions to our team in the coding department have also been instrumental in reaching the ambitions that we were aiming for in accordance to the type of games that we like. It’s not just that adding one or two coders will raise by that many measures the amount of code that we can expect to achieve. Having a healthy workflow where feature ideas can be discussed, tested, tweaked and then talked about again until it fits our vision has had a multiplying effect of several magnitudes. It changed a lot from the issues that we had where a lonely coder could easily get lost in the sheer quantity of features that were tossed around in our earlier attempts.

It's about time:

As we all know time management is one of the biggest issues in a sprinting run like this, but I’ll get back to that later. Being lucid enough of what can and can’t be achieved in any given timeframe is difficult whatever the conditions may be regardless of the type of project. In our case, everyone, in preparation to the game jam, took the time to reflect on how deeply we were going to able to get involved. Some of us also had to manage work (even on a weekend) and family (especially on a weekend). Having that foresight, we carefully chose the features that we were ready to work on and their different priorities. For example, we decided it would be best not to allow the player to manually assign workers to the mines on the colonized planets. It allowed us to limit the amount of work necessary for the UI. It meant less management needed by the player and brought the gameplay to a higher level. More generally, reducing the amount of parameters made balancing easier and it kept the player from getting too lost.

Balance is key:

We managed to get a working prototype relatively quickly, which was essential for playtesting, as it’s the most crucial part when balancing the game by finding out what’s working or not and whether population growth or resource generation, for example aren’t moving too fast or too slowly. What’s gratifying is that, from the feedback that we are starting to get, it turns out our work in that respect is showing. The first players seem to be enjoying the pace at which the game runs and no-one seems to find it unfair, yet. Nothing ruins a good game idea more than poor balance. We know that from experience.

Everyone says I love UI:

Another important aspect of our game that we had to get right is the UI. We’re not saying ours is perfect. But given the time that we had, we’re actually quite happy of how it turned out. Playtesting, again, was essential in getting there. I’d say most of the work in getting to the state that our UI is in, right now, has been done in the last three hours before the end of the jam. The first versions that we built had a lot of issues and Quentin spent almost all his remaining time in reworking it until we felt we had a layout that efficiently displayed all the information the player needed without submerging them in an avalanche of useless data. Needless to say, if we ever push on development on the game, the UI is probably the part where we would continue to work on hardest, as we would try to make it as perfect as possible. Especially knowing what good examples can be found out there. https://www.endless-space.com/

So what does a game designer actually do ?

Having access to a game designer was also something awesome. The input, even in small touches at different stages of production, of someone solely focused on game mechanics is something that I’ve grown to heavily rely on over the last few game jams I’ve participated in. Nyckos kept us focused on what the game should be instead of getting lost in feature creep.

You call that art?!

For my part, I knew I wouldn’t be able to spare much time, that weekend, so having the focus of the game being in space and mostly about interfaces allowed me to be smart in the choice of visual assets that were to be produced. A few ships in the low poly style that resonate with my lego-playing inner child and that could all share the same texture, and some generic planet textures were all that we needed. We were joking about old-school EGA graphics while getting ready to jam and we thought it would be fun (and also super-fast) to do all the textures in that raw, dithered style. Had I had more time I would have followed through a lot more on that front, refining the look of the UI, for example, but this is not the part where I talk about our shortcomings, yet. In any case, one thing I’ve learned over time is that being minimalistic is often a smart choice on these occasions as it’s much harder to ruin a fun game with some bad graphics than to ruin a good-looking game with bad gameplay. Not that I would ever set out to do bad graphics!

Where’s the beef?

So, what went wrong? We actually compiled a list of good and bad points that I’m using to write this bit and the first element that the coders wrote down is their disorganization. Everyone started working on different tasks depending on what they felt like doing without too much concertation. From what I’ve observed, that was mostly the case in the first part of the jam, before the structure of the game crystallized into what it would later become. Quickly the structure of the team became clearer and having a spreadsheet of our different goals helped us get back on track. Even though we had a document that laid out all the different tasks and who would work on them, we didn’t always spend the time to fill it out step by step. Still, although respecting procedure can be vital on a long-haul production, it didn’t have too many ill-effects, in our case.

Yolo code:

Obviously in a format like that there are going to be shortcuts and quick and dirty fixes to solutions that might lead to a less than optimal code (they call it yolo code). But, in my opinion that’s part of the game. Not working together in the same room or even continent made organizing work the hardest part. Quentin, our veteran coder wasn’t always available to supervise and help out the newer members of our team, which in some cases led to some confusion and consequently loss of time. Also, the difference in time zones excluded Vincent of some of our brainstorming sessions. With myself being extremely busy over that weekend. It resulted in very little input from the part of the artists in the first stages of development. That being said, I’m still very happy in how things turned out in the end and the resulting moderated ambition in the visuals allowed me to participate at my own pace.

Stick around till the very end:

Myself and the rest of our team are mostly in Europe, so the end of the jam becomes something quite special when it’s 3AM. In the final hour, as we were struggling to push the game onto the servers, the moral support from everyone on the team, even though most of us had nothing more left to do, is something very dear to me. At every Ludum Dare that I’ve participated in, these last moments of a 72 hours marathon have always been a heartwarming experience and that is the main reason that brings me back here every time…

The end?

In a game jam, when you know you’ve only got 72 hours to get to a working game, you will necessarily have to cut some stuff and having to make such cornelian choices can often leave you with a fair share of frustration. But you know you’ve made the right choices after the game is published and (hopefully) playable, and more importantly enjoyable. In these cases, the frustration from cutting features and ideas can turn into something much more motivating and productive. In fact, (and I know it’s not the first time I say this) I have a very good feeling about what we started here. And I know I don’t only speak for myself when I say that I’d like to see this seedling of a finished game grow into something more. To be honest there must be at least five or six games that we’ve made where we said we’ll keep on developing this and make it into a commercial product, and I still believe that in time, at least for one of these games we will.

After all, aren’t that what game jams are all about?