Hi Conga Master fans!
We can’t be happier! We are getting so many of good comments and reviews from you, that we’ve decided to make Conga Master, bigger and better!
We will let you choose from ALL the characters in the game, there will be more of them! and they’ll be different! some will run faster, some will get the attention of other dancers more than others… and more!
Stay tuned! And Thank You for all your good reviews!!
If you have played The Wewelsburg Experiment, maybe you didn’t know that there is an EXIT you have to find and that the castle is brand new, generated every time you play.
We didn’t have time to watch people outside the team play to get feedback, and we’ve been getting feedback now that make us think that. And so, we wanted you to know :). Open the map and try to get out of the castle!
Tags: castle, experiment, feedback, map, wewelsburg
For The Wewelsburg Experiment we recorded quite a few sound effects to give voice to all the Doctor’s transformations and to create a stormy ambience, but we didn’t have much time to work on the game’s soundtrack so it consists on a single track.
We just uploaded it to sound cloud in case you want to listen to it:
It’s a simple, happy and upbeat chiptune piece, composed in the free software LMMS and using the Nescaline plugin which mimmicks the NES sound chip. We’d love to hear your impressions on it!
You can play and rate the game (and the music 😉 ) following this link.
We hope you enjoy it!
When working on The Wewelsburg Experiment we knew one of the most important things for the game to be fun would be to have a ton of different characters. We even made some that didn’t make it to the final game (gamejams are like this I guess) and you can even find some graphics in the game folder that were not included.
Anyhow, we got to make a quite a few, and I was wondering… did you manage to play with all of them? 
Tags: characters, GameJam, unused
I cannot even type how happy we are to finally submit the game! There are some features that we wanted to include that didn’t make it but… I don’t think you can ever make the game that is 100% as you want it, right?
Please check it out. We hope you like it ! ^__^/
It’s been a hard but we did it! We have submitted “What happened to Michael?” on time. It’s our first “point & click graphic adventure”, and we must say we now have a lot more of respect for Ron Gilbert, Dave Gilbert and all other Gilberts… creators of adventures. Wow.
We had a lot of trouble with objects on screen so, please do try to beat the game (it’s fully playable!) the “Not now” are objects that should not be clickable, but they are there, sorry about that. If you need help, there is also a Walkthrough available 😉
We are happy anyways. Not bad for our first adventure and just a few hours. Cheers!
Hi all!
We have uploaded a video walkthrough of What happened to Michael, our entry to Ludum Dare 37, to Youtube!
Tags: adventure, LD37, Point 'n' click
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!
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!
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.
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!
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!
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.
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.
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…
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.
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! 😉
Tags: adventure, LD37, Point'n'click, postmortem