(Republished from my blog at www.makethatgame.com)

Ludum Dare is over! Actually it has been over for a couple of days, but I’m just now digesting all that happened over the weekend.

For those who want to try it out you can download it from the Ludum Dare page.

It definitely helped this time around that I had other people working with me. I had Taylor actually working with me to make the game, and two other friends were making their own game for the competition in the same meeting room. I recommend that if you are doing your first (or even second) LD that you get some friends together and actually meet up physically to work on you game(s) (even if everyone works on their own). It really helps push you forward and you have a great source of crowd sourcing if you get stuck on some bug or implementation problem.

The other main thing I learned from this experience is how much time I need to allocate in the future when I participate in other competitions. Art takes up a lot of time, so expect to make some beginning sprites early and allocate at least 2 or 3 hours just making that. If you are using a framework that does not give you most of the convenience functions (ex. collisions, sprite management, level creation) make sure you are prepared to take another 3-4 hours setting up those common functions. What I’m going to do about that next time is actually create a framework that has all the features I need and then post it for free on GitHub so everyone can use it (maybe, RL might get in the way). It will probably be in XNA and not Pygame though.

Finally I realized how much time those little things take if you are not prepared for them. If you don’t prepare a title screen early, then it may take a lot of work to shoehorn it into your game at the end. Same with win/lose conditions and allowing the player to restart (whether that be restarting the level or the game) without exiting. Next time I will definitely be prioritizing the full game cycle much earlier in the process.

In the end I had a lot of fun, learned a lot, and am excited to participate again in March. Hope to see everyone then.

​Timelapse

So earlier this afternoon I sent out a quick poll to the Ludum Dare twitter account. The premise was simply, should the Ludum Dare Compo (48 Hour solo event) require source?

So yes, as it turns out a significant number of people like this requirement (or are indifferent). Drilling down in to the reasons people like this rule, we get the following:

1. It’s a good reference for new developers
2. It encourages community
3. It lets us verify that somebody didn’t cheat (**)
4. It keeps people honest
5. It can solve disputes (**)
6. Some broken games can be fixed with just a few source tweaks
7. I like to look at how people implement things
8. Source code is one of the best things to learn from
9. Any code created in 48/72 hours wont contain any serious secrets
10. Even if it’s not you, somebody will learn from the code
11. Ludum Dare is about Learning

And some of the reasons against.

1. The code is often messy and not a good example of proper game code
2. I use a proprietary engine. I can’t release its source.
3. Some tools can’t easily export source
4. Code can be stolen, games can be illegally published
5. I like to make games and sell them later
6. Unity/Flash users get lots of features and only have to share game code
7. My code is mine

I was actually surprised by the overwhelming response, so to make sure we didn’t have skewed results, I added a 2nd question about half way through the poll:

So about 60% have looked at source code, and 33% have learned something from it. All things considered, that is a significant number.

The data says something else too.

I didn’t ask specifically how much source code people have looked at, but one fact I will share is that in the 10 years we’ve run Ludum Dare, we’ve never had to take action because of what was found in source code. I can’t remember any questionable games ever making it in to the top games. Funny enough, many real disputes have been complaints about people forgetting source.

Now as you all know, Ludum Dare very big now. The idea of us policing entries is well beyond what we can do. We don’t actually have prizes, so there’s really no reason to cheat at Ludum Dare. So the old policy of “to stop cheaters” really didn’t make a lot of sense to me anymore.

That said, there’s a lot great reasons to continue requiring source. The Jam has never required source, and that has been one of our main ways of inviting more people to participate in the event. That will not change. But where there may be room to change is why source is required. So, to quote myself:

Of course, if disputes do happen, having source gives us something to make a case with. Innocent until proven guilty is kind-of a nice policy after all. So perhaps the main reason we share code should change.

Here’s another thought:

Now there’s an interesting twist. One of the classic complaints of “From Scratch” developers versus Unity/Flash/GameMaker/Middleware developers is the sort of “unfairness” that they have to share so much. It is an issue we let happen, and it is true it’s not fair. So alright, Matt’s idea provides a fix to that long long problem. Not to mention, #2, #4 and #6 in the “No” list. There’s nothing stopping you from submitting everything as usual, but it gives more liberties to those that are protective/unable to share their engine code. In contrast, it does mean fixing code for some entries (Yes #6) is not be possible (extremely cool but uncommon anyway).

So that’s what’s being considered. Again, we really don’t have the time to police thousands of entries, so the thought is to redefine why we ask for code, and perhaps what we ask of code.

Share your thoughts in the comments.

This past weekend was a blast! I knew from the start that I wanted to get a little bit out of my comfort zone, and I had been wanting to make *something* involving space ships of some kind. So I formed up a general concept that could have worked with most of the themes though it may have needed some tweaking here and there.

What came out of it was “Brobulon the Terrible.”

Play and rate it here.

I built it using Unity, but I made the entire thing sprite based with an orthographic camera and put the sprites on single planes. All the collision geometry was 3d (spheres and cubes) and I wrote a simple script to cycle through different sprites for animation.

What worked:
The movement system worked out pretty much how I wanted it, though maybe the ship could be a bit faster.
The pixel art seemed to convey what I was trying to do pretty well.
The rules of the game were simple enough that it let me make quite a few levels very quickly.
I used a transparent cutout unlit shader (built in to Unity) to draw all the sprites, and at least on my machine I get pretty solid framerates while there are ridiculous amounts of bullets on the screen.

What didn’t work:
I originally did a daytime sky that would have been featured in some levels. But it was too hard to see the targeting cursor and rather than spend more time making the cursor darker I just cut that background.
I spent an awful lot of time on pixel art (much more than I’d like to admit). I hadn’t done pixel art in years, but I was trying for it rather than doing anything in 3D because I figured it would save time.
The red and purple jets in particular fire more powerful shots and that’s not really conveyed well until you get hit by them (they use the same sprite as other enemy shots).
Tanks are too hard to hit. I gave them more health than the fighters because they should theoretically be easier to hit, being on the ground and slower. But since buildings get in the way they’re borderline invincible until you’ve cleared at least part of the level.

What I wanted to do (and what I’m going to do since I want to refine this project):
Bigger, scrolling levels. The idea being that when you reach one side of the level, you loop back around like you went around a planet.
Upgradeable stats (speed, shields, weapon power) between levels.
More varied buildings.
There was a warship sprite I made and actually imported into Unity, but I couldn’t figure out how to include it in the game in a way that would give me enough time to finish. The warship would have had at least four “turrets” to fire at the player with.
“Boss” events at different levels of Planetary Subjugation on each level, either being fleets of fighter jets or a warship to come in that you’d need to deal with.
A timer and a bonus awarded for how fast you cleared the stage.

I plan on working further on this, after a little relaxation and when time frees up a bit more.

I really haven’t posted much this LD, and this has been for two reasons:

• I have a twitter now, so I couldn’t focus on both pieces of my online presence.
• I didn’t have much warmup or anticipation for it this time, I just jumped in to it.

Of course, only now do I realize how much of a jerky move this was, so I’m making a little post.

SUMMARY: So, I had to do the Jam again, because I lacked focus on it during the first two days. Yesterday, I found out it didn’t work on slower computers. I fixed it up, staying within the rules, so that it did. A few people played it, and they liked it. Today, I found out my slower computer fixes messed up some of the story. It didn’t ruin the experience for those people, but I had to make a second fix today for the old fix. So yeah, I’m feeling like a little bad right now.

It should work now though. Go ahead and give it a play. We can only thank the fates I haven’t had time to start rating games and not to many people saw the ever-so slightly messed-up story.

This whole LD has felt very, very off to me. Either I’m not myself right now, or the world isn’t itself right now. Perhaps both.

Here is my timelapse!

I’m working in the post mortem entry, may be tomorrow will be ready with the postcompo version, which greatly enhances the gameplay just changing some variables, no new content.
Recorded with chronolapse, a capture every 4 seconds and playing 60 per second which makes every minute represents 4 hours

You can play in “Flamenco, Tapas & Siesta” here http://bit.ly/TVodSS

Tags: mesene, timelapse

Hey.

Special shout-out & thanks to all who’ve given my entry a go & taken the time to write a comment. I added a detailed design breakdown in the entry comments, so if you’re curious about why I made some of the choices I made there’s some info there.

The following is copy-pasted from the project page on the Acre:

What Went Right

1. Years of Preparation
I’ve been at this for more than two years now. The only jam I participate in is the Ludum Dare 48 Compo, because I love its brutal nature and it’s perfectly suited to my modus operandi. This was my 7th entry, and I’ve submitted working games for each. In the interim I’ve done more than a dozen Darkade jams, a handful of major projects, and all the while gathered skills with the tools I use. All of that culminates in these compos, which I see as tests of my abilities. So yeah, I’ve got experience and it really showed this time out. I managed to make what was in my head a reality, and within the time limit. It’s not without its warts and bruises, but it’s by far my best entry yet, and that’s all to do with the talent I’ve been cultivating through relentless full-time practice in the art of making videogames.

2. Focusing on Content
In the past I spent way too much time trying to come up with “innovative” systems to support my designs. This time I kept it simple so that I could spend less time mucking around in the guts of Unity and more time doing things like creating interactive objects. I chose a fixed camera, no lighting systems, and a very basic graphics pipeline. All of that enabled me to come up with a nice, tight little adventure game.

3. Holistic Asset Creation
For the first time in my history of attempting these challenges, I managed to correct something that previous post-mortems had identified: the uneven creation of game objects. In the past I would approach everything in a sort of layered way; code the interaction systems, block out the levels, add models, materials, textures, and finally audio. This time I made things as I went, treating each little asset as final, and imagining that I wouldn’t be coming back to polish it later. Whether or not this is a “best practice” is debatable; I’ll let my results speak for themselves. But by crafting every in-game object to be fully functional on implementation, I was able to keep cranking out content right to the end without worrying if I’d added appropriate SFX to a door, or properly textured a wall, or written a description for an area.

4. Fixed Camera, No (Visible) Characters
I decided almost immediately that the environment was going to be the main protagonaist, so I focused a lot of the storytelling production there. Like, how could I make this area interesting? How could I show a bit of history with this object? It wasn’t an extremely detailed execution, but that was only because I knew I only had 32 hours to work (I like to get 16 for sleep) and I could only communicate so much with that amount of production time. There were no (visible) humanoid characters, so there was no rigging or complex modeling to worry about. Also by fixing the camera and forcing the player to move in a grid-like fashion I could tightly control what they saw at all times. It also freed me from worrying about things like collision and physics. So yeah, for those who are complaining about the fixed camera/movement system, that was by design and it helped me execute the game on time. If I had allowed more freedom who knows how many more hours of production I would have needed to finish. More than 32, that’s for certain.

5. Sought Early Feedback
I threw up the production build almost immediately, I think within the first 4 hours, and right away I got a lot of good responses. It was clear that my initial camera choice (free, mouselook 1:1) was not comfortable. Certain things didn’t read well. Parts of the UI were confusing. I managed to address all of these concerns (some perhaps not to 100% satisfaction, it’s hard to work for perfection when you’re under the gun) but at least they were informed design choices. I knew by the time I submitted my entry that it had been tested to some small degree, and in game development even having one extra pair of eyes other than your own on the project can mean the difference between a good game and a bad one.

What Went Wrong

1. Not Enough Time Spent Mastering Texturing
I’ve identified a bit of a weakness in my speed pipeline, and that’s with texturing. Originally I envisioned using the “AO bake style” that you see in the game to complement some nice bumped/specular textures made either in Quixel’s nDo/dDo or Allegorithmic’s Substance Designer. As I worked I kept notes on what was to go where: grated floor panels in the main corridor, control panels on the machine and keypads, grime on the sewer walls, an so on. Right up to the last few minutes I had everything clearly mapped in my mind, but there just wasn’t time. I made that decision early on when going with the “holistic asset creation” method mentioned above, and I told myself that the AO bakes would be acceptable. And I think they are, I mean at least the game has a unified look to it. But it certainly wouldn’t hurt to have a few detailed textures in there, either.

2. No Title Card
This shouldn’t bug me, but it does. The game jumps right from the standard Dark Acre splash into the game. I would have rather had a little title marquee with “THE CONDEMNED” animated somewhere on it, but whatever. It’s a vanity thing.

3. Looked At #LD48 & the Ludum Dare Site During Compo
I think somewhere I’m quoted as saying that one of my secrets of success is how little I engage with Twitter/blogs/comments. And I think this is still the truth, but for this compo I let that discipline slip a bit. I figured making a few community posts on the site would help. Sadly, the pessimist in me tends to focus on the negative, so when confronted with people complaining about the theme, or dropping out, I got a bit down. But then I said to myself, “screw those weak bitches” and let their failure fuel my success. There’s only ever been one theme for LD48 for me, and that’s “make a playable videogame in 48 hours or less, and make it one that doesn’t waste anyone’s time”. I’ve managed to do this 7 times in a row now. The streak is real. Now if only I could win the thing I could retire.

Thanks again for reading, and happy holidays!

P.S. A playthrough with developer commentary is coming, hopefully before the end of the week.
P.P.S. If you tried to play the game using the Windows standalone, it was broken. That’s been fixed now.
P.P.P.S. The flashlight doesn’t work in the sewer; that’s by design. If it did work as intended I doubt so many people would be able to “win” the game. I’ll talk more about that in the video.

Tags: post-mortem, postmortem

An evil giant goat is attacking good goats. You are the evil giant goat.

We recently added a level with goats. (In post Jam version)

Click here if you want to play it.

In this, my 6th Ludum Dare, I had yet another fairly unique experience, encountering both new and old challenges and successes:

(Repeatable) Stuff That Went Well

• My code was organized. In the past, I’ve written all the code for the game into the main function. This made it difficult to have more than one level and made it painful to add, for instance, a starting screen. In general, it let me make more content than usual.
• I got feedback from people (well, one person), then implemented it. I did this early, leaving me time to do a good job implementing it and still leaving me a whole day for assets. The comment really helped me though, giving me an idea of what would make my game fun.
• I left a lot of time to make assets after finishing the game. I spent the second day solely on assets.
• Based on my own playing of the game, I refined the balancing of the game to draw more attention to the special mechanic I’d added to the game.
• I chose an easily attainable goal and then built on it. I had somewhat of an engine done within the first hour or two. From there, I was able to add more stuff and polish.
• Certain bits of polish were really helpful to the game. For instance, the sword in my game was pretty sweet.
• I stayed motivated. In the middle of this competition, I kind of hated my game, or at least, I didn’t put much faith into it and didn’t really know what to do to fix it. However, I pushed on, doing what I did know how to do (assets) and then revisiting the gameplay later and finding that it was not really as bad as I’d thought and that I did have solutions for it.

(Avoidable) Stuff That Went Poorly

• My code was spread out. There was no single place I could do all the balancing from, so it was a huge pain to do so. Also, I made too many tabs on Processing, so I could only see the names of 3 or 4 at a time, which made it hard to find any specific class’ definition.
• I didn’t put much thought into what sort of mood I wanted. Resultantly, I didn’t exactly create any cohesive mood.
• My art still wasn’t terribly good. I think I could have used more animation to make the top-down thing more convincing, but I don’t know. I wish I were better with this sort of thing.
• The controls may not have been the best choice.
• I don’t often play games based on action or on being quick and not so much on decisions. I therefore found it difficult to capture that sort of gameplay well.
• The game concept isn’t wholly original. It feel more like a variation on some sort of shooter game – the majority of the game (the shooter part) has been done before. Only a small aspect (the part about summoning enemies by taking stuff) is really new. Then again, people keep saying they like the idea, so… maybe it’s a good concept.
• I did not proofread the title page. It has a lot of typos. Like the good player of a game that I am, I never read anything in my game and just clicked on stuff.

Also, if you are one of the >1000 people who haven’t tried my game, you can click here. (P.S. I love comments on my game – it’s one of the best parts of the dare for me)

Tags: postmortem, tips

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.

Tags: tips

Hey everyone! It’s Rich, the programmer/composer half of Green Pixel. This past weekend Joe and I entered our first Ludum Dare and ended up making this game over the course of 55-60 working hours (which is almost a week and a half at a regular job when you think about it!).

Before the Jam:

As much as I love playing and making games, I also love developing really boring but useful tools. Early on Joe and I realised we only have interest in creating games from the NES/SNES era and that means sprite sheets and tile maps, baby! So over the past year, knowing our self-imposed limitations, we’ve been working together to create a set of tools to make our lives as 2D developers easier (every day we inch closer to the “generate game!” button!). Two of these tools, our animation system and tile map editor, became extremely valuable over the weekend.

For the week leading up to Ludum Dare, I started writing a 2D flash engine. We went with flash because:

1. You can play the game directly in your browser.
2. ActionScript is a rrreally forgiving language which is perfect for trying to get a game finished in 3 days and not being arsed to fix memory leaks and whatever else.
3. I haven’t gotten around to making a cutscene tool yet, so movieclips to the rescue! 😀

I had never tried making my own engine before and now I can’t imagine how I got by before. With the tool chain and the new engine in place, Joe could section up a sprite sheet, create animations and I could have it in the game in about 5 minutes.

The Jam – Some notes on the creative process:

Friday – First of all, the theme really took me by surprise and I think I actually voted it down a few times haha. Anyway, we heeded the advice of the keynote and spent about an hour or so brainstorming ideas. We decide on a top-down Link To The Past style game where a Mad Scientist would have to gather resources to build a death ray to protect a world he hated from a meteor by smashing up people’s property whynot. I began by breaking the game down into the various objects that needed to be coded. We had the idea to randomly generate the town and the house interiors, so I first broke up the map into equal sized squares. Each square could have a 0 or more houses, each house could have 1 or more floors, each floor would have 1 or more rooms and each room would contain various objects and NPCs. Too ambitious! At the end of the first night and having a bunch of weird-looking half-assed procedurally generated house interiors, it was clear we would have to design some house templates and assign these templates randomly to build the town. We also constrained each house to only have a single floor. The game looked like Colecovision at this point with my amazing programmer art of solid coloured rectangles, but morale remained high!

Saturday – When I woke up, Joe was finished most of the character animations at this point, so I added them to the player and the NPCs. The NPCs just stood in the top corner of each house and didn’t scroll with the map, but they looked good! The big task for the day was grabbing sections of the templates to build the town map and house interiors. We also discovered the size limit on a ByteArray in ActionScript! Fortunately, Joe was able to prune the templates down so we could load the maps. That night we discussed things we wanted to put in the game, but would have to cut if we were going to reach the Monday deadline. We had originally planned on a few different locations (military base, good scientist’s lab) and giving Dr Vile an inventory of collected resources, similar to Minecraft, that you’d periodically have to empty at his lair in order to build parts of the death ray. We scrapped these ideas and just focused on the town game play. By the end of the first full day, we had a clear vision and most of the visuals in place… just no game play.

Sunday/Monday – The long haul! We vowed not to sleep until it was complete! (We actually did end up sleeping, but we also completed it so I guess that’s ok). Jobs for the day: NPC AI (yeah, I foolishly left this until 23:00 on Sunday night), breakable objects, loot spawning, music and sound effects, cutscenes, HUD graphics, game flow (menu – game game over – final cutscene – menu). So… basically half the game. We worked until 9 am Monday and took a brief 4 hour nap and then rushed like crazy to get the rest of the things into the game but it all came together in the end.

Scary Times:

• We had a bug in one of the tools that almost erased all the art for the game on the second day haha. Luckilly, it was fixable while the art was still in the RAM.
• Generating a ByteArray so large that it crashed the flash game and not really having the time to design an alternative.
• A bug in the AStar implementation meant that if an NPC was more than 10 or so tiles away, it would take about 20 seconds to calculate a path. AStar is not a lot of fun to debug at the best of times, but it was about 4:00 am Monday. Luckily, the problem was simple and it ran fairly smoothly after that.
• NPC AI in general. I had never done enemy AI before and there are a lot of things I would do differently now (like not calling the path finding function every frame when they’re chasing you d’oh!)
• Combat. I had also never really done any sort of melee combat before. It works ok, but it’s definitely clunky and can lead to some garbage deaths.

Good Times:

• We finished!
• Pretty much had time to implement everything after stripping down the feature list.
• Learned a lot in a short amount of time about AI and procedural generation.
• Doing both code and music has a nice duality where if I get pissed off with one, the other uses the other side of my brain. 😀 Mmm, brain massage.

Conclusion:

All in all, it was one of the most fun weekends I’ve had! I already can’t wait for the next Ludum Dare in April. <3

Someone expressed interest in the source code in the comments section for the game itself, so I’ll upload that. I don’t know about the engine code? It’s kind of in an unfinished state and I might release it as an open source library along with the tools some day. Hopefully the game source will still be interesting!

Congratulations to everyone who participated and submitted a game!

Tags: 2D, as3, flash, jam, ld25, post-mortem

Someone just informed me that “Bad Puppy” is, like, a “term” in gay porn.  Whoops!

Tags: #BadPuppy, noreallyitsjustapuppywhoisbad, notgayporn

This was my 3rd LD and 1st time that I finished and submitted a game, so also my first postmortem =D (sorry about bad English as is not my native language).

The Last 2 LDs gave me nice projects to work with after the compo, but this time I made up my mind to lower features count, lower graphics and to bring something complete to deliver here.

Theme

I was expecting “End of the world” but hoping for “Construction” or “Ocean” as it fits very well with games that I like to create. “You are the Villain” came as a surprise at Saturday 00:00 here in Brazil and no idea was coming so I decided to went to bed and think better with the morning.

Ideas

The first idea was about an alien at his UFO tormenting a city. Brainstorm brings tons of features ideas like flying saucer upgrades, capturing and use human meat as fuel, land
off the UFO, weapons, tanks and soldier fighting against you and then I realized that would be another half year project.

So no flying saucer, maybe a lone alien. Then I thought that too many entries would use aliens, so no aliens… A vampire then. In his castle… at mountain’s top… Hunting at a village at night. Maybe turning into a bat at will? But if he can turn into a bat why not give him other powers? Maybe ones that he needs to research first… using blood as fuel.

He must fear some armed humans and use ambush tactics to succeed. Ok, so concept was ready. This came at something like 10:00 am saturday. Later I added a last feature that was the day/night cycle and sleep at coffin to protect from sun.

The Good things

Unity 3D: I’m on it since 2010 and it never stop to surprise me. Aside from the powerful 3D engine, the additive pattern (where you add a behavior to an object instead of descending sub classes)  gives a huge boost in productivity from reuse and was essential here. I managed to finish 100% of planned features, all 7 spells (Bat form, Invisibility, Speed, Sunlight resistance, Hypnosis, Charm and Fire bolt), the day/night system, human AI (poor right now), and so on.

Place holder graphics: From some tips that I did read from ancient LD masters, one fixed at my mind: THOU MUST FINISH THY GAMEPLAY SATURDAY NIGHT. So be it. Nothing except code all Saturday. By 01:00 am Sunday the gameplay was ready.

The “Could be a little better” things

Complexity: A nice portion of the game is hidden from casual players because it is behind a lot of work to research spells. Maybe I should have made the “Bat Form” to start already researched so this also would minimize the long way castle <-> village.

The BAD things

Vampire control: I was thinking of allowing the vampire to walk forward and cast spells with its view (aim) mouse controlled, like a tank. Bad idea. Now most people are disliking it and I agree.

No Sound, No music: Spent 1 hour on music at Sunday just to realize that would take like 5 hours to be ok. I left sound for Monday night and then I found some final creepy bugs to kill, so no sound.

A bug with graphic quality control: Unity have some controls to tweak with graphics quality and turn some eye candies off allowing wider audience. Well, I just left a debug line at starting code forcing quality to last level. I mean the ULTIMATE level. Now it just can’t run on low/med CPU/GPU.

Gameplay balance: To implement every feature that comes in my mind cost the miss of the 48 hours deadline and forced me to join as jam. Even worse it left few time to tweak simple gameplay values that would change a lot things: Like the tedious looong way from mountain to village and back to mountain every night.

If the world not end (post compo)

I will resize the island, there are lot of space not being used in game. Smaller castle <-> village way will be nice.
I also will add features to improve fun: Give more value to surprise element (like human frozen if catch from behind unaware ; Improve combat system allowing vampire to block sword/arrows with claws; Introducing wizards with strong long range attacks to give something to REAL fear and avoid (or incentive the research for more power); New spells (heat sensor, teleport, raise zombies); Some bonus drop from humans like research bonus; Better meshes (animated), better textures, better HUD, Music and sounds; AND YES, BETTER VAMPIRE CONTROL.

Now some gameplay of a powerful vampire in action:

Thank you!

See you at LD26 (theme: Ocean =D )

Tags: post-mortem, unity3d

I wrote a lengthy post-mortem for Legithief, our Ludum Dare entry.

You can read all about it on my blog!

What an adventure.

I learned of Ludum Dare from my past obsession with the game Minecraft. I really enjoy looking into the backgrounds of works: how they were developed, fun facts about the creative process, etc. As I was reading about Notch, I found out he participated in some weird contest called “looduhm dair.” I played his games that he made for it, and thought it was interesting, but then it went on the back burner.

Now, for most of my life I’ve been interested in computers and such. When I was a kid I designed meager webpages, and eventually I started learning to program games. I also did animation for a while, and although that has kind of died out I still love to draw. Lately I’ve taken a great interest in designing games, which has been greatly spurred on by things such as Egoraptor’s “Sequelitis” series and the dev commentary from Valve games, among other things.

However, I had never fully completed a game. I had created many test beds for small bits of code, but never anything full and what I did create was pretty awful.

A friend of mine was talking about how much he’d love to try making games, but he had no programming knowledge. Enter myself.

So this pretty much spurred on my interest in games, and I soon remembered this Ludum Dare thing and decided it would be fun to participate in it, and that I’d learn a lot from it.

So how’d it go down?

Once the theme was announced, my mind got to work. About ~10 minutes after, I had an idea. A sort of reverse-Mario, where you place Goombas and gaps in his way. I kept thinking over the theme for about another hour, though. I didn’t want to go with my first idea, fearing it wasn’t good enough.

Though after a short time I decided that I was gonna try out making a little AI-controlled character jump over blocks in Game Maker. It worked well, and I kept adding things and fixing bugs in “ld25test.gmk”.

Weird stuff happened, and it was frustrating, as it was my first proper AI. The player got stuck in blocks, on corners, turned around in weird places.

So I decided to start forming this AI around tighter “rules” and then the idea came to me to use these rules against the AI.

Time passed and soon my small tests formed into something reminiscent of a tech demo for a game. The little red square which was a placeholder for the player jumped over black squares (blocks) and avoided blue squares (enemies). Fun fact: the enemy placeholder sprite was a 32×32 blue square, and so the final design for the enemy was, you guessed it, a blue square. With legs.

Another fun fact: the canned particle effect used for explosions, the player dying, the player killing enemies, and slightly modified for the teleport effect, was the first particle effect I made and was intended as a placeholder. I just liked the look of it a lot and made it dynamic so the particles could change color based on the object.

Bear in mind that all of this was done about an hour after the theme was announced, and beforehand I was planning to not start until the next day. Holy hell, am I glad that I didn’t choose to do that. Probably about half of the base engine for the game was made that night.

As time went on I just added more and then came right down to the deadline with a few minutes to spare, and the game you’ve all (hopefully) played came to be.

so OP…

What Went Right

First, I think the central mechanic of the game was definitely popular and definitely allowed people to look past other, less desirable parts of the game. It feels damn good to make a little robot explode into bits, and to have the sort of freedom in the game.

I think the length was good, and kept the levels from getting too stale.

I think the levels are, in general, designed well and teach the player effectively. In fact, my little brother was my playtester and could pass most of the levels with a bit of head-scratching, which is a good sign.

I think the art came out well and gives a fun look to the game.

I especially like the quick sounds I whipped up, specifically the bomb dude’s “wwwwoooOOOOooooowww!”

What Went Wrong

The puzzles could have some really cheap solutions. This goes hand-in-hand with the bomb dudes being too OP. This was simply because I didn’t have the time to tweak these things, because…

I did a bad job at time management. All in all, it came together, but the levels towards the end got pretty repetitive, the ending was anticlimactic, the title screen was cheap, and the gameplay and levels required large amounts of balance.

However, pretty much everything that went bad, in my opinion, was due to the above.

So, to conclude, successful Ludum Dare! Yay!

I’m a bit late with this explanation, since it was announced for yesterday. Sorry for that, but here you have it:

Link to entry-site: http://www.ludumdare.com/compo/ludum-dare-25/?action=preview&uid=18894

If you start the editor, you soon will notice the radio-buttons at the bottom. These will determine the “layer” you are currently editing.

1. Paint World: Use this to set the pictures of the tiles. On the right side you may have noticed the list of tiles. There are 4 main types of tiles:

• Unpassable (Rows 1-12): these can only be traversed, by using a glitch or kind of hacking the game. Do not use the very first tile. It was initially transparent and used to display literally nothing, but then I realized, that java was capable of if-blocks, which were way better for drawing void
• Passable (Rows 13-22): these tiles are like the floor in your favorite public or private place: you are able to step on them
• Collectables (Rows 23-26): items that initially planned planned to have purpose, but now are just collectables with no known use, a little bit like ancient relicts (if you step on them, the tile will be replaced by the following on)
• Presents (Rows 27-30): the holy grails of christmas thiefs and actually any other person. Don’t place more than 45 presents unless you want to f**k up the collection-display, you greedy ruffian! (Beware placing the tile at the very bottom right or an ArrayOutOfBoundsException will haunt you in your dreams!)

You can select multiple tiles, by dragging the mouse over the palete (Notice: you have to move the mouse down-right to do so). To paint selected tiles onto the world, just click or drag the desired position(s).

2. Define rooms: This tool lets you define areas which the game will notice as rooms. Rooms are like the place you supposedly are in right now: You can be in it or be outside of it. The game will check if you (well, the playing character) are in a room, and if so, whether the is an enemy in the same room, to decide when its time to brutally kick you out of the level right onto the world-map-screen.

To define an area as a room you need to drag the mouse from the top-left corner to the bottom-right one. If you want to remove a room, just right-click somewhere inside of it. Rooms may not intersect each other. They will be indicated by a yellow rectangle.

If you collected all the presents, you need to go inside an exitzone. Exitzones are similar to rooms, just have an other purpose. To define an exitzone, hold down the Y-key and drag the desired area as if you wanted to define a room. To remove an exitzone, right-click it while holding the Y-key.

3. Events: Events are visible or invisible thingies, which have different purposes, depending their type. Create an Event by just clicking a position, while being in create-events-mode. As soon as you do so, a window will pop up, showing you the properties of the event and allowing you to adjust them. If you want to reopen this window, rightclick an existing event. Note that each window is linked to its specific event. Before you close such a window remember to APPLY CHANGES!

• TilesetInformation: Multiple purposes depending on the subtype: (if you’re messing with values other than -1 use propperly dimensioned images)
  • -1  –  player spawn point
  • 0  –  indicator to change the background from default to the file specified in the path-textfield
  • 1  –  indicator to change the tileset from default to the file specified in the path-textfield
  • 2  –  indicator to change the playerimage from default to the file specified in the path-textfield
  • 3  –  indicator to change the enemyimage from default to the file specified in the path-textfield
• Enemy: People who hate it to be in the same room as you (maybe a shower would change that, but that feature is not yet implemented). If creating an enemy it is important to set the subtype to 0, or the game will crash. Enemy-events will snap to the grid as soon as you apply changes. Create a list of movements with the buttons at the bottom half of the window. By selecting an element in the list and hitting a button, it will insert specific action at the selected position. If no element is selected actions will be added at the end of the list. Selected elements can be removed by hitting the “Re…” button, which would look like a “Remove” button, if it hat the propper size (I didn’t feed it enough and I feel sorry for that). Each non-waiting action will move the enemy a whole square.
• Door: No purpose at all.
• Picture: Displays the picture from the file specified in the path-textfield
• Text: Displays some lovely little characters, which you schould input into the path-field

All references to image-files need to be ralative to the directory, where the jar is living.

If you create a nice level, then for god’s sake remember to save it via the save button. We actually have lost ~10 creations by rushing out of the editor and forgetting to save the file. Currently the only way to play your level is to replace an existing campaign-level. Do not use the editor to cheat you through the game, because you want to see the ending! Use the one-button-win-everything-cheat instead 😉

If you have any question related to the editor feel free to leave coment.

I’m wishing you much fun creating your custom levels.

Greetings,

StMatn

I’ve made updates to my LD25 entry. The page hasn’t updated yet since I submitted it, so here are the changes since I submitted it to the jam:

-UPDATE 2-
Lan can change direction faster between shots — she shouldn’t get stuck facing the wrong direction now.
Arrow indicators point to the exit on each map.

-UPDATE-
Alternate control scheme for crappy keyboards.
Bullets don’t go through enemies at point blank.

Seems like everyone’s doing a post-mortem of their game jam – and since it’s easier for me to do one than it is to find out if it’s actually mandatory, here we go.

1. What worked

Almost everything worked for me, actually. Being forced into a small time frame made me simplify the graphics – meaning I didn’t have time to be fussy over colours, and didn’t have the time to agonize over the placement of each pixel, which is something I’ve had a lot of problems with while developing my other game, Return to Roots. This also resulted in a much more consistent aesthetic, which leads me to believe that the more time I spend on sprites, the worse I get.

AI development also worked out really well. Before tackling the AI, I wrote out a sort of “chain of command” that all enemy units would follow and communicate to one another. Having a bulleted list of “Do this, and then either to this or that” made it easy to split up the process into smaller, isolated tasks.

Program workflow kind of worked well. Stages are split into scenes, which contain a list of brawls. The “brawl” class could have been designed much better than it was, and creating a new scene required writing an entry into two places instead of one. Same for the brawls: edit code in two spots instead of one. But that was it; it was very easy to define where brawls would occur, who would be in them etc.

The control scheme. Controls feel smooth and (mostly) responsive, though I regret not adding single-key input buffering. The ability to attack in different directions regardless of which direction your character is facing was adopted rather well.

Feature Creep was rather nice to me. I had little trouble coming up with great features to add, but also had little trouble axing them due to time restrictions. So despite it being my first game jam, I managed to avoid biting off more than I could chew. (Chew means code.)

The storyline/plot of the game also came naturally, worked very well as a framing device for the game, and was well-received.

2. What didn’t work

My animation manager, for starters. I’ve developed a small but versatile class for handling spritesheets that allows for multiple animations of varying sizes and framerates and playback styles. Due to the nature of the LD48 compo, I couldn’t use it, and instead wrote something similar but much more barebones, from scratch. The result was slightly messier and more restrictive.

Time management was also pretty lousy. I thought I’d pace myself, so I went to bed by 3:30am on the first night. And slept for 11 hours. I had to make up for that by skipping sleep the next night, instead taking a 3 hour nap around 10am. I also did some other things unrelated to the competition during the competition, but they were more in relation to the next thing that didn’t work:

My chair. After sitting in it for 8 hours straight, even with a throw-pillow between me and the chair, my arse was killing me. I had to sit on the couch or in bed and play video games (Kingdom Hearts: Dream Drop Distance and a full run through Sonic the Hedgehog 3 + Knuckles, specifically) to pass the time and get the soreness down. I’ll need more cushions and regularly scheduled 5 minute breaks next time. Because there will be a next time.

Playtesting. I’ve got a lot of experience in software testing (well, comparatively to other things I do) so the game itself was functionally tested, but game balance didn’t receive any attention until 90 minutes before the competition’s end. Enemies were given too much health at first so that was pared down a little, but I think it still got overwhelming near the end. Game Overs boot you to the title screen, which someone was quick to point out the viciousness of. A game should be difficult and challenging, but it should not be frustrating. A fair punishment would be restarting the stage, but to redo the entire game is enough to make people drop it, especially in a competition such as this one.

The Main Menu. I should have spent more time on the title screen, making the difficulty select be menu driven instead of pressing a specific key for a specific action. The number keys aren’t used at any other time, and they don’t exist on the gamepad, so when I do port the control scheme to XInput gamepads, I’ll be having to redo it anyway. Should have planned that one ahead.

Ludum Dare 23 was a huge success for me with Zunzanda, and I said that I would not return to do another LD until my commercial game is done. But I guess I lied. It’s just too much fun to pass up! This marks my 7th LD (I think) and I think I did OK.

With the list of available themes, I picked the top three that I thought would win and began to brainstorm. I had some great ideas for END OF THE WORLD, and I was sure that it would win. Then, when the theme was announced, I just kind of stared at the screen in amazement. I honestly did not even think about YOU ARE THE VILLAIN. I should have, but for some reason it just didn’t pop up. I immediately stood up and began doing random things around the house while my mind raced with ideas. I usually go through this process. Instead of sitting down at the computer and drawing sketches, I just do some mindless task so my brain can sling crazy ideas around.

After enough thought, I decided to do something that I said I’d never do. I made a ‘Zelda clone’ with unoriginal slime creatures as the main enemy. This style of game is very unoriginal and the enemy is ‘easy’ to draw and is a total copy of about a million other games… but in that familiarity I crafted my overall design purpose: to use the player’s own history and tendencies against them. I will explain more about this design approach in the “THEME ANALYSIS” section. Reading that before playing the game will basically spoil the entire purpose of the game… SO GO PLAY IT!

CURE 48

Time, as usual, was the main enemy.

Features that got dropped after day one:

Features / tweaks that got dropped on the last day:

WHAT WENT RIGHT?

– The music. Cure 48 features two songs… the main theme and the ‘escape’ theme. I used the same instruments for both songs and kept them similar so the change wasn’t jarring. I think it works very well and the main theme is pretty rad.
– The spriting. I was able to get a fully animated main character that’s generic but somehow not generic at the same time. Enemies are decently animated and have three palette variations. The world tiles are also pretty snazzy except for the walls.
– The overall ‘purpose’ of the game seems to have been a great success based on the comments I’m getting. More on this will be revealed in the “THEME ANALYSIS” section below.
– Graphical overlays and special filters. These make the game feel like it’s being viewed inside of an old, crappy monitor. Scan lines and static included.

WHAT WENT WRONG?

– CRASHES! My computer kept crashing on the first night and it put me behind by a considerable amount. It ended up being a hardware conflict related to my audio setup. BARF.
– Much of the mood that I wanted to set got scrapped due to time. This included detailed intro and outro sequences with voice acting to help frame the actual game.
– Screen transitions are harsh.
– The sound effects are pretty standard. I wanted to do more unique sounds but I guess it fits.
– Porting to HTML5. I was hoping this would be simpler but there were just far too many tiny errors that kept piling up. Things like world tiles flickering, audio not being triggered on time, objects and sprites changing at random, and AI not behaving correctly. It just wasn’t worth ironing out all of these bugs, especially when there are just so many other games to play and rate.

THEME ANALYSIS

So here’s the part that you shouldn’t read unless you want to be spoiled. If you haven’t played the game… GO PLAY IT NOW! If you’ve already played it, don’t want to, or CAN’T… then feel free to keep reading —->

The theme “You Are The Villain” immediately painted an image in my head of playing as the bad guy. Role reversals start popping into my head. What would be the most interesting to attempt? I thought about it for a while but eventually decided I was thinking about it all wrong. The YOU in YOU ARE THE VILLAIN is the player, not the character. This means that the player has to play the game in a villainous way. That is, if the game is designed to lock the player into a role, then the player will obviously have to act within those rules. With my game, I wanted to make the player the villain without actually telling them to be the villain. I wanted them to be the villain by default while also giving them plenty of chances to be the hero. By using a familiar type of gameplay and introducing a familiar game enemy, I was able to manipulate the player into acting a certain way without ever asking or forcing them.

Cure 48 puts the player in the role of a ‘spaceman’ of sorts that is tasked with saving Earth. A plague has swept across the globe and the only cure is found on another planet far away. This cure grows on a plant, and the player is asked to harvest as much of the cure as possible… and that’s it. The gameplay is very similar to The Legend of Zelda, in that you have a sword (in this case, a light saber kind of thing) and can swing it in four directions. The first screen consists of the player and his ship. You can only go right. Once you go right, you start to see some plant life. These plants do not contain any cure but can be cut down. Curious players may test swiping these plants just like the grass in many of the Zelda games. Going on the next screen presents the player with an interesting grass layout that draws the attention to the plant in the center. This plant has a white ball on top of it. Cutting this plant makes the ‘cure’ drop to the ground. Picking this up makes a sound and the cure count goes up by one. The player now knows to look out for these plants. So right away the player is used to moving around and using the sword to cut plants and gather the cure. In these first two screens, the player has already learned everything they need to know to ‘complete’ the game.

The next area introduces the mini slimes. These green creates are familiar to most gamers. You’ve seen this guy before in other games. He’s a grunt. He’s an easy to kill enemy. But in Cure 48, he can’t hurt you. He doesn’t even follow you or try to get in your way. Up until now, the game hasn’t mentioned anything about being a villain. The game has never asked you to kill anything. Killing these slimes gives you nothing, but maybe it’s satisfying to be able to cut down something other than a plant. Maybe gamers are just curious to see what happens. My guess was that a combination of the game genre and the slime itself would immediately prompt a violent response from the player. In this moment, the player becomes the villain, not the character in the game. A creature from Earth that is trying to save his species from an attacker (the plague/virus) is now on another planet acting AS the plague/virus to another species. And this is all done voluntarily by the player.

Continuing forward, a large slime is introduced. Again, this green slime will not hurt you or try to attack you. UNLESS you attack it first. It then becomes red and starts to defend itself. Hitting it twice more will kill it, and it will drop a cure. The player has just learned that the cure can be found in two places: on plants and in large slimes. This causes the player to now seek out the large slimes in order to get more cure. So now the player is committed to being a villain without even knowing it. Killing a green slime out of curiosity is bad enough, but now the player is slaughtering a peaceful creature in order to obtain something that is easily obtainable in a non-violent way. The next screen is much larger and has a mixture of large and small slimes and plenty of plants that contain the cure. Many of these plants contain two or three ‘cures’, whereas the large slimes only hold one cure each.

Let me jump ahead a bit and talk about some of the comments I got about the enemies. Several players felt as though the large slimes are frustrating because they attack from an angle that can’t be hit by the sword. This was done on purpose. For one, it makes it more challenging as a game, but the most important reason is that it further supports the idea that attacking the slimes is not only a villainous thing, but it’s a stupid and dangerous thing. The game can be complete without ever attacking a single slime. There is literally no reason to ever have to deal with this ‘frustrating’ aspect of fighting the slimes. The player has personally chosen to pick a fight with an innocent creature and now the player is complaining that the angle at which the slime defends itself is less than optimal. WHAT A VILLAIN! “How dare you attack my weak spot!” I was hoping that somebody would fall into this trap that I set, and it seems like more than a few did. I couldn’t be happier. By acting like a villain, the player is making the game exceptionally harder than it has to be.

So back to the game progression… you go to the next area and large blue slimes are introduced. These slimes don’t immediately defend themselves if you attack them. Instead, they will bounce backwards a bit. This is yet another test for the player. These creatures won’t even come after you if you accidentally swipe them while trying to get the cure. But if you hit them enough, which means you WANT to kill them, then they break into two small red slimes. These slimes will drop one cure each, yielding two cures for each blue slime killed. Introducing yet another reason for the greed of the player to kick in. This room also contains plenty of plants that contain cures.
The next room is the final area. This room contains no enemies. This area has a TON of plants with many cures to collect, but it also has a curious object in the middle of the screen that looks like it may be the source of the cure. In fact, it is. I was unable to really describe this area in full detail because I ran out of time, but the idea is that the plants feed off of this power source and the slimes feed off of the plants. If you let a mini slime grab a fallen cure, then it will grow into a large slime. This was to show that the cure you are seeking is also the source of life for these slimes. This also explains why cures fall out of large slimes when you kill them. This object in the middle of the room flashes red when you hit it to show the player that it can, in fact, be damaged. Striking it five times will result in your light sword breaking (which was unfortunately not described as well as I had wanted due to time). The music stops and the ‘escape’ theme begins to play as slimes start to flood out of the back of the room toward the player. These slimes are red just like the defending slimes from earlier. You cannot attack them because your sword is broken, so you can only flee. They are simply defending the power source that gives them life, so their response can be seen as defensive and not aggressive. They will chase you all the way back to the start of the game, where you get into your ship and leave with the cures that you have collected. If the player attacks any slimes, then there will be aggression. If the player does not attack any slimes, then the only time a red slime is seen is after the player has already lost the ability to attack. So there is literally no way for a non-villainous player to kill any slimes as a method of “defense”. This ensures that all slimes killed are because of VILLAINY.

At this point, the game rates your performance and gives you an overall rank and awards you with medals. By killing just ONE of the slimes on this planet, you are branded as the villain. To reach the rank of a hero, you have to collect a certain number of cures and kill zero slimes. To get the rank of a perfect hero , you have to get the Collector medal, the Defender medal, and the Feeder medal, and of course not kill any slimes. There is an award for killing a large amount of slimes, but that’s to show that bad behavior can also be rewarded in our society. You may also notice that when the ship is shown flying away, a green slime crawls around the back of the ship and sticks his little face up on the left side. This only happens when you get the villain rank. This is to show that the slimes follow the player back to Earth. I was unfortunately unable to create the ending sequence that I wanted, which would’ve shown the spaceship returning safely. Upon opening the ship, slimes flood out of it and attack everyone waiting to greet the spaceman. The slimes prevent the cure from being delivered and all life on Earth ceases to exist. The hero ending would’ve shown the spaceman step out and deliver the cure to save Earth. So here once again we see that by being a villain, the player not only made the game much harder, but they actually sabotaged their own mission. The humans see the plague as the villain so they send a hero to get the cure. Upon reaching the planet, a majority of players see the slimes as enemies(villains) keeping them from obtaining the cure. The slimes see the human as the villain trying to destroy their life source so they send slimes back to earth to prevent any more spacemen from endangering their planet. And of course the humans then view the slimes as the villains that are invading Earth. It’s a cycle of perceived villainy.

So there you have it. That’s how my game approached the theme, and I’m so very glad that 99 % of players have proven that we are all very capable of being the villain without even realizing it. The difference between a hero and a villain often depends on what side of the battle you’re on, and I think that’s what has really stuck with me the most after this Ludum Dare. Thanks for reading!

Tags: post morem, post-compo, post-mortem, postmortem, theme analysis

A timelapse creation video of R. B. A. is out now on YouTube, just in case a 12 and a half hour livestream (multiple parts) is to long for you to watch.

You can play and rate here.

I’ve shifted into finals mode this week (almost over). Then I will be playing and rating games actively, my goal is 5 per day (and makeup the days lost to finals) So by the end I will have rated 100+ games.

Tags: timelapse

This my very first competition and really full foray into the world of game development. My main goal was simply to finish the competition with a simple working game. After the two days I definitely feel accomplished.

• Patient Zero

• Music

Friday

I took a small nap in the early afternoon so that I would be more mentally prepared for the announcement of the theme. When I finally read the theme I immediately hopped on the treadmill jogged for twenty minutes talking through various game ideas. Simply moving helped me work through some ideas and by the end of the twenty minutes I had a single game mechanic that I could implement and place a story around.

Your character has imbued themselves with the power to infect people around them simply by coughing and sneezing. This power will make people get out of the way. Ultimately allowing you to reach some end goal that is normally blocked by people.

Immediately after starting the development I realized that I still needed more tools to get the job done. Just over two months ago I started building a game framework written in ruby powered by libgosu. When the competition started I was missing quite a few elements:

• Tile Map support
• Collision Detection

Before I went to bed on Friday I had a working prototype of the hero that would could move other people by using their ability.

Saturday

I started to replace the initial images that I had given my characters with animations that I started to draw. I really appreciate people posting their work throughout the process as I was able to use that for inspiration for developing some simple pixel art.

When I got done with the characters I realized that I needed to spend a lot more time building all the collision detection for the tile map that I loaded. I spent the rest of the day figuring that out.

When evening rolled around that the initial gameplay, as I had implemented it, was not going to be rewarding as it was too random. I had a choice to turn the game into more puzzle game where the moves were more deliberate. I liked the idea of the solution but I did not feel that I had enough time to ensure that the puzzles I created for this new gameplay would be rewarding.

So I made the choice instead to simply grant my character the ability to infect people. When a person was infected they died shortly after. I then made the character die after a certain amount of time. So the game mechanic was reduced to a simple speed run through trying to infect and kill as many people.

Saturday night I stood at a crossroads as to how best to tell the narrative of our villan. I decided that the effort to try and convey a story for such a simple game mechanic would feel strangely bolted on so I focused all my effort on the music.

Inspired by “The Dark Knight” soundtrack I crafted what felt like three songs for the game (i.e. Theme, Escape, and Requim).

Music

I went to bed pleased with the right choice that I made as far as limiting the gameplay and deciding to focus solely on music to deliver a narrative.

Sunday

The unfortunate problem with choosing ruby and libgosu is the ability to package games. I spent the majority of the morning packaging and troubleshooting performance issues when running the game on Mac OSX.

I submitted my game shortly after noon because I had a plane to catch and would land far after the submission deadline.

Conclusion

While the game is not what I initially intended to create, I feel I made the right choices as far as adapting my idea with the remaining time allotted.

While I love writing games in ruby, I think for future work I am going to use an already existing engine that manages tile maps, collision detection, and packaging for me. Allowing me to spend more time on the gameplay mechanics and not engine implementation.

I also realized that I loved making the music. Even after the game I had some more creative ideas of how music could tell the story and have since composed two more songs.

Next JAM event I would love compose music on a team