you know about SILX #LD27
Awarded by alvivar on August 29, 2013
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.
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!
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.
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.
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”.
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:
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!
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.
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.
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.
Here is the GitHub repository if anyone cares to look at it; it requires LOVE 0.8.0:
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.
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:
Life likely will get in the way; I have a fantasy football draft, plus…you know…college starts back up on Monday for me.
So, I didn’t think about this initially (because I had really no thought that people would actually play my game), so I didn’t set something up beforehand, but is there a way to get the number of page views and other similar stats on here? I used just a public Dropbox URL, so no luck on that end. Just hoping there is some way for me to see this stuff. Thanks.
I’ve had an enormously entertaining, enlightening, and indelible experience (grr…) in this inexorable endurance endeavor, but it’s also been extraordinarily hard. I guess that’s what makes a game jam and game jam, and the Ludum Dare compo is probably one of the hardest due to its restrictions. Due to the complete and utter reliance on oneself, it seems that luck is much more involved than in more collaborative jams. If the theme that is picked is something I have absolutely no interest in, then I have no one to really fall on to help push me in a good direction. This isn’t even touching the need to be a multitalented genius to hit all the usual game departments.
This is all just leading up to a nice pat on the back for myself for completing…something…on my very first game jam. Supernova is more or less a game. It seems to bug out after only a few minutes of play, but I also felt that I took a fairly large idea to start with, so I didn’t really have much time to squash bugs beyond the first moments of gameplay. But I am getting ahead of myself. DNIWER.
What is Supernova?
Supernova is essentially a tower defense game. The object is to protect your sun from an invading alien army. You do so by placing planets around it on one of three orbits. There are three different types of planets to choose from:
Attack Planets: weak, but is the only planet that can actively attack enemies, by launching missiles at them.
Additionally, you can buy upgrades to these planets that increase their potency (or alternatively, you can use the upgrade to heal the sun). Keep in mind that the cost of each planet goes up after every purchase, so plan carefully…or not…
It’s an endless game (or at least it should be), so there isn’t a win condition, which sucks. But whatever; I’ll leave the professionalism to my second LD48.
Planning: How does it work?
I’ll start with the bad, because that means I’ll leave you with a warm, fuzzy feeling instead of a cold, hard feeling.
- Plan until you can’t plan, and then plan some more: I did not plan much at all. I could chalk it up to the fact that I initially had an entirely different idea for my game, and spent at least two hours working toward that idea, but looking back, I still had plenty of time to plan better. I’m almost certain I lost at least four hours because of bad planning. Case in point: my HealthBar class. Because I made my Sun an entirely standalone class, when I went to attach it to my Sun, I couldn’t easily do it the same way I did with all my other planetoids. Since I didn’t really get HealthBar working nicely until the last day, I literally had to implement an additional attach slot in every HealthBar just for the Sun’s HealthBar. I shudder at the ugliness of that.
- There is a difference between understanding your tools, and knowing your tools: I am fairly new to haXe, NME, and HaxePunk. I understand haXe syntax, I understand the nme command-line tool, and I understand the general hierarchy of a HaxePunk game. As I learned throughout these past 48 hours, I don’t really know any of them. I would spend 10-15 minutes creating some algorithm or function, only to stumble across a prebuilt version somewhere in those tools. I know how to make an Entity, but do I know how to make an animated Entity? What about a Tilemap? Would a GraphicList help when I want to create a button with images and text? How do I get rid of the black background of my Text graphics? These questions have fairly available answers (usually in the form of FlashPunk tutorials, but haXe and Actionscript are so similar its stupidly easy to transfer it over), and if I would have had a bit more time with my tools, I would have not wasted more time on learning them during the compo.
- Do not decide to get the latest version of your development engine’s libraries DURING THE COMPO: don’t really need to say much more there.
- If you do not have artistic skills, don’t even bother trying to make it look nice: I spent far too much time just thinking about art. I don’t have the skills to put the grand image in my brain onto the computer screen, so don’t bother trying when you are being timed.
Overloading add() to success
- Given my overall disappointment with the chosen theme, I felt I had a decent enough idea: originally, I wanted to make a 2D, Shadow of the Colossus-esque side scroller. But I got about 5 minutes into the level design, and I realized that I don’t have really any idea on how to get started on the gameplay, so I scrapped it. Luckily, Tiny World got me to think about the end scene from the first Men in Black (I linked to it on an earlier post), where the camera flies backward from the Earth’s surface, through the solar system and out into the galaxy, only to reveal that the Milky Way is actually just a nice design for a marble in an alien’s current set. I felt, what if that alien had to protect his marble, by intervening in galactic conflicts when necessary. Something like a sun being forced into supernova ahead of schedule. What lengths would that alien go?
- Even though it was the hardest thing I have ever done (programming-wise), it wasn’t THAT hard: most of my game is just logic. If your shoot timer goes off, fire at the closest planetoid/enemy. If button is clicked, attach planet to cursor, and remove resources when planet is placed. There were a few tricky spots, like getting the placement of the planet by the cursor to work correctly in conjunction with rotation (which I mainly blame my addled mind for causing me such pain over the issue; I still don’t know how arctan2 is supposed to give me an angle between two vectors).
- Some people might call it hacking; I call it SUPER SEXY FUN TIME: there were a few ah-ha moments during this weekend that helped boost my confidence and strive to finish. One of them came when I was thinking of better ways to attach HealthBars to planetoids (not the super ugly situation I described before, but getting the Healthbar to do its thing automatically). A neat feature about haXe is that (I think) all methods are virtual. So when I needed to release a planetoid from my cursor to an orbit, since I wasn’t inside the GameWorld, I would have a hard time getting any special function to work outside of it. But, with an overridden add() function, I just check to see if the new Entity is a planetoid, and add a HealthBar right then and there. Brilliant!
Hopefully Supernova is enjoyable. I certainly am proud of it, but I also certainly will need to good LONG rest before I can think properly again.
It’s coming along nicely…kinda. Still need to add enemies, and all the necessary reactions to those enemies, but the general idea is coming together.
Buttons, how do they work?
The Earth like worlds are the food worlds. When they are placed, they will add to your resource total (not pictured…but will be on the right side). You purchase new worlds from these resources and place them on the orbits around the sun. Currently that part is where I am stuck, since it’s kinda difficult to decide which orbit the player actually wants.
Back to the coding…unless you want to look at game running…
Woohoo! Ludum Dare! Yay!…and all that.
Having a great time so far making my game. Have already hit a few hiccups, including an idea and some associated artwork scrapped as I quickly realized I was both unprepared for that idea and it was a little big in scope (think Shadow of the Colossus; sounds awesome…but I mean, c’mon, too much work.)
I was not (and really am not still) a big fan of this particular topic; I would have much preferred any of the “life” options like Evolution, Artificial Life, Built It and then Use it, or Death is the New Beginning. I guess I’ll have to just hold onto my super sweet idea until the next Ludum Dare with a similar theme to those.
So, now the new idea. It’s fairly simple. The image that kept popping into my head when I would think about this topic was the final scene in the first Men in Black.
If you are too lazy to watch the clip, essentially it is saying that there are much larger forces than us that manipulate entire galaxies like they are a sack of marbles. I wanted to incorporate that idea into my game. You are playing some godly entity who needs to protect a star from an invading force. What’s the motivation, you ask? There is none. Hush now!
You place different planet types on different orbits. Since I’ve only got 43 hours left of jamming, I’m going to stick with three types: attack, defend, and food. Their jobs are pretty self-explanatory. You fight waves on enemies, and gain the ability to add more planets based on how much food you are producing. Think of this as Plants vs. Zombies IN SPACE!!!!!
Here’s a little sketch up of what the game might eventually look like:
There are a few more ideas I have to make it a bit more complicated, but I’ll save them for another post. I’ve got my orbiting planets, and I’m all good for tonight. Let’s try and get some sleep and come back refreshed for many hours of badassery.
P.S. here is my “game” so far…don’t judge me!
C’mon! We’ve got one of the biggest game development locations in the world, and only 5 people participating? For shame…
My virginal entry! Don’t be too rough. Seems you’re supposed to use this as an opportunity to declare what you’ll be using for the Compo.
Editor: Sublime Text 2 (Evaluation version). This brings up a question…which I’ll ask later in the post.
Graphics: Kolourpaint for the simple stuff / GIMP for the less simple stuff.
Sounds: Honestly don’t know; probably sfxr.
Ogmo Editor. Never used it, but whatever, it’ll be fun to learn. Looks like Ogmo made the dastardly move to XNA. I spent some time trying to get it to work on my Linux machine, and at least got it to compile using MonoGame, but cut my losses when I hit some runtime errors (not a big fan of MonoGame). Tiled it is!
So, my question. I know that the license of an open source editor has no effect on anything you produce from it (GPL or otherwise). But for something like Sublime Text 2, which isn’t open source and has a licensed version and a free (as in beer) evaluation version, would something I make using the evaluation version not be allowed to be sold? I doubt anything I make over this weekend will be worth a dime, but just musing here.
EDIT: Edits galore!