Ludum Dare 36
The Theme is:
Ancient Technology

Feedback Friends
Give and receive feedback on your game
Play and comment!

The Jam ends in
Solo and Teams, relaxed, 72 hours.

Line-line collision detection investigation (part two)

Posted by (twitter: @sealfin)
Friday, July 29th, 2016 7:11 am

I recently rebooted development of a project I tried to develop for the Ludum Dare 20 contest held in April 2011, the theme of which was “It’s dangerous to go alone! Take this!”

As the project will require a function for performing line-line collision detection, and as I’m interested in whether it is possible to program that function using the knowledge I’ve gained-, and the abilities I’ve developed-, studying the Introductory Algebra Review (MA004) and Visualizing Algebra (MA006) courses offered by Udacity, I’ve begun an investigation into programming that function.

In the second part of the investigation – posted to my blog – I investigate programming a function for performing line-line collision detection when the two lines are finite in length.

Line-line collision detection investigation (part one)

Posted by (twitter: @sealfin)
Saturday, July 9th, 2016 11:18 am

I recently rebooted development of a project I tried to develop for the Ludum Dare 20 contest held in April 2011, the theme of which was “It’s dangerous to go alone! Take this!”

As the project will require a function for performing line-line collision detection, and as I’m interested in whether it is possible to program that function using the knowledge I’ve gained-, and the abilities I’ve developed-, studying the Introductory Algebra Review (MA004) and Visualizing Algebra (MA006) courses offered by Udacity, I’ve begun an investigation into programming that function.

In the first part of the investigation – posted to my blog – I investigate programming a function for performing line-line collision detection when the two lines are infinite in length.

We Shouldn’t Be Allowed to Rate the ‘Overall’ Category, Right?

Posted by
Friday, January 22nd, 2016 1:41 am

I want to share something with you guys and get your feedback. Feel free to agree or disagree. But before I continue, I just want to say that I’ve participated in 8 Ludum Dares so far, and they’re what I look forward to, I love them. Ok, now I’ll give my little spiel.

After making your game in the 48/72 Hour Time Limit, we get to check out and Rate other people’s games. When rating somebody’s game, we are allowed to give them x out of 5 stars in 8 different Categories. These Categories include: Innovation, Fun, Theme, Graphics, Audio, Humor, Mood, and most importantly, Overall. I’m going to talk more about the Overall category in a minute. Let me just talk about something else first:

As many of you may have noticed, probably for a while now, your results don’t seem very honest. The results you get may seem surprising, this could be in a bad way, or in a good way. You’re either pretty disappointed, or you’re really happy. This is because you didn’t get a ton of votes (i.e.: ~20-70 votes, which is what a lot of people end up getting). Think about it, there were about 2,800 other games out there. Do you think that with 50 votes out of the 2,800 entries you’ll get a really honest evaluation? You shouldn’t, because unfortunately, that’s not the case.

If 5 people rate your game and they all give you a 5 on Fun, the average would be a 5/5. If 10 people rate your game and 8 of them give you a 5 on Fun, and the other 2 give you a 4, the average would be a 4.8/5. Now the game with an average of 5/5 is ranked higher than the game with an average of 4.8/5. But the game with an average of 4.8/5 should be ranked higher because it had similar scores, and more people played it. Now I’m pretty sure that in the end the game’s categories aren’t ranked based on just the amount of stars given but still, I just wanted to give you something to think about. The rankings aren’t all that honest. I noticed that many of the Top Ranked games only had about ~30-70 votes. You’ll see that the games that got the most votes weren’t up there in the Top 100. But they did, however, have more real honest evaluations, while the others with ~30-70 votes were just lucky enough to get a handful of good ratings which therefore gave them higher rankings. The Top 100 are great games, no doubt, but are they the best out of the 2,800? We don’t really know for sure.

Ok, now I’m going to talk about this Overall category. The site says that your game is ranked overall based on your Overall category ratings. Do you think that we should be allowed to rate the Overall category? The Overall category should be based on the other categories rounded up. The site should give us the Overall Rating, not us. Here’s just one reason why: I’ve seen many people give a game great ratings, like 4-5 stars on every category, and then they would give the Overall category a 3. Umm… What? Shouldn’t you base the Overall category on the other categories? If you gave all the other categories 5 stars, then why would you give the Overall category 4 stars? The Average Overall Rating would be a 5, so give it a 5. But since people don’t always do that, let the Robots do the math and give us the Overall Rating, not the Humans.

I’m not entirely sure how Mike (Founder of Ludum Dare; Support him on Patreon!) can make the evaluations more honest because you can’t just have 2,800 people play all 2,800 games, that’s just ridiculous. But it’s just something to think about.

Thanks for listening!

SDL2 joystick interrogator (third version)

Posted by (twitter: @sealfin)
Friday, September 25th, 2015 3:03 pm

Interrogating a Sony PlayStation 2 DualShock 2 controller; I’ve yet to figure out why SDL2 reports that the DualShock 2 has five axes (although my PlayStation-to-USB adapter might be to blame), I’ve yet to figure out a solution – which doesn’t involve a ⅓ axis dead zone – to the problem of the thumbsticks on the DualShock 2 not always returning all the way to the origin when they’re released, and I last touched a DualShock 2 a long, long time ago so I’d forgotten that the D-pad is disabled in analogue mode :/

I recently rebooted development of a project I tried to develop for the Ludum Dare 20 contest held in April 2011, the theme of which was “It’s dangerous to go alone! Take this!”

As the project will require a controller with an analogue stick to play I’ve begun to develop a utility to interrogate the capabilities of various controllers – and as I feel that the SDL2 documentation is lacking with regards to the joystick support offered by that library I’ve posted to my blog the source code to the third version of that utility, for the benefit both of myself and of others.

SDL2 joystick interrogator (second version)

Posted by (twitter: @sealfin)
Thursday, August 13th, 2015 9:04 am

Interrogating a Sony PlayStation 2 DualShock 2 controller.

I recently rebooted development of a project I tried to develop for the Ludum Dare 20 contest held in April 2011, the theme of which was “It’s dangerous to go alone! Take this!”

As the project will require a controller with an analogue stick to play I’ve begun to develop a utility to interrogate the capabilities of various controllers – and as I feel that the SDL2 documentation is lacking with regards to the joystick support offered by that library I’ve posted to my blog the source code to the second version of that utility, for the benefit both of myself and of others.

SDL2 joystick interrogator (first version)

Posted by (twitter: @sealfin)
Saturday, August 8th, 2015 12:57 pm

I recently rebooted development of a project I tried to develop for the Ludum Dare 20 contest held in April 2011, the theme of which was “It’s dangerous to go alone! Take this!”

As the project will require a controller with an analogue stick to play I’ve begun to develop a utility to interrogate the capabilities of various controllers – and as I feel that the SDL2 documentation is lacking with regards to the joystick support offered by that library I’ve posted to my blog the source code to the first version of that utility, for the benefit both of myself and of others.

TRI Post Mortem

Posted by (twitter: @RatKingsLair)
Tuesday, November 4th, 2014 1:53 pm

TRI is a game with a long story, so I won’t even attempt to remember every detail. Instead, I will write down what comes into my mind. This way the following article might be a bit inconsistent; I hope it’s still an interesting read.

The story begins in April 2011, when I participate for the first time in a big Ludum Dare event. It was the 20th Ludum Dare, with the theme “It’s dangerous to go alone! Take this!” (a quote from Zelda) – but the theme didn’t really matter, as I got the idea for my entry the evening before. I was inspired by working with 3D modeling software, where you create and manipulate polygons, and I thought: how could I use that for a game? Good thing the eventual Ludum Dare theme kinda fit – I just equipped the player with a “Tri Force Field Gun” (the “this” for the theme), and TRI was born, where all you do is creating triangles to walk and jump on them, and solve a few puzzles.

My entry was kinda successful: I submitted it to the Compo, but eventually switched to Jam, because I copied a character controller from the Unify wiki (as Unity’s inbuilt one was too wonky). The Jam worked a bit differently back then, so my entry didn’t receive any ratings. But PoV featured TRI in the results announcement post, and people who played the game (the community of Ludum Dare, and players on Kongregate) liked it well and some even asked for more levels.
A few months later, in October 2011, we were searching for a cool new project. Somehow we convinced ourselves that we could create a full version of TRI within a few months, which of course was very naive. We actually already made two commercial games back then, but as those were done in a much shorter timeframe and were for mobile only we still underestimated how hard it is to make a full-blown game with individually designed levels, somewhat complex gameplay, physics and a story-line. Also – and this was the worst part – a lack of clear direction (due to missing experience) hindered a straight development, and so we changed the design several times before TRI became the game you can see and play nowadays. Of course, we learned a lot during these three years, but I often wish we would have learned this stuff faster.

TRI was made by Jana and me, Friedrich. Jana created the visuals and most 3D models, while I programmed in Unity/C# and also made the GUI. We both created the levels and searched for and worked on the sounds. The music was composed by my brother Ludwig.

It is still funny for me how each department is received extremely differently by different people: some love the graphics, some find them bland. Some adore the gameplay, some think it’s clunky or just headache-inducing. Some bought the soundtrack, some just found it repetitive. I know that tastes differ, but as most feedback nowadays comes from official reviews, it’s just silly how one piece of opinion claims that our levels are “not convincing” while the other describes them as highly genius.

But yeah. A lot of reviews miss the “polish of Portal” in TRI, and I can’t do anything else than concur. We are a two-man team, still learning, with a fraction of the budget of Portal. I guess the secret of success is to hide such facts as well as possible, but I don’t know how. So the biggest learning for us: we won’t do anything this big again soon. At least we shouldn’t.

We even had to take breaks during the years, because of interfering contract work, or just because we had to take some time off. Both didn’t make development any shorter, and if Rising Star wouldn’t have approached us to give us some funding and a deadline to kick our asses, we probably would still work on TRI (or having a break from it).

In reality, TRI was a good project for a small team, as the game has a narrow scope: the main gameplay is about creating triangles, and almost all of the other mechanics somehow work with this mechanic. For example, there are light rays, and you can reflect them – with the triangles. And you can walk on the walls and the ceilings – thanks to the triangles. There are also some basic physics puzzles (dropping crates on platforms and so on), but the physics are built into Unity. So how did TRI become a “too big game”?

By not being absolutely clear about the game’s direction.

One indication for this is the game’s story. We wanted a background story from the beginning; the original TRI has one, although fairly simple and only communicated via texts on walls. And yet it added a big portion to the package – so we still think some kind of narrative is necessary as a hook. Just think of how showing triangles would be boring for reviewers and YouTubers. This is why we needed some characters in the game. Unfortunately our story changed a lot during the development, or rather: the whole design and with it the story. From a sci-fi setting with a mad professor and a fantasy story with an alchemist, to the now present fable about a Monk and a Fox. This last iteration of TRI’s plot feels a bit tackled on sometimes, and really you can still complete the game (hopefully) even when you skip all story bits (hopefully not). So it’s there to entertain, but the narrative sadly isn’t an integral part of TRI.

The most problematic thing was that Jana and I never fought over what TRI actually should be – at least there never was a clear winner. Jana was all for making a game about atmosphere and looking at nice architecture. I on the other side was totally focused on the gameplay, and how there should be a lot of puzzles, because I feared people would be bored otherwise.
This way TRI became a game with two souls – there are parts that are mostly about the design, and parts that contain a lot of riddles and obstacles. Thankfully it doesn’t feel too much like a game with multiple personalities because Jana added her personal touch to each level after they were done by adding the textures and decorations. And fortunately the Monk and Fox also help to string them together, at least in my opinion.

Nobody ever complained about the sound design – apart from our very own voices for the climbing. Still, this fact is kinda great because although we actually tried to hire someone to make sound effects, the deal didn’t come to place and we found our best partner in freesound.org – really a great resource for indie developers. Most of the sounds actually were done within a few days. Sound design may be something that we still neglect, but TRI didn’t focus on sounds anyway, even though we wish we had time to create atmospheric “sound carpets” for each level, because sometimes everything is silent and nothing happens, and it then feels a bit too lifeless.

Although we normally tell everyone that the game was released on 9th October 2014, we actually put TRI online for the first time in June 2012, as a “pre-alpha”, which was a stupid description. We renamed it quickly to “alpha”, and a bit later I also tried to get rid off the version numbers (like 0.3.0) which always were low and unattractive, by replacing them with something cooler: code names! The next version was then “MagicalMonk”, which sounds much more confident.
These early-access versions (purchasable via our website and Desura) were not very successful in terms of sales, but we actually never did much marketing for them. We rather tried to get feedback from people interested in the concept and art style, by pre-selling the game for a low price and adding a survey at the end of the game. The later versions even included the possibility to give direct feedback via an inbuilt form. (Thanks to Jedi for the idea!) This was great, because people could send us bug reports or suggestions together with a game save. And it was a solution for our QA problem – every game needs testers, and this way everybody can be one!

In October 2013 we submitted TRI to Steam Greenlight, and some months later it was finally approved by Valve. It also made a lot more people aware of our game. But unfortunately Greenlight was a better marketing tool when it started in 2012. While the first batches of greenlit games were celebrated by the press, this effect became non-existent, thanks to the countless, bi-monthly batches with 100 titles approved at once – and TRI was part of one of these, in February 2014.

It was like winning \$20 – nice, but absolutely underwhelming. On the other hand we’re a bit proud of being greenlit before TRI even reached the Top 100, although I am not sure what exactly that means.

Anyway, at least we’re on Steam – and as the saying goes: “be on Steam, or don’t be”. A little anecdote: to be visible to curators (the new thing on Steam) we had to rename TRI, as the name was too common (think “Counterstrike”) for the search form to work, as it relied on auto-completion only. This is why TRI is now called “TRI: Of Friendship and Madness” (Jana’s idea) almost everywhere.

Thanks to Rising Star Games we’re also on GOG. GOG was great regarding the release, as they wrote a very cool release article. And you can also get our game directly on the HumbleStore, too!

Overall we are happy with the reception of TRI: more reviewers than I would have expected like or even love the game, and our Steam user score is pretty high – as of writing we have 30 positive and only 2 negative reviews, resulting in 93%. Yet, the game is still missing visibility – Steam, Greenlight and reviews alone don’t do that for you (anymore). We need more YouTubers with a high amount of subscribers, playing the game on their channels. And probably some sensible discounts, as it seems a lot of potential buyers are just waiting for the inevitable XY% off sale. I can’t even blame them: with so many games on my backlog, I do the same with most new titles.

What can TRI offer you? It has 16 levels created by our hands, 5 different “worlds” each with a different background music and a new look, two animated NPCs, all degrees of freedom, and unlimited triangles. You conjure these to overcome abysses, to block and reflect light rays and lasers, and to walk on the walls and the ceilings. A lot of areas can be approached differently, depending on your own play style. Even some of the puzzles have more than one solution, and I sometimes see people solving them in a new, unique way. There are very open levels where you can fall into the void, and levels with a lot of narrow hallways. You can jump, crouch, climb, run, carry crates around and use levers.

TRI is a bit about celebrating freedom and possibilities, and we hoped that a lot of people would love that. For now, we still have to find out how to reach them.

If you enjoyed reading this, you might want to have a look at our Making-of video series, our our blog.

“Quarter Quell” Ludum Dare Week!

Friday, May 3rd, 2013 10:13 am

I have to be honest, I mostly didn’t participate in the last LD because I wasn’t a huge fan of the theme. I know, I suck, but it’s the past now…

….. But now, to make up for my laziness, I am bringing the past back!

Starting this Friday, I’m having a Quarter Quell (#HungerGamesReference). For a week, I will make a game based on one of the 25 first topics, and it would be cool if you guys joined me in this effort! If not, it’s cool lol.

You can pick any topic (or topics) from the random list below. I went to www.random.org/sequences/ and randomly selected 10 out of the 25 numbers:

So the topics are:

Advancing Wall of Doom
Swarms
Build the level you play
Evolution
Preparation — Set it up, let it go
It’s dangerous to go alone! Take this!
The Tower
Infection
Growth … <– “Grow”, also this May’s optional theme for One Game A Month

I think standard LD rules should apply, minus the week to do it. I plan to do this alone, but you can be in a team if you so desire. If you want to participate, post in the comments of this post your intent to do so… and share your finish products when you’re done!

If any of you decide to participate with me, let’s see what awesomeness we can create!

Ludum Dare OST Volume One

Posted by (twitter: @Phantom_Green)
Sunday, January 13th, 2013 7:28 pm

I just compiled all of the songs from my various Ludum Dare entries into a single soundtrack. You can download it for free HERE !

The new TRI, pre-alpha

Posted by (twitter: @RatKingsLair)
Tuesday, July 10th, 2012 3:44 am

Hallo!

Some of you may remember “TRI“, the game I made for Ludum Dare #20 with Unity. The theme was “It’s dangerous to go alone, take this!”, which was good luck, as it fitted the idea I had the night before. 😛 It also was my first real Ludum Dare back then.

The original TRI

The game was about triangles; you created them by shooting three little spheres onto gray surfaces. These triangles could then be used as platforms and reflectors. That’s about it. TRI didn’t feature any story, but some texts on walls here and there, for hints and to somewhat simulate the voice from some god-like entity, like GlaDOS. Overall it worked pretty well and there were some people who liked the game although the controls were pretty flawed.

A year later, we (my partner and me) decided to make TRI into a full commercial game. Only the idea of the triangles was adopted, so the setting, the “tri gun”, the maincharacter, the story and the everything changed, or are due to change. (We still use Unity, though.) This basically means the new TRI isn’t a sequel to the LD game.

The new TRI – WIP

We added some gameplay elements, most prominently the wall walking. Yes, the triangles can now not only be used as platforms to walk on, they also temporarily change  the personal gravity of the player. This way, she or he is even able to jump into a hole in the ceiling – this needs a little bit of exercise though.

Walking on walls

Also, instead of deadly lasers only there are also non-fatal light rays now, with which you activate crystals in order to open doors and do other things. And then there are those little flying ghosts (the Kami), which lead the way and later can be reflected, too. They will be more important later in the game.

Reflecting light rays

The new TRI is still named TRI, as most of the names we came up with were just too silly or too complicated (Some examples: “Trinsane”, “Trizarre” (thanks Cell), “Tri and Error”, “The Third Eye”, “Connect the dots”, “Konstrukt”, “Trigonomancer”, “Trimancy”, “Triception”, “Triplex”, “The Right Angle”, “180 degrees”, “From Point To Point”, “neuTrino”, …).

TRI can now be pre-ordered for \$5, which guarantees access to the pre-alpha. The current  build has one big level (with three sub-levels) which basically serves as a tutorial. There’s also a demo, showcasing the first sub-level. Oh, and here’s a trailer:

The final version hopefully will come out end of the year, and have a price tag of \$10. There are far more informations on the official website, tri-game.com, so you might want to give it a look.

– ratking

Against the Wall – My (not really) October Challenge

Posted by (twitter: @michaelpconsoli)
Wednesday, November 9th, 2011 7:42 pm

When I first read about the October Challenge, I was inspired, though I kind of missed the mark in the end. I had been working on a game called Against the Wall for months, since the LD #20 really. It was my dream to make it my first commercial game! Thing is, I was promoting it minimally, nothing much besides a couple forum topics, a blog, and an under-used Twitter account. I had been working on fulfilling my dream project in near secrecy, a bit afraid of the reception my rather unconventional first-person platformer might have received.

When I saw the challenge go up, I accepted it… sort of. I knew that the game would not be finished within a month, and I would be unable to sell any real copies. Instead of following the LD’s challenge, I started to follow my own hacked version of it. I’d make a Kickstarter project and recieve crowd-funding rather than sell a completed game. I also decided to add a new level to the game with some additional strangeness that would be a hook for people playing the alpha.

I was pretty preoccupied by this whole thing, making a video of me feverishly explaining the game and why I needed donations, scripting the new level, debugging constantly, and putting together a few new art assets. I was so distracted that I completely missed the deadlines for a some major indie games festivals. But no matter, My Kickstarter project was the real goal here.

By mid-October, I loaded a new version of the game and prepared to launch. It was a rather nerve racking experience, putting my game out there for the whole world to see, exposing it to potential scrutiny and so on. Nonetheless, I managed to press the launch button… five days later after my Amazon Payments account linked up with my new bank (a requirement for Kickstarter). I used the extra time to fix some of the more atrocious bugs, add checkpoints, and test the thing repeatedly.

Then I launched it. The praise was mostly positive, and I was happy. A little while later, a friend managed to get my game on a Kotaku article, which gave my site over 15 thousand visitors!

At the end of the month, after receiving a good number of donations, I had to decide whether to submit the game to the October Challenge. You can correct me if I’m wrong, but I felt as if my game did not qualify, being unfinished and lacking any real sales (the major rules for the competition). I hadn’t made a single dollar, Kickstarter only cashes out once the threshold has been reached. Instead, I opted to walk away from this particular challenge, satisfied in my own little victory.

Just thought I’d share it with you, and at least update everyone on that my LD#20 game has been progressing. I’m looking forward to the LD#22 and all the crazy game concepts that the community will come up with!

Lightning Trailer

Posted by
Friday, September 9th, 2011 2:27 pm

HMS Lightning Beta v0.2 (LD20)

Posted by
Friday, September 2nd, 2011 10:34 am

You can play it on Kongregate – HMS Lightning BETA v0.2

Just an Update on my LD20 project, added in a menu (see below).

Improved the intro graphics, couldn’t resist adding a Scuba HUD.

Music and sound effects added but still quite a bit I would like to add!

Please give it a whirl and let me know what you think, on LD or Kongregate.

Cheers

All my Ludum Dare Entries…

Posted by
Monday, August 29th, 2011 3:10 pm

Play them on Kongregate.com

The idea is to progress these games polish them and improve them over time.

So don’t just leave your LD game on the shelf go back to it improve it, enhance it and get it out there where people can see, play and enjoy it!

Henchmen, Attack! postmortom

Posted by (twitter: @qrunchmonkey)
Monday, August 22nd, 2011 5:55 pm

This was my 2nd Ludum Dare (you can play my LD #20 game here) I was a bit un-prepared this time, since I only found out that I would have the weekend free about 45 minutes before Ludum Dare started. Talk about timing!

Once again I chose to use the Flixel engine. It’s a powerful and simple little engine, and developing in Flash means just about everyone will be capable of playing my game with no trouble. For my IDE, I used Flash Develop running in Windows 7, running in a Parallels VM on my Mac. I don’t recall exactly why, but that’s what I did last time so I stuck with it. Once again, sounds were recorded on my iPhone and edited in Audacity (cfxr doesn’t work on OS X Lion. I might need to fork it and fix that…) Also, I recorded a time-lapse of the whole thing using ScreenNinja, a Mac app I developed for exactly this purpose. One minor hiccup: I didn’t have Photoshop installed on the machine I was using, so I grabbed Pixelmator from the App Store. It’s a nice little photoshop replacement app suitable for most tasks, but unfortunately making pixel sprites isn’t one of those things, and I think that may have cost me some time.

The main frustration I had with my previous Ludum Dare game was that it was very short, so this time I knew I wanted to have some sort of endless map (plus, I think it fits with the theme) – so that’s where I started. Progressive level generation is tricky to get right, and looping though a single map just isn’t the same thing. What I ended up doing was designing a number of levels (at first 3, in the final entry I believe there are 11), each only slightly larger than a single screen, and as you approach the edge of one level, the game randomly picks another level and inserts it on the screen. Because the ‘levels’ are tile maps, and each is loaded from a .png file, I was able to design levels in Pixelmator and easily see how each level would look next to all the others, and make sure the edges lined up right.

Once I got that working I quickly threw together some basic player and enemy logic (it’s fun seeing the henchmen jump off cliffs, lemmings style), then it was just a matter of throwing things together and seeing what was fun. In action movies, the gun is a versatile tool. Along with killing the bad guy, guns can also be used to open doors, disable equipment, activate buttons or traps at a distance, or anything else an escaping hero might need to do. So I thought a game based around a sort of chase sequence might be fun. One of the things I programmed and didn’t end up using was for the wall mounted turrets to fire missiles that would destroy the ground under you. It looked really cool, but unfortunately the player could get stuck in the craters, so I had to take it out (although it’s still in the source code if you’d like to see how I did it)

Bugs. Hopefully there are no major bugs in my game, but there’s always a few weird ones. Occasionally the henchmen just won’t jump off the edge of a cliff, and I can’t figure out why. I’m pretty sure 30 lines of AI code isn’t enough to gain sentience, right? Also, sometimes the door spawner will spawn a henchman 32 pixels lower than it’s suposed to (and he ends up stuck in the ground below) But, since neither of these were game breaking bugs, I said screw it and worked on new features instead.

And finally, I tried to add a little humor and competition to the game in the final few hours with the game over screen. Much like in Super Shotgun Deathrace, the final text is assembled from many different pieces so it’s different each time. After showing a near final prototype to a few friends online as well as the IRC, it was suggested that I should have some stats besides distance displayed at the end of the game. So, I added the damage values and a henchmen killed counter. Took all of about 10 minutes to do, and I think it significantly improves the game, so thanks everyone who suggested that.

Oh. One more thing. Play (also, please vote and comment on) my game here, then you can click here and watch the timelapse

The Evolution Of Diamond Hollow

Posted by (twitter: @arkeus)
Thursday, August 18th, 2011 1:42 am

With LD21 rapidly approaching, I wanted to do a Post-Post-Mortem of my LD20 entry, since in addition to improving the game to make it ready for wide release, I’ve been working on a sequel for the last 4 months. Links for those who don’t want to read:

Diamond Hollow on Kongregate (380,000+ plays): Diamond Hollow
Diamond Hollow II: Coming soon…

So let’s get to it!

In the beginning (approximate 7pm PST on the opening day of LD20), there were a couple of block games. These block games were well intentioned, but I could tell they weren’t going in the direction I wanted them to, so I quickly tossed them in the trash (the last one actually went into a filing folder somewhere to deal with at a later date).

My goal was to make something that players would find fun. Being the superficial dev I am, I quickly took to the past winners pages, and found that players like platformers. Great! So I immediately switched focus from block/puzzle game to platformer. I decided to go with a tower climbing theme, and this was born:

It was very generic; it was very simple. Now that I had the basics down in a way that I thought I could turn into something fun, I began drafting out what features I wanted in the game. Among these were:

• Randomly generated infinitely high level
• Quick paced movement and jumping
• Gun shooting with the mouse
• Enemies to kill
• Something to collect
• Upgrades to spend your collections on
The first few points I was able to get started on immediately. I tightened the control scheme, added a way to randomly generate levels, and popped it all together and came up with the following:

It was looking good! It was at this point I needed to choose a theme. While it was a tower climbing game, I wanted to do something not tower related. My first thoughts were climbing a castle (but that would have just been a tower so I threw that out), and climbing up through the branches of two large trees on either side of you. However, my powers of art are extremely limited, so while I would have enjoyed a tree climbing theme, it would have looked pretty terrible and have taken too much time. However, dirt was something I knew I could do easily (fill brown, add noise filter, DONE) in photoshop, and the first thing that popped into my mind was a cave. So quickly I hopped to photoshop, and the pictures above immediately grew into:

Awesome! But then I hit the “collect” point. What can you collect in a cave? Rocks? Bats? Diamonds! It wasn’t the most elegant solution, but with the clock ticking, I hopped on it, and it wasn’t long until I had cute little diamonds sitting to collect. At this point I also added my first enemy, the slime:

Things were looking great now! I could jump up a cave, collect diamonds, and avoid cute little slimes that liked to wander back and forth (why? because they are slimes of course). However, in order to hook players I needed upgrades. Many people find upgrades cheap and hate them, but they are like crack in the world of casual flash gaming (and I, like many others, feel drawn to upgrade anything and everything). However, in preparing how I wanted to do upgrades, I started thinking of other aspects of games that hook me. The main one that came to me was Achievements. Achievements usually mean nothing, but they can make a game much more fun by giving you goals, and goals in games are always great.  For example, killing goblins for hours can be boring, but when you’re doing it for a quest or achievement, you feel driven to do it, and you feel like it means something. If I’m going to have you climbing an endless cave, I might as well reward you as much as I can.

So I took to photoshop, and in a surprisingly short amount of time (according to my timelapse), I had a protype mostly complete:

This is what pushed me over and kicked my motivation into overdrive. As soon as I had this working I blogged it. There was just something about it that made me want to play the game myself, and it sounded like others liked it too.

After a nice 8 hours of sleep, adding sound effects went much easier thanks to as3sfxr. I got through that, balanced the game a bit, and ended up with pretty much a final product.

The last thing I needed was a name. I asked a couple of friends what they would call a game about collecting diamonds in a cave, and I got some absolutely terrible suggestions (that I’m happy I didn’t go with, because some were names of other games about caves they had played at one point but forget). Eventually, after using thesaurus.com for a bit, I settled on a simple “Diamond Hollow”. It wasn’t exciting, daring, or clever, but it got the job done.

And with that… It was complete! And before the deadline, even! Overly excited, I submitted it and took a sigh of relief.

The next day I woke up refreshed, pulled up the game and started to play. Immediately I realized my error. The game was not balanced at all. Knockback was frustrating, the game was hard in general, and some of the achievements were way overtuned. Fortunately, while it was too late to change for the contest, there was still a life that Diamond Hollow could take after the competition.

Wasting no time I immediately got to fixing things. The first thing was the music. It had to go. Without the restrictions of having to make it myself, I turned to music licensed under the creative commons, and found something upbeat and catchy. An instant huge improvement. I then started rebalancing things which turned out to be a much bigger feat than expected. Changing achievements to require less skill is easy, but when you make gameplay changes that affect how easy the game is overall, all of a sudden your rebalanced achievements need re-rebalancing. It was a headache, but it got done. I then adding more polish to the game, fixing things like spawning, diamond locations, just to make the game feel less “thrown together”.

My goto place for flash games is Kongregate, so that is where I settled on for a home for Diamond Hollow. I wasn’t expecting much, as this game was made in a very short amount of time (well under 48 hours, even if you count the improvements I made). I was thinking it would get a low to mediocre response, and it was going to be something I would just watch and see how it progressed so that I could learn from it, and use player feedback as a way to improve my game development skills for future projects. But it turned out very different.

As soon as I posted it, it got an “okay” rating, but I began getting tons of feedback. While I had intended to use the feedback for future improvement in general, it all felt like improvements that the game should have had in the first place. I began compiling the feedback, coming up with concrete things to change to address the issues, and got to work. Every couple days I would work on implementing the latest round of feedback, release a new version, and announce the changes. It turns out that players like it when a developer listens and implements their feedback, and the effect was incredible. My “meh” rating went up by quite a bit until it was a “pretty good” rating. My plays started growing quickly, I got featured on the front page, and soon enough I obtained badges for my game. At the time of writing, the game has over 380,000 plays on kongregate. This was really exciting!

Then the feedback changed into bigger things. People wanted to explore. People wanted bosses. People wanted an “ending”. At this point I had to start rethinking my actions. There were a lot of things I would have liked to put into Diamond Hollow if I had the time during the competition, and there were a lot of features that players think would improve the game a ton. However, these would require major rewrites of all the code, at which point I might as well just start over from scratch. And that is where Diamond Hollow II was born.

Like with Diamond Hollow, I began by drafting out the features I wanted. Given I had no time constraint, I was able to include a lot of things, but I also had to limit myself. Did I want to get myself into an overbudgeted project that I would never finish? That was something I wanted to avoid at all costs. Among the list of features, I had the following:

• An ending
• Multiple guns
• Bosses
• More achievements
• A story mode
• Particles
• Varied graphical environments
• More enemies

With these goals down, I got to work. Rewriting the engine from scratch, I was able to greatly optimize it, allowing me to implement all the features I wanted, without it being slower than the original. However, I hit some major snags along the way in the form of content. Creating levels was taking quite a long time and it was starting to make me rethink having a story mode with hand crafted levels. Perhaps I could randomly generate the levels? Would players know the difference? In the end I stuck with it, and eventually managed to carve out the shell of a story mode. Then I began to fill it with enemies (new and old), and tons of improvements including new graphics, powerups, more upgrades, story text, and bosses.

Bosses were one area where I had a ton of fun. I needed to keep the bosses simple, in order to make them accessible to a casual flash player, but I was able to greatly vary them, and add different abilities and phases to them to make them a lot of fun.
After 3 long months, story mode was done. It was strange that for a project that I expected to only take about a month to complete, I had finally finished the first mode of the game. Thankfully, with all the framework in place, the other modes wouldn’t take nearly as long.
I immediately started work on the escape mode. Escape mode I wanted to be very similar to the original game. The idea was the same, in that you must climb as fast as you can while trying to survive. However, with story mode I had taken away the automatic-scrolling screen, and the game just felt so much more fun. With that, I didn’t want to return to the scrolling, but I wanted to keep with a sense of urgency so I compromised. Rather than racing against the screen, you are racing against a constantly rising lava level. This allows you to move up and down freely, as long as you stay out of the lava. The next mode was intended to be time trials, but after having played the game so much, this just didn’t feel too much like a time trial game. So I decided to scrap that mode, and instead implement that as a couple of achievements to beat some of the story mode chapters in a certain amount of time. I replaced the idea of time trial with boss mode. Because I had a lot of fun making (and playing) the bosses, I implemented a mode to try to defeat them all one after another. But that wasn’t enough. I then took it a step further and implemented a heroic boss mode, where the bosses are stronger and posses new abilities. This was my way of catering to the hardcore crowd, and give them a very challenging mode, without taking away from the experience of the average player.
It was at this point that the game was finally coming together. However, I still had a couple ideas floating around, so I implemented prototypes of them quickly, and after doing so, felt that they didn’t seem as fleshed out as a full mode, but I felt they were fun, so I put them in as minigames.
Diamond Hollow II is now getting the last finishing touches, and will be put up for sponsorship soon and released not long after.
Overall, the last few months have been great, and it’s crazy to think that everything behind Diamond Hollow 2 was born from Ludum Dare. I don’t think I can give enough thanks to all those involved in Ludum Dare that make it such a great experience, and to the other entrants that serve as the best motivation a game developer can get.

[cache: storing page]