Ludum Dare 33
The Theme is:
You are the Monster

PlayRate80Star

Judging Ends in
3 weeks of Playing and Rating games!

Posts Tagged ‘post-mortem’

Post Mortem

Posted by (twitter: @JangoBrick)
Monday, August 31st, 2015 4:37 pm

So Ludum Dare #33 lies behind us now, and I take the chance to write a quick follow-up of how this all turned out for me.

There is also a timelapse video of Virus‘ development:

The Preparation

I didn’t prepare much this time. No basic games to get back into the whole process, not many commits to my engine.
What was important though was that I made a list of ideas for the 20 final themes, which helped me a lot in getting creative and was quite a bit of fun, too.

The First Night

I forgot to commit final but crucial changes to my engine, which I consider would be cheating since then I would be the only one with access to that code. I noticed my mistake very late, and after documenting and committing everything there were only about two hours of sleep left.

When I woke up and started Eclipse as well as my timelapse software, I noticed the latter didn’t really work. Everything looked JPEG-ish, even though I had set it to PNG. I spent the last seven minutes before the theme announcement quickly building my own timelapse script, just to realize the original software did work correctly… Anyway.

I was not happy with “You Are The Monster”. Not at all. I mean, I knew that the chance for it was high, but still. I ended up making my biggest mistake, not sticking to the idea I had prepared beforehand. I wanted to do something atmospheric, something calm, like flying a bird. There was my idea – you play an eagle, which looks friendly at first glance, but for something like a mouse an eagle is quite the monster.

I built awesome flying mechanics (really, they deserve to be called “awesome”), made the textures, and put it all together into a lovely little eagle. It would even sit down when you flew it to the ground!
Unfortunately, after spending around six hours on that, I had no idea what to do with it.

My eagle

After sleeping a little, 14 hours in, I gave up. Back to my original idea: playing as a virus that infects all of humanity.

Starting Over

Progress came fast, since I had mostly the whole thing in mind from the start. In just a few hours, the basics were already done, although it was still far from a game.
In the evening that day, I took a break from coding and started with:

The Music

I am bad at making music, there’s no doubt about it. Partly because of my missing experience, I guess – this was the second time I ever made something for real.
It isn’t what you’d expect when you think of the word “music”, it’s rather some disturbed synthesizer sounds with a heavy focus on drums. Those are the only two things I am not that bad at. It turned out OK.

Want to listen to it? Play my game!

Making It A Game

After tuning the music to my satisfaction, I added the progress minimap, tweaked the gameplay and added the main opponent: vaccine production.

I also changed the background to a non-static one, with a pseudo perspective on the houses. Very proud of that!

Final look at Virus

Voice Acting

I appear to be surprisingly good at voice acting. It was my first time to ever narrate anything, and I only did one single recording, but it turned out very well!
One hour of effects work to make it sound like some highly-disturbed walkie-talkie transmission, and suddenly my game got a lot better.

Testing & Fine Tuning

Obviously, when you have played such a simple game for a few hours, you get really good at it. That is a problem, because as the developer, you have had to play it over and over again, which means you don’t know how hard or easy it is for someone starting from the beginning. That is where I got other people involved, basically just playing the game and reporting back how it worked for them.
Then followed lots of fine tuning, since the game turned out a lot harder than I had thought.

After one of them managed to win, I called it a success and submitted my game.

My Overall Experience

This Ludum Dare was absolutely great. I had a bad start, but after that, everything went very smoothly and I am happy with the outcome.

The way I did it this time appears to be how I should always handle game jams in the future. Giving everything you have drains a lot of energy, and you lose more than you gain. If you do this in a more relaxed way, you are not exhausted and get to do more.

  • If you haven’t yet, you can view my entry here: Virus
  • The development is available on YouTube, sped up to just over 5 minutes: Timelapse
  • And please vote :-)

Thanks for reading,
JangoBrick

So who’s the Monster in The Mammoth anyway?

Posted by (twitter: @inbetweengames)
Monday, August 31st, 2015 7:04 am

Hey,

David here from inbetweengames. After giving everybody a bit of time to may be check out our game ‘The Mammoth: A Cave Painting‘ and reading the awesome comments on the page, I wanted to talk with you guys a bit about the integration of the theme that we decided for. This is going to be somewhat of a spoilerfest so if you want to check out our game with fresh eyes best do it now before reading this. We’ll be waiting here.

PLAY THE MAMMOTH: A CAVE PAINTING WHILE YOU STILL CAN!

Mammoths

Everybody good? Are you ready for a hippie, arty rant? Cool, let’s go. :)

At first glance it’s not very obvious who the monster really is in the game. There’s no clear Sesame Street or Horror like monster at all. The Mammoth itself seems like the first obvious answer but that.. well is that a monster really? Does the game fulfill the theme at all? We think it does, it’s just when we were brainstorming we took all of our obvious first ideas and threw them away. All of those were good ideas and there are a few games in the jam that went for them and executed them beautifully. We just decided for the oddest one that hopefully has more than one possible answer about who the monster is. So let’s look at some of the possible answers together.

‘YOU ARE THE MONSTER’

A quick excursion into semantics about how we read the theme to begin with. In our minds the sentence ‘You are the Monster’ can mean a great many things.
It can be ‘you’ as the player. It can be ‘you’ as someone else in the world that you’re saying this to – aloud or in your mind.
It can be ‘you’ as the collective you. Everybody. A group of people. etc. So which one did we go with? Basically all of them. Let’s check them out.

THE MAMMOTH IS THE MONSTER

The obvious choice for the answer of who the monster is. You’re the mammoth – so you’re the monster. Kind of an odd choice for a monster though isn’t it? But we thought the way Mammoths (and most animals actually) are displayed in cave paintings like the famous Chauvet Cave gives them monster like qualities. The animals are drawn immensely large in comparison to humans in the pictures in a way that goes beyond a realistic depiction of scale and probably has much more to do with the perception of meaning and power. So scale here is based more on emotional and magical evaluations rather than the ones our modern minds would focus on.
On the other hand when we looked up the term Monster on Wikipedia (of course we did) we found this little perl of a quote:

The word “monster” derives from Latin monstrum, an aberrant occurrence, usually biological, that was taken as a sign that something was wrong within the natural order.‘  Wikipedia

The Mammoth in the game is also meant as a totem like representation of all mammoths, THE Mammoth as a whole, as an idea, a shadow on a cave wall – you might have heard that parable before.
So the story of The Mammoth in the game is not really the story of a single mammoth. It’s a legend on a cave wall telling of The Mammoth as a symbol, meaning all mammoths really and how they went away which obviously is what’s wrong with the natural order. The story is told by the hunters whose many hands also mark the borders of the level. In this case you as a player are telling the story by playing in a theatre like performance. Which leads us to..

THE PLAYER IS THE MONSTER

Very cathartic to smash up the hunters’ village at the end…though I lost my last baby mammoth in the process. Point made, I suppose?Ryusui

Now since this is a game you as the player are the one driving most actions in the game. So when we heard that the theme was ‘You are the Monster’ we kind of went ‘Oh well we have done this before, let’s just do it again.’ Which was based both on the fact that we did a game called Spec Ops: The Line before in our day jobs at YAGER but also had never done a game jam before. So it seemed like a safe option.
So within the game our goal was to turn you as the player into the monster. We give you something that you care about hopefully and then we construct circumstances that in all likelyhood will take it away from you with a clear culprit to project your negative feelings upon. You will either care and seek revenge, in which case you’re a monster, or you won’t care at all, in which case.. well you get where I’m going with this.

THE HUNTERS ARE THE MONSTER

I’m truly upset that the horrible hunters did what they did :(TailyILoveYou

The only problem is that I (as the mammoth) am not a monster… the monsters are the bad humans who killed my kids!Galvesmash

Now that we have the more obvious answers out of the way it gets a little more interesting. The Hunters in the game are really the ones killing all the Mammoths right?
So they’re kind of the monsters. Which is a comforting thought because we get to shove the blame on these external evil beings that we have no connection to – if it would’nt be for the fact that..

WE ARE ALL THE MONSTER

We are the hunters. We as humans have eradicated more species than anything that came before us including whatever killed the motherflipping Dinosaurs.
It’s quiet possible that we will add ourselves to this list eventually. We are the monsters.

NOBODY IS A MONSTER

Really loved the sad story for this although I don’t see how the mammoth was a monster in this case.RougeRogue

Now this can mean that we either missed the theme completely or something a bit more meaningful.
For that second option I’ll just leave this one to some of the commenters on our page who laid it down perfectly in my opinion:

Hard to say if you’re the monster or the hunters. I guess, in the end no-one really is, they’re all just trying to survivedickpoelen

Oh my god that was so depressing! I don’t think I was the monster here though, I only cared for my progeny. But weren’t the Hunters protecting their children too when they were hunting instead of watching their beloved die from hunger?

Is there really anyone to blame, is there any monster or is the world itself the merciless beast? The story of the Mammoth and the Hunters repeated several times in the past and will happen again, perpetuating the neverending suffering… but I can’t help to wonder, and I cling to that though as it is my last glitter of hope, is there a way to spare one mammoth child and make the herd anew?Hvedrung

Thanks for reading this wall of text and please let us know what YOU think by commenting here or on the game page!
We’ll write a more traditional post-mortem sometime soon but this just kind of started to write itself after thinking about your comments. :)

Cheers,
David
inbetweengames

Sly Slime – Revenge On All Players

Posted by
Saturday, August 29th, 2015 11:00 pm

 

The slime is the most common monster in JRPG. Millions of them were killed by players during the whole video game history. So it’s the time for REVENGE!!

After 72 hours of hard work, we made this game – Sly Slime. It’s visually beautiful, fine-tuned, also brutally hard and unforgiven. You are weak just like your kins, so try your best to survive this bullet hell, sneak and send these players to hell! Give them everything you got!

Please visit our game page here, and don’t hesitate to rate and comment!

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

Good Game, Good Luck, Have Fun!

Monster of the Matrix: post jam progress

Posted by (twitter: @@jespertingvall)
Saturday, August 29th, 2015 5:13 pm

Still having a cold decided to continued working a bit on my Ludum Dare 33 game Monster of the Matrix. In the game you play as a skeleton trapped inside a dungeon crawler. But something is wrong… You realize that you are trapped inside a world that is shutting down. You must escape…! And something is hunting you….!

New version

  • The original Ludum Dare game had one random generated level of fixed size, with one exit. After the jam I split it up into 7 different sized, still randomly generated, levels. It also added a new gameplay element, doors. They made the game much scarier since they limited your sight. And behind every door an agent could lurk…
  • A stamina mechanic was added. You need to rest and can not run the entire time. The agents more a little bit faster than you, so you can not loose them unless you are running from them.
  • More and scarier sounds where added, among them footsteps to the other skeletons and really spooky music from Connor O.R.T. Linning.
  • I also integrated Gamejolts API into the game, giving the player achievements.

Old version of game

 

Links

Hello Ludum-Darees!

This is my first post-mortem butchery and I am very excited to share my experience doing the music and sound design for our entry:

“Cataphilla”

21417-shot0-1440484896

Given the fact that we started slightly off schedule and that we changed the mechanic and aim of the game in the course of only 2 days we were

slightly limited regarding fine tuning the game but we made due with the resources we had…

For this game we (tried) implementing Fmod into making the audio behave a lot more dynamically and react to inputs rather than just looping seamlessly from beginning to end.

 

 

This is only the 2nd time I have used Fmod inside a Unity game and I was relatively happy with what we achieved but I there are several hurdles that I would like to get over for future jams:

 

Challenges:

-Making instruments come in after each other

-Changing the snare-sound when switching between left arrow key and right arrow key

-Creating a “muffled” effect when entering the giant peaches

-Transitioning from the main beat to the transition and into the new section

Making things sound cool and glued together

-Switching between sound effect stings

fmod

Fmod for an audio person is fairly simple to use as it acts just like any other “DAW” (Digital Audio Workstation ie. Ableton/Fruity Loops/Pro Tools/Reason)

Its main purpose is to make the programmers life a bit easier by creating parameters that the programmer can tie to an event/instance in the gameplay, hopefully making

the programmers life a lot easier (in theory at least  :D)

It also serves to create a bit more interesting audio flow which is really essential because hearing a loop over and over is annoying.

fmod2

The music track is ssplit into 7 separate audio layers:

Layer 1: Basic Groove with Snare 1

Layer 2: Basic Groove with Snare 2

Layer 3: Synth Pad

Layer 4: Rhythmic Synth 2

Layer 5: Melodic Synth 1

Layer 6: Melodic Synth 2

Layer 7: Drop

 

These layers are “Events” in fmod and I have several parameters that affect these layers on the fly:

Parameter 1: Switch between Layer 1 + Layer 2

I wanted to have a different snare sound for when you go left with the catapillah then when you go right. This feature was purely experimental and maybe a bit unecessary but definitely added to the dynamic of the audio.

When you change the parameter, the audio layers should crossfade “smoothly” from one into the other.

fmod3

Parameter 2: Bring in layer 3-6

The different synths that you hear when you fly through the golden pips (located on the inside of the fruit) were initially meant to be 3D objects that you have to find but we ran into time constraints and just made them add to the track.

 

Parameter 3: Trigger “Drop sound”

Because the game was centered a lot around the music everything had to be synchronised to the tempo of the track; the transition time from the basic groove to the drop layer and back could be set in musical increments which was just what we needed. I set it to be 1 bar, which might be a bit too long but was the most musically pleasing variant.

 

What I learned :

-Transitioning between layers/events and having the transition happen rhythmically while maintaining a fairly immediate response is a very delicate task

-Too many dynamic changes in the audio can be positively tributing to the gameplay but shouldn’t be overused. Repetition is very important too.

-Learn your programs beforehand; knowing the ropes of Fmod/Wwise or even just Unity’s native audio mixer can help save time when you are crunching to get general gameplay polished before the deadline.

21417-shot3-1440455644.png-eq-900-500

We had a lot of fun making “Cataphilla” and there are so many more opportunities on the audio side that I would like to explore – maybe a post-jam version is soon to follow :)

If you are interested what I’m talking about check it out:

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

 

Thanks for reading/scanning through!

-Mexicanopiumdog, Pomb, Brendon

Wild Flirting: the post mortem

Posted by (twitter: @calendulagame)
Saturday, August 29th, 2015 12:35 pm

Hi all!

Blooming Buds here with the post mortem of our first Ludum Dare entry as a team. Some things went right while others went wrong, but in the end we came up with a quite positive balance.

The game

In Wild Flirting you take the role of a monster trying to find love using a dating app. The problem is that you have the social skills of… well, a monster. You’ll have to check user profiles and learn about their personalities while you chat, so you are not uncovered and banned from the app.

 

BG-principal-titulo

The process

We have to admit that we had a hard time finding the game idea. We started with a point and click game about being a disguised alien in a spaceship. You had to eat people without getting exposed. We had some more mechanics and contents planned, but we decided to go to sleep and keep thinking before committing to that idea.

The next morning we were not fully convinced with the idea, so we started from scratch! We discussed the idea for like three hours, and then the “Dating app simulator” thing crossed our minds. We switched to the new idea pretty fast, since it was more affordable and heavily focused on design, which is the part we enjoy the most!

We splitted the work into four groups: design, code, art and music.

The design focused on building a huge dialogue database. We had to create a narrative big enough for 10 different characters, each one with its own personality and its own set of questions and answers. We ended up with about 12 pages of script. At first we thought that it was going to be easy, but then we realized that coming up with this amount of meaningful content was really hard and time consuming.

Before the magic

56152-shot2-1440466867.png-eq-900-500

After the magic

On the programming side, we started from scratch. First, we coded a parser to store and link every conversation with each character. After that, we implemented a simple conversation scheme (question-answer-question-reply), trying to mimic the flow and aesthetics of apps like Whatsapp or Tinder.

With the aforementioned coding finished, it looked like we were close to be done. But nothing further from reality. The main scene transitions (between character selection screen and conversation screen), the intro screen, the art positioning in a pretty and usable way… All these “details” took about 60%-70% percent of the development time.

output_VyBOsg

Let me see your guts, Unity

The art team had to build a good environment for the game (the monster’s chamber) with a few animated details. Besides from that, any dating app would need profile pictures, so we had to draw a portrait according to every character designed, which somehow represented its personality.

For the music we had the chance to use a Farfisa Professional 88 organ of a friend of us. That brought exactly the kind of sound that we were looking for. A perfect mix of the 60’s seductive songs and dark humor.

The real MONSTER

What went wrong

  • Distance: lesson learned. The problems in the development of a game are directly proportional to the sum of the distances between all the members of the team, or something like that. We made the whole game separated.
  • Not very modular: our game basically occurs in a single scene, which usually means problems when dealing with Unity + Git.
  • Testing (minimal): we had no testing. Ah no, wait… two people.
  • Last hour bugs: The two testers found some bugs just before the deadline. So we were in a hurry!

What went right

  • Scope!: we are proud to say that it was, surprisingly, highly accurate. If we had decided to put some other mechanics or content we probably wouldn’t have finished on time.
  • Organization was key: knowing what each of us had to do at every moment kept us busy and focused.
  • Team work: we had constant communication, allowing us to help each other and providing feedback when needed.

What we used

  • Code: Unity, C#
  • Art: Photoshop, Illustrator
  • Music: Farfisa Professional 88, Cubase, Audacity
  • Collaboration tools: Google drive, Gtalk and bitBucket

Thanks for reading and feel free to try Wild Flirting!

Try it out: http://ludumdare.com/compo/ludum-dare-33/?action=preview&uid=56152

 

Path of a Psychopath – A Post-Mortem

Posted by
Saturday, August 29th, 2015 9:12 am

I am incredibly happy with this summer’s Ludum Dare results. Not only feedback has been overwhelmingly positive in areas we only started experimenting in, the game managed to get 3.11 on kongregate which is huge new record for us and motivation to keep ever going.

Now, what is this game, you may ask?
It’s an interactive story with a somewhat uncommon interpretation of the theme: instead of straight up Godzilla-style destruction we went for the more subtle dictatorship-building kind.

What went well:

  • We kept it simple. This may sound silly but it feels like the hardest part of every LD is planning small, then cutting most of it off to fit in time. We focused a lot on doing the MVP (Minimal Viable Product). We made just enough conversations and cutscenes for the story to have a beginning, an arc, an ending. We could have added so many more, had the ideas for them all. But rather than shipping a game with 8 incomplete and ugly and inconsistent levels, we decided to have the 4 we had and polish them.
    We added effects, refined the texts, had playtesters fish out the bugs and try to break the game by clicking everywhere they shouldn’t be clicking. This all ended in a much better experience all-together. Keep in mind, a longer game is not necessarily better.
  • We dared to go for minimalism.
    This saved us both time, effort and probably made the game better all around.
    Instead of full figures and faces, we used silhoutettes. Easier to draw (art is a weaker side of our team compared to the visual wonders some others make here :) ) and it allows the player to place the characters of their own imaginings into their place. We had a very clear idea of how our monster would look but others from all around the world would probably have different ideas so we settled for an evil-looking hat.
    The other artistic decision was making the game full grayscale. It ties in well to the old-timey atmosphere and generally dark storyline and also saves us the color-picking effort.
  • Teamwork. This is the 6th Ludum Dare the full team takes part in and by this point, we work together really well. There is a general sense of who is a master of what and how much progress we should be making by the nth day and the need to ask each other what we should be doing once we finished X task is smaller every time.
    Despite our scheludes being all over the place, we managed to make our best game yet.
  • Shine, polish and juice. We added a bunch of effects that really help the atmosphere appear. See one below for example.

What went wrong:

  • The aforementioned scheludes. We didn’t plan ahead enough for the LD and families and stuff so I believe if we had more working time we could have done some more features and scenes.
  • Spaghetti code. We did not have a conversation-framework so we made one on the fly – making the final debate that has a large conversation tree instead of the randomly rolled standard kind of the first 3 was a lot of pain and copy-pasting. Seriously. For lack of better ideas to name them, I made 40 functions with the names one, two, three… forty.
  • Recording device. Our music is praised a lot in comments but it was recorded with a camera that was lying around the house. It would probably be even more gorgeous with an actual microphone.
Very sinister!

Very sinister!

Gameplay

Gameplay

 

Play the game by clicking here!

Hell Court – Post Mortem

Posted by (twitter: @9chuckeles9)
Friday, August 28th, 2015 3:10 pm

This is a long post about my experience making Hell Court. Reading time: 7-10 minutes.

1

 

About the game

Hell court is a platformer, where you are a master of a dungeon in hell. Humans that have sins come down here to be judged. You first listen to all the sins they have made. You then deal physical and mental pain to them, based on the sins they have committed.

Here’s how I made it.

Before the Ludum Dare

Two days before the start I was kind of bored and visited CompoHub.net. There I noticed that Ludum Dare is starting soon. I immediately started voting and let my family know that I will be coding a lot in the following days. This would be my second game jam and I was curious what I’ll come up with.

To maximize productivity, I told everyone not to distract me during the jam. I also installed Cold Turkey to block distracting sites. I paused every aspect of my life not related to making games, such as reading books.

I was ready.

The start

The Ludum Dare started at 3 am. I could not sleep well, so I got up at 5. I read the theme and started coming up with ideas. Soon enough I came up with the idea of my game. You will punish humans for their sins in your hell dungeon of some sort.

So I took two sheets of paper and started drawing. Images, mechanics, anything.

IMG_20150828_215414.011

Then I drew a rough plan of a level from the game and made a todo list.

IMG_20150828_215356.350

After all that, I was ready for the computer. So I created a Github repository and Unity project inside it.

First day

I decided that I will create the platformer part of the game first. This had to be good enough, so it would not stand in the player’s way. I created sprites for the devil and some blocks in Aseprite. Then I moved to Unity.

I should now mention that my artistic skills are horrible. I knew that, but I also needed to create graphics for the game. My previous game looked bad. I knew it was because I’ve been using random colors (and lack of drawing skills of course :P). So this time, I wanted a simple color palette with few colors I wouldn’t have problem using. I used ColorBlender and Coolors to create a simple color palette. I also restricted myself to 16×16 pixel images to keep things simple. In the end, I think it all paid off.

So back to Unity. After a while, I had the movement done. I then added stairs into the game.

Next, I started working on the sins system. I wanted every human to choose random sins from the sin database I would create. The exact number would be defined by level settings. Every sin would have associated mental and physical pain.

Done. Now humans. For movement, they shared some of the components of the player. I also added random movement so they don’t just stand still.

Now I needed a way to deal the pain. I added a pot and a skeleton. Then UI and dialog system. Then I made humans and skeletons say random stuff.

I wasn’t worrying about the quality of the code at all. It ended up being a mess, but I was astonished about speed at which I kept adding things. Lesson learned.

Anyway, first day was ending and I was happy with the progress.

2 3

Second day

I started by taking a paper again and drawing mechanics I wanted in the game. I also drew objects and the sequence of the listening table. Finally, I made a new todo list.

IMG_20150828_215313.601 IMG_20150828_215335.891

That day I wanted to add animations and sound. So I started drawing idle, walking and carrying animations. Then I moved them into the Unity. Making animation states in Unity is super easy, so I had all animations in within an hour or two. Next, sound. I downloaded Bosca Ceoil for the music before ahead of the start. I decided not to create any music, though, because I had no idea how.

For the sounds I used sfxr. I added them in, putting code to play sounds all over the codebase (and adding comments like “shouldn’t be here, but it’s LD so whatever”). I couldn’t get 3D sound in Unity working for my 2D game. So I wrote custom system to handle volume and panning (and random pitch) of the played sounds.

With animations and sounds the game felt great to play. It made me proud. The best sound system in the game is that for the dialogues.

More levels, menu, highscore system, random objects to fill the levels with… I made good progress. I went to sleep happy.

4

Third day

I decided to add statistics tracking to the game, just for fun. I used Mixpanel and Mixpanel-Unity-CSharp I found on Github. It working great. I tracked useful statistics, but also some funny ones. Like the number of times a human has been picked.

I needed more ways to deal pain. So I added flying ghosts, reusing logic from skeletons. Then lava. I also added a healing table.

After that, I spent a lot of time creating levels. I found out that Unity is not that great for building 2D levels, especially tiles ones.

After all that, I added flamer.

The game was done.

It was about six hours before the jam ending, so I began the preparations for a release. First time I was releasing a game in Unity.

At first, I created and entry just with a Windows build, but I also wanted a web build. After a few tries, I wasn’t satisfied with the WebGL build, so I made a Web one. I put the game on itch.io, wrote a post and a tweet. Later I also added Mac and Linux builds. I couldn’t test them, but Unity makes it so easy, so why not.

What went well

  • No distractions. I blocked them all, on the internet as well in the reality.
  • Graphics. By using a constrained color palette and image size, even I was able to put out decent graphics.
  • Code. I didn’t worry about the code. I didn’t refactor much. I didn’t create complex systems. That allowed me to advanced faster. The code is a mess, though.
  • Planning. I drew a few things, made a simple todo list and that was it. Then straight to computer. No long descriptions or anything.

What to do better next time

  • Some basement for code. This I will accumulate over time, just right now I started from scratch. I would certainly need a code for game object pool, for example.
  • Recording development. Right now I only my memory to recall what was roughly happening. Next time, I will probably record a timelapse and write notes.
  • Keep the game short. According to my statistics, nobody made it past the fourth level yet! That means that nobody even tried a flamer yet. Next time, present features faster.

5

The future

I will work on the game. Some aspects need to be tweaked or removed, like the platformer side of the game. I also need to rewrite most code.

Also, I’ve never sold a game before. I will try it with this one. The full reworked version will hopefully be my first paid game. I will create a blog and post updates there. I’m thinking I’ll use Tumblr for that.

Final

Thanks for reading this long post! If you haven’t played Hell Court yet, check out my entry here.

What do you think about the game? Should I continue working on it? Please leave a comment here or at the entry page. Have a nice day!

This post has been checked by the wonderful HemingwayApp.

6

Fear Me! – Post-mortem (pun not intended)

Posted by (twitter: @JustSomeNikola)
Friday, August 28th, 2015 1:58 pm

In Fear Me! you play as a happy-go-lucky ghost who has recently breached the veil of the damned in pursuit of his favorite leaisure activity – scaring children. A sort of action-puzzle blend, check it out if you dig that sort of stuff.

One of the more action oriented levels.

One of the more action oriented levels.

Short disclaimer: I’ll be writing like I know everything about everything, but in fact I just have approximate knowledge of many things.

How it went:

After being rudely awoken somewhere in the early afternoon by a combination of my dogs yelping and my neighbours drill-and-hammer work, I came to the realisation that Ludum Dare was going strong for about 11 hours. After a couple of sobering slaps, cups of java and some sandwiches I was ready for some gamedev on PC action. It was time for…

Brainstorming! (1-2 hours)

I put some depressing music on – Steve von Till – and pulled out my notebook and pen. A list of wild ideas came torrenting from the weird places of my brain.
It includes a Through the eyes of a dictator – Painting Simulator where you’re a painter. But you’re also Hitler.

Pictured: Game design document.

Pictured: Game design document.

(more…)

Post-mortem: Flappy Monster

Posted by
Friday, August 28th, 2015 1:55 pm

Flappy Monster is a nod to helicopter-in-a-cave style flight games, and turns them sideways. More popularly known as “Flappy Bird” games, the thrust/gravity/navigation mechanic has been around for a while. In my twist, I gave the monster ineffectual wings. Flapping makes him angry (because he can’t fly) so he runs, runs faster, through buildings and forts of humans civilization who desperately lay down sharp pikes to stop him.

WHAT WENT WRONG

Idea waffling

I start each game jam by walking the dog and talking to myself like a weirdo. I run through the possible interpretations of the theme, what I think others might do, and how I might distinguish myself. When I get back, I have a drink (this time it was Remy cognac), sit on the porch, smoke a cigar and brainstorm. Normally by the end of the evening I have several ideas fleshed out and I’ve at least picked one, with the core mechanics designed. But this time, I was flustered, and was waffling between two ideas until 4AM.

The first idea was an homage to The Thing where you were accused of being the monster (but not actually). It was somewhat a logic game, where you knew little facts about the other people that clued you into who was the monster. Anyone left alone with the monster could become infected, and then you had two monsters. You assigned characters to do tasks which revealed more clues about who’s the monster. Characters would have trust levels with each other, making this task harder, and ultimately putting suspicion upon you, perhaps leading you to becoming infected yourself. I loved the idea, but I spent hours researching logic puzzle design and failed to nail down precise core mechanics.

The other idea was a chasing game. People thought you were a monster and chased you, and you responded nonviolently. If they grabbed you, they held you in place until you shrugged them off. If you stayed held long enough (perhaps because several people grabbed you), your health would begin to drop. The twist was when your health reached a lower threshold, you’d explode with rage, killing everyone on the map. So ultimately you are the monster (albeit provoked), and your goal is to survive long enough. I eventually settled on this idea, but I was still analyzing mechanics in the morning, trying to figure out how to make the chase exciting. Ultimately when it got to noon, I acknowledged that this design had too many issues and no time to work on them.

I came up with the Flappy Monster idea as an alternative, as something I thought I could build with the time remaining.

Poor prep

I generally code Haxe using the Sublime 3 text editor. It’s not an IDE. It has support for templates but I don’t use them. It has support for completion, code style, and shortcuts using the Clemos Haxe Bundle but I had trouble getting it working properly and stopped using it a while ago.

Under the hood, Flaxen uses Ash-Haxe as an entity-component system. The benefits of this system are only realized if you actually use systems and components to address states and behaviors in your game. These things require some boilerplate code. Not a lot, but when I’m coding under the gun, the extra minute it takes to set up this boilerplate and locate the file in the appropriate location seems like forever.

So instead I start hacking. The code base gets ugly, cluttered, and hard to extend very quickly, and by the end of the 48 hours I’m fighting kode krud in my desperate attempt to cram in one more feature. Next time I’ll put together some templates and macros to make this process quicker, and keep me leveraging the ECS.

Also, I had little practice with Spriter. While I love the ability to do custom animations in it, it’s a buggy and very quirky app. Between Spriter and TexturePacker, I was trying to discover an efficient art pipeline that wouldn’t drive me nuts. In the end, I barely escaped a Lovecraftian descent into insanity. Seriously Spriter, I have to enter my custom rect every time? You can’t save that shit in the scml file? Jerk.

Ran out of time

This “what went wrong” is always on my post-mortem list. And every time it’s my fault. Because I know I have 48 hours and only 48 hours to make a game, yet I “blow the time budget” at various points. I have to be more ruthless in my time management. Unknowns are a killer and a time sink, so prepare as much as possible, and if the design is not coming together quickly – ditch it!

As one gets to the end of the deadline, things stop dropping off your to-do list in favor of more critical priorities. In my case music and more special effects never happened. And the game would have benefited immensely from another hour of playtesting and tweaking. But that’s alway the case!

Users complained that the pikes were hard to see, the difficulty was brutal, the RNG was unfair, and the monster took too long to slow down. All true, my friends, all true.

WHAT WENT RIGHT

Knowing when to scrap a bad plan

I’m glad I switched ideas.

The chase game was still stuck in design, and I’ve been bitten before jumping into development without thoroughly understood gameplay. The idea I came up with was a twist on Flappy Bird, placing it on its side. Instead of flapping for height, you flapped for running speed. Instead of the “height” of a hurdle to get over, buildings of different sizes required a minimum speed to run through (or you get knocked back and your game ends). And to simulate a “roof” to duck under, I added pikes in the ground that you could only tiptoe through; if you ran too fast, you’d trip and get impaled.

It’s a decent twist. It doesn’t quite provide the same depth of experience as a flying game. For example, when flying you may have to fall half way down the screen, but in Flappy Monster (where the running speed correlates to flying height) there are no pikes that require a max of “half” speed. All pikes require you to go pretty slowly, so as a result pikes right before buildings can be quite punishing.

Completed!

Out of 9 Ludum Dares, I’ve completed 6. That’s a terrible stat that shows I have persistent issues with time management. In some cases I’ve hit the deadline very close to a playable game, which I consider a minimum requirement for submitting. (Some people don’t.) Despite my fumbles, I (eventually) leveraged my ability to recognize when plans needed to change, I identified and shifted priorities, and most importantly, I placed utmost priority and focus on the goal completion. Without that, no game!

Working on a Post-Compo version

When the compo ended, the game had only JUST become truly playable, and I was entering a groove where adding features and juice was eminently satisfying. So why stop there? I branched my code and kept working on a post-compo version, albeit at a more-relaxed pace. I added scrolling grass, shaded the monster, cleaned up and animated the pikes, added a demolition rumble effect, smoothed monster movement, tweaked the RNG to be less cruel, and gave the monster an increasing deceleration for faster and more dramatic slow downs. It’s more playable. And I’m still adding things to it. It gives interested players a change to look at something closer to “what I was going for,” and rewards them with a better experience as appreciation for looking. And I get to put in those missing elements that make me happy. :)

Out West Post-Mortem

Posted by
Friday, August 28th, 2015 2:12 am

Well, it’s that time! This has been my first Ludum Dare, and it has been great so far. Thank you for all the support! Right, now onto the important stuff.

Out West Promo Photo

Play “Out West” here!

 

The Concept:

My goal with this first Ludum Dare was to make something small that could be developed, finished, and played without any major bugs. I had been experimenting with text adventures and pixel art, so I chose Twine as my tool, since it’s very easy to use, can be expanded upon, can incorporate art, and is contained completely in one HTML file that can be hosted anywhere and played by anyone.

Once this choice was made, I decided my secondary goal was to try and create a very tense and atmospheric mood with only text, art, and time, disproving the common notion that text adventures are perceived as boring slogs which appeal to a certain niche audience (myself among them). Granted, I cheated a little by including art, but as a picture is worth a thousand words, I felt it would enhance the gameplay immeasurably.

 

The Bad:

  • The game is very short. I needed to keep myself in check; my games are prone to feature creep (which is one reason I participated in this jam) and tend to balloon into iii development nightmares which can’t realistically be handled by one person. Even so, I nearly didn’t make the deadline. There are three possible choices early on, and then another three later: These immediately necessitate nine different endings, plus different factors which dictate other variables that require separate endings, plus these all tie into the main ending, which must take into account everything that’s happened in the journey. Due to the exponential complexity being created, I had to cut off many ideas I wanted to incorporate and focus on making satisfying endings for what I had. That isn’t a bad thing in and of itself, but it forced the game to become minuscule, which is a bit more of a problem with text adventures, there being a finite amount of content with a definite end, as opposed to Pacman.
  • There was no time to add in any complex game mechanics. I know: Game mechanics, in a text adventure? Surely you jest! In all seriousness though, I wanted to add in even more interactivity through JavaScript enhancements. Unfortunately, there was no time to properly code anything myself or learn someone’s mod. I worked with what I had, and from the feedback it appears that effort’s been appreciated; But I would have liked to do something like roaming AI characters in the town, with random conversations as possibilities.
  • Almost no animation in the art. Again, this was time related. I didn’t want huge cutscenes, just little touches of animation that would enhance the world, like having the landscape bob up and down as if you were galloping on a horse, or animating flames, weapons, movement, villagers, that sort of thing. Repeating gifs, mostly.
  • The game is very linear. This is partially due to writing and the nature of Twine; the story requires a certain progression, and the creation of atmosphere and mood also require a certain amount of control. That being said, there perhaps could be a free-roam period before the start of this particular sequence which allows you to explore the world a little, or some other stuff which could expand the illusion of choice and open world gameplay.
  • The art. Some have commented how they enjoyed the pixel art, and I’m very happy they do – I’m almost a complete novice at it. In general, I’m quite happy with what I was able to achieve with a fire under my butt and limited art skills. I would like to get a bit better at pixel art and go back and polish up some of the imagery to facilitate better immersion in the world.

 

The Good:

  • The art. Again, I’m a pixel art beginner, and I’m frankly amazed that I was able to finish up all of it in time, and that it’s all decent. Nothing looks horribly out of place, and I’m actually a little proud of the final image that’s revealed at the very end. Gives me hope of improvement in the future.
  • The writing. This wasn’t my opinion all the way through; as I was writing the adventure I was horribly aware that, since it’s a text adventure, everything relies on the writing, and if I messed it up or it simply wasn’t good, the whole thing would collapse with almost nothing to salvage. That said, the feedback that I’ve received about the writing has been positive, with several mentions of it being very well written. I breath a sign of relief. Moving on.
  • I finished it. As with many game development beginners, I fall into the trap of being overly ambitious, even with text adventures. I am glad I put down my foot and had a very strict goal in mind. Though I had to work until the deadline because the art took more time that I anticipated, I still managed to incorporate all the stuff I had planned for this tiny little thing.
  • People seem to enjoy it! I’ll be honest, this was a nerve-wracking experience for me (especially ticking the little “Anonymous Feedback” box). I have never done a game jam before, and had no idea what would be said about something I made. I wasn’t expecting anything, but just the fact that someone enjoyed the experience the way I attempted to craft it is a wonderful feeling. Thank you all again for your feedback. It’s appreciated. And thanks to everyone who’s games I’ve played: They’re all wonderful, fascinating and strange! Well done!

 

Conclusion:

I think I’ll work on this some more, give it a bit more of an edge. I’ll have to be careful: I don’t want to bloat the experience or dilute the atmosphere. We’ll see where it goes. Five minutes of story is vastly different from a three act structure. Either way, this has been an eye opening experience. If you play Out West, I hope you enjoy it. Good luck to everyone!

LD33 – Post-Morterm – Engine design

Posted by (twitter: @tehPHEN)
Thursday, August 27th, 2015 5:56 am

Thank you all for this great jam! This was my Ludum Dare. I barely made something ‘playable’ and I had a blast doing it! (Link at the end)

Things I’ve learned about designing a fully functional game engine. There’s tons of subtle things I’ve learned over the years of programing and the 4 months I’ve been developing a silly 2D engine.

First of all, if you want to make a game. Don’t start with the engine. Start with the game!  I’ll reiterate this again!

There’s a very distinct lesson in there about making engines. This post-mortem is all nerdy-programmer engine problems talks. So unless you’re into that, this post isn’t for you!

So for those of you crazy enough to venture down this road I’m here to talk about my experience about using my engine.

Why do this?
I find there is a unique design problem when designing a system for games. With games the problem set is very distinct, yet no one has one right way of doing it. I find it fun trying to approach these problems in different ways, and learn why they were made.

Second reason: I love C++, and wanted to try some of the new features introduced in C++11.

Why Ludum Dare?
I’ve been working on my current engine for about 4 months now (every odd weekend, and weekdays.) I haven’t actually made anything out of it, other than making some squares collidable on screen.

I feel having a solid criteria such as making a playable game in 72 hours seemed like good way to test drive your engine, as a great way to see if your original designs worked the way you wanted to. The timing of Ludum Dare was just right, so why not I said!

My engine of course wasn’t done going into this, so this was as good as a train wreck as you think it might of been for someone’s first ludum dare.

So what are your take home lessons?

Lesson One:

A modern ‘game engine’ isn’t just the code you write to get your game running, but it should encompass all the tools and built-in scripts to get the dirty work out of the way.

My engine had none of these said tools. No tools to align hitboxes, No tools to preview how large this magic ‘64’ units is on screen, no tools to preview the scene/camera in game. I had to manually write the code to spawn game objects in a particular position on the screen (translating from game cords to screen coords).

There’s a ton of things established game engines provide, and I fear should anyone designing a game engine should address these problems to even be considered a modern feasibility useable engine.

This lack of tools caused Iteration time during the ‘working on the game’ part was extremely slow. I either had to: Program in a solution (which has nothing to do with the game itself) or Hack together some solution that solves it for this game, and doesn’t really apply to any other game. Hacks made my stomach churn as I *knew* I’m going to remove this code as it really doesn’t belong in the *engine*.

Solution: none other than to provide plenty of tools for your designers and developers. Low level engine details should be left for the crazy people like me to work on. Things like game logic, game rules, positioning hitboxes and animations should be done in tools designed for the engine. Even the engine itself could be a tool if designed well.

Lesson Two:
A modern  ‘game engine’ should have fast iteration times in every aspect of design.

I knew this would be a problem, so I introduced a game object serializer. I can modify the base version of a game object in plain tex, reload the game and bam! the object has been changed.

Unfortunately, this was strictly just that, one game object, one file. My game had hundreds of trees and chickens flying everywhere. It just wasn’t feasible to do everything using the serializer, so some values *had* to be computed at run time.

Every time I wanted to change how fast something spawned on screen, I had to either: Finish writing the serializer to support loading in this value at run time (this could of taken precious hours!). Or change a magic static number and re-compile a small portion of the engine (this took 2-5 minutes).

That wasn’t bad, until I realized things spawned too slow. *recompile*
Still too slow *recompile*
Then I made everything collidable, now things spawned too fast.  *recompile*
Then I …

You get the point, those add up! Game design truely at its core is iterative. 

Lesson 2.5:
A modern  ‘game engine’ should have fast iteration times in every aspect of design.

Reiterating this again, fast iteration is key! A engine should not impede its designers!

Next thing to boot, was animations! Boy, changing a file name was a PITA. Every time I renamed my file, I had to re-open and re-edit all my game object text files. To boot ontop of that, I couldn’t think of a elegant way to frame-rate using the serializer, so I just hardcoded the animation frames in code.

This meant, each time I added a new frame of animation, I had to update all text files that references this new image, recompile the engine itself because I hardcoded the frame time for this animation.

The amount of work it took to get a 5 frame animation in was so much work, I *completely* abandoned animations for the sake of getting something done.

I think Scripting will solve this issue. Implement a way to talk about your game objects, modify your game objects, and do all game related logic in your scripts. I really regret not prioritizing having a fully scriptable elements in my game prior to entering this.

@indieprogram recommended me Squirrel (a variant of LUA, used by tonnes of valve games).  I’ll definitely look into this!

Lesson Three:
A modern ‘game engine’ should not be a PITA to deploy to your users.

I knew NOTHING about releasing binaries on Windows. Boy, does windows make it hard! In the end I couldn’t solve the issue. I had to get users to install the Visual Studio 2015 ‘Universal Common’ Runtime libraries.

“Universal Common” my butt!

My engine was only 2megs big, half of it being game assets! Why do I have to include a 14MB microsoft installer for it to work on a Windows machine!?!

This was something I didn’t consider going into the Jam, and boy. I spent hours on hours trying to get a half decent solution.

I have yet to look into ways of solving this, short of not including standard runtime libs.

Wind down:
It was a blast for my first Ludum Dare. I honestly think I would of had a better game if I dropped my engine and paired up with someone and just worked on game in established engine (such as GameMaker, RPGMaker, Unity, Unreal… anything really where I didn’t have to struggle with lack-of-tooling)..

The game design (or what little of game designing I did) were quite fun. Things such as Brainstorming, Player Feedback, General “look” and “feel” of the game where things I touched on this Jam!

I found it especially engaging to come out to my local meetup group (@calgarygamedevelopers) to brainstorm and work on ideas. I highly recommend going out to these and engaging with your local community!

I’ll likely keep working on my engine post-jam as I’m having tons of fun. I’ll hopefully bring it to another Competition with a better game next time :0

Feel free to hit me on twitter! @tehPHEN

If you want to see the results of this checkout:

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

Someone stole the Princess! Post-Mortem

Posted by (twitter: @@donpastor82)
Thursday, August 27th, 2015 5:52 am

TL;DR WARNING!!!

 

Let’s code a roguelike. Should be easy, right?

Oh man, I was SO wrong. A roguelike might be one of the most complex game types to code, given the amount of interactions possible between its elements (just take a look at NetHack).

From the start I planned a short dungeon romp (about 10 floors deep) with no inventory screen. The original plan was an icon to appear over the player’s head when stepping over an equipment piece for exchanging gear (with the future difference in stats reflected in the GUI).

Of course, as monster can’t hold much equipment (they are not that intelligent) I wanted to put emphasis on drinking potions. Lots of potions with crazy effects affecting gameplay.

You can see the details in my Super Awesome Design Doc ©

Greatest concept art ever

Greatest concept art ever

The challenges

A roguelike is NOT a realtime game. Monsters move when you press a key, and the game world is divided in tiles (usually square tiles, but not always). Each key press is a “turn” and, as there are many actors involved in a turn, there must be a way of managing everything.

Another obvious challenge is map generation. In roguelikes every game is different. Maps are procedurally generated, as well as item end enemy location.

Other not-so-obvious challenges involve enemy AI (foes should chase you in an intelligent way) and field of view, where only the visited rooms are drawn in the map (strategy players will know this as ‘fog of war’).

What???

What the hell?

How does a turn work?

I designed the turn management (turn-o-matic in my code) as a fixed series of events:

Player movement → Enemy movement → Effects update (poison, burn, etc)

First the game would check what kind of tile the player wants to move towards. Depending on the tile type different actions will be triggered:

  • If it’s a wall, player won’t move.
  • If a potion, player will pick it up and effects will be applied.
  • If an enemy, combat will be triggered.
  • If a closed door, it will be opened.
  • If a ladder, player will climb and map will change.
  • Finally, if it’s floor or an open door, player will move.

Next would be enemy movement. Enemies chase the player when there is a path available. That was accomplished thanks to the EaysStar.js library, that allows asynchronous A* pathfinding in your game.

For EasyStar to work, you must provide an array filled with numbers and tell which tiles are walkable, and the start and destination coordinates. For example:

      var walkablemap = [[0,0,0,0],[0,1,1,0],[0,1,1,0],[0,0,0,0]];
      estar = new EasyStar.js
      estar.setGrid(walkablemap);
      estar.setAcceptableTiles([1]);
      estar.findPath(foe.posX,foe.posY, player.posX, player.posY, function (path) {
          if (path) {
              //if success then move the player
          }
      }

EasyStar returns a “path” array containing all the calculated steps to the target. So for a turn we would take the second element of the array, as the first one is the origin point:

    moveFoe(path[1].x,path[1].y);

As EasyStar wouldn’t let the foe step over a wall, game must only check if the destination tile is an empty tile (in that case the foe move towards that tile) ot the player (then it triggers combat).

As for the effects updating, things like ‘Poison’, ‘Burning’, ‘Weakened’, ‘Silenced’ and such were planned but not implemented, so this part is empty.

What went well

Tileset generation went smoothly. Cosmigo ProMotion, while not very intuitive, is a great tool for making tilesets. I also tried Pyxel Edit and liked it even more, but sadly the outdated free version was full of bugs, like refusing to load half of the tiles when loading a project.

The game flow coding went smoothly. Almost a pseudocode to code direct translation.

The map rendering worked on the first try. While some of the wall tiles are not drawn correctly, it doesn’t affect gameplay. It will be corrected soon (that should count as a bugfix for the entry, right?).

¡Behold this amazing black screen!

¡Behold this amazing black screen!

What went wrong

Map generation. For the map generation I took a look at this code, and while I got it somewhat working, didn’t have time to fully integrate it with my game. This is something I’m looking for in the post-LD version I’m making.
I ended choosing a random map between 20-something premade maps. While not common it is possible to see a repeated map ingame.

Field of view is not implemented at all. Shouldn’t be hard to generate a rogue-style FOV, where the full room is revealed once it’s in the player’s range. I’ll leave that for the post-LD version.

Content and gameplay balancing. Base game took so long to code that I didn’t have time to implement many of the things I planned: different foes with different behaviours appearing at different depths, player abilities, equipment system and, of course, some eye-candy.

Map generation needs work

Ouch! Map generation needs some work.

Thoughts

Just as last LD, this was a really fun experience. While I didn’t enjoy the theme much, I’ve always wanted to code a roguelike. I did not completely succeed, but at least my entry is in a somewhat playable state. I’m fine with that :-)

See you at next Ludum Dare!

You can play my entry HERE. Feedback is welcome.

Tactical Superiority Post-Mortem

Posted by
Wednesday, August 26th, 2015 11:00 am

Particle Splendor

Play it here

Or continue reading to uncover important life lessons.

Overview

This time around I tried something else. Historically my plan has always been to come up with an ambitious programming heavy design and get it done (with varying results). This time the theme didn’t inspire any kind of grand design so I decided to take a walk on the other side.

On the very opposite side, where a few programmers dare to venture..

Graphics first!

24 hours later I had created a single asset, the mech.

To do this I had to relearn my rusty Blender skills (they’d been rusting ever since last LD) and apply a hefty amount of new found graphic artist abilities on top of that:

Modelling, rigging, inverse kinematics, animating, texturing, the list goes on (no it doesn’t, but that sound more dramatic!).

The rest (not sleep, unfortunately [as you’ll soon see {foreshadowing!}])

With only one day left for programming (and modelling other assets) there was no chance to both reach for the moon and cook up a delicious pie from the sky masterpiece.

I settled for a simple design about the player, piloting a mech, attacking a non-military target thus triggering nearby militia to action.

I did come up with some further backstory in the darkest hours of my plight development process, but implementing that fell soundly beyond achievable limits, as did sound to that matter.

Impact (on body and soul)

Monday I got sick. I would wager a very pretty penny that this was caused by not sleeping enough thus disturbing the immune defense system from doing its job. This is the first time for me, so maybe I’m just becoming older. Nonetheless, next time there will be more naps.

The future

The cut features will be implemented in a Post Jam version. I have one additional learning opportunity that I will pursue, but the less I say about that the better. It might not work out.

 

Lessons learned

  • Sleep a bit more
  • Learning is great, but learning the tools could be done before the jam

 

The next LD will be about over ambitious ideas again. It’s been a while…

 

Post-Mortem: Monster House

Posted by (twitter: @Korso10)
Wednesday, August 26th, 2015 7:57 am

Being my first Jam –and my first complete game-, my main objective was to deliver a complete product in 48 hours. Although I’ve been programming since 2006, I was very little experience with graphics, and almost zero with games.

I’ve tried different frameworks and engines to make games during the last years. I’d loved to deliver a game that can be played via web or -at least- in the three main OSs, but due to my lack of experience, I finally used GameMaker Studio (Standard Edition), cause I felt more confident with it. In retrospective, it was a good decision; I doubt that I had completed the game with another tool.

 

The Theme

So it was like 3:00 am here in Europe when the theme was published. I wanted to do something original, but keeping in mind that I had to keep it small. Fortunately, the idea came this same night:

NuevoDocumento_1

Here is a draft of the mechanics of the game. In that moment, there was a single type of monster and two types -green & red- of characters. Nevertheless the main idea, that is, characters run away from the monster turning clockwise or counter-clockwise, was already there. I chose those colors to ‘guide’ the player, cause are the same colors used in planes, boats, etc. to indicate left and right.

So I had a somewhat solid idea of a puzzle ‘lemmings style’ but with a 2d-cenital perspective.

 

Day 1:

First day I decided to do the assets in the morning. My idea was do all the art and core mechanics in the first day, leaving levels & tutorial creation and SFXs and music for the second day. So I did a list of all the assets I needed:

NuevoDocumento_3

I don’t have much experience drawing sprites, so I decided to keep them small, and choose a 16×16 grid that I’d zoomed later to obtain a 32×32 base size. Although I was to use Paint.NET, I decided to do a quick research for more specific tools, and I found Piskel, a free -and awesome- online sprite editor that I used to do almost all the assets. I need also a color pallette, but I quickly found this thread of Pixel Joint forums where an user provided a 32 tones pallete, that I ended using:

db32_v1_pal64x32

To my surprise, I discovered that I actually liked my assets, so I decided to animate them, so I spent some hours in it.

In the evening, I finally began to do some coding. I’ve already decided to switch the mechanic from two types of characters to two types of monsters, so I drafted the ‘monster detection algorithm’ and began the work.

NuevoDocumento_2

NuevoDocumento_5

That night I thought that I had almost all the code, so I did a ‘test room’ just to be sure that all was working properly. Here was where the bugs began :(. I apparently didn’t understand properly the collision system in Gamemaker, so there were a couple of corner cases where the characters ignored the monsters. I couldn’t finish the code that day, so I went to sleep and left the bugs for day 2.

 

Day 2:

So I spent all the morning solving those nasty bugs, and I was running out of time: I had like 12 hours to do all the SFXs, the scenes structure and all the levels -both the tutorial and the game ones-. I decided to skip the game music and I focused in the game structure. Fortunately, all went smoothly and a couple of hours later I was this problem solved.

For the SFXs, I tried to record actual sounds and equalize them to sound more creepy. I could do it with some effects, but I ended using SFXR for the rest of them.

I spent several hours doing the buttons, start screen, credits, etc. So I had only 6 hours to do all the levels. I though that it was more than enough -I didn’t knew how deeply wrong I was-. My initial idea was 5 tutorial levels + 10 game levels. I wanted to do them right so I planned to show 1 new rule in each tutorial, and a smooth learning curve in the real levels.

level3_sol

The process was simple, but time consuming: I first named that level to provide some initial idea. For example in Level 03 – Semaphore, you have a 1 green + 1 red monsters. Second thing was to draft my ‘ideal’ solution for this level (note the floor tiles in the image above), and after that, I looked for another alternative route to provide more than one solution for the player, and an ‘easy’ route without additional points to ease the level to the player if they can’t find ‘my’ solution. Finally, I added the ‘traps’ (ghosts, bats, etc.) to the routes, and complete the map with the rest of the assets. Unfortunately, I ended spending almost one hour per level, so I had to cut my initial idea of then levels to only 5.

When the submission hour was approaching, I ran the game and completed all the levels & tutorials to ensure everithing was Ok, and submitted the game. Unfortunately I only have ‘standard’ license to Gamemaker, so I only could generate the Windows executable -aparently you need a Mac to compile Mac version-. I’d really wished that I could have submitted an HTML5 version :(.

 

What went right:

  • Gameplay idea: Fortunately it came very quickly and was solid enough.
  • Tools used: I consider to use Löve2D, but I’m sure that I had not finished the game if I had used a different engine.
  • Mission acomplished!: For my first jam, my main objective was to deliver a game. I did :)

What went wrong:

  • Time (lack of): I had planned some little tweaks that I think that would improved the game playability, but I spent too much time with some bugs and I didn’t have the time. The lack of music is a pity too.
  • Fast button: In the comments, one common issue by several players is the lack of a button to accelerate the game. I agree 100% with them, and the button it’s actually there -F key to fast-forward-. I mentioned in the info screen, but I had to mention it in the tutorials too. Lesson learned :)
  • Learning curve and level design: Clearly, the difficulty progression that I’ve planned was not too good. And the ‘lack’ of fast button definitely didn’t help. I need to design the levels more carefully, and a ‘pass the level’ option when the player can’t complete it, maybe would had helped.

Conclussion:

This Jam has been an amazing experience for me. I honestly never think that I were capable to create a game like this in just 48 hours. And I think that the game can be improved with some tweaks, so I guess I’ll continue developing it in the next days. I’ve enjoyed so much Ludum Dare, both the event and the community, so expect me for the next! 😀

 

The Void Beast post-mortem

Posted by
Wednesday, August 26th, 2015 5:58 am

In a nutshell, me and my artist completed a Ludum Dare Jam that we weren’t supposed to be joining, but we were proud that we made the choice. We were busy and were loaded with college assignment, however, being inspired by the theme, I told him that we should definitely make a game now (as we have skipped the past 2 Ludum Dares).

Screenshot 2015-08-24 23.17.30

The Void Beast - Hard Mode

Play our game here!

 

Some back story (skip this if you want)

It was 11am Saturday noon when I opened my eyes (yes, I am a night owl), I decided to scroll through Facebook. I saw the first post on the home page, it was one of my Games Development Club (GDC) members wishing me and three others (who are also in the club) good luck in Ludum Dare. I was speaking to myself “Dude, I thought I told you I am not joining??”.

But then again, as the president of the club (oh yes, I am), I decided that I should set a good example to the other club members who didn’t join. I was already late 2 hours (Ludum Dare theme was announced on 9am my time), but I have been even more late the previous Ludum Dare (with 6 hours in, holy shit!), and I am confident that I still have enough time.

While still lying on bed, I brainstormed with my artist and composer (he is new and has no experience in music making yet). I came up with an idea that you are a monster that hunts human down, and the gameplay is roughly inspired by MOBA games such as Dota 2 etc. They agreed, and we went on with the plan.

I woke up and prepared myself and had a brunch while brainstorming to myself how the gameplay will be like. My artist won’t be available until around 8-9 pm (he is out with his family, and he didn’t expected that we are going to join Ludum Dare this time), and I told the composer to go on and try to make some Dota 2-like music. And so, off we go for the next 7 hours. I will be focusing on programming the core gameplay features without the help of any arts.

It wasn’t until 8pm when the composer said he couldn’t make any music, and something is always wrong about it. He felt like he couldn’t continue this Ludum Dare, so I set him free. Well, its not like I don’t know how to compose music anyway, right?

And then, when my artist finally came online at around 9pm, and we continue the rest of the Ludum Dare until Sunday midnight. I showed the game to my GDC members and he showed the game to his friends to get some comment and test for bugs. We implemented the full tutorial slideshow that night, some few minor gameplay changes and bugfixes from the observation when we showed them the game.

We completed the game under 2 days, and the 3rd day is only reserved for beta testing and to make final adjustments and polishing the gameplay.

 

Tools used

  • Game engine – Game Maker Studio: Professional Edition (me)
  • Image editor – Photoshop CC (artist)
  • Sound effects generator – SFXR (me)

 

What went right?

  • Gameplay idea – Everyone (except for one of my friend) is praising the gameplay concept and encouraged us to continue making this game. Well, I didn’t actually think that this garnered much interest, but we think that we know what our next full game project is going to be >:D
  • All planned features – Surprisingly, we were able to implement all of the planned features under 2 days, with the addition of few more features on the third day. Previously, we would have cut corners and do only bare minimum gameplay, but we have improved a lot since then and having much more experience helps too.
  • All assets are original – Oh yeah, its the most indie-est of all indies! And we lived in the basement under the basement! Holy shit its so original 😀

 

What didn’t went so well?

  • Music – There was no music, I didn’t have enough time to focus on it myself, plus I’m not quite confident in music composing yet, and wasting few hours just to get a crappy music? Nah, gameplay’s far more important IMO.
  • Graphic – Since the artist came in late on the first day, he has a lot to catch up on, so instead of going for quality, he had to opt for speed. And that’s why it doesn’t look as pretty as it should have been, but its functional!
  • Game optimization – Since I didn’t want to deal with any more bugs (as experienced in my previous non-LD game projects), I had to use tons of global variables in order to save debugging time and make sure that everything works. And I didn’t do any texture swaps optimization or stops drawing things that are outside of screen as well. This might cause those with lower specs computer unable to run the game without some FPS hell.
  • Bugs – There is still one or two minor bugs left, particularly with the stars that is given to those who completed certain difficulties setting. However, since its not game-breaking nor its that important, I’ve decided to just leave it for now until someone complains 😛
  • Balancing – I will agree that the game is slightly harder for certain people (including my artist as well, his highest score is only Level 5), and the spells mana requirement, the upgrades etc wasn’t very well balanced, but still playable. In the previous Ludum Dare, we had plenty of time for rebalancing the gameplay, but this time we didn’t have enough time and only the last day to finally find out what rebalancing we should do etc. But I think its still playable, as long as you have the right strategy to approach it :)

 

Conclusion

We were really impressed that we managed to squeeze in so much gameplay features in such a short time (2 days for core gameplay) for something we previously thought might take more than just 3 days of hardworking. We also found out that there is a great potential in this game (from the feedback of those who played the game), and we have decided to turn it into a full game in the near future, after we have gathered more ideas on improvement that is. We had great fun in this Ludum Dare, I hope to see y’all in the next Ludum Dare again!

[cache: storing page]