A musician, a business administrator, an architect and a programmer. Not really a gamedev team; just a group of close friends looking for fun! And now we here to share the experience we had on the creation of Keysmith’s in a hurry!

We’ve met online at talk.gg just a few minutes before the theme announcement. At that moment we had already set a roadmap for the game development, as the following:

1. Theme brainstorming
2. Mockups and game name choosing
3. SGDD writing
4. Game assets and scenes creation
5. Game programming
6. Game sounds and musics inclusion
7. Game publishing
8. Post-Mortem writing

As soon as they announced the theme, we’ve started the brainstorm. Monsters, food, spaceships, rogue-like, quiz, game board, popcorn and a lot of crazy ideas… Until we finally got to the key-idea: to shapeshift keys for npcs that would tell a single-line story about why they needed a key. So this was the first mockup, made on flockdraw:

1º Mockup for Keysmith’s in a hurry!

We’ve spent a lot of time discussing the game features and drawing the interface. Later we moved to draw.io for a better mockup:

3º Mockup for Keysmith’s in a hurry!

With the mechanics and interface defined we could start thinking about the name. We’ve came across a lot of ideas. From the ok ones (Keymaker; Keymaster Legacy; Keystorm) to the awful ones (The Insane Adventure of the All-Keys Maker; Lord of the Keys; Keymberly!). In the end, we’ve picked the name “Keysmith’s in a hurry!” mainly because how it sounds. Also, no game has ever been made with that name.

Next step: writing the SGDD. [SGDD stands for Short Game Design Document, a development documentation method for small-size games. Original article, in brazilian portuguese: https://goo.gl/wNf46h]

We did it collaboratively using Google Docs:

For demonstration purposes we’ve reviewed and prettified it before posting here. During the jam it was a little messy due the lack of time. [PDF version is available at https://goo.gl/KoKu2U]

Assets & Game Scene.

With the assets and scenes in hand, it was time to make a game of it. Make the static become dynamic. At the moment we started programming, we remembered to turn Chronolapse on: https://goo.gl/S89bY3

The game was all scripted using MonoDevelop. Meanwhile the soundtracks were being created with Cubase. Also we’ve included sounds on buttons and made some improvements on the UI:

Our game on Unity3D.

Finally, a few minutes before the deadline we’ve published it!

Click this image to play our game!

Time for a well deserved rest before start writing the post-mortem!

Game Specifications, Experience and Feedback

Mechanics

It’s a game about resources management. In summary, each round the player needs to read a order description (to know what kind of key he needs to create), choose the material he wants to use for each part of the key and then click on the shape of the key they want to add to the key table (where the key is assembled). After the key is delivered, the next customer comes in and the next round starts. There’s a time system, but not so useful as we couldn’t implement it further; it only resets the current day startistcs every day. The statistics are currently the only feedback the player has for the customer’s opinions about the keys created.

The game targets computer web browsers, and all the interaction is made through mouse clicks on several buttons from the gameplay screen. It’s a simple and functional game, but due to it’s linear gameplay, it gets boring after five minutes.

Aesthetics

We’ve focused the aesthetics on something reminding middle ages. All assets were based on this premise. So you see medieval keys, hear medieval coins and listen medieval songs among the game. The game is all in one screen because we had not much information beside numbers.

Story

We’ve setup a short background story just to let the player understanding why was he clicking all those buttons. As you can read in-game, the backstory is:

“Descendant from keysmith masters, you are currently the best keysmith of the region. Besides being recognized for your excellence and tradition in the manufacture of keys, you were recently knighted by the king, for creating the key that saved his kidnapped daughter. Now you need to race against time to meet the demands from your old customers in addition to those who are curious about your work and sudden fame.”

Technology

We’ve developed the game on Unity3D, but decided to export only to WebGL (HTML5), so our game is basically a web browser game. The best thing about HTML5 is that anyone with a uptodate web browser can play it. Besides the game engine, we’ve used a lot of great and modern tools to make this game exist, as you’ve read above.

What we’ve learned

One of the first things we’ve noticed is that not everyone is prepared for the Pomodoro Technique. We used it on the first day, but not everyone could stop their work on the intervals. So we didn’t use it on the following days. But we’ll definitely try it again on the next jam.

Having an SGDD as a development guide helps a lot. Once the game tasks are defined, we just need to follow the list!

Our strategy of using controllers+events on the programming was not perfect; we still had some scripts referencing others directly. We’re already studying new techniques for that.

The Bad

We all agree that it took us too long discussing the game ideia. Besides that, we needed to change tools (for conference and drawing mainly) several times, due to the lack of functionalities or for not working on some members computers. We should have tested the tools in group before starting.

At the end of the jam we didn’t complete the programming task list from the SGDD: there should be a feedback message for the player to know what the client thought about the key. We’d do it through a message box that would slide down from the top of the window (you can see it being implemented on the timelapse video). But it was cancelled due to the deadline. We also missed the game over conditions, that was already defined on the SGDD. And also a few fixes, like disable the Deliver button if the key had only one or two of the three parts and disable the Discard button if the key table was already empty.

We’ve spent some time to share assets. Using a shared folder on Dropbox would accelerate our work.

The Good

The best part was the laughs! We laugh a lot! That was enough to make that time count! But we also liked alot our teamwork. So much effort put on it!

We’re all proud we could make the random customers orders work; to see the different combinations of keys with only a few assets; to try out those techniques (Pomodoro and SGDD) and know it works; to see our UI design being so much appreciated when we had no one to focus on the art.

All this gave us a very pleasant experience overall.

Tags: post-mortem

Man, time flies when your having fun. 48 hours are over before you know it. Anyway, I had a lot of fun creating Shape Running for my second Ludum Dare: Ludum Dare 35. So here is my Post Mortem.

What went well

• Creating a quick proof of concept. At first I wasn’t too happy about the theme. Coming up with an idea for a game usually isn’t my biggest issue. For me the main question is: “how am I going to make this fun to play? (in 48 hours)”. So I always draft up a quick proof-of-concept to determine whether I believe enough in the idea to commit fully to it. I time box this activity to two hours max: if within two hours I don’t believe I can make it fun enough, I abandon the idea and try the next one. Fortunately, this time I could continue on the first idea I turned into a proof-of-concept.

• Time management using Kansan Board: I love using Kanban for managing time and tasks. At all stages of development I have a complete overview of tasks that still need to be done, without being distracted of the ones that I’m currently working on. It also helps allocate time: how much time are you willing to spend on a task if there are still 10 waiting?
  

• Graphics and Sound. I’m really happy on how the game turned out looking and sounding. I decided to allocate extra time to graphics and sound (especially music), because I like to deliver a complete and polished experience. The graphics are actually quite simple (lots of primitives), no texturing, but the use of shaders and image effects (bloom and motion blur) really help them stand out. The music was created using loops in GarageBand which is a blast to use.

What didn’t went well

• Second mechanic: the game basically has only one mechanic: change shape in time. There is no strategy or variation whatsoever. In particular, you can’t become any better at the game once you finish it. So I really wanted to find a second mechanic, but wasn’t able to find one that actually added to the fun. I tried sideways movement and acceleration and actually went and prototype both, but my implementations just weren’t adding to the fun. And in my opinion that means that if they don’t add to the fun, they take away from it. So one mechanic it is, but if anyone has any suggestions for an extra mechanic, one that adds (strategic) depth to the game, please let me know in the comments of the game (or this post).

Link to game: Shape Running

Hey you! Do not forget to vote in my game Run Rainbow Run and have fun! (^ – ^) v

Post Compo version 1.1 of Hungry Blue Fox!

* Added 2 more levels (Still a bit short on time D: )
* New and improved animations!
* Tightened controls (Jumping works better!)
* Added nature sounds (Credit: klankbeeld @ freesounds.org and gnerkus’s idea)

Entry: http://ludumdare.com/compo/ludum-dare-35/?action=preview&uid=61896

WebGL Link: https://tharemo.itch.io/hungry-blue-fox-post-compo-11

Yeah, someone made a gameplay of our game, and he was AirAssassin15! He has lots of cool stuff on his channel, including some other gameplays, so go check it out

Here is the gameplay. By the way, we want to thank this youtuber for the video, really, thanks a lot!

Tags: airassassin15, gameplay, henkan pachinko, LD35, Ludum Dare, youtube

Click on the image to play!

Hello everyone, Luka here from Kuality Games. Here’s a small post if you’re wondering how we made the environment for our game, Mushroom Muncher. I will be focusing on the texturing part that I did, by just explaining the basics.

Base/White-box:

First of course, we started off with the basics in Unity. Our designer Rafael set up a basic white-box of what was to be our main level in the game. Since we had time constraints because of the jam, we simplified things and decided that our level was supposed to be an arena where enemies would attack the player infinitely. This also reduced the amount of level design we had to do, as well as art assets. At this stage we had the basic level layout and overview of object scales/sizes.

First white-box of Mushroom Muncher arena.

Texturing:

Most of the environment work was done through texturing. I decided to try Substance Designer for the first time and first thing we did was prepare base materials for our environment. Plan was to finish up materials at first and then apply them to the environment meshes that we would model, in Unity. This approach can be different of course, from the traditional “Model it, Fix the UV, Texture it in Photoshop/Gimp”. It didn’t seem like this approach saved a lot of time, but it did give us a lot of control and flexibility in terms of randomizing the look of textures in the game. By using substance materials, I was able to easily blend textures together and instantly randomize the look of Stones, Rocks and Dirt as well. So once the base materials were finished, I started to blend them together in Substance Designer and also exposed a lot of values that made it possible to edit materials in Unity, here’s the example of this:

Procedural texture properties (Unity’s Inspector window)

Here we can see couple of options where we first start off by choosing the surface (Ground or Cliff for example) and then we can start tweaking individual properties. You can see the example of this at work below:

Randomized Rock material – clean.

Rock material – with dirt.

As you can imagine tools such as Substance Designer in this case can be extremely powerful, for both big and small projects. I would recommend any game developer to try them. Here’s another example:

Stone- clean.

Stone – with striation.

At this point base materials were done and they were ready to be used in Unity. Learning and preparation took most of the time, but it was worth it as at that point I could produce random and unique texture for our environment in matter of minutes.

Sculpting/Modeling:

This part was rather simple. Our artist Jenny first sculpted the base rocks in Zbrush, after that moved them to Maya where the low poly meshes were made and some Zbrush decimation errors were fixed. As a last part, she UV-mapped the rocks and exported them to Unity. Applying materials and assembling the scene was done in the game engine.

All of the base meshes we used in the environment including the ground sculpt.

In Unity:

After the meshes were prepared, we had everything ready in order to assemble the arena in Unity. Even though we had the ground sculpt prepared, we had to scrap it and go with the flat surface in order to avoid some of the gameplay problems we were having and particles intersecting with the ground. There could have been much more done about the ground, but in the game itself ground texture tiling wasn’t that visible and it didn’t make much of a difference in the end. We added some extra props quickly in order to make the arena a bit more interesting as we were running out of time.

Shot of the arena from the side.

Conclusion:

It was very interesting to work with Substance software for the first time and approach things differently, that is why I would recommend this to any artist/game developer out there. We did face some problems such as these procedural materials increasing the loading time of our game significantly, but that was due to bad optimization of these materials by me in Substance Designer itself. Even though optimization can help, these materials can still be quite heavy so that is something to consider.

In the end what we managed to create in three days still looks nice and doesn’t mess around with the gameplay, so I would consider that a success. If you have any questions feel free to ask on Twitter: @KualityLuka. You can also find us on Facebook.

Cheers.

Tags: environment, jam, LD35, MushroomMuncher, mushrooms, substance, unity, unity3d

Let’s talk about the characters of Realm Shifters.

All 3 of them share a single humanoid avatar. At first it seemed a bit weird when the cow started walking around on two legs but the end result became really funny! 😀

Realm Shifters – cow

We used Unity for the game and man, it’s model importer is quite powerful! If the target model has the more-or-less correct bone hierarchy, it automatically maps the bones of the target rig to the humanoid reference avatar. If it’s not correct, you can still configure it manually. Our dragon guy required some manual setup like this and still got into the game in no time!

View post on imgur.com

Okay, it’s not AAA category, but did the job. We really enjoyed selecting and putting together the final characters. Being only 2 programmers on the project we had.. hm.. let’s say limited artistic skills, so using a shared skeleton greatly reduced the time required to get our creatures moving. This technique also made it possible to try out multiple versions and choose the ones we liked the most.

View post on imgur.com

There is great potential (e.g. platformer moves, melee fighting) in this approach but we found it too buggy and complex to implement these extensions correctly within the given time frame so we kept only the animations and basic controls. We shifted our focus on improving the atmosphere, juiced the scene with sound and visual effects and some nice particle systems.

> Play Realm Shifters! <

Tags: Abyss, cow, Crystal, dragon, GameJam, jam, LD35, Ludum Dare, Orb, Realm, Shape, Shift, Shifter, untiy3d

Right, so a lot of the comments/criticism that my entry SHAPE.SHIFT() has been receiving was geared towards the game’s brutally unforgiving difficulty and whilst pretty much of it is my fault (I didn’t make the holes bigger, I should have increased the gap between obstacles, The player moves too slow etc.), it is still possible to get a pretty good score (A friend of mine managed to get 110 points and someone who rated this got 160) so I figured I might as well write up a quick guide with some tips and tricks on how to get good scores in my game (i.e. not die every time)  .

Top and Bottom Holes

When an obstacle with either a top or bottom hole appears, the best position to be in is to move towards the edge of the screen.

Top Hole

Bottom Hole

Middle holes are generally more tougher to pass through because of the somewhat pinpoint positioning needed but as a general rule of thumb, the position you’re at when the game starts (i.e. don’t move yet for a few seconds) is the one you most likely want to be in when attempting to pass through middle holes.

Middle Hole

Moving From Hole To Hole

Once you get the hang of positioning yourself, the next tricky part is learning how to move from hole to hole. Whilst going from top to middle or bottom to middle or middle to top/bottom is relatively easy because of the short distance, going from a top hole to a bottom one (and vice-versa) is pretty tough because of how slow the player moves but the one golden rule I’d like to give out is that as soon as you pass the previous hole, start moving immediately towards the next one (ideally just after you hear that ding sound when you score some points for passing through a hole) although it does require some split second timing (i.e. not too early/late).  When a shape switch is required when going from hole to hole, what I find works best for me is to move straight into position then switch shapes at the last possible minute just before entering the hole.

Anyway here’s a small gameplay clip of me getting 280 points in the game using these techniques (ironically my personal best although what you didn’t see were the number of time I died trying to record a good run).

If you haven’t tried the game yet, you can do so by clicking here (And if any of these tips actually helped you in getting a good score let me know )

Get it here: https://play.google.com/store/apps/details?id=com.indgaming.altruism

View Original Entry: http://ludumdare.com/compo/ludum-dare-35/?action=preview&uid=24878

I added the much-needed checkpoints that everyone talked about. Along with touch controls, a different guide for those controls, and some other minor fixes.

The Golden Sphere is the result of 72 hours of work by a three man team. It’s a jump’n’run game featuring a narrator including voice acting.

Let’s look back at how the game was created, what went well and what didn’t work as planned.

Making of

Our Weekend started on Saturday at 8 o’clock in the morning (Ludum Dare was already running since 3:00 am in our time zone) with the discussion of game ideas. We first weren’t really happy with the theme but after a few minutes we came up with the idea we now implemented. As we knew that the first idea often isn’t the best one we looked for more. The best we could come up with was that you are a frog and can shapeshift into a prince. You would then have to infiltrate a castle without getting noticed. Obviously the first idea was better so we took it: you can shapeshift into a human, a wolf and a turtle, each of the forms has unique abilities. Those allow you to solve different kinds of puzzles / platformer elements.

The rest of Saturday was spent implementing the engine, doing artwork, level design and narration writing. On Sunday we recorded all the narration which took several hours. So much monologue… In the evening we tried to create some music but failed horribly. It was Sunday midnight and we didn’t have any levels implemented in the game and only about three existed on paper. The engine also still needed a lot of work to be done. Our goal was to be done by this time, instead we had virtually nothing playable. Oh well, we would need to spend the Monday as well on the game. The lectures at the university had to wait…

The Monday was mostly spent with implementing the levels in the engine (writing tons of xml, so much fun…) and teaching the narrator when to say what. In the end the narrator took about 1000 lines of code, one fourth of the whole engine. The last level was done at one o’clock in the morning, two hours left until the deadline. By the way we still hadn’t come up with a name for our game yet. Unfortunately we didn’t have time for a proper play through as we still had to fix some bugs. And yeah, we still didn’t have any music. We had a few sound effects but no music. So we gave up with trying to create it ourselves and let the computer take over. Thanks to Abundant Music we were able to add music in the last minute. It was somehow depressing that the computer created better music than we were able to but this just means that we have to practice more ;-). We opted to let the users vote on audio even though we didn’t create the music ourselves as we spent a lot of time doing the narration which is also part of audio.

After we uploaded our game and the deadline was over we were able to play the whole game for the first time. And as you can imagine a few small bug fixes followed shortly after. At four o’clock on Tuesday morning we were done, but luckily, so was our game.

What we want to do better next time

• Create our own music. The music we now have is good but our own would “feel” better.
• We didn’t have any playable levels until Monday morning. Plays into the next point.
• Have the game almost finished way earlier so more time can be spent hunting bugs and improving the game experience.
• Include the bear in the game.

What went well

• Idea turned out to be better than expected.
• We have about 20 minutes of game play. Or much more if you haven’t already played each level a thousand times.
• Our goal before the jam started was to made a game with a narrator. It worked out pretty good.
• The visuals of the game are – at least in my eyes as a developer – pretty nice. And we have a nice shader for the mountain lake.
• We were able to turn the missing bear (cut due to the limited time budget) into an ongoing joke.
• We finished the game on time (later than planned but still within the deadline).

Conclusion

Although we first didn’t really like the theme I think the game we made this time is my best Ludum Dare game so far. Most things went well but took more time to complete than we first thought. But that’s always the case. We were able to adjust the scope of our game early enough to be able to still finish it. The feedback so far is great and we already thought about making the game bigger and better. Coming Summer 2017?

If you got curious and want to play the game: there you go!

Tags: LD35, post-mortem

Fylgjur V1.1 TEASER

I worked a bit on the game this weekend and managed to get the start of a combo system in place. Now I just need to make all of the animations and I can release V1.1, so here’s a teaser!

Play Fylgjur

Our Ludum Dare 35 experience was riddled with problems from scheduling to programming and even to brainstorming. We had a HELL of a time brainstorming… In the end, we came up with ‘So You Think You Can Science?’ (SYTYCS?), a top down shooter/roguelike featuring no less than 3 playable characters.

The Team

The main team behind SYTYCS? was myself (programming/design, @morrilet), Jeremy Helsel (programming/design, @JIHlucky7), Josh Ruffolo (music/sound, @jruff7) and Jasen Helsel (graphics). We also had some help from our good friend Matt Carollo (@trip_yuh), who stepped in with some sound effects toward the last half.

The Idea

Brainstorming, for us, started at around 8 or 9 PM (depending on your time zone) and it took us a solid couple of hours to settle on SYTYCS?. Josh wanted to do sounds for a sci-fi game, I wanted to make either a dark and gritty story or a racing game where cars transformed into humans (I still think it’s a genius idea), and Jeremy wanted to make a roguelike. We ended up switching our idea back and forth between a gritty story game or a goofy shooter. In the end, we went with the shooter, because that’s simply what we knew best. The first idea we had for the characters was a porcupine who shot his quills, but with the addition of Lemmy (the bee-shooting bear), we swapped the porcupine for a cactus. We just didn’t want two animals, and for us, Lemmy was the more interesting character. The porcupine was replaced with Francus (pronounced Fran-sus), the cowboy cactus. After that we were trying to come up with an idea for a character that wasn’t carbon based, and our tired brains settled on a hairdryer wielding, you guessed it, a smaller hairdryer. Thus, Cordulator the maniacal hairdryer was born. We also all agreed that it should be sci-fi themed, so we decided that the setting would be an infinitely deep space ship run by an alien mad scientist and guarded by his alien henchmen.

The Process

We ran into issues at almost every step of the way. Firstly, this was my second time using github and my first time using it with more than one other person, so we had a few scares during development. Secondly, I’d never worked on a project with this many people, and planning was soon recognized as a big issue. All of us have jobs, and some of those jobs are at odd hours of the day. This made keeping everyone working together difficult. In fact, on the last day, we almost didn’t have any overlap where all of us could work together to submit it. Some people even left work early and rushed home to finish. The whole thing would’ve taken even longer, too, if it weren’t for some scripts I had lying around. Because of this, we didn’t have to bother making a camera or 2D navmesh agents. This was also the first time I’d actually used a procedurally generated map in a game, and the first time I’d programmed shooter AI that did more than appear, point, and shoot.

Submission Hour

We went right up to submission hour and came in hot. We were in a mad dash to get sound effects in and build. To make matters worse, every time we built, we had a new issue. Once, no sound effects played. Another time the player spawned in with no health. Every build, new problems. In fact, the build we ended up submitting had horrible UI scaling problems and didn’t play gunshot sounds. These bugs and others wore heavily on all of our minds for the rest of the night and most of the next day. We hadn’t intended to release any updates, but we couldn’t live knowing we could’ve done better. We released an update to fix the menu resolution and sound effect problems. A day later, released an update to fix wall sticking.

Final Thoughts

I think we all learned a lot this time around. We certainly have a better handle on working in a large group and I feel pretty confident in my ability to throw together AI, which was entirely alien to me for a long while. Next time I think we’ll probably scale back a bit so we’re all less stressed out. Also, we’ll have to manage our schedules a little bit better. I think, all in all, that this was a fantastic jam for all of us. We all got to do what we wanted with the game and I feel very proud of the game (and the characters) that came out of this jam.

You can find the original build of ‘So You Think You Can Science?’ here.

If you’d rather check out the updated version, you can find it here.

Go ahead and give our game a try! We’d love to hear what you think.

Hello there!

Here’s a new post to talk about last week-end. Indeed, and as always (or nearly always), I definitely HAD to take part to LUDUM DARE!
As some of you may know, the 34th LD turned out pretty well for us, so Lullaby decided to team up again, and to renew the experience of Jamming. Now it’s been a few days since the end of the Ludum Dare 35, and it’s Post-mortem time!

And if you want to play our Game, Kitsune, it’s over here!

Ludum Dare #35 : “Shapeshifting”

For this Jam session, we were the same team of three : Louis Denizet (Prog/Assist. GD), Benjamin Baldassini (Music Composer), and I, Mathieu Clavel (Main GD/Art). But this time, it was a bit more special : I was alone on board, Game Design-side. Louis was moving to his new living-town during the week-end, so I had to take care about all the Game Design, documentation and Art during his absence. He would get all my work when arrived at his new place, and start to code the game.

So let’s enter into Kitsune development. First of all, what is Kitsune ? Well, look down to learn more 😉

A (new) Game Designer challenge!

This time, I decided to go for a new game design method. I took my old Game Design Document format and put it in the trash. I needed something more efficient, that Louis would be able to understand “crystal clear” without us communicating in live by Skype or telephone. The ideas would be illustrated by a moodboard with keywords, expressing the proper DNA of each feature. Then, I’d list efficient user-centric lines that would need to be checked one by one in the TODO List.

Example of Moodboard illustrating 3Cs

And now it’s time to actually make things happen (…again)!

Then, it was a go for the “production” part. The graphic part went good, and even faster than during the last LD. I had a really precise view of what I wanted : Japan, Old-fashion Theatre set, a fight between Good & Evil. Classic, but definitely working In the same time, I made a first prototype of the game in order to help Louis get a precise idea of the 3Cs (that he would custom/improve later).
Talking about Louis, he finally managed to get some time in the weekend, and started programming over my first prototype. I polished art, hand-made animations and documentation during the week-end, and was informing Louis about where exactly we were in the project, as he was in the train to his new living-town. As stressed as we could be with just a beginning of game and all the DATA done, I kept on iterating on the design, and Louis started programming and making feedback on the design again at the first second he was back at home…
Unfortunately, I was working on Monday, so I just closed and shared my files Sunday at night, and went to bed. At the same time Louis was still working, it was kind of a Relay race !
We were looking at the timer, and were only starting to make Level Design and still improving the Altars behavior and rules. The tutorial part went particularly good, as Louis had kept the experience of our previous entry concerning that part. We finally made some adjustments, and the game was cooked.

The goal of this LD35 was to create a game with a great experience concerning the Mood and Gameplay (that we wanted nervous, timed and fluid, cf. Moodboard), and I think that we’re pretty close to that today.
We won XP on organisation, and creation and adaptation of processes. We produced something, and lived a unique (and I think non-reproductible) experience. Ludum Dare style.

What went wrong?

Since we don’t have any result yet, I can only make suppositions. On a production-side, I think that the word that could describe our week-end is “cahotic”. When I was doing stuff for Ludum Dare, Louis could not, and when he could, I was working or getting a bit of rest. It cost us precious iterations steps on the game, and we have been lucky that the final product ended so well.
The release was a problem too, though. We had no time in the first few post-release days to look after our game, and came back to it only around Thursday. So we started to vote for others and get review only around Friday. After these reviews, I think that I’m able to tell our weaknesses on this project :

• The game isn’t playable on Web (Windows only). Again. And it’s still a thing that Web-playable games will get more exposure as you don’t have to install them on your PC.
• The fact that the game has a “Die & Retry” gameplay is totally assumed, but can make some players fly away.
• Level Design balance is still one of the last things we do, and I think that it should change for the next time.

Actually, thanks to all of you guys, we have a lot of good and constructive feedbacks on Our Ludum Dare page, so I invite you to go and read them
Anyway, we’re always waiting for more and more feedbacks, so hope you’ll like it!

Cheers

Mathieu, aka Ekilibr

Just wanted to let you know that a post-compo version of The Great Biohazard Escape – my point&click escape room adventure about a scientist infected by a deadly virus that gives him the ability to shapeshift is now released.

This version has now a more catchy outro, an auto save game option, newgrounds medal and includes all (or at least most of) the remarks I got in the comments: bug corrections, a new icon for change screen and some text hint changes.

I hope you’ll enjoy it!

So I’ve seen 40-50 aweseome games.  But only 1 or 2 stood out for me (Note: my game is not one of those xD).  Part of what I like about LD is that I think of it as a showcase of random game elements put under magnification goggles.  You get to see one game mechanic in isolation — which you can learn a lot from.  I have a theory that the more constraints there are in a jam the more creative people get.  But I could be completely wrong.

LD34 for example had LOTS of games that felt like they almost invented new genres / core mechanics.  Maybe the theme in LD35 wasn’t very restrictive?  Do you guys disagree?  Do you recommend any games from LD35?

The game I ended up with for this LD is perhaps something that neither I nor any of you expected. Questionably related to the theme it turned out to be a game all about listening, as well as a test on your patient. Many have pointed out that it is difficult to understand what is happening, but maybe that just adds to the atmosphere. I mean who wouldn’t be disoriented in a completely dark room?

So if you haven’t already, try it out here!

Tags: darkness, headphones, jam, LD35, light, sound, soundscape

me again! improving gameplay on iOS and also adding new features. Also visual improvements, flashing lights warting and lot more stuff suggested by you all.

If you havent played the original game in the compo entry , link below:
http://ludumdare.com/compo/ludum-dare-35/?action=preview&uid=90316

little demo working on iPad

Hi everyone, just uploaded a short gameplay video of my entry ‘Court of Talis’.

You can check out ‘Court of Talis’ over here:  http://ludumdare.com/compo/ludum-dare-35/?action=preview&uid=63291 

Tags: gameplay, LD35, Ludum Dare, video, youtube

In my game you collect shapes in the real world by walking to them with your phone. In the original version it required up to 600 m of walk to get your first shape. Perhaps a bit much.

So I’ve added the option to try my Shapes Outdoor game with shorter walk distance. Your first shape can now be collected within 100 m of walk, and you only need to collect 3 shapes to win the game.

It is still possible to play the original difficulty if you rather like to do so.

To the game

This was my 9th solo Ludum Dare! In the past I’ve made, in order: Ethan’s Bike for LD 25, Consumerism for LD 26, 10 per for LD 27, One Kingdom for LD 28, Ordained for LD 29, Silence … Noise for LD 30, Blob for LD 33, Spaceman 34 for LD 34, and, finally, Monster Village for LD 35.

Over the events, I’ve noticed improvements in

1. Attitude
2. Programming Skill
3. Self management

However, what has stayed the same is

1. Art Skill
2. Music Skill
3. Anti-patterns

Attitude

In terms of personal growth…

I entered Ludum Dare 25 as a self-conscious, anxious developer. Here are a few quotes from December of 2012:

• “I am going to be attempting to make an entry for the famous LD!”
• “I’m a VERY new code writer”
• “I am a bit guilty because how how AWESOME other people’s submissions are”
• “I actually just jumped in with a ‘YEAH THIS IS GREAT’ attitude, and no thought is a bad thing for design”

Underlying these words was this attitude:

• I don’t want to be seen as arrogant for entering the Ludum Dare
• My game sucks, and someone is going to tell me “get out”

This attitude was constructed from my own circumstances in life, and, as a seasoned Ludum Dare-er would know, is not how things are.

Ludum Dare is a community where everyone rapidly develops a game to the best of their ability, and then gives constructive feedback and encouragement to others for their own games. Ludum Dare is a community of learners. When you are learning, there is no “arrogance,” just people sharing their thoughts about each others’ games.

Now my attitude towards Ludum Dare is:

• Let’s make something
• My game sucks because I’m learning
• Look at what other people made!

This is vastly different because it is geared towards learning and looking at what other people made to get new ideas. Learning works best when you aren’t afraid to try.

Programming Skill

I can implement features a lot quicker than before. I have more to say about this under “anti-patterns”

Self management

At the start, my usual routine was:

1. Let’s make an MMO
2. Oh god this is too much
3. Let’s make a decrepit skeleton of an MMO
4. My code is too messy, I’m going to give up now
5. Submit

Now:

1. Let’s make an MMO
2. Let’s scope down to the basic mechanics
3. It’s too small now, let’s make it a tiny bit bigger
4. Finish the scoped down version from step 2
5. My code is too messy, but I have some of what I planned done
6. Submit

You can see that the start and end points are the same, but the middle points have seen a significant improvement.

Art Skill

Compare Ethan’s Bike with Monster Village: it is the same. This is because I focus on programming far more than drawing, and I have not put much effort into improving my art skills. I blame laziness.

Music Skill

Half my games don’t have music, and some don’t even have sound effects. This is due to focusing on programming.

Needless to say, if I ever join a development team, I’ll definitely be a programmer.

Anti-patterns

For all of my games, there is a “PlayState” class that essentially holds the entire game. I’m aware that this is bad design, yet, in the interest of implementing features quickly, this is what usually happens.

1. I have my game planned out
2. I made a few flowcharts and diagrams on how this is going to be implemented
3. Well designed part of the code is implemented
4. I need to implement the rest of my code now
5. I didn’t plan for how a few features were going to be implemented
6. Mud ball

This is a large improvement over my first game, which was

1. Start making game
2. For every feature
3. If it is data, make a “Thing” class
4. If it is an action, make an “ActionManager” class
5. Go back to step 2 until everything has its own class
6. Cobble

A humorous example of this was the all powerful PercentManager class from Ethan’s Bike:

package com.horsentp.ld25;

public class PercentManager {

public PercentManager() {

}

public boolean calcPercent(int stat) {
boolean percent;
if(stat>=10) {
percent = true;
} else {
percent = false;
}
return percent;
}
}

As time goes on, and as I make more stuff, I get a little better at ensuring good design principles, but the PlayState-mud-ball problem persists across all of my projects.

I believe this is due to “quickly implementing features.”

I believe that if I take a step back every time I see a mud ball forming, and make some design changes right then and there, I can avoid the point where my code becomes so messy that I abandon my project.

Type of games

I noticed that most of my games in Ludum Dare and outside of Ludum Dare have the following gameplay elements:

• Management
• Platforming

and I attempt to make this gameplay

• Fast paced
• In depth

Obstacles

But “in depth” usually becomes “why is this so complicated” (See One Kingdom). “Fast paced” becomes, ironically, “slow paced” (See Ordained and Silence … Noise). Over time I have become better at making games “fast paced” (Blob and Spaceman 34), but less so with in depth games. A major reason for this is likely player feedback. Most of the games I make that attempt to be in depth end up being confusing. They’re confusing because there aren’t a lot information sources for the player to use while playing the game. In an attempt to make the game less cluttered, it becomes more confusing. GUI programming and design as well as gameplay design is what needs to be worked on to improve a game’s “understand-ability.” Not surprisingly, bad GUI programming is always because of  mud-ball style PlayStates.

Other notes

• I drink too much coffee during every Ludum Dare
• I feel like I wrote beautiful code until I get a bug that takes 4 hours to fix
• I always implement animation, but I don’t have the time to make them

In conclusion

1. Thank you for reading
2. Patience is key
3. Beware mud balls
4. Keep making games so you get better at managing mud balls and yourself