A game made of stop-motion animations ? That was a “risky” bet!

So…there are only 5 days left to rate the game, maybe it’s time for us to write a small post-mortem [EDIT: not that small eventually] in order to explain how we made the BIGGEST GAME in Ludum Dare history! 1,14GigaBytes! Shi*! That’s more than Minecraft!

Size does matter

By the way, you can play and rate the game here!

Post-mortem below! (because it’s big too)

WHAT WENT RIGHT

Pooling talents (and extra constraint)

Before this LD, I was used to make games, but didn’t know anything about stop-motion animation.

On the other end, Felix was used to make stop-motion animations but didn’t know anything about game making. So, naturally, we thought we should make a stop-motion animated game, whatever the theme, and that’s the main reason we worked together on this LD.

I think that was a pretty good idea cause we both learned some new things, and because the more constraints you have, the more creative you get.

Felix working on the “Agricola’ scene

Getting prepared

Since we had no idea how to make a stop-motion game, we took an afternoon before LD to experiment things and sharpen our tools. That way, we discovered some problems like files incompatibility, scaling, cut out and could avoid them during the competition. Unfortunately, one big problem managed to slip through…What was it ? Suspense! Read further.

Hot Chocolate

Hot Chocolate is part of my own LD ritual. Every Ludum Dare, I wake up at 8, I look at the theme, and then I go out to order a hot chocolate and croissants in my favourite café (in France, the theme is announced at 3-4am so…it seems wiser to have a good sleep and discover it on the morning). I think going out is a good way to find inspiration, even if I can’t scientifically explain it. It always worked for me, and this LD was no exception. Of course, this time, we ordered two hot chocolates.

Fan

Since it’s pretty hot in Marseille, and since we spent two days together in a small flat with the curtains closed and the lights on (for the shootings), buying a fan was a DAMN GOOD idea.

It’s getting hot in here…

Time management

We didn’t use any time-management technique or whatever, but we managed to be extraordinary synchronized. While Felix was building his studio, I was coding the basics, while he was shooting an animation, I was writhing its dialogs. That way, we always could know precisely what was done, what was left and how much time we needed. Eventually, everything was made in time

Funny breaks

We didn’t take many breaks (except for eating and sleeping) but kept finding new ways to make the work funnier : drinking real rum for the Red November animation, inviting some friends fo the tarot animation, finding funny way to destroy the Monopoly…In the end, the game making was fun all along, and I can’t think of any better way to make games.

Cheers!

WHAT WENT WRONG

The theme

When the theme was announced, we were really happy. This theme was the one we were expecting. It was a big relief, and at this moment, we knew theme won’t be a problem for us! How ironic, here are some comments about Coin-Operated Afternoon :

I don’t understand how it correlate with evolution theme

I didn’t really get how it involved evolution

I don’t see the relationship with the theme

I have to say I don’t see the theme clearly either.

And so on…

So, obviously we failed!

We wanted to make a game about evolution of game mechanics through boardgames and to show boardgames evolving through the animations, but it looks we had so much fun making this game that we forgot a bit our initial idee

The flat was a bit messy

Sounds and Music

We never planed to have any sounds in our game, but we planed to have some music. Jay, the third man of the team, which is a great musician, was supposed to be in charge of this aspect. Unfortunately, during this week end Jay

– wasn’t in the same city

– was quite busy

– had no internet connection

– and didn’t even have a windows computer to play what we were making! ^^
So, even if we thought it was still possible to make something with him, it obviously didn’t happen. This is a shame because Coin-Operated Afternoon REALLY NEEDS music, so I hope we’ll make a post-post-compo version to complete the game!

HUGENESS (no shit ?)

Ok, we were aware that making a game in stop-motion will lead to a big .exe file…but 1,14GB ? Seriously ?! Well…it looks like Adventure Game Studio wasn’t made to build stop-motion animated games. The good news is that it allowed us to break a new record! I really think we’re the first ones to reach the 1GB limit in Ludum Dare History ^^ (but I might be wrong)

-Hey I got an idea! What if we turn the game in 8bit colors to lighten it ?
Oops…bad idea

And that’s it

Yeah, that’s it. Except for these “little” problems , Coin-Operated Afternoon went RIGHT! We made the game we wanted to make, we had a very good time, and we’re very proud! So once again, thanks Ludum Dare for making people happy!

Multi-player games need YOU!

We ought to get together a list of multi-player games and, on say the last few hours of voting or some time we can all agree on – rendezvous in-game.

Because for the poor soles rating games when they are alone in the game-would, it must be hard to appreciate them.

I’ll be sitting in my multi-player game hoping you’ll come and appreciate it!

FOR THE darWIN – Jam Entry

The Idea

Before starting to come up with ideas, we sat down and wrote a list of what we were NOT going to do. By determining early on, what we were not going to do, it greatly helped narrow the scope of the idea. The biggest things we decided was that we would not do anything related to character evolution (leveling up, gaining powers, etc). That threw out a ton of ideas we were spitballing. Over a bowl of ramen, Nolan and I started brainstorming a game where you played Darwin, and had to discover evidence of evolution. As soon as we connected this idea to fast paced Match-3 style mechanics, we were set.

Code, Travis Chen (@TravisChen)

Most important thing here is to use what you’re comfortable with. For me, that’s Flixel. When I’m making game jam games, I dedicate more than half of my time to tuning and polishing the gameplay and user experience. Being comfortable is key so you can get to polishing and refining the experience as quickly as possible. Below is the code and also a game jam template I’ve created for future games:

The code for the project can be found here: Github: FOR THE darWIN!

Template project, I’ll continue to refine this: Github: Flixel Game Jam Template

Art, Nolan Fabricius (@ShiftlessHobo)

I’d like to point out a couple of things that may not be obvious upon one’s first play through. Firstly, the preist has Gout, That’s why he winces when he walks. He spends every waking moment in total misery. Secondly, Darwin’s jumping ability is historically accurate and not exaggerated at all. In sumation, I  regret the lack of weather effects, I feel like setting the game during a hurricane would’ve “totally flipped the script” so to speak.

User Learning

I wish we made the skull sequences for the game more clear and gave a little more instruction on what the player is supposed to do. While people seem to love the game, I think a number of people are missing some of the experience because of not understanding the sequences. So here’s a hint!

Play and rate FOR THE darWIN here!

And play our other jame games here!

Hope you all enjoyed playing our game as much as we’ve enjoyed playing all of yours! We’ve played over 100 games and are continueing to play more each day. 

Until Next Ludum!

Travis & Nolan

Well, now that Ludum Dare 48 #24 is done and the voting is almost over, I figured I would go over how I felt it went. First I’d say I was happy that I was able to produce a finished game, even though it lacked a lot of what I wanted in it as a final product.  I started the event by getting sick right off the bat and fighting an illness the entire time, this set me back a lot.

Here is what I did accomplish:
Completed the story for the game.
Completed the code and multiple paths and ways to lose.

Here is what I wanted in the game, that didn’t make it in the initial release:
Background Music — I had tools to do it, but didn’t know how to properly use them.
Sound Effects — Once again I had the tools, but lacked the knowledge.
Background Art — This was a big one. I had planned to hand draw all the backgrounds and scan them in.
Saturday morning the scanner fell and broke, leaving me at an impasse as I didn’t know how to draw well enough directly in Paint.Net

What I learned from the experience:
1. Expect the unexpected. Be prepared for illness, The loss of a type of toolset and any number of other things that could and probably will disrupt you.
2. Know your tools, having them available isn’t enough, if you have to fumble around with them to figure them out. With only a short time span you just don’t have that sort of time.
3. Have a back-up plan for any set of tools/hardware. If you plan on using a scanner for hand drawn art, plan on the possibility that you will need to go another route and be prepared for that outcome.

How I feel about the experience in general, is great. I managed to produce something instead of just thinking about it. I am sure in the future I can make much better games without the time constraint. So I plan to do just that, LD48 was the kick in the pants I needed to start developing myself.

Where does B M S go from here:
Well, I enjoyed the project and decided that I would add the things that I wanted in and release a 2.0 version.
I have added the music, as well as one of the many backgrounds.  I also have begun fixing grammer and spelling errors within the original story.
I plan to add a few extra scenes and lengthen the game, beyond what it is currently.

My LD24 48-hour entry Darwin Award was an infectious disease simulation with some population genetics thrown in.

A new post-compo version is available that allows the user to tweak all the various simulation parameters and adds some visual indicators to make the game play less opaque.

Hello Everyone,

First let me apologize for the delay. Thank all of you who played the game, left comments and feedback.

Now on to the Post Mortem:

Things that went well:

• Unity Is a great engine. Simple to pick up and work with. Curtis, our lead programmer, happens to actually be an artist first, and over the course of a couple of months was able to gain enough knowledge to make a solid game loop.
• Using Google hangout to coordinate everyone.
• Blender, My Paint and Gimp provided all of us a smooth pipeline for rapid asset generation.
• The Aesthetics, the team managed to keep a consistent look throughout the game.
• Spanking Boars was strangely addictive.
• Misfit Chris awesome music.

Things to improve:

• Camera System, It’s hard to see around corners and you could be attacked without warning.
• High level of difficulty, with high level criteria and no health pick ups, the boars can easily destroy you. Maybe that’s a plus thematically. (Survival of the fittest.)
• Death bug. It’s a very minimal bug that doesn’t break the game but can be annoying.
• Add Particles!
• Improve Animations speeds.
• Story elements.

The only bad thing that happened during the jam was when we opened the Pixel Oaks hangout to the public, we had a random ‘visitor’ show us his ‘metapod’s’ harden ability. We immediately reconsidered and switched our hangout to private.

Most of the things on the improve list are being worked on as we speak and most have been fixed, but we are also heavily considering making a full game based on the characters of the game.

If you have not done so please play our game and tell us what you think. You can view our entry here. Or click the picture.

Make sure to follow PixelOaks.com for any future indie projects from us.

Hello, fellow jammers!

we’ve had a bunch of family appointments lately, but finally managed to write a proper post mortem! This time, we experimented with procedural level generation – this is at the core of Singularity’s design and was where we spent the most time during that crazy weekend of sleep deprivation and an unhealthy peanut based diet. We wrote a post in our blog explaining in details how the procedural level generator works, take a look!

In our postmortem we do talk a little about how we spent our time, but the main focus is on what we learned about procedural level generation. But there are dev screenshots too, for we love those things, don’t we?

Placeholder graphics being replaced through the weekend

Yep, that awful head was the avatar in our first tests! For the close observers, you’ll notice that the bizarre archer enemy that starts spawning at about Difficulty 5 is actually the silhouette of a placeholder enemy that we didn’t have time to replace! 😉

Anyway, several hours putting background graphics together and programming particles everywhere, the game got a substantial visual overhaul mostly during the last day. Here’s another screenshot of how it looked by the end of the day:

So, to cut to the chase:

What worked

*The level generation technology works well, and is fun to create and to play!
*The brainless gameplay summed with infinite levels gave the game a good replay factor, despite its very limited development time.
*The open, non-content-based design enables us to expand the game more easily, if we want.
*The ease to test game balancing and incorporate new mechanics in the middle of real levels makes it much easier to balance and prototype new ideas. A new jump height can be tested in an infinite amount of situations, a new kind of cannon can be easily tested in all sorts of level topographies and in the middle of other obstacles.

What could have been different

*Specifically in the context of Ludum Dare, most players don’t play the same game more than once, due to the need of playing many other games. The levels being different at each playthrough isn’t something that makes a difference for those particular players.
*The enormous amount of time spent with technology and playtest left us with a short time for aesthetic polishing. The silhouette based graphics is interesting and easy to create, but we’d need more particles, shaders and color balancing to reach the level of quality that we originally aimed for.
*The possibility that the level generator could create impassable levels led us to create ‘conservative’ level chunks and less randomization than we’d like.

Take a look in our blog to see how the level generator works, to know more about us, or our main project The Journey of Eko, for which both Singularity and Tiny Shard are some sort of prototype. Or just find us in Twitter (@pixel_cows) and say hello!

And for you hardcore platformer fans who missed it, you can get Singularity HERE!

This is our second time in Ludum Dare, and once again it was a lot of fun! It is a true honor to be part of this great community. You guys ROCK!

Cheers from Brazil

Gabriel and JP
(@pixel_cows)

Ahoy all!
Here is quick post-mortem about my LD24 entry called Deep Sea Fish Loves You Forever. The game is about piloting an underwater exploration robot and analyzing oceanic wildlife with a pink sonar.

What went well

Tech & Engine
I used the same technologies as I did during my other 2 Ludum Dare and this is really paying off. I am now very fast when it comes to prototyping and testing things in Bacchus (my custom game framework written in Haxe). The only tech problem I had was due to a recent rewrite the audio part of my framework, more about this below.
I don’t think I fixed a single engine bug during the whole weekend.

Timing
My schedule was similar to last time.
1. Do graphics on Friday night (I hate using programmer art so I start with gfx)
2. Write the core game mechanics on Saturday
3. Make a title screen and winning/losing conditions on Saturday night
4. Add audio, polish gfx and playtest on Sunday

I think it worked quite well, except that my (few) testers did not find too many bugs so I ended up submitting early. I could have added more species to the game but I was afraid to break the balance (which I thought was good (it’s not)).

Iterations
Testers were very useful not for finding bugs but for highlighting usability issues. It is thanks to them that there is a species counter in the GUI. This feature makes the game’s objective a lot more explicit, I’m really happy someone came up with it (thanks Phil!).

I also used them to improve the opening tutorial. My first testers didn’t understand much about the game because the tutorial had too much text and some of it was not explicit enough. I had enough time to redesign it and then to improve its texts later on. It went from this to this:

Assets creation
During LD#22 I wasted a lot of time doing pixel art (and an 8-frames long walk-cycle!). This time I painted things with basic Photoshop brushes and scaled them down. I think it looks quite good and it took a lot less time. The only thing where I worked on the pixel level is the GUI but it didn’t take too long because it’s very geometric.

Audio was a pleasure to make using Reason and my Akai MPK Mini. I had not done anything audio-related in 6 months so I spent a few hours reading and watching Reason tutorials the day before to get back in the mood. It was my first time writing some Electro-ish music and that was a lot of fun. I used a morse signal sound for the main the track intro (just for fun) and I was inspired by The Future Sound of London for claves’ sounds on top of the beat.

I didn’t have a microphone this time around so I made all the sound effects using synths, but this was ok because most of them are mechanical anyway.

What went not-so-well

Theme & Concept
Evolution is not one of the themes I was looking forward to and I had a hard time coming up with something. As always, I was very stressed at the beginning and settled for a vague idea quickly. I thought I would make a game where you play as a bacteria and evolve from species to species by consuming radioactive pills in order to solve environment puzzle (think Space Station: Sillicon Valley on the N64). Of course there was no time for that so I scaled it down from top-down to underwater and side-scrolling. Then I started doing art, without any other ideas in mind. By the end of the night I had drawn all the fishes that are in the game (and a radioactive barrel which isn’t) but I didn’t have any puzzle or gameplay ideas to accompany them. It was supposed to look like the following picture. I think this scale looks a LOT better than the one I ended up using but I didn’t want the player ship to be 5 pixels big. Maybe I was wrong.

The next morning I realized this was not going to work because I would never have the time to do environment puzzles, animations and gameplay programming for all the species. The challenge became to find another game concept where I could use all this art while keeping the evolution theme. After half an hour of panicking, I came up with the final concept. As a result, it doesn’t fit the theme too well (esp. in its gameplay).

Computer
My computer did shut down without a warning twice during the weekend. The second time it did, it decided not to turn on again so I went to bed. The next morning I had to open it and replug the hard drives, I think the SATA cables were twisted too hard or something. That was very scary and I thought I might have to go finish my game at the office (it was under version control so I wasn’t afraid of losing any work).

Food
I put some barbecue sauce in my sandwiches and omitted the eggs. BAD BAD mistakes.

Performance
I heard the game was very very slow on some computers =(
I didn’t pay any attention to performance because everything was running at a solid 60FPS on my machine. Some obvious optimizations could have been done to improve that. Not drawing a 2000 pixels tall half-transparent gradient on top of the screen would have been a good start.
Also, I found out that the new audio work I had done in my engine was painfully slow so I added a dirty one line hack to bypass it.

All in all, I had a lot of fun and I’m very happy (and proud!) I made this game, even though it’s far from perfect. Thanks a lot for reading and for being such a friendly community!

Tags: post-mortem

This entry was posted on Thursday, September 13th, 2012 at 3:08 pm and is filed under LD #24. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Finally I found some time to make a post-mortem for “Watercolor Wheel Evolution“:

What went well:

• Letting my daughter with her now 3 years doing the art. She did incredibly well, had fun doing this (as every time she can make some watercolor pictures), and was really impressed with the result in the game. Seeing her self painted creatures move along the screen put a really big smile on her face. Is there a better way to give your child some insight into your game-making hobby?

My daughter at work doing the game sprites.

• Being in the jam – not only due to the teamwork but to have this extra day. This is quite valuable with wife and two children at home.
• Fixing late bugs. Wow, it is quite scary everytime what strange bugs will appear if your game is almost finished and the deadline approaching. But I could fix them.
• Noticing the progress I’ve made since my first LD one year ago. This is one of the greatest aspects of this time restricted jams. You really get a hang on efficient techniques for creating and developing and also improve in code structuring even if it’s still quite a mess compared with a project in a more extended time frame. The sound/music recording, which cost me some time last LD, was merely a routine this time.

Like last LD: totally professional recording equipment.

What went wrong:

• The game mechanics. I totally missed the point with giving the player a good incentive doing the things the player should do to make the mechanics work. I don’t know if that was due to lack of testing the game or a misconception of the whole mechanics.
• Social (real) life. My wife fled with the children on sunday noon as I was too much into game development. Returned in the evening ;).

So if you like to, you can play and rate here.

The result.

Tags: handdrawn, post-mortem, pygame, python

Hi!

I will talk about Moche, a screen splitting game.

First, comments on my game made me pretty happy – insane is probably the most used word to describe the game, so I think I have accomplished what I wanted.

I have made a post-compo version of my game, which correct many problems. The time I spent on post-compo has been really usefull to understand my errors.

What went well

Engine

I have used Unity3D to make a 2D game. Using a 2D engine would have been really benefical for the performances, allowing a better optimisation than the use of multiple Cameras on Unity. However, I think I’m much quicker to create mini-games in Unity. So, even if it would have been much better to create the game with something else, I don’t regret using Unity for the ludum.

Sound

Well, for my first attempt doing sound, I must tell I’m pretty happy with the result. With some tips from friends, procedural music generation with MIDI sounds is quite easy and fast to do, and not so awful.

What was just OK

Bugs & Crashes

Well, I couldn’t fix all the bugs for the ludum. But a huge problem was the game crashing when you were splitting too much – depending of your computer. Many players have crashed the game while testing it, it’s a shame. I knew that, but decided not to spend time on this issue. However, I started investigating this for the post-compo version – I have really improved performance, and you should crash way latter now. This improvement took me 5 or 6 hours, so I think I’m pretty confident with the fact of not having it fixed for the ludum – I prefer a ludum version with more fun, even if it crashes.

What I did really wrong

Graphics

Ok, graphics are bad. Really bad. But I have the talent of a 4 year old child when it comes to drawing – and Moche means ugly in french, after all.So yeah, I would have liked better graphics – the game would deserved them – but I just can’t, sorry.

Comprehensibility

Here is the real problem : game is really hard to understand. You have to split the screen to improve your score – when you split, the two created screens perform different actions. First, there was no border between screens in the ludum version, which made it really hard. I’ve added this in, like, 10 minutes in the post-compo version, and it really adds much to the game. In the same way, the fighting game had absolutely no feedback – nobody understand what happens. Again, in 20 minutes I added feedbacks for the post-compo version. You also are given a bonus (invincibility for the runner, unsplit for the fighting game), but this is not explained, and really not understandable.

So, the real error done was : not having anyone testing my game before the end of the ludum. We were three people in my house, I was discussing with friends on IRC, I could have made them test the game to have clues about this. I will think about that for the next ludum.

Scoring

I think the scoring system is quite funny, but it had no leaderboard, so it wasn’t really usefull. It took an hour to add an online leaderboard for the post-compo version. I should have done that sooner.

Conclusion

Well, I’m pretty happy with this ludum, and definitely want to do the next one. Playing a lot of games is fun too.
Oh, and if you want to play, try the desktop version, I find it less crashing than the web version – and check the post-compo too !

Play

Hi guys, we spent our week to finish “Promoted!”
We are polishing it right now,
Hope you will be able to play it this week-end.

Hello fellow LD people!

I have participated in Ludum Dare 24 with my game, Dissolution. Many of you said that you wanted more of it, so I’m beginning to work on more. An awesome writer is working with me to bring more depth into this project. Together we will explore the subject of life and death and, well, dissolution, as deeply as anyone has ever explored in a game.

But in order for this epic project to succeed, we need your support. I’m sure that you will buy Bundle-In-A-Box (http://bundle-in-a-box.com/) anyway, so when you come to redeem your games, please vote for Dissolution if this is something you think you would like to play as a full game in future. The more votes we can get—the closer we will be to receiving a grant, it’s really that simple.

Thank you!

PS: If there are any troubles with the list, or you have feature request or opinions, let me know in the comments. I really want to make this an easy way to rate low-rating games.

This entry was posted on Friday, September 14th, 2012 at 1:21 pm and is filed under LD #24. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

We didn’t manage to complete the game on time. That’s why we’ve just finished and released it today. The result is:

Codename E

Codename E
Program the robot’s behavior. Guide him through all the obstacles to the exit. Collect all of the modules to extend its functionality.

How to play
In the command input window (> _) sequentially enter commands to move the robot. The list of available commands appears in the RTFM. All commands have the following form – AAX, AA where two-letter command, X parameter of the function (from 1 to 9. Typically, the number of tiles to move).

For example, to move the robot forward for 5 tiles, enter MF5. Need to type all the commands to complete a level. Limit – 15 commands.

We used:
Programming Language: Monkey
Framework: Flixel for Monkey
Graphics editor: Inkscape
Level Editor: DAME
Sound editor: Bfxr
Music editor: GarageBand for iPad

After the competition the game has changed little. Bugs were fixed, interface was finalized and sounds were added.

You can play flash-version of the game here – http://lab.devolonter.ru/games/ld24/codename-e.html

What went wrong

– We spent a lot of time choosing the plot
– Even longer we were choosing visual style
– We didn’t have enough experience working with tiles
– We were very tired

This was my first foray into the LD compo and my first postmortem, so here goes…

What went right:

I spent about 2 hours thinking about the theme and how I could marry the theme to the game mechanics before I did any asset development.  I did not get started until around noon on Saturday.  Even then, instead of diving right into code or asset creation, I just sat on my back porch for several hours and thought about the theme.  This allowed me to focus on what mechanic I wanted my game to have and how it would be influenced by/reenforce the theme.

I spent the majority of the first day on the mechanic.  I did not worry about art assets, music, sound or quality code during this time.  Instead I just played around with the player movement and the mechanic of shrinking/growing based on what the player was doing.  Once I had the main mechanic nailed down, it was pretty easy to knock out levels utilizing it.

I set a clear scope that was very manageable.  I really wanted to be able to work on my game casually, and spend time tweaking whatever I felt needed work.  So I really tried to set a goal and scope that I felt was easily achievable.  It turned out for the most part I was correct.  This led to a fun weekend with ample time for error correction (aside the physics problems below).

What went wrong:

NO PLAYTESTING! and therefore floaty physics.  I don’t have much experience with platformers.  The physics and movement of the player felt pretty smooth to me, but of course I was developing it.  I did not have anyone play the game until about 3 hours before the deadline.  It was readily apparent when they played that my physics for the player were floaty and slippery.  Unfortunately, because I did not have anyone play it beforehand, it left me little time to fix the issues.

When the rules say you must create your own assets, YOU MUST CREATE YOUR OWN ASSETS!  This was just a stupid oversight from me.  For some reason I did not think about the music in the game on the same level as art and code.  So Saturday evening I picked out a nice song online that was free to use through the creative commons license.  Then, as I was sitting in front of my computer on Sunday, it dawned on me that I had to create my own music.  I have no music making tools, and no knowledge on how to make game music.  Luckily I recorded myself whistling in Audacity and tweaked it enough to make it work.  Had my game not had a minimalist style, I would have been less fortunate.

It is unclear for the player what to do.  Which can be equated to poor level design.  This goes back to playtesting, but in 48 hours there is not a lot of time.  I should be more sensitive to a new players perspective, and build levels in such a way as to lead them where they need to go.  The game should be challenging by design, not by developer oversight.

Thanks for reading.  I had a great time.  Here is a link to the game: http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=13158

Pjchardt

   I’m 7Soul and I’m the programmer of Dead Pixel Games, a group of 5 brazilian friends with a passion for game design.

   Cosmic Canvas is our second ludum dare game, the first being Biodome.

   I don’t have much to say, other than go play our game, and have fun.

Tags: 7Soul, Dead Pixel Games, postmortem

I was curious to play the Android entries for LD #24 since Android is shaping up to be an awesome gaming platform (Ouya anyone ?) … so I’ve compiled a little list. I think I caught them all …

Click Red, Eat Rest – Beep2Bleep – 48 Hour Compo Entry

Platforms:

| Web

| Android

| Source

Chromasome – Jeremy Nikolai – Jam Entry

Platforms:

| Linux (32/64-bit)

| Android

| Windows (32/64-bit)

| OS/X

Caveman’s Quest for Food – jfroco – Jam Entry

Platforms:

| Web (HTML5)

| Windows

| Android

Survival Of The Tastiest – zeh – 48 Hour Compo Entry

Platforms:

| Web

| Android

| Source

ProtoZoo – raver1975 – 48 Hour Compo Entry

Platforms:

| Web 1.1

| Android 1.1

| Java 1.1

| Source 1.0

| Java 1.0

Death Hockey – Toby – 48 Hour Compo Entry

Platforms:

| Windows

| Source

| Android

| OS/X

Clever Blocks – Cthulhu – Jam Entry

Platforms:

| Android (Post Compo)

| Sources

| Windows / Linux / Mac

Dig, Jesus! Dig! – monkeymad2 – 48 Hour Compo Entry

Platforms:

| Web

| Web (iOS / Android)

| Source

One Last Chance – dr_soda – Jam Entry

Platforms:

| Web (Unity)

| Android (.apk)

Aggrandize – moomoo112 – Jam Entry

Platforms:

| Source

| Android

Nom’s Evolvathlon – bvanschooten – 48 Hour Compo Entry

Platforms:

| Web

| Android

| Win/Mac/Lin (java)

| Source

Winding of Isaac – TehSkull – Jam Entry

Platforms:

| Source

| Android

| MP3

Temporal Agent – Deykoweec – Jam Entry

Platforms:

| Android

ANT FIGHT CLUB – gamblore – 48 Hour Compo Entry

Platforms:

| Source

| Android

| AndroidPunk

ANT FIGHT CLUB – gamblore – 48 Hour Compo Entry

Platforms:

| Source

| Android

| AndroidPunk

Troll Spirit – zzorn – Jam Entry

Platforms:

| Windows

| Source

| Android

| OS/X

| Linux

Firefly – timtipgames – 48 Hour Compo Entry

Platforms:

| AllOS (Java)

| Sources

| Web (Applet)

| Tutorial

| Android (GooglePlay)

Super Genome: Hyper Evolution Turbo Edition – Raptor85 – 48 Hour Compo Entry

Platforms:

| windows

| source

| android

| video

| Linux x86-64

(and one post compo bonus I found: http://www.ludumdare.com/compo/2012/09/03/going-mobile-and-also-some-graphs/)

Tags: android

A few things I’ve been up to since…

http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=15315

Pretty new real time Shadows!

People seemed to think that the game was a good idea and that they wanted to see where it would go. Well let me tell you; I’m planning on taking the game to completion, hopefully releasing it on Steam or something.

I’ve been up to a bunch of stuff, new graphics (more to come), better collision, more levels, analytics (playtomic right now but probably going to change that) I’m currently working on adding a scripting language into the game engine I’m writing. I want to be able to script from within the Level Editor (Tiled) that I’m using.

My first thought was to use Lua. There’s a nice java lua project out there (here) however I wasn’t really super sold on the idea since I’ve used Groovy at work and I know it pretty solidly I leaned more towards using it.  Using Groovy meant though that porting to Android will most likely not be an option anymore. I’m guess I’m  not super concerned with that though, maybe if Ouya is any good I’ll regret that decision, but as for an Android version I don’t think that the game would work at all with crappy touch screen controls. Anyways, I ended up going with groovy; so we’ll see how that turns out.

Ultimately I’d like to release a level editor that would let people create their own levels for the game, so I think having a custom scripting language inside the game would really help.

As for the controls…

People seemed to be confused by the controls in the game; which I would have to agree weren’t the best. My original idea was to use the mouse to drag a square over the Blocks you wanted to mate. However due to the fact that it wasn’t working and the deadline was approaching I bailed on that solution. Now that I have more time I can get that to work, although I have to say I’ve grown attached to the way it is. I’m hoping there’s a way to have the best of both worlds; any suggestions are welcome 😀

People also noted that switching between the blocks was confusing so I’ve changed that around a bit, instead of pressing “e” or “q” to switch between the blocks I’ve made it so each block will have a number that is displayed above it, which will correspond to the 1-0 keys on the keyboard. If you press that number you switch to that block. It also means that the total number of blocks you can have on the screen is 10 at any point in time, but I think that this is a little easier to understand/ know where you’re going to switch to.

Anyhoo so concludes this update 😀

Unnatural selection (my LD24 entry) was originally only a Unity webplayer game, but now has Windows and Mac standalone builds available – which may or may not mean that Linux users can get it to run under emulation.

Looking at comments left on a lot of the games I’ve been rating, I’m a little bit perplexed by the number of Linux users who post on games that don’t profess to support Linux, just to say that they can’t run the game under emulation on Linux – because it’s running on a framework/engine that is known not to work on Linux.

Well what did they expect?

Did they expect a solo indie dev in 48 hours to not only have written a complete game but also figured out how to overcome the limitations of XNA or the Unity web plugin? Or do Linux users just have a chip on their shoulders when it comes to games? 😉

Rift of Time was made by a team of four people from France:

– Laetitia Meyerfeld: graphics
– Matthieu Bonneau: sound design
– Mélanie Grosmangin: game design
– Martin Bussy-Pâris: programming, sound implementation, sound design

Mélanie will introduce you to the Concept and the Gameplay, and Martin will deal with Programming and Sound Implementation.

Concept

The theme of evolution was developed through the meeting between an ingenious modern scientist, whose name is Sapiette, and a prehistoric man, Australo. Both characters possess their own gameplay, directly influenced by their level of evolution. Sapiette makes use of advanced technology while Australo stuns the enemies by yelling at them.

Rift of time is a two players game. The goal is to escape a laboratory full of zombie scientists.

The idea is to create a collaborative gameplay between the two players: the game can’t be beat without this collaboration. Australo must protect Sapiette by stunning the enemies before they kill him, while Sapiette must open the different doors and unlock elevators in order to escape the scientific complex with Australo.

Gameplay

The two players use the same keyboard. Sapiette plays with the keys A and D to move left and right and the Space key to activate different mechanisms. To move, Australo plays with the arrow keys. What makes Rift of Time different is that the player must yell in his microphone to stun the enemies.

The game mechanics are quite simple. Other features would have provided more challenge and difficulty, but we didn’t have the time to design and program them!

To skirt the problem, I tried to design a level progression that benefits from the main feature.

About level design, the only way for me to control the difficulty was the number of monsters in the place. I created a trap too, at the end of the level: a vicious door with lots of monsters when you activate a button!

I organized the level around 4 different areas. In order to break the monotony, I tried to give each area a different structure, which you’ll notice by the number of floors and doors in the area and by the different ways to open these doors.

The principal difficulty to build the level design was to test it, which meant repeatedly yelling in the microphone… Picture me at 4am, in the room with the rest of the team, working hard to finish the game… Near the end, I started to hyperventilate!

Some players have asked us to implement an alternative control for Australo’s shout. While being fully aware that some people are shy, have children in bed or don’t have microphones, we decided against it: we feel that would kill the gameplay, which would then become unoriginal and far less fun.

Programming

Considering I am a sound designer with limited programming skills, I decided to use Game Maker, a 2D game engine that I know pretty well. Moreover, GMWwise, a Game Maker plugin made by Cédric Liaudet, allowed me to easily integrate Wwise (the sound engine) into the game. You’ll understand why I needed Wwise so badly in the Sound Implementation part.

So, through programming in Game Maker, the main issue I encountered was the elevators system: I think I spent about 15 hours coding the lifts and fixing their bugs. And yet they’re still not perfect: some players have reported in the comments that they’ve had a critical collision issue activating the lift that freezes both characters. It requires to restart the level (in this case, the checkpoints don’t work, unfortunately).

However, through the playtests we’ve made, both during and after the jam, this bug only appeared one time, so it‘d be pretty difficult for me to find the source of the problem.

Sound Implementation

The main gameplay mechanic is based on the audio input and Wwise is the simplest way to implement it into our game. In fact, Wwise’s authoring tool allows the sound designer to set the audio input like any ordinary audio source. It’s then possible to use it in the tool as if it had been an audio sample.

[SPOIL]

Okay, so there’s a big revelation for you: Rift ot Time does not actually measure how cavernous, terrifying or prehistorical your voice is. Wwise only conveys to the game the volume of the audio input, via a Real-Time Parameter Control (a RTPC). So it turns out you really only have to blow in your microphone, and it will work almost as well as if you shout. But admit it: it’s just far less fun to blow at the zombies than to yell at them.

[/SPOIL]

By default, in Wwise, once the audio input is activated, you hear it through the master bus. Yet in this case, we didn’t want the players to hear it: it’s useless, unaesthetic as part of the whole soundtrack, and audio feedback can occur. I couldn’t just mute it though, because I needed Wwise to send its RTPC value to the game. So I put the RTPC on the audio bus containing the audio input and I routed this bus to another muted bus. The audio input is then muted to the players, but the game gets the RTPC value.

Audiokinetic, the studio which develops the Wwise audio engine, really liked our game and presented it at the Summer School on Game Audio on September 5th, in Ankara, Turkey. We have been told that the PhDs there loved to yell at zombies during the lecture.

Link to the Summer School on Game Audio:
http://s3p-gameaudio.ii.metu.edu.tr/~s3p-gameaudio/index.html

We hope that you’ll enjoy the game as much as we enjoyed creating it!

Link to the Rift of Time’s entry:
http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=12981