We're proud to present to you our submission for LD40
https://ldjam.com/events/ludum-dare/40/space-dominator
Will you be able to colonize your procedurally generated solar system and stockpile as much resources as possible ?
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
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
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.
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.
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.
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.
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/
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.
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!
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.
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.
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…
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?
I thought I’d write a little sort of behind the scenes article about our game to attract some attention and because these game jams are always, in my mind, interesting experiences worth sharing. I’m sure for many usual participants it’s nothing new, as we all go through similar processes, but I figured it’s fun to share and, it might be of interest at least for some first time participants.
Crate Job Simulator focuses on the work day of a forklift robot operating in a futuristic warehouse. The player receives a growing number of crates over the 3 minutes a level lasts and has to ship them out according to demand. Obviously, as the theme suggests, the aim is for the player to get overwhelmed by the number of crates coming in and they will have to manage their stress and keep the warehouse organized in order to score the most.
6 people have worked on the game in total but most of it was done by programmers Quentin and Loïc with Nicolas doing the level design. All three of them worked together in Belgium at Quentin’s place.
I worked out of Paris on the graphics of the game but was only available on the evenings of Sunday and Monday.
Fabien joined the developers in Belgium on Monday evenin to gigve us that last little push we needed in programming and Vincent got in touch with us from Montreal and helped me with some polishing on the graphics.to
Most of the team was actually in the same room while Vincent or myself kept in touch via hangout. When I had questions or wanted to show what I was working on I would share my screen to the others and just leave the sharing on afterwards for a good part of the project.
Since most of the team was located in western europe, our time zone and the new deadline meant the we had to finish the game on Monday at midnight. The three hour offset was kind of unusual for us compared to previous editions of Ludum Dare.
It meant we didn’t have to lose too much sleep before the announcement of the theme and had a somewhat normal night before starting work on our entry. It also meant to me that, since I was working on Monday, I kind of felt that I had three hours less to work on the graphics in my already short available time.
Running out of space. We primarily focused our thoughts on the concept of small spaces. After moving some ideas around, the idea of having to transport crates became the preferred one all around.
The mechanic of the game was relatively straightforward which allowed us to get everything in place in order to have a playable version of the game quite quickly. Sooner than usually compared to earlier LDs. This also gave us time to refine the gameplay even further in order to be as much on point as possible.
In that process, one of the decisions we finally took was to drop a part of the game where you were actually aboard a spaceship. You had to manage the ship and phases of organizing and offloading had to take in account the different locations you traveled to.
In the end we felt that it complicated the game too much. Not only for the players but even for us in terms of balancing and having a game that is immediately fun to play.
At first we were going towards a physics based grabbing and dropping system but it quickly turned out to be buggy. Instead we decided to use a slightly less realistic but more robust snapping action like in everyone’s favourite cooking challenge.
Overcooked is an obvious reference. The clear top-down view, cameracentric controls and simple grab and drop mechanic were an ideal fit for a game like ours. The dash function became an obvious addition as well.
I didn’t have much time for the graphics (even for a game jam) so I turned towards MagicaVoxel for its fun interaction and quick (and cute) results. I took inspiration from other endearing robots like Wall-E or classic sci-fi builder Startopia’s Scuzzer, among other things, for their cartoonishly industrial look and cobbled together this sort of cute hovering robot.
This design direction actually meant to solve a whole bunch of animation challenges at once by removing any moving parts. Furthermore the two forklift spokes on the front are there to give a clear indication of which way is forward and what your task in the game is.
Textures were kept to a minimum for time’s and clarity’s sake and doing them in pixel art not only fit the voxels of the main character but meant that the players would be unconsciously decoding all of the details in their heads. Had I had more time, I would have liked to add some prettier particle effects around the player character as, right now, I don’t think it’s actually that clear that the robot is hovering above ground. Indeed we felt that having the character on tracks or wheels might induce the players to expect tank controls.
I also regret not having had time to add some more polished lighting to the levels. At least the current basic setup allows for a clear picture although somewhat lacking in dramatic contrast. Some red alert style atmosphere changes when the music speeds up would have been nice.
We were really happy to have a specialized level designer this time around. Nicolas spent most of his time on this topic and allowed us to feature five (FIVE !!) awesome levels in our submission. That’s a huge step up from our previous experiences and it definitely increased our overall production value.
In the final stretch Fabien joined Quentin and the others in Belgium and set up our leaderboards. We feel like it’s always nice to have the possibility of leaving your mark and comparing your score to your friends’. It’s the kind of details that can add that extra value to the overall gameplay experience and encourage players to come back and give it another go.
We’ve taken part in a fare share of game jam’s over the past years, now, and every time is still an opportunity to learn a little more. Finding interesting ideas quickly and managing production on such a short term are some of the categories we’re making progress in. However, one thing I think we’re getting better at is trying to keep the best habits.
We try to get decent sleep, eat as well as we can and, more generally speaking, we try to take the time to reflect on where we’re heading. As for myself, I didn’t even neglect my family this time around and it was totally worth it. Good teamwork can also from good communication. If you treat this like a miniature version of a "real" production, you also get a much higher return in experience.
It’s always tempting to go all-in into the development process thinking it’s a sprint, not a marathon. You can always catch up on sleep and all the rest while it’s done, right? But like many longtime participants, I’m sure, we soon realized that by doing so we were actually missing the point.
All in all, our main takeaway is that we had a ton of fun. Now we’re having another ton of fun playing our game and showing it to our friends and family and that, to us, is the real prize.
For an overeview of our previous games you can head over to Quentin's website and check out our previous entries.
Spoiler alert, or whatever...
With everything we managed to get done in so short a time, we didn't manage to find enough time to put the story screens into our game. But they exist ! And here they are ;)
Now follow this link and play The Curse of Uddh before you read the rest !! (https://ldjam.com/events/ludum-dare/46/the-fool-the-muscle-and-the-treasure)
Or if you want you can just go on reading right now :
Hope it will still want to try to play
The Curse of Uddh
https://ldjam.com/events/ludum-dare/46/the-fool-the-muscle-and-the-treasure
enjoy ! (hopefully,,,)
This morning we fixed a small bug making the camera ring and knobs very challenging to control. Also the game doesn't crash anymore when returning to the title screen.
We hope you'll check out our game, diving into the captured memories of Louise, Georges and Berthe.
