We have been reading all the comments you guys have left about “What Happened to Michael” and we thought you could be interested on how the development went so, we’ve made a postmortem!

What Went Right

The game

This is true in regular game development and even more when making a game for a Ludum Dare. The fact that you have to ship a game, that can be somewhat played from beginning to end is something that must not be overlooked. That’s the most important thing!

We always try to have a minimum shippable game as soon as possible and then add layers to it to make it better. Sometimes we get the core of the game right super quick and sometimes we have to deal with more problems than expected and the core game takes longer to be done. But this is an adventure game! Our first ever point&click adventure game! And we were close to not having a complete game to ship. But we focused on that and we did it!

The vision

Also worth mentioning is the fact that we shipped the game we envisioned on Saturday morning. More often than not, the projects we want to make end up not being possible. Maybe because the scale is too big, maybe because it’s not technically possible, or because the game is just not fun. Not to mention when each team member has a different vision in their heads. What does that mean? It means you lose effort and time instead of just getting all the effort in one single product.

We were all aligned to make this vision a reality and all components of the game were made to complement each other. The end result is a very cohesive game, and a game that looks like a “3 days of effort” game, because all the things we produced made it’s way to the final game.

Splitting programming tasks

Having two programmers in the team is a blessing when the work needed to make the game can be split, so each programmer can work independently.

This game had a big core gameplay task that, if assigned to just one programmer, would leave the other programmer with little amount of work until some assets were ready to be added to the game. We didn’t want idle people but sometimes it is better to leave just a single person dealing with a big task. When we realised this, we think it payed of. Save the core gameplay! Save “the game”!

The other programmer had to wait a bit for art and sound assets to be done, but alas he got a lot of work to do on texts aesthetics, abduction effects, and little details that add quality to the game!

Trust

When building something as a team, trust in your fellow team members is a must. This way everyone can concentrate on their work and know for sure that, whatever other members of the team are making will be great.

For those things we were in doubt, we knew we could ask for help to others and get good feedback when needed!

What Went Wrong

Communication, tasks and time management

One of the big problems when making a game for a game jam is usually we all want to start doing our work, and forget about everything else, because there’s a lot of work and little time! But we must do some team work before that. Ensure we’re aligned in our vision, make a bit of pre production work so we design the game, the software and assets in a way that help us get the job done as quickly as possible, and make a little planning of the tasks and time we’ve got ahead.

This is usually not super easy to do because designers, programmers and artist all speak different languages (not literally). We’ve done together as a team several Ludum Dares, always at Undercoders’ offices. However this time it was different. One of the designers, and producer (that’s me ^^/) was in a different city that weekend, and the remaining three were at a new location. The university facilities were the designer and artist of the game was, at the same time, organizing a Ludum Dare onsite and helping his pupils. And this place had a fixed schedule and was open only from 9 a.m. to 8 p.m.! That made things a bit more  challenging than usual!

What this meant is we were not able to clearly identify a design for the dialogs that would help programmers implementing it and vice versa. Also it took time to decide on getting just one programmer on the core gameplay to try and save the core, and set the programming tasks not related to the core.

Scale

Having played classic and modern adventure games we thought our one room game was so small that we could just write the dialogs on a Google Docs doc with a few notes on dependencies and there would be no problems. Also we chose a way of programming the whole thing that made adding or fixing texts a bit difficult but… it’s a small adventure, there won’t be that much text right? Wrong.

We underestimated the scale and work needed to make even the smallest adventure game and we payed the price. As we added more text, we started realising how confusing it all started to become. We had to cut the number of objects down to just those that made the story advance and we had one programmer exclusively adding all the text, fighting the mess it all had become.

31 objects to interact with were planned

A bit late though, remembering a post on Ron Gilbert’s blog, we transformed the document into a tree of dependencies.

Lack of iterations

As mentioned before, we like building the minimum shippable game we can and then add extra stuff in order of importance. This time, the minimum shippable game was done a few hours away of the deadline and we were all tired (here in Europe, Ludum Dare ends at 3 a.m.).

So even though we could play the game from beginning to end, there were some important features to add. Features that were designed since the very first morning, but that we didn’t have time to add.

The game was not supposed to show as clickable objects those you cannot interact with at a given time in the game. But they were there! And there was no time to fix that so we had to add that sentence everybody hates now: “Not Now”. Otherwise the game would look broken and players would stop playing.

We wanted to have text we’ve read before marked and be able to skip the texts. We had time to add the ability to skip text… but unfortunately very close to the deadline we found an important bug related to that feature and we had to remove it entirely.

And so on…

Bugs reporting

This one is a classic. You feel the deadline approaching, test the game and start reporting bugs skipping all the right procedures to report bugs (say Trello, bugzilla…) and instead report them through Slack or just talking directly to the programmer. Which causes some fixes that were feasible (like changing the unreadable blue text color) to get lost, like tears in the rain.

Conclusions

I cannot overstate enough how important Pre Production is. We got right some things on pre production, like aligning all minds on the same vision, but we did not on how to make it easy for the programming and the writing to come together nicely.

Making a good pre production saves a lot of time while in production. Never forget that! 😉

Hi all!

We have uploaded a video walkthrough of What happened to Michael, our entry to Ludum Dare 37, to Youtube!

A few days ago we posted a post mortem piece sharing how we created Michael’s Room for our LD37 mini adventure named What happened to Michael?. Today, we’re going to take a look at how we created the characters for the game.

Once we had the idea for the story written, we started to develop the characters. The story is centered on Michael and his mom, so those were the first two we created. We imagined Michael as a 90’s teenager (the game takes place in 1998), with a classic rebel attitude, and his mother as a 40 something tired and worried woman.

The FBI agents had a secondary role, but one of them had to be playable. Since Michael disappears under strange circumstances (no spoilers! 😉 ) We quickly imagined them as our favorite 90’s show protagonists. You can probably see the resemblance!

This was the first version of the cast. As we did with the room, the first thing we created was the outline of the characters, in order to be able to use them as placeholders when writing the code. Having a clear idea of the scale of the room and characters was important, in order to create a consistent space and perspective. Thanks to this, soon we were able to try them on set:

When coloring, we decided to go with pale and slightly unsaturated colors, in order to go with the moood of the game, but at the same time more vibrant than the bedroom, so that they would stand out from the background.

This was the first version of the colored characters. As a homage to Conga Master’s protagonist (our Ludum Dare 34 entry made one year ago), who has also called Michael, we used the same color scheme for his T-shirt.

Since the room has perspective, we drew the characters at their biggest size (the closest point to the camera) and scale them down by code when they walk to the back of the room. The scale is roughly a 75% of the original size. You can see this in the following example:

The last step, but probably the most time consuming one, was to animate the characters. Two of them, Michael and the FBI agent, had to be playable and move around the room so the needed walk and interact animations, while all of them needed an idle and a talking sequence. The animation was done frame by frame, here’s an example of a complete spritesheet:

Once we had the game working we noticed Michael’s mother needed an extra animation when…. well, things don’t go as expected (as said before, we won’t be spoiling the story! 😛 ), so it was added in a last-minute effort:

The story is quite emotional, so we thought that, even if time was scarce, it was important that some actions had a powerful visual reaction. Lastly, Michael had to go to sleep, so he also has an extra  frame when he goes to bed.

And that’s the process we followed when creating the game’s cast of characters. A few additional animations were desired if we had enough time, namely different talking loops (since there’s quite a bit of talking) and some object-specific reactions, but we were able to produce the minimum we had planned to have a complete game. In retrospective, we’re quite happy with the result but, as always, there is a lot that could be improved here.

So, we hope you enjoyed this second piece of post-mortem, please let us know if you have any comments, suggestions or questions. We’d love to read your opinions and feedback. If you haven’t played What happened to Michael? you can play the game following this link.

Cheers!

With the jam over and our game posted, it’s time to look back and take a look wt how we created “What happened to Micahel?”, our mystery mini adventure for this Ludum Dare. In this post we’re going to talk about how we created Michael’s Room, the one and only setting for our game following the Jam’s theme.

The idea was to create a setting inspired by our teenage bedrooms from the mid-90’s  (after all, we’re all 80’s kids!), which would have enough content and information to define the protagonist. We decided to use a pixel art style with enough resolution to be able to differentiate objects and put some detail on them. Since we needed placeholders as soon as possible, we started with this version of the room:

This had the basic elements we had discussed when designing the game: big windows, a computer, shelves and a bed. It was of great help to have it soon during the development process but, of course, there was much to improve.

Once we had the placeholder characters moving around the room and a more complete version of the story, we added more key elements which were needed. The version with most of the objects looked like this:

Can see a red dot in the middle-left of the screen? What was the vanishing point used to establish the perspective. In this version we added a secondary shelf, the chair, guitar and amp, a GameBoy and the inevitable posters we all used to have in our bedrooms. The door was also added and the right shelf had to be cut in order to make more space for it. A foreground layer with a cabinet was created too in order to add some depth.

Here we have the same version of the room with the first version of the characters. We had a placeholder character from the beginning in order to establish a scale and make all objects coherent in size.

All of the objects were created on different layers, so that coloring was easier. This way we could also hide and show objects (or even eliminate them) if we needed to. We also needed to create a night and day version of the room, so having everything in different layers would make it easier to change the tone of the room. Here’s a first colored version:

At one point we were so used to the “outlined” versions of the graphics that we considered making the game that way, but after trying some colors we decided it looked better with some volume. Due to the nature of the story (no spoilers 😉 ) we used an unsaturated and brownish color palette.

With the first colored version we also added some basic shadowing, making borders a bit more smooth. The room had most of the content we needed, but it still looked very plain. Luckily there was enough time to give it some personality:

And this is the final version of Michael’s room. As you can see we added a bit more shadowing to the ground and walls, as well as tons of objects on the shelves and the content of the posters (can you recognize them? 😉 ). The door plays an important role on the game and, as you can see, it is drawn on a different layer so we can have it open and closed. The same goes for the font cabinet.

Two additional versions of the room with different lighting appear throughout the game, according to the time of the day and the events of the game, but we leave that to your discovery when you try the game

In retrospective, we also would have liked to add a bit of animation to the scene and visually interactive elements (such as drawers opening and closing), but with the limited time they ultimately had to be cut out. With the layered design, though, it won’t be much of a problem to have them in future versions!

And that’s how we made Michael’s room. Hope you enjoyed this part of the post-mortem, please let us know if you have any questions, comments or feedback! You can play “What happened to Michael?” in Windows, Mac or Web in this link.

Cheers!

Hi!

Two Ludum Dares ago we did Conga Master and got great scores (thank you!!) #21 Overall, #5 Fun… ^^ so we decided to work on it a bit more.

9 months later… Conga Master has been released on Steam, GOG and Humble Store with more than 30 characters, 7 clubs, local multiplayer modes… ^__^ We hope you enjoy it as much as the Ludum Dare version!!

How we created The Wewelsbug Experiment‘s procedurally generated castle

Besides the multiple transformations of the game’s protagonist, we also used the Shape Shifting theme in the Castle: every time you play, the castle layout and rooms are different. Today we’re going to explain a little bit in depth how we achieved this!

We wanted every gameplay to be different, but at the same time we didn’t want the castle to be completely random or unfinishable, so we created a set of rules that every castle layout should comply:

• The initial room has 4 exits.
• The minimum distance between the initial room and the exit, must be of 10 rooms (where 10 can be set as a constant).
• All the rooms in the ideal path have 4 exits.
• The rest of the rooms can have from 1 to 4 exits.
• The platform layout of every room must guarantee access to the 4 exits.
• The single exit rooms located furthest from the exit must contain health packs.
• All rooms must contain, at tleast, one enemy.

One layout of the castle, via the in-game map

These set of rules guaranteed a playable castle from begining to end, with a reasonable size. Even if players take the wrong path, they won’t lose a lot of time and they’ll be rewarded with health packs to avoid frustration. Exploration rate was also added as a bonus, in a Castlevania fashion.

In order to apply the rules, the algorithm starts always with the initial room and builds a path of 10 rooms until the exit (taking care not to create U turns). Once the path is created, we create a matrix where the initial room is on the center and the exit on one of the borders.

After that, we backtrack from the exit room to the center room, launching a backtracking algorithm which creates a new room with any number of exits from 1 to 4 for every exit in a given room. This way we can create the rest of the castle in a consistent, yet variable fashion.

A health pack in a single exit room

Health packs, platforms, enemies and platforms are added once the castle has been shaped, simply following the mentioned rules.

Aesthetically speaking, we created a large number of backgrounds and decorative assets. Backgrounds and assets are combined in a way that the rooms are also visually different every time.

Procedurally decorated room

In the screenshot above, the algorithm has curiously spawned 3 pianos (we should have limited repetition, a painting, a clock a statue and a couple of chairs. The lamps are also spawned procedurally, in this case we have two of them.

As you can see, the algorithm is pretty simple, yet the results are quite satisfying when it comes to creating a shape shifting castle! You can check them out yourself by playing the game and using the in-game map.

Of course the time was little and there are a few rules that we would should have included, in order to provide a better experience. Most notably, don’t spawn enemies near exits (the top platform ones are sometimes unavoidable if you take the bottom exit), limit the number of same assets in a room (piano galore!) and create warp rooms (to go back to the initial one if you end up in the wrong side of the castle).

But oh well, that’s the great thing about a Ludum Dare: create something that works, but evaluate how could you do it better with some more time.

So, wht do you think about our Shape Shifting Castle? We’d love to read some feedback on it! 😀

The Wewelsbug Experiment

“And now… for my final experiment!” are the last words of Dr.Poochie, before becoming an uncontrollable shape shifter in his quest to escape from a shape shifting castle.

We had a lot of fun developing this one, especially coding the procedural generation algorithm for the castle, navigation system and balancing the abilities of the different transformations.

We had some time consuming bugs with the combat system, which forced us to leave out some content which had been prepared, but the game is playable from start to end (ending included!)

We’ll write a post mortem in a few days, but for the moment here’s a short gameplay video:

The game is made in Unity and works on Win/Mac, check it out here!

We’d love to hear your feedback!

Hi everybody!

As we were super thankful for the great reviews, we decided to make Conga Master bigger and better. And here it is! All the things we are working on and a brand new video. We couldn’t wait until 2016. WE ARE ON STEAM GREENLIGHT ^__^/

Please give us a thumbs up and go and do the conga tonight!

The Conga Master team wishes you ALL THE BEST FOR 2016!

–

Hi all!

We’ve been working hard on our game Conga Master for the Ludum Dare 34 jam so we didn’t have time to post anything. But here it is!

Conga Master

http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=66146

This is our game. All graphics and programming were made during the Ludum Dare, and much more! Because we did several prototypes trying different controls. Moving your feet with two buttons, one for each leg, choosing your direction using an oscillating arrow and a button to run, etc. We took our time but we believe the end result feels super nice. What do you think?

We wanted to add different kinds of people affecting the gameplay. Say you got lots of geeks in your conga, then cool people would hesitate longer before joining. Eventually we decided on the pig idea which everybody seems to like :).

Please play the game and tell us what you think! We can’t stop playing to listen once and again to the music while dancing all around!