About MarekkPie (twitter: @mkosler)

Entries

Trireme Ludum Dare 36	Harvest Ludum Dare 34	Masyu Ludum Dare 33	A Galaxy United Ludum Dare 30
Patch Ludum Dare 28	T-X Ludum Dare 27	Plunder! Ludum Dare 25	Supernova Ludum Dare 23

MarekkPie's Trophies

Jupi's Jam Favorites

Awarded by Jupiter_Hadley
on October 28, 2016

you know about SILX #LD27

Awarded by alvivar
on August 29, 2013

MarekkPie's Archive

Trireme

Rocky starts

Been participating off and on in Ludum Dare for four years now. (wow, time flies!) To be honest, I was in kind of a rut the past few compos. Now that software development is my day job, the idea of spending a weekend coding wasn’t too appealing. This event started out like that as well. I saw the theme, thought of an interesting idea, but as I was coding it Friday night, I just couldn’t find the fun in it.

My first idea was about being a telephone switchboard operator. The player would receive a queue of calls and then have to connect the caller to their destination. It felt like a neat idea, fit well with the Ancient Technology theme, and had an easy-to-see goal – connect the most callers within a time limit.

My main problem was the engine I wanted to use. I had been tinkering with PICO-8 for a month or so now and found it to be amazing for the types of games I like to make. Combine that with built-in sprite, map, sound effects, and music editors, you have everything you need in a single tool. The problem is the telephone switchboard operator idea is super tedious if you can’t use a mouse, which PICO-8 doesn’t really support. (I found out on Twitter last night that you can poke at the memory to find it, but it’s not supported on all platforms that PICO-8 supports.) I tried making a cursor that you would navigate around the board with your arrow keys, but in order to make the switchboard realistic, you needed a large number of in and out jacks, which made movement tedious and boring.

Frustrated with this predicament, and feeling the fatigue of the workday, I tweeted out that I was bailing and gave out the idea. (If anyone reads this that saw that tweet and used that idea, I’d love to play your game!)

Rested Breakthroughs

Next morning, I woke up a bit early than usual and started my morning routine, but there was this nagging in the back of my head. I had skipped the last Ludum Dare as well, and skipped another game jam – Giant ROM 3 – two weeks ago due to vacationing, and had geared myself up for this one. In the shower I started thinking about some ideas I’ve had that could be adapted to the theme, and would control well with a limited control scheme.

That’s where Trireme came together.

There’s a fantastic fast-paced cooking sim out there called Cook, Serve, Delicious that turns the player into a restaurant owner and chef. I always wanted to give that style of gameplay a shot, and figured I could do some key reuse in order to maximize the different actions a player could do in PICO-8.

But how to work in the theme? I initially thought about working with a gristmill; the player would feed in different grains in order to make meal, then bake it into bread. I was confident that the idea could work, but worried that my programmer art wouldn’t hold up. Also, PICO-8’s limited color palette meant that I could only squeeze out so many shades of brown to represent different grains.

So, I needed something that could be modular, but colorful and easy to draw. That’s where shipbuilding came in: it can have any length and any number of colorful, and anyone can recognize a ship at a distance – even a poorly drawn one.

Challenges

Since the game is about looking at an “order” and doing a series of inputs to complete that order, I needed to think of a good representation of those inputs. I scoured the PICO-8 manual and saw that when called without arguments, btnp() returns a bitstring representing whichever buttons are currently pressed. So it just came down to converting those bits to decimal and popping them from a stack as they were correctly input by the player.
PICO-8’s limitations breed creativity, but they still are limitations. Chiefly, its limited color palette means moving objects can clash and bleed into other objects. That’s why I added drop shadow to basically everything, to help each object stand out. For the simple geometry it was fairly easy to just repeat the draw but in black, but for complex collections of sprites, it gets harder. Luckily, PICO-8 also has this function called pal(), which converts one color to another in subsequent draw calls. So, I just set all 16 colors to black, run the draw call, then reset them all back to get a nice blackened sprite.
I had never previously used the sound/music editor in PICO-8, but this nice YouTube playlist provides a great explanation on how to use them.

Eighth attempt, hoping for my sixth completed game. Usual tools: Lua/Love2D, GIMP, *fxr.

Since getting a job outside of the gaming industry, I’ve really come to appreciate these events more. I don’t feel the drive to do everyday games programming, because I’d just spent my full day programming other things. But having these events that I can jump into and finish up within a weekend I feel is a great way to scratch that games development itch.

Given that Twitch is currently on fire, I’m streaming (mainly 48 hr Compo games) on Hitbox! http://hitbox.tv/marekkpie

It’s been two days since I submitted my entry to the Compo, and I wanted to take a look back at the good and the bad of the entry. Postmortems help me formalize my understanding and intuition on my projects, so I can more easily see what went right and wrong over the course of the event. Without further ado.

The Tools

In my “I’m In” post, I talked about wanting to try Unity2D this time around due to wanting some real experience with the engine prior to working with it on another project. While I had used LOVE for every entry prior to the first, I rarely ever kept anything from past projects, so using a framework like LOVE cut down on the actual game implementation quite a bit. Rather than working on my game, I had to first set up the foundation.

However, there was one little snag in my plan: I also wanted to stream the development. I felt that due to my inexperience with Unity, I wouldn’t provide anything exciting to see, as most of the time would be spent searching for answers to questions that even a novice Unity user would be able to answer. So, I went back to LOVE to both use something I am already familiar with and to provide an option for viewers to look at a framework that they may not have been aware of.

The Theme

Prior to the beginning of the event, I usually look at the final round and think of a few, simple, starter ideas for each theme. This helps kick start my creative juices and separates the themes that I’d like to do from the themes I wouldn’t. Connection Worlds was not a theme I was particularly excited about.

One thing that I believe makes a good theme is how agnostic it is. Something like Break the Rules or You Must Leave It Behind can apply to any setting, any genre, and nearly any game. It doesn’t coerce you toward a single path. Global Game Jam often provides good, ambiguous, agnostic themes that you can wrap your idea around, rather than the theme encompassing your idea.

A shorthand that I have for identifying good themes is how quickly you begin to think of ideas for it. The quicker the ideas come, the more the theme is pulling you in a direction. Connected Worlds pulls you heavily in the direction of “space,” and you have to fight to find your way out of that mindset.

The Game

After twisting myself away from the first idea I had (a Settlers of Catan-like board game, which would have either required multiplayer or decent AI to make interesting), I went with a Lost Viking style platformer called “A Galaxy United.”

You have three characters from three different planets orbiting a yellow sun: Foo, Bar, and Baz. Each character has a special trait that the others do not possess.

Foo is actually a much smaller alien that rides around in a tank like vehicle that he can deploy and retract into his pocket. This allows Foo to pass through small pockets that are too small for the others to squeeze through.

Bar is a world class boxer with a single floating fist that demolishes structures. He can break through obstacles that others can not avoid.

Baz is the most athletic of the group, and can use his spring to jump into the air. He crosses gaps that would be the death of anyone else in the solar system.

There are seven different levels in the game: one for each possible combination of characters. Each character has a solo level which acts as a tutorial for their ability; the level is usually extremely straightforward. Then, there are levels for each pair, and finally a level at the sun which requires all three characters.

The Good

love.physics

I had previously used supplementary user libraries like HardonCollider (no, I didn’t misspell that) or bump for collision detection, and then rolled my own simple physics, but I wanted to give the box2d implementation that LOVE comes packed with (love.physics) a shot, and for the most part, everything went extremely smoothly. I didn’t have many issues with getting simple platformer controls in place, and had much more flexibility in creating what I needed for individual objects on the screen. One particularly good part was combining Tiled’s Object Layer with defining the solid ground my players would be on. I could simply build my level with my tiles (of any shape and size), and then define a polyline in the object layer that traced the edge of the world. Then using box2d’s chain shape, I simply create physics objects that follow the polyline. Before, I was often either having to create large, conditional logic functions for particular tiles with abnormal shapes, and had to try and programmatically construct a complex definition of the “solid ground.”

Metadata

I decided to formalize a Lua metadata file for each piece of art I used, regardless of whether it was an actual spritesheet or not. This allowed me to be much more generic in my classes, since I didn’t need to hard code in the quads or animation definitions. Each metadata file had the path to the image, width and height for the physics object, quad bounding box definitions (Quad being the LOVE term for individual subsections of an image, like the frames of a spritesheet), and animation definitions (which references the indexes of the quads for easy reuse).

Art

I am absolutely not an artist. I can get by if I take a long time to craft an image, but it usually doesn’t turn out well. This time, however, I was determined to try and implement some character art. Since the game revolves around using special powers for specific characters, I needed at least some distinguishable models for each character. I also wanted to try and implement some animations as well, because there is nothing worse than a single frame just moving statically across a screen. I started out with much more complex models, but quickly realized that the more complex the model, the more fluid the animation would need to be to avoid being stilted and jerky. So after a few aborted attempts, I ended up with the models present in the game, which all have a nice charm to them.

Streaming

Streaming probably saved my game. At one point, with around 10 hours left, I was extremely dissatisfied with the game. I already had my MVP (minimum viable product), but I just wasn’t invested in improving it. However, I had made a promise to stream the development, and felt that I would be abandoning the people who might have been enjoying my work, regardless of my personal feelings on it. Streaming, and the obligation to stream, kept me from pulling out. Beyond that single instance, streaming meant providing entertainment for an audience, which reduced the amount of time I spent screwing off. Given how well streaming kept me focused, I might do it more outside of Ludum Dare for game development.

The Bad

Polish

One thing I have found throughout my many Ludum Dare’s is that the more polished a game is, the better reception is receives. It doesn’t really matter if it is the simplest game or the most complex; the more bells, whistles, and polish a game has, the easier it is to look over other issues. My game has very little polish. It has only two states: level select, which is a static screen with the different levels visible, and the game state. If your character falls into oblivion, you have to restart the executable. There is no sound; all the art besides the characters is extremely bland. There is no explanation of controls, no options menu, nothing that a highly polished game would have. There are probably plenty of bugs that I wasn’t able to squash.

A lot of my issues with polish have to do with my choice of LOVE as a development tool, By using a framework, I have to spend far more time creating the engine and then my game using the engine, meaning less time for art, sound, and debugging. That was part of the reason I considered Unity this time. I always plan on creating something simple and then spending the last 16-18 hours just polishing what I have, but it never ends up that way. I usually have only 6-8 hours for all the art, sound, and bugs, so I am super rushed at the end to cram it all in.

Fixes

I say this nearly every Ludum Dare, but I need to make simpler games. Even “simple” games end up being complex, so I shouldn’t worry about whether my entry will be complex enough, because adding addition complexity in the programming seems to increase time spent exponentially.

Currently, I am fairly rusty on game development practices, and as such, need more time to remember the best ways to implement things. I should code more often to stay fresh.

Use more libraries, whether self-built or from users. I have a tendency to want to do everything myself, but that just wastes a lot of time when it is something that doesn’t really require custom logic.

To give a wallpaper

Ludum Dare is upon us in only a few days, and like every competition, newcomers and veterans alike prepare themselves for the stress, excitement, heartache, nervousness, and fun of the event. One of the most important choices is the choice of tools to use to develop your game, and there are a multitude of different options out there for all skill sets. One question I often wrestle with the week prior to the event is whether to choose to develop my game using a framework or an engine, and I wanted to write a bit about the benefits and drawbacks of each choice to help others who might be struggling with the same issue.

A framework is a collection of libraries that help facilitate game development. They help provide common functionality that most games require, such as handling inputs and rendering visuals on the screen. They try to be as minimalist as possible, only giving the developer what they absolutely need, allowing him or her to customize their tool set to fit his or her personal preference. Frameworks are the scaffolding used to build engines. They usually have communities that are actively building adapters and plugins for different tools to better integrate the two together. Using a framework to develop your game gives a deeper insight in the challenges of piecing your idea together, and can be a rewarding experience as you grow your understanding game by game.

From a game jam sense, frameworks often require more initial setup to get started on creating your game, since you often need to write boilerplate code in order to start the game, handle game state transitions, load assets, etc. They are often much more fluid in how to achieve particular game development goals, since their goal is to give individual developers the ability to choose their own route. Often, it takes longer to see the fruits of your efforts when using a framework, and it may leave you with less time to tweak and improve on your ideas. Frameworks often require a higher technical skill cap to use, as you need some understanding of programming in order to utilize them; however, most of concepts you learn while using a framework can easily be transported to another framework if you decide to try a different one in subsequent games.

Good examples of frameworks are XNA, Love2D, and SDL. All of these provide the developer with only what is necessary to create a game, and leave the rest up to him or her.

An engine is a framework and set of tools and processes bundled together. Engines give developers the complete package for getting started, from a fully realized asset pipeline to map creation tools. Engines are often the results of a developer spending many years perfecting their preferred method of development and releasing it so that others do not have to walk the same path to achieve the same goal. Engines are the toolbox used to build games in a specific way. Some engines are highly specific, optimized to only build a particular genre of games. While it may be feasible to use those engines to build other genres, you are actively working against the design of the engine. Engines often have communities that are actively providing improvements to the engine itself, rather than attempting to patch in outside tools to use with the engine.

From a game jam perspective, engines sometimes require an upfront understanding of their particular workflow, but get you quicker into developing your game. They can be rigid in how things are done; they were built to utilize a particular map editor or work with bitmaps, so trying to use other map editing software or vector graphics will either require going outside the bounds of the engine or even be impossible. Engines have a varied skill cap to use; some engines can be just as challenging to master as frameworks, but generally are designed to be usable by anyone who puts in the effort to learn the tools that come with the engine. Engines can expose the underlying framework to the developer, but will unlikely allow him or her to change anything fundamental about the engines design. The skills you learn while using an engine are less likely to be applicable in other engines.

Good examples of engines are Unity, Source, and Twine. All of these provide the developer with a complete tool set to get started on creating a game.

The choice of what to use depends largely on a few key factors:

What is your goal for this Ludum Dare? As in, do you want to learn a new tool, build a complete game, have fun with friends, etc.?
Are you willing to try something new?
How much time are you willing to invest learning a tool versus using something you already know?

If you want to use something you are already familiar with, then have fun! There’s no harm in it. However, if you want to try something new, or already know a few different game development options and need help decided what to use, then first ask yourself those three questions, then carefully way the pros and cons of your options. Hopefully, I’ve provided a quick reference for some of a common difference between frameworks and engines to help your decision. This is in no way an exhaustive list, and if you have comments or questions, feel free to reply with your thoughts. I am certain loads of people would love to hear other perspectives. Thanks, and have fun jamming this weekend!

Howdy, Ludum Darers!

Seventh LD48, working on my fifth completion. Now that college is out of the way, game development is becoming more of a hobby than a potential career so having game jams like Ludum Dare give me a great excuse to scratch that creative itch that I don’t get at the job.

Engine: Unity (2D). While I am a huge proponent of using frameworks to get a deeper understanding of how a game is held together, engines like Unity provide a clean, professional tool set that gets you to creating your game much quicker. I was looking for an excuse to try out the “new” 2D mode of Unity for a project I am working on in my spare time, and this compo looks like a great opportunity to do so.

Art: Paint.NET or Inkscape. I am not an artist, so usually I either create very crude pixel art or try and leverage simple, generated shapes to keep things abstract. In college, I used Linux distributions religiously, mainly due to most of our code needing to run on *nix architecture, but there wasn’t ever a great, complete replacement for Paint.NET on Linux. Most of the programs out there like Pinta either missed a few key features or felt clunky by comparison, and I always felt like I was barely using GIMP for my development. I might take a longer look at vector graphic programs like Inkscape if Unity supports SVGs.

Sound: bfxr/sfxr. I finally started to prioritize sound in my last Global Game Jam game and it added so much to the game for so little effort. A jump without a sound is barely a jump at all.

Just a friendly reminder on a simple way to get clickthrough statistics for your entries. Create an account on your favorite URL shortening service (bit.ly, for example), and use those URLs. Bitly keeps track of number of clicks, locations, and all sorts of neat stuff!

I’m back for another shot! This will be my fifth attempt, and hoping to finish off a third game. I’ll likely be sticking with what has worked in the past: Love2D, GIMP, sfxr, etc. Haven’t had much of the game development bug over this summer as I have in the past, so hopefully this Ludum Dare will kick start me back up. Got to get ready for apply for jobs for next summer!

P.S. Shot in the dark, but if you know of any game development jobs in the US looking for recent graduates for next summer, feel free to comment!

Fourth time through Ludum Dare. Have been fairly LÖVE centric due to #1GAM, so hopefully I won’t need to spend too much time figuring out my tools now. I think no matter what the theme, I’m going to make a straight up platformer. My past three game ideas were too big for the compo, so forcibly simplifying my scope before it starts will help me build out my engine code more easily.

I know it’s a bit late to get the nice after competition statistics, but if you haven’t been doing so already, you can use bit.ly to gather a small extra bit of statistics for your download/click-through information on your game. The service is free; and the setup is as simple as pasting in your current URLs and using the bit.ly shortened URLs instead.

Then, you can track your stats by logging into your bit.ly account, clicking on your “bitmark” for the other URL, clicking the little i, and then the other little i next to your simple stats. It then breaks down your click information by time, referral website, and location.

If you provide bitmarks for all of your various versions, you can see the popularity split among the different platforms as well.

It’s a neat little free tool that I hope people can use to their advantage.

I’m glad I was able to participate again this Ludum Dare. This is my third jam, and first time submitting to the Jam rules. While that’s technically true, as I submitted on Monday, I didn’t really start until 24 hours had already passed. That, coupled with the solo work and the starting from scratch, makes it feel to me more of a compo entry, but alas, I have no say in the matter. Onto the postmortem.

Plunder Postmortem

I decided to give Lua and LOVE another shot this time around. I have been using the framework off and on over the past year, and really enjoy how rapidly you can develop on it, but the lack of true Object-Oriented Programming techniques have hampered me in the past (and as you’ll read later, nearly caused me to bail this time around, too). There are plenty of great libraries out there that create a pseudo-class system, but they aren’t as fully featured as you’d find in a natively OOP language because…well…of course they won’t be!

The Idea

When the theme came out, I immediately started think “Tower Defense”, because it works extremely well with it. Simply put a princess in your tower and done. But As usual, as soon as I started looking at what other people had been posting I once again realized that the first idea is often the same idea everyone has. I could have just rolled with it, because even though it’s a bit obvious it’s clearly a good idea, but my first Ludum Dare entry was also a Tower Defense game, so I wanted to try something different.

I eventually came up with the idea of a rampaging boss razing and pillaging a town, all the while having to fend off various heroes along the way. The boss would be clearly more powerful that an individual hero, but though sheer determination, they could eventually whittle the boss down to defeat it. Thinking back, I must have gotten the idea from a recent play through of Rampage: World Tour with a buddy of mine, because it hits all the same beats. I even was going to have “peasant” characters that the boss could eat to regain health, and a destructible environment.

Programming

I tore though the framework relatively quickly. Most of it was all fairly benign code. A Hero class with subclasses for the particular Heroes, a Boss class, a Block class for the environment. I started out exclusively using vrld’s HUMP libraries, but I ran into a few snags (the big one I later figured out was of my own doing), and switched to kikito’s middleclass for my pseudo object orientation. I used vrld’s HardonCollider (you read that right; it’s the LOVEly thing to do) for my collision detection, although if I had known about it earlier, since I only used AABB’s, I could have used kikito’s bump to lower a bit of overhead.

Art

If you look at my game, you’d think I was still in elementary school! I have come to realize that I am a terrible artist. I plan on putting in some effort of the school break looking into Inkscape and vector graphics, because GIMP is not cutting it for me. Too much freedom, not enough “tweakability”.

Challenges

I had three big challenges, all of which stem from the HardonCollider library and my interactions with it. Granted, I have not really used it all that much, so I maybe it’s just growing pains, but it ended up costing me a lot of time that I could have used polishing the art or adding some more mechanics.

Is your mama a llama?

You are supposedly able to use the HardonCollider objects inside your classes, simply adding to the resulting table your additional information. But it did not seem to interface too well with middleclass, because I could never add those objects into HardonCollider’s object pool if I tried to assign its created object to self. I assume it has to do with the metatable being overridden by middleclass, and therefore HC cannot guarantee that what I am passing in is a HC object, but I ended up having to create a separate bounding box field inside the class to hold onto the HC object’s information.

This might not sound much of an issue, but you have to understand how HC works. After you add your objects to its object pool, you write callback functions to describe how the objects should respond to one another. However, the objects you get in the callbacks aren’t attached to the class objects you created them in! Luckily, in Lua, this can be fixed easily without having to change any of the libraries code: just add a field to the HC object that points back up to the the object’s parent. You just then have to be aware that you have a circular path here, so you need to be careful about how you use those objects.

Calling for disposal in a garbage collected world.

Lua is garbage collected, which helps greatly when dealing with a quick project like the game jam entries. And most of the time, it works like a charm. But here’s the tricky thing: Lua has no proper way to define a destructor (or dispose method for a garbage collected equivalent) for non userdata (i.e. C API interfacing) objects. So, when you do something like say, registering an AABB with a collision detection library, and then say, change levels, unless you are keenly aware of this fact, even though you’ve lost access to the parent of the AABB, which should have destroyed the AABB, it persists in the ether, since the collision detection library has no way of knowing that the encapsulating object is out of reach of the program. (It really isn’t, considering that I had to attach a reference to the parent on that object to fix the earlier issue).

If destructors were a part of the Lua lexicon, then maybe this wouldn’t have been an issue because I would have had to thought about this beforehand; but when I run a few checks and see why my levels are changing even though my boss character is no where near the door, everything sudden falls into focus, and I curse to the heavens. And, as usual with things like this, the bug is often super simple to fix compared to the amount of effort required to find out what exactly is causing the bug.

Why did we decide to move our origin again?

Everyone knows (or should know, otherwise how have you made a game for Ludum Dare) that most 2D graphics libraries out there choose the top left corner of the screen to be the origin of their Cartesian coordinate system, and that the positive y-axis points downward from that point. I understand the decision to make positive y point down given that the origin is now in the upper-left, but why make it there in the first place? Why not follow the convention of mathematicians everywhere and make the lower-left the origin?

Besides random pontificating, the point of that was to show how the convention works. Most people extend that convention to everything that requires a coordinate system within their code. If you have a local coordinate system for an individual image, the origin is the upper-left. Mouse movement? Upper-left. Consistent across the board.

HardonCollider does this as well, but for whatever reason, when dealing with it’s movement functions, it decides to use the centroid of the object as it’s movement. I can only assume that since HardonCollider fully implements SAT collisions, since it can handle any convex polygon, having to calculate the “upper-left” might be too much of a hassle when using any other point would also serve the same purpose when moving based on velocity, but when you have a moveTo function, you’d think that you’d be moving the upper-left of an object to the specified point, not the centroid.

This one might be on me more than vrld. Once I actually took the time to read the reference materials I saw it was stated fairly clearly, but it was fairly annoying while I didn’t know, and caused me to implement walls because I couldn’t understand why the images would jump in the air whenever I tried wrapping them around the screen.

Things I would have done differently

Don’t try to be as ambitious as I was. I think next time I do a game jam (which likely would be the Global Game Jam coming this January), I’ll try and pitch just making a simple platformer. No enemies; no weird mechanics; just a finely tuned platformer that I could finish rather quickly and spend most of my time polishing rather than implementing critical code at the last minute.

Work with an artist, or hone my art skills. I was reasonably happy about my game until I started adding art to it. I didn’t have much time (nor honestly enough energy) to spend on making some decent art, so when I threw together some art to replace my sweet rectangles I had been using, everything looks so incredibly ugly. I almost thought this was too embarrassing to turn in. So, hopefully by next Ludum Dare, I’ll either have gotten a team together for the Jam, or have greatly improved my art.

Hey guys and gals,

Third time participating. I usually do the Compo, but I had a family gathering, so I am just going to act like the Jam turn in time is the Compo turn in time. It’ll still be just myself, even though I am submitting to the Jam.

I’ll be using Lua and Love again this year. I’ve fallen back in love with the simplicity and ease of use of Lua for this kind of quick prototyping. And since it’s just me, I don’t really have to worry about the issues that come up with having everything public, since I know what’s important to regulate to methods and what I can change.

I’m using Pinta as my image processor/creator/whatever. I just have my little netbook with me, so no chance for something on the higher end.

If I get to sounds, sfxr or bfxr will be the obvious choices.

Libraries are pretty much anything you can find on the Love wiki (specifically middleclass, hump, Quickie, and maybe HardonCollider if I can’t get my little bit working).

You can check out my progress on my Github (https://github.com/mkosler/LudumDare25)

Good luck all my fake Jammers!

So, I’m dropping out this time around. It totally sucks, but I’m really only about 1/3 of the way into the game, with still some fundamental programming issues to tackle. Since you all won’t get the chance to actually play the game, I’ll go over what I came up with:

Robocalypse

Story:

Millions of years after the last humans left Earth to colonize more fruitful planets – leaving Earth as a wasteland on trash and filth, new life evolves. While many traditional beasts emerged, they were all quickly eradicated by a new dominant power: those beings with cunning and resourcefulness. Rather than rely on physical traits, these new creatures created armored, robotic shells from the scrap that riddles the planet.

Now, with the planet’s nutritional load quickly evaporating, conflict has gotten more fierce among these beings. You are one of the last surviving dominant beings, and you must adapt to your enemies, or die!

Game:

The game was going to be a sort of robot battle royale. You build your robot with choices of armor, movement, and weapons that have advantages and disadvantages against other builds. For example, if you chose steel armor, you had extremely high physical defense, but it slowed you down from the weigh, and also increased your damage taken from electrical attacks. Or maybe you chose wheels as your method of movement. You’d probably want to chose a ram as your weapon, since wheel provide the highest linear velocity.

After each round, you have to opportunity to preview your next opponent, at which point you can scrap a particular piece of your robot in order to better combat the enemy. However, in doing so, you lose all upgrades to the scrapped piece, so if you want to switch back in the next round, you had to start back at level one upgrades.

Programming:

I had initially wanted to do either CoffeeScript or JavaScript with HTML5, but since I was interning the whole summer, I didn’t really have the time I wanted to play around with either of those languages. So I went back to Lua and the LOVE engine, the first engine I messed around with significantly.

Also, given how modular my robots were going to be, I wanted to implement an Entity-Component system in my game. This is where the big problem hit; I have never used Entity-Component in any work I’ve done, so beyond just a general idea, I didn’t really know how to implement it fully.

Pitfalls:

Besides the lack of knowledge on Entity-Component, my failure mainly has to deal with trying to cram too much into my game.

Each method of movement has a different control scheme (tank-like, omni-directional, car-like, walking)
Each weapon has a different way of dealing damage (linear velocity, angular velocity, and distance)
I wanted a non-trivial robot editor with drag-and-drop capabilities
Non-trivial AI

Not to mention the usual graphics and audio responsibilities. My brain just got completely fired, to the point where I could only work in 30 minute stretches before I had to take a break.

I think a lot of it had to do with the choice of theme. Evolution almost requires high variation, which leads to overall complexity. I’m sure if you stretch the theme to the edges, you can find ways to not do so (such as “Unnatural Selection”, a platform shooter where you plays as Charles Darwin), but if you really want it do deal with evolution, it has to have complexity.

Source:

Here is the GitHub repository if anyone cares to look at it; it requires LOVE 0.8.0:

https://github.com/mkosler/Robocalypse

Good luck to the rest of you all! Hopefully, I’ll have better luck next time.

I was going to make my own simple GUI, and I might still end up doing so, but at least for now, I am using Quickie, and Immediate Mode GUI for LOVE.

https://github.com/vrld/Quickie

I haven’t really gotten into the mental space for a Ludum Dare, so I might not be able to make it this time around. I had wanted to do something in CoffeeScript, but due to my internship this summer, I never got around to really playing with CoffeeScript/HTML5 Canvas. If I do, however, I’ll likely use:

GIMP
LOVE (www.love2d.org)
hump (https://github.com/vrld/hump)
HardonCollider (https://github.com/vrld/HardonCollider)
bfxr/sxfr

Life likely will get in the way; I have a fantasy football draft, plus…you know…college starts back up on Monday for me.