Posts Tagged ‘ld24’

Troll Games has pretty much finished up our jam and we still have until the end of the day on Monday?!

Man, so much time to polish. Get ready folks.

TEJITAOFAAP TITLE

A quick preview of the title screen of our game.

LD25 Progress Report #2

Posted by (twitter: @MikeRedhorse)
Friday, December 14th, 2012 11:48 pm

Tilemap array initialised and basic loading code added. Advanced loading code added, basic track sprites added, no transitions yet. Small test to make sure map loading is working, and it works! Still trying to get through my first cup of tea, stomach issues and game-making marathons really don’t mix.

2

Aeon gameplay

Posted by (twitter: @AleksandarDev)
Saturday, November 17th, 2012 6:51 am

If you haven’t had chance to play my game from last LD Compo 24, I have finally managed to find some time to record and upload a video. Game is called “Aeon” – evolved classical snake game.

Ludum Dare 24 – Aeon gameplay

Super Clew Land Postmortem

Posted by
Sunday, September 16th, 2012 9:30 am

Super Clew Land
Rusty Moyher here. I’ve participated before in Ludum Dare, but Super Clew Land is my first experience entering the Jam or working with Shaun Inman and Matt Grimm. After this roller coaster weekend, I know I’ll be doing both again.

A week before Ludum Dare, I asked Shaun if he wanted to make a Jam game. He was interested, but concerned how we’d break up responsibilities. Shaun and I are do-it-all guys, so we didn’t know of a good way to split the work. We decided to sleep on it. (Which actually meant not making a decision until the last minute.)

Day 0

We met up on Skype an hour before the jam to finalize plans and workflow. Before splitting responsibilities we’d wait to hear the theme. Shaun had worked with Matt before and we sent him a Twitter DM in hopes he’d join us.

At 9pm EST we received the theme: Evolution. We came up with a dozen bizarre ideas including a colored vine puzzle game that the player would grow through to proceed. After four hours of brainstorming both of us were wearing thin. We almost slept on it (again), but finally chose the idea we’d spent the most time fleshing out: an evolving Metroidvanian puzzle double-game.

Imagine a split-screen or Nintendo DS double view. Players would encounter a platforming world above and unlock new abilities in a top-down gene sorting game below. Even as we shrunk the gene sorting into a HUD minigame, the idea seemed ambitious for 72 hours.

List of evolved abilities

List of evolved abilities

To make the creation manageable, we made a last minute framework switch. Shaun and I were both eager to try out Futile, a new 2D Unity framework. But the scope of our idea required tile map support. Rather than trying to roll our own for Futile, we chose a framework more familiar: Flixel.

We also (finally) decided on the responsibility split. Shaun would design and I would develop, but we’d switch things up as needed. We heard back from Matt too. He would do music and sound. 8-bit Voltron was formed.

Shaun came up with our hero’s name, Clew, before heading to bed. It wasn’t as late for me in California, so I spent my last four hours awake setting up platforming physics and a TMX level loader.

Day 1

I woke up to find over a dozen animations in our shared Dropbox folder.


Hizzah! Clew was real.

I started building the “Protein Puck” minigame as Shaun drew food and enemies. Shaun and I communicated almost entirely through FaceTime on our iPads. (He found it useful during a previous collaboration.) This made it easy to bounce new ideas around while working. By using our iPads as dedicated video devices, we never had to manage a floating iChat window. It was so helpful we left the stream open throughout the entire jam.

By the end of the day we had most of the character animations done, a pretty-much-working minigame and an fun retro soundtrack from Matt.

Recombination MP3

Day 2

All three of us live in different timeszones, but by the second day this seemed like a plus:

Working with a dev in another timezone is awesome. Go to bed with an idea, wake up to a working implementation. Could get used to this.

As Shaun finished up animations and wrote the Flixel animation timing, I started implementing the player, food and enemies. Halfway through the day Shaun switched to code and implemented autotiling to make world building faster. About this time I started adding Matt’s sound effects.

Puck Match MP3

Puck Poof MP3

Death MP3

When the autotiling was ready, Shaun started building the world in Tiled. The pieces were coming together, but a mountain of polish remained. As the day grew long we came to an unspoken understanding: there would be no sleep tonight.

Day 3 (I think)

While the sun rose, I squeezed in a few good playtest sessions. Shaun programmed the enemy pathing behavior and then kicked level design into high gear. Matt had to leave for his day job, but was able to write a few final sound effects in his off hours.

The Final Design

Nearing the end of the Jam, we we’re all exhausted. At some point I took a shower to try to clear my head. Picking the game’s name took near an hour, but this was mainly due to our exhaustion. In the last thirty minutes we added a title, an ending, and Matt’s final piece of music. And….submit!

Epilogue

Working with Shaun and Matt was a blast. Each Ludum Dare I’ve participated in has been more rewarding than the last. I’m not sure I can stop now. :)

We’re all pretty happy with what we pulled off in three days. If you haven’t checked out Super Clew Land yet, what are you waiting for? Go play it now!

Cheers,
Rusty

Our favorite games so far!

Posted by
Saturday, September 15th, 2012 11:24 pm

Well we had a blast developing our entry, and we also had a lot of fun playing games made by others!

As the judging deadline is near I thought of building a list of the games that we have enjoyed the most so far!

I think these games deserve some more love as well, so be sure to check them out!

As every member of the team has taken the time to play a number of games on their own, I’ve compiled this list based on the overall score we’ve given to those games. I won’t be making any comment on them as I’ve personally played only a few from the list myself.

So, with no further ado, here is the list! (in no particular order):

Go Back (Aceria)

 

Oneway (Azurenimbus)

 

Inu no Ongaeshi (Shmarah)

(more…)

Ludum Dare 24 Postmortem: Golden Eggs

Posted by (twitter: @sorcerystory)
Tuesday, September 11th, 2012 4:11 pm

It was a hetic weekend, but I managed to wrap something up for the Ludum Dare 24. And the result? Golden Eggs.

When the theme of Evolution was announced, I wasn’t exactly sure of what to do. Truth be told, Evolution was one of the themes I had voted down. I just didn’t have that many ideas to go along with it. But I was bent on carrying it through. Doing something you like while within a theme you aren’t especially lukewarm about is a challenge, but you can learn to like it all the same. At least I did!

At first, I didn’t know what to do. The only things that went trough my head were the immediate, overdone things: dinosaurs, DNA manipulation, all that jazz. But then, it hit me! The most prominent game I’ve played around the subject was the chocobo breeding mini game in Final Fantasy VII. Normal chocobo could breed and, using foods and other items, breed higher tiers of chocobos that could then be used in several tasks. I remember it being so complex that I looked up a guide online and was absolutely dismayed by how big and detailed it was back in the day.

With that little thought in place, I wanted to root the player in a more mundane setting (and also not incur in copyright infringement). Since the original mini game takes place in a farm, I decided to use it as a base for my game. And instead of chocobos, chickens and roosters took their place! And of course, everyone knows that the chicken who lays golden eggs is the best! After that, I needed to have a growth mechanism, some way to make them progressively better, and so the idea of feeding them better crops was born!

At the time I didn’t even realize how similar it could be to other games out there. People pointed out Farmville and Harvest Moon in the comments after I submitted the game, but since I never played any of them, I wouldn’t know. Thing is, I was so excited with the idea at the time I didn’t even look back and started creating the game!

Since I’ve been using Unity3D, I decided to try my hand at it in a different context than I’m used to: pixel art. The game took a while to make not because it was incredibly complex but, as I came to realize, it’s tricky to do pixel art in Unity. But when you know what to do and what to avoid, it gets simpler to do it, and that was the main reason for doing this blog post.

So, what went well?

1. I managed to nail a decent art style fairly quickly.

I never did pixel art for a game before, and wasn’t sure of how it would turn out. After two tries, I finally got a simple style I could create art quickly. Lowering the number of pixels from my initial try also helped in this regard. Considering the comments I got for the game, the art was the best thing about my entry (not that I had much else going for it, truth be told), and people really liked it.

 ->       -> 

2. The core of the game was done by the first day.

By the end of the first day, I already had the systems for animating the characters and other props already done. The animals wandered around and the player could be controlled. The second day was to be used to get the gameplay flowing.

And what didn’t go so well?

1. I used sprite sheets.

From the get go, I wanted to use sprite sheets to increase the game’s performance and to learn how to do it, since I’m making another game that could use the technology. I have never used sprite sheets in Unity3D before and, little did I know, turns out that they’re not the best things to use, according to its developers. Even worse, the slight errors in calculation during the texture mapping ended up being even more glaring due to the size of the textures (16 x 16 pixels). This wasn’t a big problem for full blocks, but became very visible in partially or almost completely transparent blocks, such as the fences and the grass:

But the change to single textures for every sprite and animation frame ended up being too complex to do in time, since the code was already done for sprite sheets. I’ve fixed the problem since then, but in the end, I ended up having to submit the game with the glitches because of this.

Even worse, I couldn’t get over this glitch and tried many things to fix it without changing the system I had coded to no avail. I lost precious time and ended up not finishing the core gameplay, which I might have finished if I had given up after the first or second try to fix it in the first place. Thing is, it was really hard to stop trying to fix it, even tough I knew I was loosing precious time. Human nature, I guess.

2. I didn’t prepare enough.

Despite the fact I thought of the game idea right at the beginning, I could have saved some time by thinking of some ideas for each theme and gameplay to go along with them. I had some ideas for the themes I liked, and didn’t think too hard on the ones I disliked, which ended up being a problem since it was one of the themes I disliked that ended up winning.

Also, I was very reluctant on choosing a tool to make the game. I knew I wanted it to be pixel friendly, but ultimately decided to use Unity3D over Gamemaker in order to test its capabilities. Also, according to the many tips on the Ludum Dare site, the web is a preferred platform and Unity3D, having web publishing available in the free version (unlike GameMaker), ended up pushing me towards it even more.

I also could have probably saved a lot of time by creating the animation system before hand, but I wanted to see what I could get done from scratch.

In the end

Being my first go at a gamejam, and a Ludum Dare, I really enjoyed the experience. Most importantly, I learned quite a lot of what to do and avoid when using pixel art in Unity3D. Despite everything, I liked my entry enough to continue working on it until I get it to the state I wanted it to have from the beginning. After that, I’ll continue with my usual game development woes. But, before that, time to reply to the comments on my game and rate some other games!

Mighty-chondria post-mortem

Posted by
Sunday, September 9th, 2012 6:27 am

This is our second time entering Ludum Dare! Our previous game was Macro Marines, and you can read about how we got on. We’ve learned from some of our mistakes, and we think that this time our game is better! Please play and rate it!

 

See how we made it:

 

Good

Unity is brilliant, and easy to use! We had great fun learning to use it in LD23, so we used it again this time and had a better idea of how to use it properly. It does everything for you and lets you get on with making the game, we love it!

We got plenty of sleep and decent food!The Jam started at 2AM UK time, so we decided to get an early night and wake up bright and early to discover the theme in the morning and think of ideas over breakfast.Each night we slept enough to be refreshed the next day.This is in contrast to how we’d do things at university, where some of us would try and go the whole weekend without sleep! (it didn’t end well)

Nice graphics!There are still some rough areas in the GUI, but overall the game looks good and the bacteria shaders look like proper scanning electron micrograph images.

You can only tell this isn’t a real blood vessel because of the health bar

Catchy music!Just listen to the groove on that DNA upgrade screen, yeah!

Good time management!Although we didn’t get a “basic but finished” version of the game uploaded and submitted 4 hours before the deadline like last time, Ricky did drive us to finish before the deadline and concentrate on the important features.

Decent gameplay in a short amount of time!We programmed the basic flight and shooting controls in an hour or two, allowing us to spend time tweaking and making sure they felt good. The bacteria AI took longer, but was working well by the end of Day 2. This left us with a day to implement the DNA upgrade screen – the key to the “Evolution” theme (although the bacteria do mutate and exhibit natural selection) and something which makes the game more complex and interesting than a simple shooter. But does that make it more fun?

The cubes are supposed to be segments of DNA

Title screen – pwnz deus ex

Bad

Spent too much time on procedural environment generation. We thought that generating the “tunnels” in code and having junctions or “rooms” between them would allow us to either create a large level for the player to explore, or allow the computer to generate the level for us. In the end, neither happened, we just created a small level with three joined tunnels. For the work we put into it, we could have created an equivalent level in Blender in half the time, but when we extend the game beyond the competition it will come in very handy…

Mmm, splines

No jokes or silly voice acting, the bacterial theme didn’t really lend itself to that although I suspect we just weren’t trying hard enough to fit them in. Also we were running out of time and this was low on the priority list.

Upgrades aren’t balanced, it’s too easy to become too powerful too quickly. We need to learn how to pace a game properly.

These bacteria were busy dividing behind my back while I cleared out another infection

Conclusion

We had great fun making a game with Unity, and I think we’ve learned from our previous Ludum Dare and made a better game this time!

Please play our game, leave some feedback and help us see what we can do better next time!

100 Games rated – Best Of

Posted by
Friday, September 7th, 2012 10:06 pm

Just like the last few times, now that I’ve passed 100 games rated time to pick some favorites that I think could use a bit more <3 !  This time is a little different though, I’m not going to pick “overall” favorites, as to be honest this LD every game so far that i’ve loved in one way has managed to frustrate me in another, so I’m going to categorize some favorites based on what I think is their strong suit!

As always, in no particular order (games that would fall in multiple are only listed in the one i think they’re strongest in)

Best Use of Theme:

Most Fun:

Best Graphics:

Best Music:

Some of these still only have a handful of plays, go try them out and give them some feedback!

And as always, I could always use more feedback on my entry as well if you havent played it already !

http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=7131

Super Genome – Timelapse and Postmortem

Posted by
Wednesday, September 5th, 2012 1:15 am

Keeping with the ludum dare tradition, time to do a little analysis on what went right and wrong during my development this time!  Before I get started with that though, for one I’d like to apologize, normally i do this at the same time as my “100 games rated” review and best of list but unfortunately so far my review list, though not quite at 100, to be perfectly honest i just dont have that many games that really stand out yet, not enough to make a real list, so expect that some time in the next week or so as i revew more!  Secondly, my timelapse is now up, accompanied by a nice track of classical music as always, so please enjoy this.

Get on with it!

Right! postmortem! The point of this post, for starts, here’s the link to the competition page itself

http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=7131

What went right:

  • The theme: frankly i was dreading another dreary, artys/emo theme like “abandoned” winning again, those kinds of themes are simply NO FUN for us programmers and it’s horifficly hard to get a decent gameplay idea that’s not just bolting the theme onto the story/background. (I generally rate 1 on theme when people do that myself, as just tacking it on isn’t really “meeting” the theme)
  • My engine: my game engine worked BEAUTIFULLY, a few minor fixes were needed after release but having a fully cross-platform engine set up and ready did wonders, so even though my idea made me write a full entity system and isometric renderer from scratch having windowing/input/state management/texture and memory management already taken care of made the task a lot easier
  • My tools: the newest version of my sprite editor (available under the “tools” link at the right) worked like a charm, it made animating the modular sprites a breeze even for a crappy artist like me, this time around a lot of people have even said they LIKED my art style!
  • Time: for the first time, I was actually able to be HOME on both days of ludum dare! So this was the first competition i technically actually had 48 hours to work in

What went wrong?

  • Timing: This ludum dare took place on the first weekend college is in, in the middle of one of the hottest weekends of the year in southern california so of course we had rolling blackouts all day saturday, my UPS tried it’s best to keep my desktop running but i ended up with a few hours of downtime midday, losing a good 4-5 hours of development, I ended up having to cut features due to this
  • Mouse control:  The game was meant to be controlled entirely by mouse using pathfinding, unfortunately due to being down most of the day saturday i ended up having to cut pathfinding or I wouldn’t have had time to make actual levels and art to play.  This made getting around corners somewhat tricky though thankfully still do-able (wasd also works as analternate, it was debug code though and not the way the game was meant to be controlled so it’s a little jumpy)
  • No way to restart: Another feature i had to cut due to time was resetting the player after he dies to restart (the levels already reset, only the player needed to reset) so i was forced to put just a simple game over screen when you die
  • Lame ending: Another cut feature, I was going to make a better image to show when you get to the end and to thank you for playing but again, due to playing catchup for saturday a lot of art had to be cut, so all you get now is a blurb of text for the temporary ending
  • not all evolutions have artwork:  my game actually tracks a LOT of statistics when you’re evoloving, over 2000 combinations are actually possible but only a tiny portion make visible changes due to my inexperience in isometric art that’s not geometric in nature and lack of time. There is no distinct skin/leg/ear/or fang graphics for the other features that evolve, only general body type, head type, and back type are actually shown
  • needed a statistics readout window:  I really needed a window to show your current statistics, the “overall” statistics modified by your current evolution status are  attack/defense/speed/flight/poison/and vision, a lot of people had trouble in the caves because they did not kill enemies outside first that would buff their defense before starting to fight the much tougher bats and spiders inside

And to close out, here’s a short gameplay video of how it all turned out!

Going Mobile and Also Some Graphs

Posted by (twitter: @thomasbowker)
Monday, September 3rd, 2012 1:40 am

Just a quick post to let everyone know I ported the controls of my LD game Vol to a touch interface and did an Android build. Do note though that the Android version isn’t guaranteed to run or run very well on your device. I have a HTC OneX and it performs okay, at least for the purposes that I created it for, which is mainly to test the control scheme on a touch device.

You can download the .APK here.

Vol on Ludum Dare

 

Also here are some analytics because they’re fun.

 

Average time (in seconds) spent on levels 1-7 and Session Time.

Session Time is time spent from starting a new game to game over, and the average is 388 seconds or 6 minutes 28 seconds. Not bad! I wish I was tracking analytics on my last LD game, had reports of over an hour before finishing.

More diverse than I expected!

More stats!

  • The number of unique players in the last week is 166.
  • 52% of players have 4GB of RAM
  • Average RAM is 5041MB
  • Windows 88% and Mac 12%
  • 48% of players have 1GB VRAM
  • Average VRAM is 925MB

Anyway, analytics are fun. You should use them in the next LD.

Social Evolution Post-Mortem

Posted by (twitter: @jorjongames)
Saturday, September 1st, 2012 7:17 pm


PLAY
 :: RATE :: TIMELAPSE

 

You need to socially evolve to get the girl you want. To have money, a car, popularity, etc. That’s what I tried to tell in my last game.

 Warning: This is intented to be a parody game, so please don’t take any advice in the game into the real life 😉

In this post-mortem, I’ll try to explain what things of the development process made me mad, what made me sad, and what made me glad.

It’s not a fun game!

At least for the last 30 minutes, the game wasn’t fun. That was driving me nuts through all the development process. I was thinking “I need to make this game fun, but how?”. Finally at the last moment I decided to make the “power-ups” come from the right side on a random basis. Before that, they were static.

This wasn’t my original idea

Indeed it wasn’t. I wanted to make a more strategic game, in which you had to train yourself to get more girls, and eventually you could get Lucy, the girl you always wanted. Of course, that was out of the scope because of the short time. 

I only had 24 hours

I woke up at around 8pm (yeah, I know), looked up the theme, and tried to think something cool. Obviously, nothing cool came about, or only ideas related to genetic algorithms, which I didn’t have the time to implement. At the end, I could have made a better and more balanced game with those extra 24 hours.

I’m (still) not good at pixel art

Not a bit. I lost too much time drawing and redrawing the characters and the background, and even though didn’t come with something cool. This is definitely something I need to improve for the next projects.

I had many versions before the “final” art

I couldn’t use my framework

My framework was on process on refactor when I learned that LD was the next day. So for obvious reasons, I couldn’t use it, and had to stick with plain Actionscript.

The Resource Maker saved lot of time

Indeed it did! If you haven’t checked out, my Resource Maker can process a folder and generate a Resources.as file which contains embeds for the assets found in that folder. I made a simple *.bat with a call to Resource Maker, hooked it on the pre-compile process, and I didn’t have to write a single embed line :)

I was well organized

There is something I’m more and more aware of: TODO list are a win. After I had some idea of what I wanted to do, I wrote a TODO list on a text file with what I needed to make in order to complete the game. Next, I had to stick to the plan, adding and removing things as necessary. After 12 hours, I was already implementing sounds and music, since the core game was already finished (although it was still boring).

 No interruptions

I wasn’t interrupted at all (except for going to sleep, going to the toilet and sleeping). That was a good thing since I was fully concentrated on the development.

Good prior sleep

Since I woke up at 8pm Saturday, I already had a full sleep. So all I needed was sleep only 4 hours during the development.

Good post-render effects

I followed this tutorial to make my fancy post-render effect. It took me around 3 hours to implement it, and it was well worth it :)

A quick comparison between normal mode and “fancy” mode

Easy music maker

Since I’m not a musician, this tool helped me a lot for the music. What I needed to do was to generate good sounding music, and put them together in a sound file.

Walkthrough

Vol

Posted by (twitter: @thomasbowker)
Saturday, September 1st, 2012 12:29 am

Just realised I have forgot to do a “I did it” post so here it is, delayed and all.
You can check out the game here:
Vol on Ludum Dare

This was my second LD and I’m pretty happy with how everything turned out. I went in wanting to make something that feels, looks, and sounds a little different than normal (or just crazy) and I think I did pretty well with that.

I also wanted to focus more on presentation this time, and unfortunately I had to make the decision of sticking with the theme more or polishing what was already there. I chose the latter though I’m happy I did.

Oh and here’s the time-lapse:

Until the next LD!

~ Thomas

No i will NOT install your frameworks

Posted by
Thursday, August 30th, 2012 4:51 pm

In the interest of less typing, first, read my post from last ludum dare on this topic, as it covers 90% of what I want to say right now.

http://www.ludumdare.com/compo/2012/04/27/how-to-ensure-more-people-can-sucessfully-run-rate-your-game/

Basicly though, the short of it is, if your game REQUIRES a setup procedure, or requires me to go out and install some other libraries or runtimes on my system itself before I can play, I will (most other people will too) click the “back” button and move on to the next game in the list of 1400.  This goes for you too love2d people! (ESPECIALLY love2d people!) Even if i did manage to figure out how to get the mess of severely outdated libraries love uses on my system without destroying my entire OS I would still have to deal with the fact that love versions don’t work with games made in other versions, so no matter which one I install it would only work for half the games!  Pack the interpreter for love, it’s a TINY set of executables and libraries, i showed a few people how to do this last LD and it seemed to be a huge success, a lot of people were able to play the game that otherwise wouldn’t have.

To add on to this as well:

* No I will NOT install a different web browser, if your game has issues in firefox I talk about the issues in firefox and rate it based on that, sure chrome may be a better experience in your game but I don’t use chrome.  If it has MAJOR issues under firefox i just leave a note saying it doesn’t run on firefox and move on. I’ve seen a lot of instances of people pointing out bugs/lag issues that break the game and the response basicly being “oh…just test it on chrome”

* No, I will not upgrade my system core (libc, libstdc++,etc…) just because you compiled with the latest git version of gcc and don’t want to take 10 seconds to copy those shared object files into the tarball.  “just upgrade gcc/libc!” as a fix to get your game working, leaving me with a month worth of tracking down every package that breaks and bug testing all my code against a new gcc version is not going to cut it.

* No, I will not install sun java 7.  Seriously, unless you have some sort of HUGE PRESSING REASON to be compiling for sun java 7, set your compile target for java 6, now magially those 90% of users complaining in your games page about “crashes on start” or “wouldn’t run” can run the game just fine!  Also stop using the non-standard java extensions for different sound types included in sun and microsoft’s jre’s only, it breaks your game under the default vm’s on android, linux, and basicly any system using anything but those two vm’s

A few extra tips to add on to the ones in the linked post:

* Linux Games:  on top of what i already posted last LD (READ THAT POST!!!)  another common mistake i’m noticing is distributing the linux games in zip files.  Remember, zip does not preserve permissions! This means that your executable files will not be executable after download, and you simply have to hope that the user knows how to re-flag the file executable. (you’d be surprised! linux is far more mainstream now, the majority of users do NOT know why that file “just wont run”…even in something here like LD) . The preferred distribution format is .tar.gz , i don’t know offhand the gui programs for linux that can create them but even from a shell it’s as simple as

tar -pczf filename.tar.gz /folder/path

* Naming your links:  Please stop simply calling everything “web” it makes filtering for platforms next to impossible, and LD’s search function next to useless.  At least make them say, “web(html5)” or “web(unity)” so that when i’m  browsing html5 games on my android or such every other “web” link isn’t silverlight or unity telling me “lol…i trolld you, i don’t have a web plugin that works on your device!”.  There’s also quite a few games that named their links “windows” “mac” “linux” and all three of them point to a windows executable, sometimes with a blurb that it “hopefully” works under WINE.

* Don’t put things like “sorry linux users”  “sorry mac users” “maybe next time i’ll do html5” or things like that in your description text, it makes your game come up when filtering for those platforms and makes the ludum dare search feature entirely useless.

* Make sure your zip/tarball has a well named folder your entire game is contained under in it, do not have all your files simply sitting on the top level.  there’s 1400 games to test, most games do this properly but a few still do not, if you dont contain your stuff in a folder it will happily unzip all your files all over other peopel’s test directories, generally containing other games we’re testing or want to keep around to try farther/review, and now instead of just having a folder to remove i get to hunt and peck files, sometimes hundreds of them, from the main directory trying not to delete the ones i meant to keep…

 

Monkey Bowling Timelapse

Posted by
Thursday, August 30th, 2012 2:21 pm

After some waiting, some LD game rating and some more rating, my timelapse is finally rendered and uploaded. GLapse destroyed the quality on the last part of it, but there’s nothing I can do about that now. Anyway, the timelapse is below and my game is here.

Young Earth Road Trip Postmortem

Posted by
Thursday, August 30th, 2012 4:35 am

Play/Rate

Young Earth Road Trip was my first LD game. I had a great time (for the most part: see Period of Despondency), was able to include all of the major features I wanted, and learned a lot.

What Went Right

  • My game plan worked very well. Friday brainstorm, Saturday build, Sunday polish.
  • I only had one strong concept idea, but I was able to develop the rest of the story and the game play very quickly once I decided that my core idea was, “YEC pilgrimages to the Creationist Museum.”
  • I narrowed my scope early on. The original neighborhood had eight neighbors, plus Miguel’s house at 316 and a few other locations, but I decided to go with the four strongest characters and only have 4 locations.
  • Gained confidence in my graphic abilities. I mentioned this when I finished the game, but I thought the real crutch would be graphic assets. But once I got started, the graphics part went very quickly and the assets are “good enough” to convey the story and some of the humor.

What Went Wrong

  • Most notably, music. I “scouted out” music tools beforehand and decided, “Oh, I’ll just use inudge.” Somehow, I didn’t notice that inudge had no convenient way to export the song, so when I started working on music about three hours before deadline I realized I was stuck. My computer doesn’t have speakers, so I couldn’t even record a crappy version that way. I didn’t trust myself to learn how to use new software before the deadline, so I ended up pecking out something on piano for the ending (the rest of the game has sound, but no music).
  • My Period of Despondency: Early afternoon Sunday I started to wear down. I was tired and I wanted away from the computer. The game was technically complete, but there were a lot of graphics, music, and sounds to add. I didn’t think I would be able to finish the ending sequence, which required a lot of new images. Fortunately, I got a second wind (had to give myself a little pep talk there).
  • When I leave an asset, I really leave it. Forever. On a number graphic assets I told myself I’d come back and add detail work, but never did. In the future I’d go ahead and spend the extra minutes polishing up each one before I move on.

The Future
I ran out of time for a few things, like a parallax bus-driving scene and blinking eyes, but overall I was able to include everything major that I planned for. With the exception of adding music and a splash screen, I probably won’t make any changes (and I might not even make those, since this game is a nice time capsule of my current skill level). But I’d like to take some of the things I learned (like how to make the random God hints) and apply them to new games.

The Last Slime – Gameplay Vid & Postmortem

Posted by
Wednesday, August 29th, 2012 3:23 pm

What went right

Coding – In past entries I spent far too much time and energy trying to maintain good coding practices. That was completely thrown out the window this time around, and, though we had to deal with a lot more bugs during development, I actually finished a game.

Basecode – I owe a lot of that success to having a solid basecode this Jam as well. In previous attempts, I had a basic idea what I wanted to make and prepared base code for that. More often than not, the theme would completely shatter those ideas leaving me with very little useful code. In this jam, I included a wide variety of libraries, and was able to choose ones useful to my project.

Map Editor – In particular, having the ability to import .TMX files right from the start was a godsend. The ‘export to lua’ feature of Tiled is great, but not perfect.

Teamwork – Despite being in separate locations, it was a very different experience having someone else to bounce ideas off of, complain to, and test gameplay. It’s much harder to justify slacking off to someone else than it is when you are competing alone.

Graphics – This was my first time entering with a partner, and having someone else looking after graphics removed one of the most stressful parts of a compo for me. It also changed my design pattern. Normally I use placeholder graphics, and then create final sprites/textures once the code is solid. This time, Alex had a lot of the graphics done before I even had the code to support them. This eliminated a common trend of my past entries where I would write a feature which later had to be cut due to lack of graphics.

What went wrong

Timelapse – I messed up my Chronolapse / VNC configuration, making my timelapse screenshots completely unusable.

Music – We had planned on being a three person team, with someone else looking after the music. It didn’t end up being finished in time, so we had to use placeholder music I created earlier in the compo. (I used GreaseMonkey’s Autotracker, OpenMPT, and FL Studio 10.)

FPS – I didn’t have much, if any, time to optimize the raycasting engine. While the walls are pretty fast (using quads to draw them in stripes) the floor and ceiling are drawn pixel by pixel, which is painfully slow at anything but microscopic resolutions. Fortunately our graphics were already intentionally low-res, but even so, the game simply doesn’t look as nice scaled as it does full res, and I know a lot of people are not going to be able to play it with those settings.

Theme – We had to completely scrap our original idea due to the theme. I’m still happy with how the game turned out, but it definitely took a very different direction than we had intended.

[cache: storing page]