Your not wrong mysterious scientists who found me in this bar. I do like traveling through deadly negative space. -> [Project Monster by 0x0961h]
Tags: 0x0961h, Larry Chupacabra, Larry Does Ludum, LD33, Negative Space, Project Monster, sci-fi
Today I could just creating this monster, and this let me very slee.. py… zz……z z… z .. z.z .z
Tags: Construct 2, pixelart
Going in –
Starting my 2nd ludum dare competition was something I didn’t know if I would do or not. I had spent very little time looking into how to use any tools or if I would be able to make something worth presenting. I made something for the warmup weekend though and it made me more confident in that I knew I could get SOMETHING made that would at least be good experience. I worked on relearning some basic pixel art, audio tools, and Gdevelop. I knew I hadn’t prepared enough for anything with real coding so I went with that. I spent most of my week learning how to use my tools effectively and read up on some tips and tricks. On the night before the release of the theme I took the final 20 submissions and brain stormed ideas for about 3/4ths of them. Luckily for me the one that got chose was one I had a decent idea for. I also knew this time around to try and make a game that is short and simple, because there are thousands of others they still have to play.
Good –
I feel like I learned a lot about the tools I used before hand with the warmup and that gave me the skills I needed to make something simple for LD33. The tool Gdevelop is surprisingly robust for something that requires 0 coding and with it easily exporting to web and being a small file it makes it perfect for a weekend game project. I lucked out with this tool because it was exactly what I needed to counter my early on lack of preparation.
The gameplay turned out better than I could of hoped for because I worked out the major glitches early on and even managed to find a quirky physics system in Gdevelop that adds that extra humor value. I know I love games with ridiculous physics and when I was tossing knights around and making them bounce off each other I knew I had to leave it in. Based on the comments I’ve gotten it has been a crowd pleaser.
The art and music turned out pretty well too despite what I thought. I am horrible with music so I tried to keep it a simple beat and I think I succeeded in making it tolerable. The art is simple but I think I followed the basic rules of pixel art well enough that it doesn’t look terrible. I’ve seen some other games so far that blow me away with how they got such a good look in 48-72 hours though.
Bad –
I had intended for this game to be pretty different than how it turned out and some limitations of the tools I used and my own lack of experience were the downfall of me. I feel like I made a decent game for the competition but it could of been much better had I prepared.
I decided that ceiling traps were a bit too much like LD32 with it being an unconventional weapon, also it would of taken a lot of time from refining what I did have ready.
The ideas I had were great but unfortunately I was unable to do more than a basic attack. I had the assets and code for the throwing axe but it made the knights go a little buggy so I scrapped it because I knew it would be a headache to debug it in just 6 hours.
I had a cool idea for an easter egg where if you continue to play and die over and over the sprite degrades until you are a token and it gives you a game over with no replay. I decided to scrap that because wow would that of been awful to do with 1 day left. I did make the last one though where there are two different death screens.
Next time –
I really want to learn enough of Unity to make something with it for LD34. I am working on learning C# and I think it should be easy enough with my previous scripting/programming experience. One of the other things I would love to work on is my pixel art, because I feel gameplay, art, and sound are the key aspects of any game.
This time I went for the compo because I knew I could finish in the time limit and to be honest I still had hours to spare and just submitted early. Next time I might try to find some people to work with and do the Jam instead because teams seem to produce the best quality overall.
Overall I enjoyed LD33 and playing the games others have made, if you haven’t seen mine yet please give it a try, it’s quick and worth a few minutes of your time c:
http://ludumdare.com/compo/ludum-dare-33/?action=preview&uid=51253
So, today, due to lack of ideas for games, I think I am going to touch up my game (or maybe rework it) to the point of it being actually enjoyable. The reviews so far seem okay, but I know that I can do better. I will not release this before the voting ends, because that’s cheating, but I think that the game still has some potential to be great. 
Just wrote a post-mortem for my LD33 game First Person Giant Monster Game which you can view on my blog.
Also, for those who haven’t played/rated it yet, click here to have a go. I’m also still looking for more games to play/rate so click here to submit your game and I’ll get round to playing/rating them as soon as possible.
Tags: LD33, post-mortem, postmortem, Unreal Engine 4
Hungry Cthulhu – try it HERE
I wanted to make a fancy, pretty and awesome little platform adventure game with a story. It was going to be full of mechanics and puzzles, there was going to be loads of art and content. Last Ludum Dare I made < 2 minutes of content and so I wanted to do… more.
In terms of gameplay, each time the character goes through a teleporter, they become slightly more messed up and lose abilities. Shooting, jumping… they become slower and eventually begin being obviously very ill indeed. This was going to make solving each level harder.
Sort of. I implemented all the mechanics: I had an NPC, a whole bunch of interactions for the player and NPC, a monster, buttons, lifts/elevators, doors, teleporters and I’d managed to do over 100 individual frames of animation for all the different versions of the player and the entity. That consumed a day and a half. Technically there is loads of stuff here.
But.
The audio was a rush. I struggled to compose decent music for this, so what I ended up with was one short little ambient thing instead of the specific music for each level I originally planned. I think it works… just.
I also had no time at all for background tiles. I ended up doing crude, basic tiles that I hoped would at least look consistent in terms of style but I’m unbelievably disappointed by how simplistic the levels look. Even the fancy post-processing shaders and lighting weren’t enough to compensate.
Finally… I didn’t have enough time to do the levels that I wanted. There was always going to be 5 levels, one for each part of the story, but with time running out I was forced to make levels 2 to 5 really just about the important story beat for that particular stage of the character’s journey without any of the additional puzzles I’d hoped to put in.
Totally. Corruption-5 was made with my own “Hexr” game engine especially for WebGL and my own level editor. Making this game made me realise how inadequate my tools really were for creating content quickly and so since then I’ve done major work on them which is priceless as far as I’m concerned.
I’m also really pleased with the animation and sprite work which was a massive improvement on my last game.
I also think that while the game is short (it takes about 5 minutes to play) it feels complete. I was able to tell a story just using the simple mechanics I had in place and all in all I think the result is a pretty enjoyable and fun little experience perfectly suited to Ludum Dare.
Yeah I sort of started working on it but I think actually there’s not much point now. This is more like what I hoped the compo version would be but perhaps it’s better just to chalk it up to experience and leave it at that.
I don’t know what the verdict is going to be for this game but I suspect it’ll be difficult to do better than my last game… but that’s okay. I’m moving on.
Next time though the important lesson is this: Fewer mechanics, more content. Making a bunch of mechanics which you then don’t have time to use in levels is a stupid waste. Also: Fewer sprites, more background art.
Gulp.
Tags: ld33 postmortem
Timelapse of my Ludum Dare 33 game. The game turned more into an interactive storybook than an actual game, but at least it was better than my previous entry 😀
If you have missed it, Grow now has a postjam version. You can check it out on itch here: http://fullmontis.itch.io/grow
You can also see the compo page for the game here: http://ludumdare.com/compo/ludum-dare-33/?action=preview&uid=21736
We just pushed a new version of our LD33 jam entry “Human Zoo”. This fix a crash in the HTML5 version when playing for several minute and going out of memory. We also give the offline solo “.exe” version and a multiplayer version. With this version, you can play multiplayer on the same machine, in lan, or through the web. We played a bit of the multiplayer, and its fun to compete or cooperate. You can grab a stunned player either to save him or to put him back in the cage. Playing the game yourself in multiplayer give a lot of emergent ideas. Let us know if you had fun !
We also recorded a timelapse while making graphics :
A confession first: the subject and the mechanics of my Twine story for this Ludum Dare were decided and thought way before the theme voting started. It was going to be a story about the life of an ethically-challenged guy and a game about telling other characters tre truth or some lie and getting away with it.
This was my game after 2.5 hour of work.
My intention was adapting the idea to the theme once it was announced. This was really a crazy bet: some of the most arcade-oriented themes would have forced me out of this Ludum Dare. Fortunately, You are the monster was the best theme for me, since my head was already full of storylines that allowed the character to become a child psycho, a teen womanizer or an adult corrupt leader.
Since I knew what I was going to do, I had a luxury that many participants lack: I could plan. This plan, that I laid down using Todoist, was the only game-related thing I did before the compo. It was also the most important thing I did.
I allocated 30 minutes for this, but used more like 30 seconds.
Not that Twine has a lot to configure, but I created a git repository. I also used the Twee2 tool to write Twine from a text editor, which had been released in alpha 3 days before. Twine writers: check it out.
I allocated 5 hours for that, thinking that it would take 4. This is a hypertext game and the logic is absurdly simple, right? I spent 6.30 hours: 162.5% of my initial estimation.
Got image from http://ghiasi.org/2013/10/hofstadters-law/
First I worked fast enough, but then all the silly details like making sure variables are given a value at the beginning so there’s never a division by zero started raining on me. By the time I finished, I was a bit down. I had no idea what was coming.
Twine has its own debug mode, but apart from that I wrote a footer passage that printed all the variables in a readable way. Twine writers: do this. And don’t forget to remove it.
This is where everything derailed. I estimated 10 to 15 minutes to write each scene, averaging 200 words, no revisions, no care about style, just churn the bastards out. With that I expected to hit 50 scenes with ample time to rest. I wrote down the ideas for the storylines and started writing the story.
That night I had 13 scenes. Each one was taking 30 minutes at the very shortest: I was generating content 3 times slower than planned.
22 Twine passages. I'm writing way too slow. I'm not sure what I will be able to get done in time. #ludumdare #ldjam pic.twitter.com/K8AUZ32jVr
— Pseudavid Menti (@pseudavid) August 23, 2015
Why? Well, did I mention that I’m not a native English speaker? But that was a lesser problem than actually making up the story. Not having a tight plot but vignettes scattered across the whole life of the character left lots of room for improvisation, but my writing skills simply didn’t cut it. Hofstadter’s Law again.
Since content was needed for the player to appreciate the gameplay, I was in serious trouble.
Very easy part and a relief from the stajanovist story hell I had written myself into. Twine authors: Google web fonts are your friends.
Until I broke down and thought of quitting. It wasn’t going forward.
This saved my game.
When you’re so behind schedule that the schedule is going to go round the world and get you from the back, is taking a long rest at bed a fine idea?
Yes sir. I did and it saved my game.
All the time I had been writing from a loose and fuzzy list of story ideas. I had no measure of progress, no indicator of completion. That was what took my energy away.
So I lay down on the bed and thought of what I had left. I went through all my story ideas, fleshed them out and divided them into scenes. Then I went back to Twine, created the empty passages, went back to bed, thought of another block.
It took 2 hours but at the end I knew exactly what I was going to do.
Now I wasn’t just churning out content: I was filling some empty boxes. When all were filled, I would have a mininum viable game. A completion indicator totally changed my attitude. Soon I was writing the best and fastest text in the game. I knew when and how I was going to make it, and now it was only a matter of physical resistance.
Two hours before the deadline I finished the minimum planned game and could take some time to add extra content.
Hint: Hosfstadter’s Law again! IT TAKES LONGER THAN EXPECTED.
The final Twine with its glorious 44 passages.
I wrote some conclussions about content and jams here and here.
Had I not planned in advance, I would have not overcome the insecurity when I saw everything taking twice as long as expected.
I finally couldn’t test the game thoroughly. I barely found one bug, but the gameplay is not quite balanced and according to comments most players like the game but don’t get quite what they were expecting.
Yesterday I removed all the code, counted the words of actual game text and was totally amazed to find out that I had written 8,500 words. Lots more than I believed, quite long by Twine’s standards. I think that the biggest problem with my game is that it’s too short.
Tags: interactive fiction, Twine
There is our Post Mortem for The Monster Way, careful spoilers inside !
The game is right here if you haven’t test it yet.
About a month ago Anna and I decided to do the next LDJam together with a textual adventure enhanced by Anna’s artworks and some musics. The fun part was that in between she is went back to India and I am living in France. So it will be a long-distance jam which in our mind felt pretty cool.
A week before the event I started to prepare tools so as to be ready to begin on saturday morning: a private channel on my Slack to talk and share the LDJam with Leo Marius (http://ludumdare.com/compo/ludum-dare-33/?action=preview&uid=43978), technical researches about how to add images and sounds to a choicescript game (our awesome game engine! https://www.choiceofgames.com/) and tweak some visual parameters (colors, backgrounds… ).
We also knew that we would be in office on the monday, so the jam will be a barely 2 days and a half.
On the saturday morning I was up at 5.30am (french time) to the skype rendezvous, but Anna was about an hour an half late so I started reading and thinking about the theme and I came up with an idea not amazing or very innovative in my mind but simply “doable” and fun.
At last Anna arrived on skype and we started talking about the theme, I shared my idea with her and she surprisingly thought it was cool!
So we took about an half-hour to build the game’s ideas: you play the final boss of a dungeon, you have to kill heroes, and between fights you have take care of your lair and try to not get bored by the loneliness of your status. We run for 4 fights and 3 “break time”, and an ending with a mirror thingy and finally a portrait of your monster based on your choices. No sounds nor musics, because… I guess we both knew that we wouldn’t have time to properly do it.
Then we started to work.
It was simple and pretty vague but at the time it seems quite sufficient.
My main goal of the day was to make the storyline, build the choices and the situations to give Anna characters, objects and rooms that she would design. As I started the writing, Anna worked on a couple of rough concept art to visualise the art style of the game. She decided to go for a dark background, monochrome line art, to keep it simple given the number of illustrations to do.
On my previous LD game (Escape The Killer) I had built the game as I was writing it, when an idea came, I would instantly change everything previously written and build upon it it in the following stages of the game. So planning (the story, the choices), writing (describing situations and dialogues) and building (coding the game) were then completely entwined.
But this time, I started writing and planning, and when noon arrived I was barely writing the first break time and I couldn’t keep up with the Anna’s rhythm. So I pushed forward the planning and let entire sections empty to give Anna the elements of the story she would need. Sadly I think that the cohesion of the writing took a huge hit because of that. At the end of the day, I had 2 fights and a waiting time partially done.
Because of the time difference I finish the day alone (Anna is 3 hours and a half ahead of me) with a serious fear that I might not be able to finish the game. I came the sunday morning with two plans to finish the game:
First, make the 3 first fights and end up with a “To be continued” screen with a joke or something like “You are not the monster, we are. Because we haven’t finished the story. Sorry, better luck next time! Kiss kiss”.
Second option, cut a chapter (one fight and one break time) and go straight to writing of the final fight, which was a problem because I had then no idea of who will be the hero (who must be special) and how the “mirror thingy” will actually leads to the defeat of the monster. Also the beginning of the game was, at this point, not playable (lots of branches not connecting), most of the game mechanics and most images weren’t in place, and the painful main door feature was only half implemented (yes, the door can be closed, open, destroyed by you or by the heroes, rebuilt fully or partially… Basically, the door joke went too far for our own good).
In short I was really worried.
Anna and I chose the second option: go straight for the last fight and skip the third fight (too sad, she had already drawn the two alternative heroes of the 3rd fight!). That was the best choice, ending with a “To be continued” screen would have been to deceptive for everyone I guess.
Here is the third “hero” who should have attacked the lair of the monster.
I decided in the morning that Jenny Everywhere would be the best fit to beat our villain. Luckily Anna agreed to the idea to use her with the dream twist to conclude the game smoothly.
At noon I was beginning the writing of the last fight, it kept me busy until the evening running out of time, my girlfriend accepted to write two secondary story branches that were still unfinished, saving me two hours of work. Following her advice, I also decided to use a final easy story trick to close the game and save a bit of time.
Anna ended the last essential pictures we needed to complete the game and go back home. She was jamming at her office to use the internet connection which is way better than her home’s. She wished she had more time to draw the minions and more illustrations but at least the main stuff were done: 34 illustrations, plus the framed version for the achievements!
By the end of the day I had filled the voids of the choices and most of the game was in place. I was glad that most of the writing was done cause I was about to ran out of ideas to make new path and new items for the monster.
Because we were both working on monday, Anna devoted her free time to proofread the game and I mostly assembled the pieces together (add missing images and missing conditions), clear bugs (the main door took me a complete hour, to finally make things a bit simpler), make the ending screen and achievements.
An hour before submitting the game I began to write the ending little “poem”, who wasn’t supposed to be a poem at all, but a paragraph describing roughly attributes of the monster. I put it together quickly and submitted it.
Looking back, the planning phase was certainly too light, despite the simple story plot. I didn’t really manage to really have the story in mind and to keep it focused, so the game is a bit chaotic and overflowed by itself. Which is finally a fun and joyful part of it.
I realise that a lot of paths and a lot of characters kind of leads automatically to a lot of writing just to keep the story on tracks, but sometimes too superficially. Small jokes became completely time consuming (like that stupid door, that was introduced initially only because Anna drew an open door in the first concept art!). And I didn’t expect it to cause that much delays on the games mechanics and on the drawing.
Luckily Anna wasn’t bottlenecked on the illustrations even if it went close!
The very good part of this Ludum Dare was that we were on the same page all along and we were both very aware of the priorities of the development. And also we did finish a playable game in time so, hey! Kuddos to us!
It was a really fun experience, exhausting one but truly a new step. The distance was in my opinion playing for us because it somehow forced us to take some time to rest and relax.
Thanks for playing the game, and thanks to all participants of this LD33.
Tags: html5, jam, post-mortem, postmortem
Heya everyone. I’m Budaniel, the artist and programmer for AAGH Games, and this is a retrospective for our LD33 entry, Dial “M” for Monster. This was both the most challenging and the most rewarding Ludum Dare of the four we have entered thus far, so I’m going to tell our tale of troubled development in this Dial “M” for Monster Retrospective.
This kind of going to be a long one, but hopefully it’s an interesting read.
Friday: The First Night (and the days leading up to it)
I was psyched to get this Ludum Dare under way for a few weeks, but as the days counted down I got more and more distracted, to the point where, on the evening the theme was to be announced, I was so far from prepared that I was worried if we would get anything done at all. I usually have all of my tools ready and tested by that point and our live streaming setup has been configured already. This time I was scrambling to get it all in place by 9 PM that Friday.
When the theme was finally announced, our live stream kicked off and we got to work brainstorming. I’m personally of the opinion that the theme itself is never a hurdle – if you can’t think of something interesting to go with a theme, you’re not trying hard enough. In the first 30 minutes we rattled off a list of concepts what constitutes a monster, things like older/younger siblings, politicians, aliens, dai-kaiju, and more. The concept we settled on was rather mundane (a monster lurking in the woods hunting survivors) but our ultimate goal was anything but – we wanted our survivors to collect tools and materials to build a shelter, all while trying to stay fed, hydrated, warm, and safe. This meant a working survivor AI, and that was something we – and I in particular as the programmer – had not done before.
Things went about as well as you would expect from someone making an AI like this from scratch for the first time ever on a 72 hour deadline – progress completely stalled. The first four or so hours were making the survivors run from the monster, approach the fire, and locate nearby any food. We started with just one survivor for simplicity’s sake, and even that presented so many challenges. We adjourned that night with little more than a monster that moved and caused survivors to flee, which was way less than we wanted.
Progress at the end of Friday
Saturday: Long Days and Delirium
We picked back up late on Saturday because I overslept after the previous night’s debacle. I spent the first hour or so making the survivors seek food and then retreat to the heat and safety of the fire. We –and our viewers on the livestream – marveled at the sheer stupidity of our survivors AI, to the point that we were thinking of making that the selling point, thinking of names like “Dunces with Wolves” and “Darwin in Action,” with the plot being that you’re validated in hunting them because if they’re stupid enough to wander into the woods without being able to take care of themselves, then they deserve what’s coming to them.
At the time we were using basic letters to signify everything from the fire to the trees. We talked about the graphics we were planning to replace them with, such as what kind of monster we actually were, when one of our viewers insisted that we keep the text-based aesthetic. After some deliberation, we agreed to keep it, but only after I touched it up some.
Around midday I passed our project over to Floata, our musician/level designer to lay out the map while I took a break and distressed. When I got it back that evening the map was complete, which was good, but now it was time to resume work on the gameplay, which was less so. We again live streamed our work, to an apparent vacuum. It was actually probably a good thing we didn’t have a lot of viewers, because I was so tired that I was making dumb, sometimes crass jokes and Floata was mumble-grumping through most of it. We did manage to get the four planned survivors on the screen together at last, and we finally got them foraging for food and avoiding the monster. Unfortunately that was as far as we got this night before we had to call it until the next day.
Progress at the end of Saturday
Sunday: Where It All Breaks
This was the day where I was sure that we weren’t going to finish on time. We started early (skipping the live streaming since we were struggling so much) and the first thing we did was christen the game with a name. Since we were committed to the art style (and therefore the monster looking like the letter M), we decided to name it Dial “M” for Monster. Our original logo looked like this.
We got to work trying to make the AI protect itself from the monster. We originally had the survivors hunting tools to make a gun but like so many other pieces of the project, that didn’t make the cut due to time constraints, so they were all armed with knives and arrows instead. Way too much time was wasted getting the survivors to shoot at the monster (instead of every which way), but that was nothing compared to getting the survivors to explore more of the map. Originally there were just four survivors, and they were all grouped around the central fire, meaning that 90% of our huge map went largely unused. I decided to lay out a “breadcrumb” trail for them to follow in the form of (invisible) dots that would guide them from place to place. It was terribly finicky to work with, placing them just right so they were neither too close to each other/food/fires or too far away to be detected, but I eventually got it working somewhat. What I really didn’t want was for them to wander a randomly selected direction – I wanted them to follow the paths through the trees to more food or the next fire.
That took most of Sunday, but once that was done, we figured we were in the clear as far as basic mechanics. Sure, we had to cut the survivor item collection and base building, and yeah they weren’t as skilled as we would have liked, but we had the gist of our vision working. Or so we thought – it was at this point it all went to hell.
Whenever we tried to rapidly attack a survivor, the game would lock up the browser, forcing us to crash said browser to get it to close. We figured it had to do with hammering on the spacebar, so we tried various fixes. We tried delaying the monster’s attack speed to only accept attacks every 2 seconds. We tried changing the attack key to something other than spacebar. We tried removing the “slashed” hit animation on the survivors. We tried making the attacking happen on contact rather than via a button press. Nothing worked. Every time we aggressively attacked the survivors, the game froze. We didn’t find any sort of fix on Sunday, so the problem had to get rolled over to Monday. The only positives from Sunday were a redrawn logo (to the one currently in the game), a working GUI and updated visuals (even if they weren’t in the game yet). Here’s a comparison chart of the old graphics to the new/current ones, showing the progress that was made (click the picture for full size).
Progress at the end of Sunday
Monday: I Love It when a Plan Comes Together
Monday was another early start, and with just over 11 hours before the deadline, we had to get this crashing ironed out. While we brainstormed on how to fix it, I made the end credits and instruction screens (if there’s one thing we’ve learned over our years of making games, it’s to never assume anything is obvious to the player, so explain as much of the game to them as possible), plus we finally got Floata’s music in the game, complete with a mute button (another lesson we have learned is that a lot of people would rather listen to their own music – or the TV, or a movie – so always give them the option to silence the game).
We fought the problem until after 4 PM, or five hours to the deadline, making no progress. I was getting frustrated and was just about to compile a playable copy for Floata and some other testers to try when I had an idea for one last test: remove the “panic state” from the survivors that caused them to turn and run from the monster. I made the change without taking time to test it, compiled a build and sent it for testing before going to eat dinner. When I get back from dinner, Floata and our primary tester had both gotten back to me with the following update: the game wasn’t freezing the browser anymore, but the survivors were now ruthless killers that stuck to the monster with a vengeance.
The problem had been found – it was the survivors’ panic state that caused them to try and flip 180 degrees and run. The issue was that as long as the monster was nearby – which it had to be to try and spam the attack command – the survivors were firing their panic state behavior every tick, and that was overloading the game in short order.
It took us probably an hour to fully replace the panic state with something that didn’t crash the game but didn’t have the survivors latch on the monster and murder it almost instantly, but now we had a working, non-crashing game. A last-minute decision was made to move from four, individually colored survivors to four packs of three single-colored survivor packs. We stuck them around different fires, colored the fires slightly to match their pack color, and took the game down to the deadline as I added one more small touch that I thought would look cool – the fires of each pack going out when you wiped out their entire group. This proved to be a challenge and I just finished it up with about 75 minutes left. Floata and I then played it through, beat it a few times, lost on purpose a few times, and agreed it was as done as it would get, so we sent it in and the rest is in the hands of all of you fine folks.
Progress at the end of Monday
And thus ends the retrospective of Dial “M” for Monster. Give it a go, if you haven’t already. We didn’t quite reach our ambitious goals, but it turned out well and we’re quite happy with the result. Thanks for reading!
Click to play Dial “M” for Monster
Tags: LD33, post morem, stencyl
I’ve Decided to work on a sideproject on the weekdays, then Village Terrorizer and Video games on the weekends. Looking pretty bad so far xD You should be able to see what it is. Going for a 3d isometric game.
Ludum Dare 33 has been a great learning experience for me. Over the course of the jam and afterwards, I made a number of observations about the quality of my game development process and my abilities as a developer. This is my postmortem.
What Worked
Simplicity
Making a new game is an exciting opportunity, and ambitious projects tend to be the most fun to brainstorm. However, ambition tends to lead to complexity making those ideas risky. With so little time, game jams are not where I would reach for the stars.
Finishing a project (as finished as a jam project can be) is more enjoyable to me than working on something and ending with nothing to show. Having experienced both results, I chose a simple idea as I felt that was key in completing my group’s project last Ludum Dare. I believe this choice made development easier, smoother, and more fun. I’m glad I went with a basic idea, and I will do so again next Ludum Dare.
Working Alone
Generally, I try to be part of a team for game jams. I have limited art, music, and sound skills, so having people to cover those areas makes for more well-rounded products. Plus, working in a team is good practical experience, but perhaps most importantly, it’s fun to make games with friends.
This Ludum Dare I was flying solo, and while I no longer had access to quality assets, there were a few benefits. Being the sole developer gave me complete creative control. Working on exactly what I wanted was more creatively rewarding than when I worked on a team. Not only that, I was free to experiment and learn in the areas of game development in which I was most interested. I don’t prefer to work alone, but sometimes, it can be refreshing.
Don’t Sweat the Small Stuff
Game jams are short affairs. One can only accomplish so much, and there are more issues to deal with than time allows. Knowing when to let bugs slide or move on from polishing a texture or particle effect is important to maximize productivity.
In my game, the player can move around during the fade in and out level transition allowing them to interact with objects. Ideally, I would have fixed this, but I figured that players were unlikely to notice. This bug wasn’t game-breaking either, so I left it as is. The time I could have spent trying to fix it, I instead used to flesh out and improve more important parts of the game. I felt I did well making these types of decisions and will keep them in mind next jam.
What Didn’t Work
Simplicity
Simplicity was helpful, but it also hurt development. The idea I went with wasn’t particularly exciting, so my motivation was lower than it may have been with a more ambitious and complex idea. Also, the way I envisioned the implementation seemed quick, leading me to underestimate the time I needed to work. As a result, I took it easy the first day, and that low productivity damaged the potential quality of the game.
Working Alone
While working alone gave me total creative control, it also limited the project’s overall creativity. Simply put, two minds are greater than one. Having more than one brain to come up with ideas even just during development would likely have made for a better final product.
Additionally, the accountability of working with another person was gone. This lowered my motivation, which compounded with the other motivational issues I mentioned above. Now that I’m aware of this, I believe I can mitigate this problem next time I work alone if I handle the issue below.
Lack of Scheduling
Game jams are informal events, and I try to have fun with them. I don’t find making a schedule and deadlines particularly fun, so I didn’t bother with them. If I had, I think I would have not only been more productive but also had more fun.
With just an impromptu task list to guide me, I went with the flow and worked on whatever motivated me or gave me a clear idea for implementation. Unfortunately, those two conditions were not always true. As said earlier, I felt I had plenty of time to work with, and when I did not feel ready to jump into a task, I would take a break till I was ready to get back to it. This lasted for the first day and a half, when I started to feel like time was catching up with me. Ultimately, I finished the basic gameplay a few hours before the deadline. By not working harder earlier, I only had that short remaining time to make levels, and the game reflects that.
This outcome disappointed me, and the rush to scrape together levels was not enjoyable. Making a schedule would have helped keep me on track to work harder earlier. With deadlines to work towards, I would have had a better idea of when I was falling behind. I believe these changes would have ultimately made for a more enjoyable and fulfilling development experience in spite of the initial drudgery.
Room to Improve
I’ve been working on and off with Unreal Engine 4 to prototype some game ideas, but I’ve never gone through the packaging process or looked into resource management. When I first packaged my game for submission, I was quite surprised to find it taking up over 500MB. There was no way I could expect users to download a game that size. Fortunately, the documentation explained a mistake I had made in including hundreds of unused assets when I first created my project. After taking steps to fix this, I was able to shrink the package down to 100MB, which is still large but at least not unreasonable. Now that I’ve realized this could be an issue, I will look into further steps to keep file sizes low.
I didn’t experience slowdown on my end while developing Wrecking Blob, but several players reported it in the comments. I’ve never worried about slowdown in the past, but it looks like I need to start being conscientious of resource management so everyone can have stable performance.
One easy improvement I could have made to Wrecking Blob would have been to make the player model a blob instead of a sphere. However, I don’t know a thing about modeling, so even something that basic is beyond me. I believe, with just a little knowledge, making a blob would be a simple task. Learning the basics of a modeling program, Blender perhaps, would allow me to make such a model, and then I could make glorious programmer models for my other 3D projects.
With Ludum Dare 33 complete, I’ve learned how I’ve grown since Ludum Dare 32 and how I can continue to grow. I have a better grasp of my limits and how to choose an idea to match them. I get bogged down on details, but I’ve gotten better at letting go and moving on. The connection between productivity and quality is clear to me. I can use scheduling to bolster motivation helping me work consistently from start to finish. I realized that with Unreal Engine, even for a game jam project, I need to pay attention to performance and file size. Modelling experience will help me in future projects. I’m going to start learning though I don’t plan to go beyond placeholder quality. With all this in mind, I look forward to an even better Ludum Dare 34.
Our entry in the Jam section of the 33rd Ludum Dare is called It Came from the Rift. In it, you play a crazy weird eye lazer shooting horror from beyond the edge of reason hell bent on the end of intergalactic civilization. We got together on the weekend and made this game in 72 hours using all manner of tools and techniques known to us.
I sure wrote a lot of code! I basically sat in a chair for the whole weekends, tapping away madly at my computer, working on gameplay and “feel”. @nomoon sat beside me and worked on sound design, a pixel perfect animated parallax background, and a variety of other systems. Special guest Cudahy — who we say puts the “++” back in ZNC++atLaw — carefully crafted controller support and massive eye lazers that look and feel wonderful. @clangmuir, the brains of the operation, was busy the whole weekend with graphics: making the creepy looking eyes roll around in their sockets, choosing and tailoring the different eye colors so that they would be distinct without looking ham-fisted, and creating the really cool looking texture that forms the beast’s body. As well as the graphics for the lazers, each colored to fit the owner’s eye. And the ships. Did I mention the ships? He found those in a sprite-bank, but the choice wasn’t random: at one point I saw him puzzling over a set of four or five sprite sheets, comparing how they looked alongside the beast.
You see, @clangmuir’s art is the art of remix. He has an eye for design. He pours hours into his work, chopping up layers, recombining, and touching up, preparing things for the procedural animation step, and using content aware photoshop tools to turn a obscure Japanese SNES era graphics into something wholly contemporary and wholly his own.
When I submitted our game I had a momentary brain fart. We were going to opt out of the Sound category because the main theme of our game is stolen straight up and without permission from a musician who goes by Bleeds. In that moment, I thought: oh, all our pixel art comes from other games so I should opt out of that too! I couldn’t have been more wrong. The art of remix is completely valid, and I would defend @clangmuir’s labor. None of our pixel art “comes from other games”. It comes from the crazed imagination of a sleep-deprived genius using professional software tools I’ve never even touched.
So that’s why I’ve opted to opt back in to the graphics category. So go check out our game, and give the graphics category some well needed attention (or update your vote, if you’ve played already). @clangmuir spent the whole Jam making graphic and animations for our game, and as a result it looks amaaaaazing!
The perfect beer to spend the night playing some #LDJAM games!
And in case you haven’t tried mine: PLAY IT HERE
I made a fast RTS game when you are pissed off zombie who have enough of “zombie killing” games.
Gameplay:
At the beginning you own cemetery, which is a spawn point of your army. Every seconds your army is bigger and bigger.
You can’t wait to long, your opponent’s army is also growing. So you should find a weak spots and attack him.
If you kill all enemies from their spot (like base camp), all the graves that are near the base start to spawn zombies. You must think which spots you should take first.
Your opponent are sending troops to your main base, so it might be require to sacrifice some bases, and rescue another spawn spot..
Graphic:
This was the first time when I made pixel art, and I’m satisfied with the effect. I have used piskelapp and it was very easy to use for me.
Evolve:
I like the final effect so I think about developing more content to this game. This is not a game for a big fun after 5 seconds of play. You have to try it few times, to find out good tactics. User learn the game from every play. I’m not sure if it works while ludum dare, so I think about making a user guid or adding some helper on the first levels of the game.
If you are a fan of RTS do not hesitate to try!
http://ludumdare.com/compo/ludum-dare-33/?action=preview&uid=29762
Tags: LD33, pixelart, postmortem
Just for curiosity, why I can’t see the user page, with previous entries of some people?
Hello, I’m back! I promised to make video reviews every day, but I participated in FGL GameJam (Being an administration member I don’t aim for the prize, just after this Ludum Dare I understood how much fun is it to make a game within a limited time).
So, here are 5 more game videos:
Hitogochi,
Alchemist
Redemption
De-monstration
Disturbed mind
More coming soon!
To get a video review for your game sooner, please, check and comment my entry:
