although we haven’t been able to participate in Ludum Dare this time we still would like to show you our last game, which would have been quite fitting for this theme…you are a bunny defending a giant carrot and killing mutants with, well, CARROTS! 😀 We have been working on our last LD31 Jam entry “Of Carrots And Blood” and we have released it on itch.io for free for Windows and Mac and it is also coming out on Desura soon. We have added powerups, different enemy types, a global highscore for the single player and we have also added a local 2 player Co-op mode (which is the most fun) with a big boss fight surprise in the end! So please check it out
And for those of you who already know the Jam version, it would be really cool, if you could compare the two versions and tell us here in the comments, if we applied your feedback for the better or worse 😉 More feedback much appreciated!
Hello there my fellow indie developers, today I want to announce that the game I’ve been working on for the past months has been released. This project started back in “Ludum Dare 30” (Connected Worlds). We saw potential on it so we decided to focus and develop a good game on that topic. Our entryBERTA was the starter point, then it went through many changes and almost 9 months later we finally finished!
(It’s not Berta but it is a ball).
This game is about a Spunky little ball that has the ability to switch between colors in order to interact with the environment of the level. Everything that matches the ball’s color becomes solid, therefore you have to choose wisely what color to use. For example, you’ll want to be the same color as the coins but not the same as the spikes! Or maybe you need that a certain platform matches your color in order to roll over it without falling.
So be prepared for a fun and innovative gameplay on your device… Also prepare to die a countless amount of times…
I hope you enjoy this game as much as I did when I created it! Also don’t forget to leave a review on the Store page if you actually had a great time playing it.
There have been reports that 10 year old Newt Scoot has allegedly destroyed majority of his home in an attempt to blockade and subdue multiple unidentified entities. Surveillance footage from inside the home displays the boy shooting various items through what appears to be a makeshift, leaf blower cannon. For more details, or to watch and “Experience” the action for yourself: Click Here
Now that my game was submitted, fixed to the point of actually working, reviewed by other people, and polished a bit with the feedback, it’s time for the thing nobody expected but will get anyway: The Spanish Inquisition my first post-mortem!
To start things, this is not my first game jam, but it was my first Ludum Dare. The first game jam I took part was this year’s Global Game Jam, where me and a couple of friends worked on a cool title called Duality (check it out HERE if you want), which unfortunately didn’t get completed in time (in hindsight, we probably shouldn’t have gone for a multiplayer game right off the bat).
Our entry for Ludum Dare 32 is called Social Sass. It is a two-man project made by me, abcdef65g (design and programming) and my brother Ryrumeli (art and text). We had a ton of ideas for “unconventional weapons”, which included love, words, pencils, cooking spatulas, toasters, fear, shovels, dancing… But eventually, one idea came up during the brainstorm, and completely blew the competition out of the water: tweets!
Chirper, the next-generation microblogging social network – chicken not included
Read on to find out about the development process and the lessons learned from this unusual project!
And so we got started on the game. My brother was given great freedom as to the art direction of the game, and really did a great job with it, especially given our inexperience with game jams. The character and monster sprites are 16-bit style, and the village and other maps were coloured aiming for somewhat of an 8-bit feel.
Initial village sketch, and how it turned out in-game
A few words on the art by the artist Ryrumeli:
My first thought when we talked about the concept was going for a Mother/Earthbound 0 kind of aesthetics, right from the NES; However, as soon as I started to make the Enemies I felt I could make them funnier if I put them in style with this Tweeter user concept, but for that I would need more definition. Then the 8 bits shifted to 16 bits in a hurry, which was a bit of a rushed decision on my part but I feel did a good job to convey a gadget for every monster. I like how most turned out, but my favorite monster is still the Wizard, a tribute to my brother!(No girls, he doesn’t let his beard grow like that, worry not!)
Finally for the character sprites, at first I was going to use Mother Sprites, but frankly time was growing dim and instead I went for a style I had already played with, Chrono Trigger, because there is always a good reason to make a reference to Chrono Trigger *Goblin Fanboy Moment*, and if I can say one thing that went wrong was starting Mother, then thinking about shifting to Medieval, and then giving up and jumping back to Modern Times.
Oh and why a Roman Helmet for a knight? Because a true hipster has a thing for the classics!
Concept art for the protagonist Sass. Trivia: Sass is actually an acronym for Silent Albeit Somehow Social
One thing I sorely lacked in the programming part was foresight. I underestimated my ability to make UI as well as coding, and in the end, the UI for the chirps and notifications took the majority of my time. The game was developed using Unity 5, which I’m comfortable with, but the new UI system was something I had only dealt with a little bit. That caused me a lot of headache, because I had to invest time on the UI and thus failed to make the battle system until the last day of the jam, which cost me patience and sleep. The movement system also had to be improvised and thus, isn’t very polished.
I think I’ve seen that plot hook before
Curiously enough, the dialogue and quest system was fairly easy to implement, which saved me a lot of time. I was able to input all text and for those and make all quests functional in just a few hours. Still, this was hardly an advantage since the art and text were all nearly done, and I was still lagging behind in programming by the last day. We still managed to turn in the game just fine during the submission hour, but that caused anther problem: I didn’t have time to test the build. So it turns out there were numerous issues with it, which I had to address in the following, day, after sleeping for 14 hours straight and waking up with an ear infection.
Not the most solid battle system, but it’s certainly entertaining!
The things we did right
Used a game engine we are familiar with, cutting down on learning curve
Parallel work: the artist and the programmer worked efficiently to achieve their goals
Decided on a game concept quickly, which saved us time early on
Used a type of game we are familiar with (j-rpgs), which made a parody game a lot quicker to design
Last minute decisions: decided to cut down on extra text and didn’t include sound, transitions and a few enemy designs, focusing on actually finishing what we had instead of failing the deadline due to not delivering everything we planned
Most importantly, we didn’t strain ourselves too hard, and had a lot of fun making the game!
The things we did wrong
Seriously underestimated the amount of work necessary to code everything
Lack of proper planning and sleep
Parallel work: when everything was put together, things didn’t quite work as expected since they were done in parallel, without the other’s constant feedback
Used a game concept (microblogging) which we WEREN’T very familiar with, as neither of us used Twitter before, making additional research necessary (particularly for the UI)
No audio: we didn’t have time to worry about audio in our jam entry, which isn’t necessary, but would have added a nice touch
I think that’s about it. Hopefully you enjoyed reading my first attempt at a post-mortem (which is about my first real attempt at a game). This Ludum Dare was a fantastic learning experience, and we’re also having a lot of fun playing and rating everyone else’s games.
It’s been about a week, so here’s a retrospective on my LD32 entry: Pedestrian Mining Corps. It was a nice break from a couple of other projects I’m working on.
What It Is
Pedestrian Mining Corps is a one-button game about launching pedestrians into space to push asteroids back to Baby Earth by jumping on them. You’re working against the clock and asteroids’ gravity wells to get as many rocks harvested as possible.
It’s built in Unity 5. It’s a jam entry, so I used some premade assets:
Google Fonts (Righteous (pictured at right), Droid Sans Mono, and Oswald)
I recorded the stomping sound with my laptop’s crappy built-in mic because I didn’t feel like dragging my gear out, and massaged it in Audacity. Planet and asteroid sprites were created in Inkscape.
I finished. I got the thing done. I had to use the whole submission hour on Monday night, but it came together. I wasn’t sure it would. I’ve failed four of the last five jams I’ve attempted, so it felt good to get across the finish line.
I’ve been doing a lot more game dev this year than previously, and I’m better for it. I was able to quickly build the UI and tweened transition effects using techniques I’ve used before. I used the awesome Unity 5 audio mixer system for audio transitions and a low-pass filter to keep the music rumbling after the game ends. I’m pretty happy with the nearly-free polish I got from habits and reuse.
I learned more about Unity’s animation system. Those little jumping animations were pretty easy to make and their sound effects are triggered by animation events. Planet and asteroid rotations use the animation system, too.
I’m pretty happy with the 2D/3D split art style, though it didn’t go over well with most players. It was borne of a limitation: I don’t know how to texture 3D objects. More about that below. I’m happy with the way the menu looks and works, the way the game looks in action, and the way the score/replay wrapup presents itself. Oswald, the button font, is one of my favorites; I’m using it all over the place in another game I’m working on called Disc Jockey Jockey.
I like the choice players make between sending pedestrians to new asteroids or putting more pedestrians on the ones already coming in. More pedestrians on an asteroid makes it (subtly) move faster and take a more direct route to Baby Earth, but it also has an effect on your efficiency. I usually spend my early game bringing in as many new asteroids as possible and the last 20-30 seconds making sure everything that’s on its way gets home under the limit.
What Wasn’t Great
In code, I tried leaning into Unity’s component system this time with lots of tiny behaviors. This was a bad idea, especially when tweaking game feel. You quickly lose track of which object has which component on it, or which of half a dozen components is applying a force at the wrong time or playing a sound when audio should be muted. Or you just need all those components to talk to each other because they’re dependent on each other’s state. I’m much happier with a manager object that’s pulling the strings. Maybe individual objects can have small behaviors attached but controlled at a higher level where I can see everything at once. Let the manager subscribe to events published by components and consolidate coordination and settings.
I mixed 2D and 3D because I don’t know how to texture 3D models. Not even cubes. The only 3D software I know how to use is OpenSCAD—best-suited to mechanical models—which has no concept of UV coordinates. I think the resulting look is playful and silly, but most players just think it’s incongruous. A voxel design would probably work better. I wish I’d known about Magica Voxel before the jam.
I worked alone, which is great for creative control and kind of bad for motivation/focus/workload. Pairing up with someone more accustomed to working in 3D would’ve helped.
Some things I’d planned but didn’t implement:
Multiplayer. The framework is there; pedestrians have a “homeworld” they push toward, so it’d be easy to reassign that to another planet.
Pedestrians yelling their names on launch. I built a whole system to scrape the filesystem for audio clips at editor time and generate random first/last name pairs, but didn’t have time to record the voices. I think it would’ve been funny to hear. Ended up being a waste of time.
Different asteroid/resource types. I’d planned to maybe require a certain number of different resources to be collected under the time limit to advance to the next wave. Or even have antagonistic forces like an enemy planet or spaceship that would attack, requiring pedestrians to take it out.
Pedestrian classes. The original game concept was more like tower defense, launching pedestrians out to stick to planets where they could attack incoming enemies. I think classes could still work, with certain class combos producing more minerals or fending off attacks.
Credits. There’s a hidden button on the main menu that goes to a dead credits screen I didn’t have time for. That might be the one thing I go back and add before I consider the game “done”.
Tuning. I need to play with the push force, steering force, and asteroid spawn rate. They could all be improved. Playtesting would’ve helped.
Networked high scores. I always put this on the nice-to-have list, but it’s probably never worthwhile. They’re too easy to subvert and they mostly make you feel bad about your score.
Thanks for reading! I’m having a lot of fun playing and rating all of your games. <3
I’m actually very proud of Frenzy Inc, the game my team and I made for this jam. It was my first time entering with a team, and my other team members first game jam. I’ve been working with them on games for a while, but the time-limited nature of a jam was new to them. We made a game that we’re all proud of, and thats really the most important thing about the jam. We have also got some excellent comments and useful feedback on our games page, which give us a warm fuzzy feeling and help to make the game better.
What went right
Time and resource management. I was the only one on the team able to dedicate a whole 72 hours to this game. But we were able to plan and work around this to use the team members whenever they were available. And I still managed to get a total of 18 hours of sleep over the weekend, so overall a win.
Visual Style. I’m a programmer, but I ended up doing all the 3d modelling on this one since I was the only one on the team with any experience doing it. I’m happy with how the game looks, even if it is very simplistic.
AI. This was really my first time writing a proper AI for the player to work against. I learned a lot from the process, but I think the key part the the AI for Frenzy Inc is how they behave when not in combat. You can actually just stand around and watch the AI for a while and see how they behave, and I spent a fair amount of dev time doing just that.
Small level. When you limit time, you have to limit some aspect of your game. We decided (reluctantly) that the best thing to cut back on here is size of the level. Having a smaller level enabled us to do a much higher level of detail on the level we did have, and devote more time to other features.
What went wrong
Lack of warm-up. My team is largely used to working within pre-existing frameworks, so we spent a fair amount of the first 12 hours spinning our wheels trying to get back into working in plain Unity. We got there, but if we had spent that time before the jam less time would have been wasted.
Lack of gameplay testing. Because we were all working remotely, putting together all the pieces to make our game feel complete didn’t really happen until the last few hours. This meant we really didn’t know how the game would be played to fix a few things, such as a few strategies which are far too effective, which really isn’t good for a high-score based game.
We’re working on fixing the problems with the game and adding a few features we wished we could have added for the jam for a post-compo version, so if you liked our game stay tuned for that.
You can play Frenzy Inc here: http://ludumdare.com/compo/ludum-dare-32/?action=preview&uid=22124
This edition I’ve had a lot of fun, and I’m proud of the amount of work done, even if the game could use a lot of improvements. My unconventional weapon of choice was words, either to hurt or stun foes.
This time I chose to wake up earlier in the morning in order to earn some more hours than in other jams. As a result (in addition to the obvious: increased time), it helped me come up with a core idea and decide on the technology really soon. The tradeoff was that I chose to do the same on Sunday, although I’d gone to bed awfully late. I’ve paid for that during the week at work, but here comes the weekend again to relax a bit
This helped a lot with development and, to a lesser, more painful, extent, to cutting out features once the “LAST HOURS” bell rang.
Familiarity with the engine
I’m currently using Unity3D at work, so I’m pretty used to it these days for 2D. Visual Studio in its Community Ed. is also an amazing tool for coding, so both programs helped me develop a more or less solid code base quicker than I’d expected.
Improvements on art
I’ve tried to pay more attention to art in terms of colour, character and environment art plus animations, and I think the end result is better than in earlier compos. There’s still a lot of improvement on this area, but feeling that you’re becoming better with time feels immensely rewarding.
Late hour change in setting
The game was born with a sci-fi setting in mind. Rather than a grumpy teacher in a high school, I first had an agent infiltrating a building where the main antagonist, a Blade Runner’s replicant-alike character, was taking hostages with the help of some buggy androids. Her demand was for the Government / Big corporation to completely disable a module that made it possible to entirely shut an AI down with a special word or passphrase.
As for the bugs on the enemy AIs, they made them extremely faulty in the Language Processing modules, thus the “damage” and stun effects taken from the speech-related protagonist skills.
Quite different from the final result, isn’t it? I gave up on the idea while I was drawing the enemy sprites. I realised that I had no clear, consistent art style on how the rooms or characters should look like, so they were coming off as very generic, and the deadline was too close for a complete overhaul. As a consequence, I decided to ditch all this and go with a way simpler plot and theme.
Initially I’d put this in the “what went wrong” section, as in a way it feels a bit like sacrificing the original idea which in my mind was very promising. However, I’ve realised that the high-school setting may be better fitting to the current art style and tone than the original idea, even more so considering that the MacGuffin feature (the “death passphrase”) for the original plot, plus a couple of interesting gameplay features that would have complemented a shocky-but-unoriginal revelation, was never close to reaching implementation stage.
What went wrong
No level progression / design
In LD31 I had defined in paper the basic level layout, and I found that pretty useful back then. Here, however, it was way more vague, which was damaging in terms of scoping, art and a tiny little detail…FUN.
Still more effort on art required
Although the graphics look better IMHO this time than in previous editions that I’ve participated in, they’re still average at best. For example, I should have given some early thoughts to the art style in terms of colours, lighting, drawing style, etc, etc (and this is heavily dependent on having a better defined level design).
And, of course, the game is lacking a lot of animations. I created basic sprite templates for the four walking directions, but only the frontal one is showing up in the submitted entry. Also, there’s no feedback on when characters are using their skills or receiving their effects other than a text that shows up too fast. The “boring speech” skill text effect could help some more polish as well in terms of timing, spacing and so on.
Asset creation time badly scoped
Again, I underestimated the time it would take me to prepare a set of animated characters, plus several backgrounds, plus the HUD/UI (I’m not too concerned with the latter, though, as I can get some functional UI graphics pretty quick, but that’s still larger than 0). This was also a result of not having the general visual style or levels defined beforehand.
Last, my lack of experience using Graphics Gale also contributed to the sluggish pace at the beginning.
Unclear / buggy combat
Some glitches in detection ranges, timing and so on, coupled with the lack of art, made disabling enemies bland, which is an awful mistake when the player’s skills were the core of the game. This, again, took away points from…how was that called? oh, yes…FUN
Having a tutorial (even better, embedding it into the game itself) could have helped, but as always…Time.
Music / audio
4 hours before submission I was close to exhausted and lacked all the menu and game over functionality. Still I decided to get some music in. While I don’t think this is a mistake at all, I devoted too little time to get only some bass and percussion sequence which didn’t even properly loop. Also, I decided to cut on sound effects if I only had time to randomly pick a barely fitting sound on Bfxr.
What I learned
Prepare stubs for basic animations & different visual styles.
Clearer level/goal design: focusing 100% on feature development is all nice when you’re under no time constraints or working with other people. With so little time as 48h it’s probably best to have in mind the whole set of features to have a more iterative development cycle, and this includes having a vision of where the game entities will be, how they’re expected to interact in a basic playthrough and so on.
Art: Practise, practise, practise.
Improvements in tasking have helped especially in the coding area, but I still need to incorporate the remaining fields into the equation. A generic “animations” task card in Trello is worthless if you don’t know if you’re going to need 10 10-frame animations for each character or 4 frames to cover all movement and that’s it.
Don’t fall too much in love with your idea and don’t fear cutting stuff out or even sacrificing things such as the plot if it’ll help you finish your game or have it more fun.
Keep working on some set of useful code toolbox. This time I haven’t had the opportunity to use the libraries I’d prepared to support tile mapping, but I did reuse some tiny progress bar script for the health and eloquence bars. Not much, but…
Expand-O-Ray is my seventh Ludum Dare entry. It really doesn’t feel like two years have passed since I participated in my first Ludum Dare back in April 2013. After doing some experimentation with Stencyl and Unreal Engine for previous jam entries, I decided to fall back on Unity this time. Along with the Playmaker addon, it makes creating a game much simpler under time constraints.
On the Friday of the theme announcement, I met with other developers at the Knoxville TechCo. We had a good crowd, and all of the regulars were there (Mike, Dylan, Jeffry, Jacob, and Ruth Ann) as well as two new comers (sorry, I’m bad at remembering names unless I see them written down). I was sort of expecting the theme to be “Edge of the World”, “Grow”, or “Unconventional Weapon”. We all waited for the theme announcement by monitoring IRC and Twitter, and had a fairly lengthy discussion about the current state of indie games. After the theme announcement, my first idea was to make a game where all of the characters are anthropomorphic weapons, but I think I’ve turned themes into characters too many times now. The next idea that came to me on the drive home was having a gun that could expand and contract objects. I don’t subscribe to the theory that you are supposed to write down your first five ideas and throw them out. My games are almost always based on my first or second idea, and I think they usually turn out well.
Later that night, I started working on the base engine. I used a similar layout to my warmup game, Power Panda, but I had to create everything over again from scratch of course. However, I am glad that I created that warmup game, as I avoided some pitfalls when creating my real entry under time constraints. One trick that I learned while creating the warmup game is to create an empty bullet spawn location object that is parented to the player object, which just holds the location in front of the player where the bullet should be created. If you spawn a bullet at the same location as the player, then it will instantly collide with the player and bad things will happen.
Originally, I had planned for the player to have two guns or rays. One for expanding objects and another for shrinking objects. The player would press a button to switch between the two. This would probably work for a console game, but on the PC I’ve found that players can become easily confused if the game requires using more than the arrow keys and spacebar, even if the controls are displayed on the screen. Using the control key to shoot is really stretching it, so having another key to switch between weapons was out of the question. Therefore, the one projectile can either enlarge or shrink an object. I color coded the enlargeable objects green and the shrinkable objects cyan.
To enlarge an object, I kept a target scale value which is the current scale value plus one. The current scale value is increased at a constant rate until it reaches the target scale. The target scale is clamped so that it will never grow beyond four times the original size. The shrinkable objects use a similar process, except the scale is decreased. One problem with the shrinkable objects is that even if it is scaled down to zero, the player may still not be able to pass since there is an infinitely small box collider still in its place. To resolve this, I added an additional check so that if the scale is zero, then the object is automatically destroyed which completely removes it from the scene. I also considered having an enlarged object slowly retract to it’s original size, since the player could become stuck if an object was enlarged in such a way that it traps the player.
There are a few things that I focused on improving on this entry over my previous ones. I have done voice work for some of my previous games such as Bomb Squad, but the story was always a virtual wall of text that the user had to sit through before starting the game. This time I made a point to have the story unfold while the player is active in the game world. This is a similar approach taken in games such as Bastion, although my narration isn’t as interactive as that game.
It was easy enough to come up with a simple story in Notepad (did anyone catch the references to my alma mater in the story?), but I wanted to display the text along with the speaking voice. I recorded my voice using my Blue Yeti microphone, and lowered the tone and applied a slight echo using Audacity. I also maxed out the treble modifier twice to make it sound like my voice is being played over an intercom system. The narration for the first level was about a minute long, which I split into ten audio clips with Audacity (one clip for every line displayed on the screen). I created a Playmaker FSM state for each line of text, which played the audio clip and set the corresponding GUIText object at the top of the screen. When the level is completed, the last state transitions to the next level’s state dialogue by responding to the broadcasted level complete event. However, a problem arises when the player completes the level before the narration is complete, so the current level’s monologue continues on into the next level, and the next level’s monologue never starts. Therefore, I created a prefab that contains an object with an FSM for the current level’s monologue. When the player completes the level, that prefab is destroyed, and the prefab for the next level’s monologue is created. It actually works very well, and the voice work is perfectly synchronized with the text on the screen. It seems fairly simple, but only a developer can appreciate the difficulties in implementing something like this. I’m hoping to make this code a little more modular, and then include it in my UnityHelper library.
Playmaker FSM for story monologue for first level
Over the past few weeks, I have been working on my modeling skills by creating a Sculptris a Week on the streak.club site. I started by creating helmet and body for my robot creature which looked pretty good. However, I quickly realized that making cylindrical shapes in Sculptris for the arms and legs was not quite as easy. Therefore, I exported my model to OBJ format and imported it into Blender to add the remanding parts, which were the arms, shaft, and wheels. I think I did my best texture mapping so far for this character. One improvement was learning that I can do a “project from view” in Blender to create the texture map layout, which is imported into Gimp to do the texture drawing. On previous models, I would define seams for the entire model, which is very time consuming and never gives a very good layout anyway. Sure, with the “project from view” technique there is a little stretching on the sides of the model, but I usually don’t put much detail into the sides anyway. Plus, with the extensive time savings, I think it is well worth the trade-off.
For this game, I used my XmlReader script again that I created for my Oiram game and also publicly available in my UnityHelper package that I previously mentioned. It makes creating the level layout very easy by reading the XML level output from a Tiled map. The only catch is that you’ve got to rename your TMX file to TXT and place it in a folder in your Unity project called “Resources”, and then link the text resource to the appropriate TextAsset public object in the Unity inspector. The XmlReader script must be placed on a GameObject (I use an empty one) before it can be called with the “Call Method” action in Playmaker. The XmlReader script defines a GetLevel method, which takes an int as a parameter which is the level number. The script then automatically instantiates the assigned prefab objects in the scene based on the layout defined in the XML generated by Tiled. I also created a LevelManager object, which contains the FSM which handles the loading, clearing, and switching between levels. The level number is kept as an Int variable in the LevelManager FSM.
Moving the character is done by simply storing the Horizontal axis input variable, and then setting the velocity of the player object in the X world direction to the input (-1 to 1) multiplied by a speed constant. Jumping is accomplished in another FSM which waits for input from the “Jump” button (spacebar by default) and then applies a vertical world force to the player object. Another FSM on the player handles playing all of the animations, which were created by modifying the Blender armature using the Dope Sheet and Action Editor. After importing the model into Unity, I used the Legacy setting on the model rig again, since it’s the only way I know how to get animations from Blender to work correctly in Unity. When the absolute value of the player’s horizontal velocity is greater than a specified value, then the running animation is played. Otherwise the standing animation is played. If the absolute value of the player’s vertical velocity is greater than zero, then the jump animation is played. The standing and running animations are looped, but the jumping animation is not. The only problem is that the jump animation played twice, since the vertical velocity is zero at the apex of the jump. Therefore, I had to modify the FSM to only leave the jump animation state once the player has collided with a block. In case anyone didn’t notice, I payed homage to Mega Man and Johnny Number Five in the jump animation. (Yeah, I know nobody under the age of 30 has ever seen the movie Short Circuit). Another rigging issue was that the wheels rotate halfway, but never make a complete rotation. I only set three keyframes in the running animation, which are start (1st frame), mid (15th frame), and end (30th frame), and the start and end frame are the same pose to make looping seamless. When posing the armature, you can only set the rotation of the bone, but it is up to the animation engine to determine the direction to rotate to get to that position. This problem could be resolved in a future update by adding additional keyframes in the animation, which sets the wheel bone at four positions instead of the current two positions, which would force the animation engine to rotate the bone in a complete turn.
Johnny Number Five is Alive!
One problem that I wasn’t able to resolve is that if the player holds down a movement key while jumping, then the player will cling to the wall. That is normal in some games such as the original Ninja Gaiden, but I didn’t intend on having it work that way for this game. It could be resolved by setting the velocity to zero if the player is jumping and collides into a block, and disallow horizontal input until the player has touched the ground.
On the afternoon of the first day, I took my MacBook Pro to the local Chick-Fil-A and composed the music for the game using GarageBand. I set a basic rhythm using some synth instruments and added a beat using the drum kits. The main melody alternates between two instruments. For the title screen theme, I just took the first few measures, dropped the beat, and cut the tempo in about half.
For the sound effects, I used BFXR again using the basic jump and shoot generators. For the expand object sound effect, I used a powerup sound. When I first added the expand sound, the sound finished much sooner than the time that it took for the object to finish the expansion process (one second). Therefore, I imported the expand sound into Audacity to lengthen the sound effect to match the same amount of time that it takes for the object to fully expand. The shrink sound is the same sound effect, just with the “Reverse” modifier applied in Audacity.
The level design was created completely in Tiled, which basically creates a 2D 14×200 array. I liked keeping the player’s movement restricted to the XY plane to give it the feel of a classic platformer. There are four objects which are the ordinary block which make up the bulk of the level, the expanding blocks, the shrinking blocks, and the exit. I created six levels for the game, which take about a minute or less to complete each. When the player touches the exit object, then the LevelManager transitions to the next level by deleting all of the prefabs, resets the player’s location, increments the level number, and then loads the next level from the XML definition for the room. The first level is an introduction to the game, which only requires the player to jump to reach the exit. The next level is the introduction to expanding objects, which requires the player to expand two blocks to reach the exit. The third level introduces shrinking blocks, so the player has to shrink a few blocks to reach the exit. The remaining levels contain a mixture of expanding and shrinking blocks. The level design isn’t perfect, and it’s probably the one thing that I should have spent a little more time developing. The old school platforming NES games like Metroid are an example of great level design, because those games seemed to always know exactly how high to make a platform to keep it out of reach until the player has performed the correct task to proceed.
Level design using Tiled
The one planned task that I wasn’t able to complete was adding the gun model. I actually made a decent looking gun in Blender and texture mapped it. The problem is that the gun mesh was a separate object, so I could not attach it to the arm bone so that it follows the arm when animated. I could have merged the gun mesh with the robot mesh, but then I would have had to texture map the entire model again, which didn’t seem like it was worth the effort. I’ve saved the gun mesh in a separate Blender file, so I’m hoping to eventually learn how to apply more than one mesh object to a Blender armature. If I can figure out how to do that, then I could add multiple guns with different mesh structures, which can be switched by the player by enabling and disabling each of the gun meshes. I also had a shoot animation, but I didn’t get it added in the player animation FSM, as it didn’t transition back to the correct animation after the shoot animation completed.
Left on the cutting room floor
Before the deadline, I added a few special effects to make my game look a little better. The projectile had a tail renderer which looked okay, but I added a green point light to the projectile which really made the projectile stand out against the environment. Originally, the Exit prefab was just a cube, so I made a cylinder in Blender and texture mapped it with a texture that I created in Gimp by adding some random RGB noise and applying the Pixelate blur effect. Then I created a layer mask and added a vertical linear transparent gradient. This makes the cylinder look more transparent at the top and opaque at the bottom. Then in Playmaker I added a simple continuous rotate action, which rotates 180 degrees in a second. I also added a red point light near the top of the exit area. Finally, I added a small particle system which simulates a puff of smoke whenever the player jumps. This was achieved by setting the emission shape to circle, rotating it so that it is flat on the XZ plane, and making sure that prewarm is selected.
Another big time saver was creating shortcuts to my project directory in Blender and Gimp. In past games it seems like I would spend a considerable amount of time just navigating the directory tree just to get to my project folder. I also got in the practice of saving my models, textures, and sound assets directly to the appropriate folder in the project directory. Again, in the past I would waste valuable time saving to a “raw” folder, and then importing the assets by dragging them into Unity. That was a redundant step which definitely got tiresome after doing it for each and every asset. I also wrote a Ruby script which copies my Tiled TMX file to the Resources directory and renames it to TXT, as required by the Unity TextAsset. It is important to keep the original TMX in case changes to the level design need to be made later.
If I decide to develop this game further, there are a few things that I believe I can do to make it into a full retail game. First, I would need to develop more levels. I could add additional obstacles and traps such as spikes, so that the player would have to enlarge objects to make a bridge over them. Shooting would feel better if the player could aim the gun in any direction, instead of just left and right. I would have a variety of objects that could be expanded and shrunk instead of just cubes. I could make some gravity puzzles so that the player has to shrink a block to let objects fall to complete a puzzle. Enemies would also make the game more exciting, but I would want to come up with interesting ways of defeating them, instead of just shrinking them with the shrink ray. I also thought about having the blocks expand and shrink in different directions to make platforms, instead of just expanding on all three planes. It would also be interesting to have moving platforms. New guns could be added to the game with different functions such as freezing time. If I felt really ambitious, I could connect all of the rooms together and turn it into a Metroid-vania style game.
I’ve got to give a big thanks to Splazer Productions and Juipter Hadley for taking the time to do playthrough videos for many of my games. I would definitely recommend subscribing to both of their YouTube channels. Plus, they don’t resort to profanity, cursing, or potty humor in their videos in an attempt to sound cool like other game casters.
I don’t think my game will do very well in the ratings, since it isn’t a 2D platformer using pixel art and pixelated blood splatters. I really don’t care, because I’m proud that I made something that I think is unique and looks cool. My game will never be on a major console, unless the “powers that be” decide to open up their systems for all developers. However, I think developing this game was a better way to spend a weekend than sitting in front of the television playing a rehashed game from one of the so-called “Triple A” monolithic game development companies.
I just wrote a post-mortem for my LD32 game Beacons (probably the earliest I’ve done a post-mortem and also the first time since I actually wrote one) which you can view on my blog.
Also, for those who haven’t played 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.
This is the first Ludumdare challenge myself and my team-mates have participated in. We are all college students who live and commute together each day and we decided to take a break from our capstone project to compete. ( Shameless Plug, www.rotrgame.com ). Our Game of entry however is Bar Brawler, where you play as an aggravated drunk who has recently thrown the last chair he ever will. We built this game entirely in the weekend and use Unity 5 as our platform (but came to find out the webGL deployment is still a bit buggy) So please enjoy our entry, Bar Brawler, in the unity web player!
Our game made use of the “Unconventional Weapon” category by making nearly every prop, including the enemies!, as weapons.
aahh sweet release! Just uploaded our game this was our first ever games jam, what a trip! dreasic sleep deprivation, starvation and savage arguments, all to make a thing shoot another thing! we’d do it all over again in a heartbeat though!
We had more in mind for our game but got snagged on a few of the mechanics and lost way too much time… but we’re please with what we have, and I’m relatively sure it all works!