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
Howdy friends, it’s @TheWzzard, and it’s Post-Mortem time. My entry is for the Jam and I did it solo, handling all the code, sound effects, music, and a bit of sprite editing / recoloring!
First let me say I was very nervous going into the Jam.
This was my first Jam of any kind.
This was basically my third game ever.
I didn’t do any warm-up which wouldn’t have been a huge problem but…
The game project I’ve been working on for the past 6 months only takes input from IRC, is AI driven, and has procedural levels, so no physics, no direct input, and no level design.
I also decided beforehand that I did not want to make a game that revolved around violence, thinking my entry could stand out since FIGHTING STUFF is what many (most?) games are about. So when the theme was announced my heart sank. Weapon! Anything but that! How was I going to make a game that didn’t involve violence while keeping the theme?
Nothing came to me immediately but I knew that there was a lot of work ahead of me. I needed music, sound effects, input, an engine, and some kind of interface. So I started with the music and the rest hopefully would become apparent. I didn’t actually know what my gameplay would be like until Saturday!
Overall my experience was AWESOME! Such a rush!
What is High Fiverer?
The final product ended up a combo-chaining game where the player high fives lonely skeletons to make friends. It is fast, colorful, and challenging, with 13 levels and a very short combo timer. The weapon? Friendship also high fives! As you make friends they go and do some high fiving of their own, possibly making new friends who might also go and make some friends and so on and so on! Basically it’s high fives all the way down. For Friendship!
You can check out High Fiverer: The High Fivening here!
Breakdown of the work (from what I can remember)
Friday – Most of the music and basic top-down engine, still not certain what the gameplay would be. At this point I had a character that could move in four directions and throw candy at skeletons to turn them into people. I definitely knew that making friends was going to be a part of the design but I still had no idea how it would actually work.
Saturday – Riding my bike home from my Saturday morning class I decided to try to make the high-fiving game I had joked about months ago. The original idea for that game was more of an Arkham style combo thing, but with my somewhat functional top-down engine I felt I could make some kind of combo chaining game. The rest of the day was spent dealing with implementing that and adding mouse controls. Basic menus and a several levels were put together as well. I believe Saturday is when I made the high five visual effect that I am so proud of.
Sunday – Tweaking levels, final music track, SFX, sound implementation, making more levels, and engine tweaks.
Monday – Tweaking everything basically. Lots of great changes to collision, motion, and visuals were done on Monday, along with lots of work on levels and menus.
Started with music – This gave me time to let the theme sink in and it meant that I could try to make all the other elements fit the music. This helped immensely for building my confidence and getting the ideas flowing.
sfxr is awesome – I could have made sound effects in Ableton Live but it would have taken way longer!
Confused about the deadline – Due to my horrible time-math skills I thought I had until Sunday evening to finish until I checked the website on Sunday afternoon. This actually helped because I had something I could have submitted that night but the “extra” time let me polish almost every element of the game.
Made a positive game – There is enough negativity floating around, High Fiverer is meant to be challenging but also super positive at the same time, and I feel that the overall design accomplishes that goal. No one is killed, shamed, injured, or put down!
Used existing artwork from opengameart – While I was hammering out the details of the gameplay I looked to the characters / tile-set to inspire me. This saved me time also but it had a drawback as well (see below).
Visual feedback – Not only did adding a lot of feedback through simple shapes help me understand the timings and ranges I was tweaking, I found that they really helped make the game pop!
Simple input – I went back and forth between mouse and keyboard input during the first 30 hours or so and eventually found that using mouse input would be simpler to implement and require way less time to tweak, which freed up more time for adding a third music track and adding more visual feedback.
Room-centric approach and inheritance – GameMaker: Studio is the only development environment I’ve used for games and for this project I finally found the correct balance between using global variables and relying on room_restart() to simplify repeating stages. I also streamlined my menu building / tweaking process by leveraging inheritance as much as possible.
Easing – This is my first attempt at using easing for anything and I almost started crying when I got the big-hands-converging-into-the-high-five-effect working.
Streaming – I streamed almost all of my work on twitch and I had a handful of viewers that really helped me stay sane!
The ‘Less Good’
Physics and collision – Since I couldn’t decide how input was going to work, the engine didn’t get iterated as much as I would have liked and with some better implementation the motion could actually be more exciting.
Using existing artwork – Yes this was on The Good list too but I spent a lot of time polishing the look of the game but had to opt out of the Graphics category. The visuals definitely make the game more fun but I still wish I had made everything myself.
Level design – Since I was tweaking how the movement and chaining worked until the very end, the levels are not as polished as I would have liked, though I am happy that the number of levels (13!) is far more than previous games I’ve made.
Friend movement – The movement of the friends needed another iteration or two.
Limited mechanics – This ties in with level design. I would have liked there to be more elements in the levels to change up the gameplay.
View shifts – The changes in view have come a long way but some players have found them jarring.
The ‘Needs to Be Better Next Time’
Weak onboarding – I tried to make the instructions as clear as possible but I ended up needing to post more info on my submission to clarify. Perhaps more text or numeric info during the game could have helped but I felt that I already had so much stuff on the screen.
Too much compiling – For my next project I need to implement a way to change variables while the game is running to reduce the amount of time I spend changing something and re-compiling only to change it again. This ate up a lot of time even for a very small game. An in-engine level editor would have been very helpful also.
A little bit more detail about the Music
Since I’ve received some very positive feedback on the music so I’m going to describe my setup, my process, and approach a little. Listen along if you like on soundcloud: High Fiverer OST
First off my music composition / production setup included:
Ableton Live 9 Suite w/ Ableton Push
I cannot recommend this software enough for composition and production, such a workhorse
Ableton Push is a hardware controller (pictured below) that streamlines Live MIDI workflow to the MAX
Ableton Session Drums (These sound great and have lots of detail!)
My go-to kit for these tracks was British Vintage
I always run these through a multi-band compressor to make them pop
Sampled instruments from the Live Suite
Electric bass and electric guitar are sample sets that come with Live Suite!
Same with the marimba on Keep Fiving
A few custom soft-synth patches
All synth tones are made with Ableton Operator which is excellent for FM and simple waveforms
These patches all have controls mapped to the Push for easy tweaking
A few commercial effects plugins, many Live effects and some free VST effects
I used NI Replika for all delay processing like on the guitars
All amp modeling and compression is done with Live effects
Master channel processing uses TLs Maximizer, Stardust, SPICE, and CrossMix
Almost all of the individual voices were played using the Push as input, with only a small amount of sequencing on the Push, and some arranging and editing in Live’s Arrangement View. I find that is easier to smooth out transitions between sections in Arrangement View with a mouse and keyboard. I cannot recommend Push enough for speeding up workflow if you already play your parts on a MIDI keyboard. Going from sketch to finished piece can be stupid fast and I made sure to take full advantage of adjusting clip lengths using the device which I often use the mouse and keyboard for.
I employed a hybrid production style with rock ensemble instruments (electric guitar, bass, drum-set) alongside FM / simple waveform synthesizers. My first instrument is drum set so I really like having sampled acoustic drum sets on my tracks. Sequencing and playing them is a little trickier if you don’t want them to sound like loops or samples so having a robust sample set and using lots of variations in velocities and patterns is important.
Game music poses some unique challenges especially in a jam setting. My total running time for my three tracks is 5:25 and 2:28 of that is the menu / final screen music. This means that the remaining two tracks are going to loop a lot considering that some levels may take 20+ attempts. I consciously used uneven section lengths and high contrast between sections to try to lessen the fatigue of repeated listening. Removing internal repetition also helps along with trying to have distinct lengths for individual sections. Structural repetition can almost be worse than having a short total length. 4 bars + 4 bars + 4 bars + 4bars gets old really fast! Our minds are great at recognizing patterns so it’s much less boring if the overall structure takes a few listens to internalize.
Don’t forget that poor implementation can still ruin your finely crafted minute long loop! If events in the game aren’t tied to the music, avoid restarting it whenever possible, especially if players are going to be restarting levels or changing screens frequently. If the levels are very short don’t change / restart the music every level.
If you want to check out more of my work I have more game music available on my soundcloud and even some OGA licensed tracks that you can use (for example if your LD32 entry has no music), and I am available to do commissioned work. Thanks for reading! Stay positive!
This Ludum Dare #32 was the first one I made an entry for. You would think I would show my creativity and innovative spirit by making something incredibly original and new and stuff… Nope ! Made a Tetris clone instead .
Why would I even do that ?
I strongly believe that there is much to learn in cloning games. See how people made their game, what makes it good (and worthy of your cloning), what are its flaws, and of course how can you make it your game and how could you make it better. Of course this really is worth doing on games you already appreciate rather than on ones you don’t like. If you think they’re good, how awesome would it be if you could make them even better ?
Besides, I’ve been wanting to try and make a Tetris clone for some time now.
When I first saw the Ludum Dare #32’s theme ‘unconventional weapon’, I had no idea of what I was going to do. Being in my bed at that moment since I had just woken up I lied there thinking. Ideas of shooters came first but I couldn’t get something unconventional enough. I figured out the good idea wouldn’t be found by just looking directly around the theme. So I thought about the things I wanted to do. The Tetris clone thing came up. How about a Tetris-powered weapon ? That’s unconventional right ?
Behold the TETRATOR !
Quick note #1 : PRETTY COLORZ
The color-changing that makes the game look so charming is the first thing I set up. That was an old idea I had when playing around with writing text (that’s more exciting than you think). Basically I had a color-changing text with a grey shadow homemade effect and I thought it would look cool if a whole game was exactly like that.
Basically, what I did is drawing everything in white on a black background first, then use it as a stencil for what you actually see, drawing the grey shadow first and then the colored thing with magic secret mathematical formulas for the colors. And that’s being done each frame.
Making a Tetris game !
Here is what you should know about making a Tetris game :
- It takes probably more time than you think. I hoped it would take maybe slightly more than 4 hours. It took me the whole first day along with the color thing.
- Each tetramino shape should have its own block style with a different symbol. Just makes it feel way more polished.
- Tracking the blocks that are already in the Tetris board with a boolean table is the right idea.
- You’ll have to manage collisions for each tetramino shape, in each rotated state, for both the tetramino’s fall, moving the tetramino left and right and rotating the tetramino left and right. It’s not very complicated but it is boring and it takes a lot of time.
- Deleting lines probably may prove to be extremely buggy while it is being coded. That slowed me down a bit.
- A good scoring system is also needed. In ‘authentic’ Tetris games the score goes up for almost anything and getting thousands of points isn’t that hard. I did simplify it though, because the ‘authentic’ Tetris score system is quite complicated and I didn’t want to dive into that. When a piece is laid down you get 5 points. If you pressed up to lay the piece down instantly you get 95 more points. When you complete lines you get [the nomber of line]²*500 points.
- The difficulty curve should be worked on. I made the mistake of not spending enough time on that as I did it in the very end. Almost every one who played the game said it was getting too hard too early. Which I understand as the tetraminos going too fast, too early.
- Be prepared for the fact that everyone already played Tetris. People will compare your Tetris game to the one they already played. They will say how they are ‘already’ bad at Tetris if they are. They will say controls are weird, however you put these, simply because most Tetris games have different controls. Several comments were speaking of how the up key should rotate the tetramino and the down key should do what the up key does (which is finish the tetramino’s fall). I set the controls I was used to because I felt like they were comfortable. I guess the best thing about that would have been to make the controls rebindable but that would have taken time and it doesn’t sound very exciting to do…
When I woke up the second day, I was all pumped up, ready to make an awesome game out of my Tetris game. I got to my PC which is just by a big plate-glass window that has no shutter. I never used that PC that early before. The sun was hitting the screen directly from outside the window which it usually doesn’t. I couldn’t see a thing on my screen. Made an opaque curtain out of clothes and even had fun while doing it.
Making an ‘original’ game out of my Tetris game !
I already had the idea of enemies coming from the left of the screen and that would make you lose if they get to the right of the screen. So I started with that.
Every second, a ‘pixy’ (that’s how I called them in the code, before I see them as invaders) is created. The new pixy is randomly either a normal, a normal bis, a small or a big one. Small ones go faster, big ones go slower but take two missiles to kill and the difference between the two normals is purely graphic. Even so, the speed of each invader is slightly random and is set higher at higher levels.
I do recommend to have several graphical versions of your default enemy because that adds diversity to the game and that leads directly to that ‘polished game’ feeling.
I also do recommend to have the slightest random factors for the same reason. Random can be very frustrating but none of it sets very strict boundaries to your game. So make sure you have the right amount !
Also, the pixies jump. In fact they jump quite a lot. They jump way more than I first thought they would. But that’s actually really good. Each frame, every not-big pixy has a chance to jump if it is not already doing so. And it looks great. Lively and unsuspectedly cute. That jumping is something I wanted because of this.
maths and physics !
Then, I implemented the cannon and the missiles. And I had no idea how to do it. I wanted a parabolic trajectory for the missiles but that was going to require some thinking. So I took half an hour to figure it out on paper with what I know about physics and maths. Then, I had a genius idea : take the squared function (which is already parabolic) and reverse-and-stretch it to make the missiles’ trajectories. It worked great. Way better than I thought it would.
Explosions ! That was important. If you don’t get why, go take a look at this talk from master JW. Each explosion is actually a one-frame colored circle followed by a one-frame black circle which you can’t really see in this game, with a sound effect that has much bass to it.
Also, on the same line of thought, screenshake ! Not detailing that but it is incredibly important !
Finally, after managing some kind of hitbox system, I needed to let the player lose. So I created another sprite for the turret, coded a bigger explosion, made the tetramino’s fall instant, wrote a big YOU LOST and there you go !
Then I built the text interface elements : counters around the Tetris game and then the main menu of the game. For both, I tried several layouts before choosing one and I believe everyone should do the same because interface is more important than what most of jammers seem to think, the problem being that we know what the game does but the player only has the clues we give him. So give it to him nicely !
Safer than the iCloud !
And at the very end, while I was thinking of uploading the game, I felt like something was missing. The top of the screen was awfully empty. Sure, a missile came there from time to time but that was it. Added procedurally generated clouds. Like a boss.
Quick note #3 : Music…?
One of the big advantages of making a retro styled game is that you can make shitty art and call it retro-styled without being too much questioned on your tastes :3. I ‘made’ all sound effects with the mighty SFXR and two music loops with FL Studio, one that is very bare (but existant) for the main menu and another, rather more complete, for the actual game. My only regret is that I set the music too loud.
So that was nice !
In the end, TETRATOR came up really nice. I was able to take the time and deal with each problem that presented itself which is good. I scoped really well what I wanted to do and I am very glad about that. And above all that, the game is actually fun to play !!
Looks pretty nice, doesn’t it ?
I’ll be there again for the next Ludum Dare !
Have fun playing all the wonderful games that have been made for Ludum Dare #32 !
I was pretty happy with my entry for LD32, so I figured I’d write up a more formal postmortem this time; partially because it might be interesting, and partially because I’ve learned a ton from this compo and want to get my thoughts down. So, without further ado, here’s what worked and didn’t work in Savior: On the Advantages of Unconventional Weaponry in Combating the Zombie Apocalypse.
How It Started
I’m not the best programmer and am somewhere between average and solid when it comes to art, so for jams like this one I like to try to come up with a kind of clever gameplay idea that can be interwoven with story (in fact, I just finished my senior thesis on this very subject at university). I think games can be very effective when story and play go hand in hand, informing each other, and I like to play around with that on a small scale for Ludum Dare.
I’ve been sitting on an idea for a game where you play as a scientist curing zombies for quite some time, but never figured out the mechanics of how it would work. With this theme, “an unconventional weapon,” I first wanted to make a sniper-style game where you take pictures instead of shoot people, but I realized I wasn’t familiar enough with the coding I would need to do to make it work. I decided a few hours in to give the idea of saving zombies a go, using a zombie curing serum as a “weapon” that actually helps the zombies. It quickly became a stealth action platformer, and then I was off to the races.
How It Changed
My original idea was to do a somber, gritty zombie story. I was going to rotoscope animations in Flash so that my characters would look realistic and the animations would be fully fleshed out. As soon as I finished my first walk cycle it became clear that this wouldn’t be feasible within the time frame; I can animate fast, but not THAT fast, and I’m new to Unity’s animation system anyways. So I took a long break and struggled to come up with a new art style.
The result was this guy: a sort of bean like thing who I grew attached to over to course of the compo.
Some animations in sprite-sheet form for the Player Character
The thing is, this guy looks silly. You can’t tell a gritty zombie story with a bean as your protagonist. So the goals mutated. I started playing up the humor, adding the bloody messages and dopey signs to the backgrounds of levels and trying to entertain myself as I drew. If I could make myself chuckle, maybe I could make other people. I took a lot of inspiration from games like Portal and tried not to take anything I did too seriously. The result, from feedback, seems to have been pretty good!
Stuck with a blank white wall in your level? Write a dumb joke! In blood!
(spoilers after the break — play it now if you don’t want the shocking ending ruined!)
I made a game about speed running and using your weapon for mobility. You can play it here!
I’m not a jam veteran but I have a decent number under my belt and there are a few lessons I’ve learned the hard way. These aren’t cold hard facts, just things that have worked for me. This is for people trying to make a complete game. If you are just looking to explore and experiment then the list doesn’t necessarily apply.
Don’t save title screens and menus for last: This is probably the least exciting part of your game development process which is why it’s so important to get it out of the way. It’s the first impression players get of your game. If you rush at the last minute you’ll be so uninterested that you’ll probably just throw something together. Also menus you can add some extra value to your game.
With Crump Rush I took advantage of menus to display your best time along side my best time for each level. It’s a small detail but it added replayability and gave your score some meaning.
Add polish early: A lot of people are going to disagree with me on this one. The common procedure is program your mechanics in with programmer art and then add the polish at the end. There’s a problem with this. A lot of times you’re not really sure how fun a game is until you’ve added those extra touches. Especially the visual and audio feedback for the actions you want to encourage or discourage. For the people that think the graphics and audio have nothing to do with making a game fun watch this. If you want to know more about game feel I highly recommend this book.
I kept using Flashpunk to develop, and I’m warming up to it. I’m not a good programmer by any definition, but the more I use Flashpunk, the less flailing around I do while trying to get the behaviors I want.
Using ASEPrite more since last LD definitely helped. The goal now is to learn all of the important hotkeys before next time. Micro-optimization and all that.
What Went Wrong
I’m awful at budgeting my time. Like, terrible. I’ll spend too long on something, trying to get it exactly right and everything else suffers. Don’t know what to do about this. Maybe start using a timer system or something?
Related to the last point, I need to set priorities better. I spent a lot of time working on getting dialog to work, and getting the music mixed right, and I ended up shirking the gameplay and level design… oops. Maybe next time I’ll write out a list of things to do, in order of importance?
Okay, this one’s not fair, but there was a huge thunderstorm that kept me from working for a few hours. That must be where everything went wrong! So remember: all the issues you spot in my game, if it wasn’t for that thunderstorm, it’d be perfect…
This is my second completed LD, and even though it was stressful and hectic it’s still hella fun. Hope to be here for another!
This edition was a lot of fun! For the first time we participated with a concept artist in the team and it was really helpful. We are really happy with the amount of work done even though the game isn’t as polished as we wanted it to be. We decided that our unconventional weapon should be light. Now, it’s time to think about what went right, and what went wrong.
Our game is about a guy named Edward, who narrates the whole adventure. He wakes up on a strange island after a night of heavy drinking only to find himself abandoned by his friends. He must find the way off the island, but it won’t be an easy task, because there are strange glowing spheres hunting him. What are they? Where did they come from? Will Edward escape the island? Play the game to find out!
Concept of the game’s map
What went right?
Idea – The concept of a game where the narrator guides you through the story and you fight enemies using light turned out even better than we expected.
Voice Acting – Thanks to Elijah Lucian we have an amazing voice acting in our game. It sets the mood perfectly and ensures that the player will have a wonderful experience.
Art – The game is looking very nice, considering it was made in less than 72 hours!
Screenshot from gameplay
What went wrong?
Fighting – Enemies are very hard to kill at the beginning, but when the player learns how to fight they are too easy to kill and can be dealt with by only one flare.
Size of the game – The game takes up a lot of disk space. But the problem is, we don’t know why. Packaged game takes up twice as much space as the project and that’s a really weird behaviour.
To sum it all up, the game needs more time spent on the design side and a little more work on the performance. We think it’s a very interesting concept and if we would go forward with it the game could turn out pretty great. We’re considering the post-compo version, but we’ll make the decision after the voting ends. Now we just want to gather feedback.
This is amazing. the flair and style is insane, whilst the theme is a lil weak (it’s still unconventional, so that’s fine by me) the rest of this is absolutely amazing in terms of presentation and style. One of my favourites so far. Incredible stuff for 48 hours. -Neonlare
Well done! Just well done!
I could never even begin to possibly dream of making something like this.
Very challenging on trying to focus on where everything’s coming from, where I’m supposed to go. A mini-map might help that.
Love the feel of movement so much! Great job maximizing a beautiful art style with minimalist shapes also! This game makes me want to move on to 3D more than any other this LD -01010111
In less than a week of submission, my third Ludum Dare entry, Star Driller Ultra has 76 votes. This is easily the most popular entry I’ve put up, compared to the 2 weeks it took for The Sentient Cube to get 100 votes, and the entire 3 weeks to get 60 votes for Laundry Day. Clearly, a lot of people liked the game, with the comment section on the site being largely positive. But I have a major confession to make about the game: I hate it. Here’s the post-mortem to Star Driller Ultra:
What is Star Driller Ultra
Star Driller Ultra is a Star Fox inspired space combat game where you play as a neon-colored drill. The entire game revolves around defeating enemy ships by drilling into them using limited fuel supplies.
The idea was born from an one-hour long brainstorming session where I written down 61 short game descriptions. The one that caught my interest the most was this one:
Game about ramming into things. Think, Star Fox.
There was a video of an obscure Playstation 2 game I had in mind when planning on this game. You would always be moving towards an enemy ship, and the majority of the gameplay revolves around dodging bullet formations. Only when you’re close enough to the enemy would you have the chance to attack, via a drill.
What went right
Early prototype identified several problems
By noon on the second day of development, I had a prototype ready to test the idea. This prototype only had a cube to represent the player’s ship, and a few static enemy spheres that shoot bullets. This product helped find some problems I needed to resolve:
The camera needs to be facing towards your target
The player’s ship will always block the view to the enemy ship
It’s going to be difficult to put together tight controls in a short amount of time
This makes it difficult to put together elaborate bullet formations, due to the ship’s reaction to the player controls
The Unity standard shader makes the game too dark to see
Enemies had terrible aim, which heavily reduced the thrills
Identifying issues this early allowed me to quickly plan on a solution to each of them.
A practical and consistent graphics
One of the first issues I’ve tackled was the player’s ship always obscures the view to the enemy ship. Ultimately, I had one of the three options to choose from:
Make the ship transparent
Make the ship exceptionally small
Make the ship a wireframe
Naturally, I chose the wireframe, as it felt like it was something most other games didn’t do. From there, I’ve experimented with Blender’s Wireframe modifier and put together a very thin ship.
After that, I dropped an unlit color shader on the ship to make sure it was always visible, even if the screen dark.
Once that was done, the rest came pretty easily: the enemies needed to be clearly visible, so I stuck with the earlier wireframe method and simply made the outlines thicker.
While I initially used unlit color shaders on enemies as well, I quickly found out that it made it harder to tell the shape and distance the player was from the enemy. Instead, I used a toon shader that provided a distinct bright color that, at the same time, made the sillouhette of the enemies clear and easy to distinguish.
Lastly, to put a nice bow to the whole package, I applied a bloom image effect, lots of trailer renderers, and star particles to fill the negative space. The result was the most easily praised feature of the game: gorgeous graphics.
Lots of enemy types
Star Driller Ultra actually features a lot of different kind of enemies: the Asteroids that replenish health; stationary enemies Turret I, X, V, and M; and moving Chasers I, X, and V. I’m personally impressed with the amount of enemies I was able to put together, especially the heatseekers and the beam types (V and M respectively), in such a short amount of time. Granted, I feel like there should have been more enemy types, since bullet formations was supposed to be a major draw in the game, but it still worked out to a cohesive experience.
Thanks to years of honing this skill, adding juice to the game came very easily for me. In this simple game’s case, I only needed the following actions to have a form of juice:
Destroying an enemy
Low health warning
This amounted to some simple feedback for each aspect of the game. For a few examples, flying only needed an obvious animation on the direction the ship was facing, which I later accented with trails on all of its four back corners. Drilling uses motion blurs which, combined with the ship’s trails, spinning animation, and rainbow-colored nose particles, lead to a really hypnotic graphic. Destroying an enemy was a bit more involved: jack up the bloom intensity, and pause for a fraction of a second to let the bright lights suck you in. Lastly, add a lot of big, bright particle effect and a low growling sound to depict explosion. Knowing about these common juice techniques such as pauses, sound effects, and particles helped me polish the game at a super-rapid pace.
Proper food and sleep
I was able to balance food and sleep pretty well in my schedule. Well, that’s not much
What could have been better
Boring core mechanic
The intended flow for Star Driller Ultra was as follows:
Since working with 3D space in a space shooter is complicated enough as it is, I tried to simplify the idea by having the player always focus on one enemy only while the fight was going on in the surrounding. This means that I needed to make the locking into the enemy and dodging bullets part as fun as possible, as they take up the majority of the time in the diagram above.
I think I failed on both accounts.
The order that you lock into a desired enemy is, from the player’s perspective, completely arbitrary. Basically, all I do is aggregate a list of all enemies, then sort them by distance from the player when the scene initially loads. The list never gets re-sorted in real-time. This has a few advantages, such as allowing the designer to control which enemy the player will lock into next, but it’s disadvantages are enormous: it makes the player feel less in control.
For dodging bullets, I had a two-fold problem: I struggled to offer tight controls for the player ship without causing it to fly off or dive right into the enemy, and I couldn’t get the enemies to be better at their aim. Given these two problems, I was forced to take one of two terrible decisions:
Make the enemy bullets bigger
Allow shooting a lot of bullets
I ultimately chose the latter, thinking it was the lesser of the two evil. Regardless of whether I was right or not, neither would have made the dodging bullets part more engaging as fixing the player controls and having better enemy aims would have.
Disguised as a space combat simulator
It kinda seems like all you do is wait until you approach the target, then hold the drill button…of course, if you run out of fuel, you’re completely screwed. I don’t know, it’s got great graphics, I just didn’t find it that engaging…
So without good lock-on system and a fun dodging mechanic, what is Star Driller Ultra, really? For a good long while, I was trying my hardest to turn the game into the space combat simulator I initially envisioned. However, as the deadline loomed, I took the defeat and polished on what I thought the game did succeed on: a resource management game where you need to handle the health and fuel meter. The health would be limited in number: you can only recover health by destroying asteroids, which needs to be locked on (a cumbersome process) from the first place. Fuel is necessary to drill, and while it deplete quickly, it also regenerates quickly as well. Additionally, drilling makes your ship invulnerable, negating the need to dodge bullets if you have enough fuel. For both, I simply put together stages that I thought balanced these aspects well enough.
Ultimately, though, I feel like I robbed the player’s expectation. As much as I tried hard to make Star Driller Ultra into an action-packed space combat simulator, I just couldn’t within the 48-hour time frame.
Poor difficulty curve
With only several hours left to put the game up, I hardly spent any time working on smoothing the game’s difficulty curve. So when it came to stage design, I relied on a simple: introduce something new in each level to keep the player engaged.
I introduce different enemy types so quickly, players had a hard time catching up to even the most basic tasks, such as controls. I could have been a lot less rushed and spent a bit of time reducing the difficulty of the game.
Prioritizing on content over playability
On the second day, there was a comment from a playtester indicating that the game was hard to navigate, and a radar would have helped. Weighing on whether I should add more enemies or work on the radar system, I ultimately chose to add more enemies and levels. At the time, I thought the radar was going to take too much time to implement. Looking back, I think I greatly over-estimated the effort to add more content, and should have focused on putting together the radar first instead. Generally speaking, I favor usability over content, but this was a bizarre moment where I simply didn’t think a radar would be that high of a priority.
What will I do next
I chalk Star Driller Ultra as a pretty big mistake and a learning experience. While my ability to create juicy and visually attracting games are better than ever, I found this entry to be a bit enlightening in the fact that I still have a long way to go in deciphering what game mechanics leads to which experience. You can’t polish turd, and if the mechanic is broken, so will the rest of the game. I also think I clung to the the space combat simulator idea too much, when I could have abandoned it and made Unconventional Stick Swinging Simulator instead, or something more experimental.
Still, I’m hardly deterred. I’ve had an incredible streak with #OneGameAMonth, with such wonderful games like Suddenly, Thousands and Ichabot Crane. If anything, I think Star Driller Ultra helps me be a little more humble with a realization that I still have a lot to learn. I could use a bit of humility every once in a while.
In any case, I’ll probably continue the experimental route that I’ve worked hard on. I’ll continue to throw spaghetti on the wall, but I have one more data point this time to make the spaghetti more sticky.
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.
Soo… I failed this time, and that’s setting my record as 2:1:1 ( Finished : Failed : Not participating). Here’s the online prototype I’ve done (you can only read intro and walk around), below you can read my why I failed.
MathDream was supposed to be a short platformer in which you encounter evil numbers! Your goal would be luring numbers on subtraction mines or throwing addition to clear them, and pick up delicious candies! But… for now you can only read short intro and move around a cloud.
Maybe one day I’ll actually finish prototype.
What actually went wrong:
Ok so… I must admit one thing at first, and I’m somewhat ashamed of myself: I didn’t participated in this Ludum Dare to actually make a game, but to enjoy myself and try to rediscover my programming motivation. So… what went wrong?
I wasn’t interested in doing MVP as much as I was in playing with parts of Phaser I haven’t used yet. You could even say that – at some point – my goal was to simply create timed introduction.
I got over-confident, I mean Phaser is great and allows you to make simple platformer in less than 200 lines of code, so I convinced myself that I could finish MVP in a few hours and let myself to spend WAY too much time on small tweaks like intro timer (at one point I changed values by 10 miliseconds), or re-colouring font. It wasn’t even playing with phaser!
On the last day of compo I went to my friend house (check his great game, I made small cameo apperance there!) and I had to work on my laptop that haven’t been used for months. So I wasted around half of an hour on setting up workspace only to realise that I forgot to take laptop charger so I had to return home for it…
Sometimes I get scared for no reason. When it came to draw that little fella from prototype I found myself thinking “I can’t do this properly, I’m bad at drawing” and it took me about 30 minutes to stop worring and actually start drawing…
Lately I’m too easily distracted by my ex-friend, when I took a walk and encountered her I felt discouraged to continue my work, and ended up wandering aimlessly for nearly 6 hours, and then staring at empty screen for another few…
I failed to check the rules, and as I remembered there was proposal to make compo as long as jam, but with 48h deadline (so you can start day after and still work for 48h) I was certain I still had at least 24h left, so I go to the pub… after all it would be acceptable to work next day if at the first I worked for literally two hours, right? I was stupid.
All in all I spend about 9 hours on Ludum Dare jam mostly doing small unnecessary things.
What I learned:
FINISH MVP FIRST, even if you know it’ll only take a few hours – then enjoy extra time for little tweaks… never ever do the other way only because “finishing MVP won’t take that long”!
Keep your priorities in check, otherwise you’ll find yourself spending more time on intro, than actual gameplay
I actually get a grip on github pages system for project sites (see details on gh-pages),
a lot about phaser state manager and timers,
I draw my first animation!
Keeping laptop enviroment up to date is really helpfull, and if you move while taking part in compo better check twice if you have everything before leaving your house
ALWAYS check compo start and finish time…
A LOT about myself and I think I know how to deal with discouragement and fear more effectively (no more wandering alone to 3 A.M!), maybe someday I’ll share those little tricks at my devblog, but first I want to share some thoughts about phaser state manager.
I hope you’ll all learn from my failure.
Good luck, Guys!
Ludum Dare 32 is over and I survived lol There’s something demented about voluntarily participating in what’s basically “crunch mode” for no reason other than to make something cool but I’m glad I did it. Here’s my post-mortem on how things went and my general design process. First up this is the final result of my 72 hours of slaving away in GameMaker: Studio and Spine:
LDJAM’s topic is announced once the event begins and this jam’s topic was “An Unconventional Weapon”. I decided the 72 hour jam was more my speed over the 48 hour competition because I don’t really care about winning or anything, this is more for me to get my creative mojo kickstarted and possibly come up with a prototype I could turn into a full game down the road so that extra 24 hours to throw in some decent art was too hard to resist. The time limit in general adds a huge doom clock hanging over your head but I know a solid concept is half the battle…there’s no point spending all weekend working on something that wasn’t a good idea to begin with and it’s hard to force creativity so I decided to give myself 2 hours with no pressure to concept ideas up. Even if I came up with a decent idea right off the bat I would keep roughing ideas out till the time was up, so if I couldn’t think of something right away I didn’t freak out since I had a full 2 hours to kill.
I had 3 main goals for Ludum Dare:
1) I wanted one good core mechanic. I’m thinking in iPhone game terms instead of making an epic RPG or something. I wanted an idea that I could theoretically clean up and ship as a simple casual game.
2) I wanted something flashy with a lot of Spine animation because I wanted to really put my GameMaker + Spine workflow to the test since I’ll be using that combo for basically anything I make.
3) I wanted to avoid menus and text because I find doing that stuff in GameMaker is a whole project in itself. It means writing scripts that display and activate buttons and draw and transition menus and lay out text areas, and there’s nothing that easily sets up scrolling menu lists etc. If I made a text/menu heavy game I would spend at least half the 72 hours just trying to get those looking good and working nice. So I wanted as little GUI coding as possible.
These always seem so much smaller when you're working on them
Let’s break it down stage by stage. I started by throwing down any words or ideas vaguely related to the topic:
It's like a word-assosciation improv class for nerds.
Looking back on this list I can actually think of a few cool ideas based off it, so as far as I’m concerned just doing this exercise alone was beneficial. Who knows, some of these concepts might make it into games I make down the road.
I started out with a pretty safe idea…I was going to try some clever meaningful artsy deep outside-the-box take on it. I watched some Let’s Plays of Life is Strange recently so I think I was just in that slow-paced mindset:
Most of these are half-thoughts that made sense in the moment but now I have no idea what they mean lol
It was actually a solid game idea. It would be similar to a Diner Dash game where you micromanage a group which is already a proven mechanic. You’re a villian working as a teacher to distract a class from passing their exams to prevent anyone from being smart enough to thwart your plans down the road. It wouldn’t be too art-heavy either, I would just need to draw a classroom for a background and I could set up a sweet camera angle and hand-draw the characters so it looks like a shot out of an anime:
No idea what anime this is from
It was something I knew I could pull off in 72 hours and fit the theme but it was boring lol And it would either be text/menu heavy or I would have to come up with some icon system that made sense and it would just be a lot of GUI coding. My buddy Derek was like “what? no defending your hot dog stand from ninjas by throwing hot dogs at them?” and I realized that my idea wasn’t really something I would have fun making. A big part of why I’m making my own games is to make whatever I want and I’m a simple guy: I like flashy action and explosions lol
TOSS IT OUT
So I scrapped that idea, threw on a bunch of Sakuga anime compilations (basically the most fast-paced over-the-top action scenes from anime), blasted some high-energy Megaman music and wrote out a bunch of words related to the theme but more action oriented:
ahhhh, this is more like it!
I liked the ideas of “killing enemies gives you a new thing to use”, “merging body parts from enemies to self”, and “stacking effects”. The most natural idea that ame to me would be killing enemies and taking their body parts to attach to yourself, stacking the effects of whatever it is you’re taking from them. Robots/mechs made the most sense because it’s logical that you could replace a robots body parts with other body parts so the concept would be clear from the start. I’m terrible at drawing/designing mechs (I’m more into medieval stuff) so I went with a robot chick as a main character, plus I loved the whole idea of Astroboy as a kid. So I started fleshing that out:
Approximately 3 weapons off this list actually made it into the game lol
I had no idea how much I could do in 72 hours so I put down anything I could think of to help me visualize how things would work. When I got enough down to have a solid idea in my mind I revised it again into something more final to follow:
In theory you could mind-map an entire game out down to every function/script and variable needed.
In this stage I try to group things together and think about what I can re-use code-wise. So I’ll jot down a list of weapons and then break them down into “projectile” and think about what attributes projectiles are going to need to do all of the behaviors I’ve listed. A pistol bullet, machine gun and shotgun blast are all just variations of firing rate, ammo per shot and spread angle. This is actually the part about game design that I enjoy the most, I like breaking big ideas down into smaller efficient chunks. This helps me visualize how a lot of the code will work too. I’m still an amateur programmer and can get lost in my code easily without a good clear overview of what I’ll need.
I really wanted to have her legs switch out for legs that can jump, jump really high, and float/hover in the air, but I knew I should start with her arms and save the legs for if there’s time.
TESTING THE TECH
First up was making a rough Spine file to see 1) if I could get Spine files loading/animating in Game Maker properly and 2) if I could get Bone coordinates off a Spine Skeleton and attach new Skeletons to them that would follow their motion. This was the major tech hurdle for this game idea so I knew if I tackled it first the rest would be smooth sailing and if I couldn’t figure it out I’d have time to switch to a new idea.
First rough idea for a character. Short hair like this would've been way easier to animate but I like a challenge
Fortunately that went silky smooth and I got it working without many problems. So I revamped the character with plans to do her hair and skirt with FFD-animation in Spine. One of the nice things about using Spine is that I can lay out a character and animate her and get her in-game, then go back later and rig up her features for more detailed animation (hair, skirt, facial expressions, adding shading to the art, etc.) and know it’s not going to break anything:
I tend to use 0-length bones so I can attach different angles for bodyparts to them but I regret that on this character, using longer bones would've made animating a lot easier.
In the end I only had time to do her bangs and I used really rough FFD placement so you can see her hair bend with sharp corners in places but the gameplay would be fast-paced enough for no one to notice…or care, because I only had 72 hours lol I had to keep reminding myself that things were “good enough for 72 hours”, no one is expecting to see some AAA product in 72 hours the fact that I had a character animating at ALL was great:
I animated some basic motion and threw her into the game to make sure everything was working and to learn how to do collison. I messed around with Bone compensation (so in Spine I could move her backwards as she dashes back and control the distance/momentum in Spine with her x/y info updating to match in code…this is something I’d want for doing a huge boss that stomps his feet as he walks and pauses with each stomp VS moving at a constant rate of speed), and I managed to pull off a while back when I was doing tests but had way too many problems getting it to work now so I gave up and stuck to animating in code. I’m using TweenGMS to set up tweening and I was able to get a good enough result that way, but I’ll definitely revisit Bone compensation in the future.
The next test was making sure I could turn off the Image Slots and spawn new Skeletons (gibs, weapons flying out of hands, etc.) at specific Bone positions, and, well:
In retrospect this probably makes me look pretty demented lol
No probs there lol The head is a separate bone. I also set it up so that “gibs” could be guns, bones, etc. and spring out at various speeds/angles etc. I’m pretty new to parent/child heirarchy stuff in code but it worked out just like I hoped. The code for this game in general is some of my best, I wish I could rewrite my main project from scratch to make it more like this but I guess you just have to accept that no project will be flawless all the way through. Definitely looking forward to starting my next game after my main project so I can write a bunch of fresh new clean organized code from scratch.
Next up was replacing her arm with a gun and figuring out how to do a nice chain of command up the guns. Each gun has a child gun that attaches to it’s attachment slot and receives commands from its parent. There’s a LOT of potential in this setup, I can have each type of gun animate in a different way and have different attachment slot positions and different length/speed animations for shooting. Originally I was just going to have one gun with a few attachment slots for other guns, but I wanted to test out optimizing my Spine code. On my main project I’m working on I tried implementing Spine but I didn’t really know what I was doing and I was getting a lot of lag with just a few Skeletons. So for this project I wanted to try optimizing things since I had a nice clean empty project to start from where nothing would break.
I did a bunch of digging through the tutorials and trying different things out and the end result was fantastic. I was stacking guns on top of eachother because that was the easiest way to test and at first the game would lag by 30 Skeletons, which really isn’t very much. When I originally tried Spine out I envisioned doing all the art for my games in it, like down to menu animations and bullet effects but no way that’s possible with 30 Skeletons so in my main project I was already planning to use Spine as little as possible.
But after optimizing I had *700* guns attached to eachother with no lag lol:
It's like a giant french-fry of death.
The sight of it made me laugh and I decided to leave the huge stack of guns while I tried to get them to shoot and once I got the entire stack shooting (with a delay too so you can see it flow up the stack one by one) I decided it would be cool to let the Player actually stack like this instead of what I was originally planning. I set up some different guns and timings and the whole thing felt absurd but made me smile so I just kept going with it. But the guns quickly go off the top of the screen so I looked for tutorials on doing zooming cameras that can zoom out to keep two objects in the view at all times and found a great one. I set it up to use the player and the top of their gun stack as the zoom targets so the higher you stack the guns the further out the camera zooms. As far as I know there’s no maximum limit, you can stack till the game crashes lol
Spaghetti missiles, explosions, robots and anime chicks...if there's more to life I can't imagine what it is.
I got cocky and decided to try spaghetti missiles that would home in on targets and leave particle smoke trails…really it would’ve been a more complete game if I had focused on the gameplay at this point instead. I had a lot of ideas for stuff like enhancements you could get that would add fire/electricity/etc. effects to your weapons, which would add a little strategy to the collecting aspect. Or even better, have it detect when you have X number of guns of the same type stacked in a row, so if you stack 3 pistols they glow and fire larger deadlier shot. That would create a mini-game within the game where you would be picking and choosing which guns you wanted to catch, having to make snap judgements as the guns fly up kind of like Tetris. Another idea was to have negative guns that you can accidentally collect, which would be in your stack and fire with the rest of the guns but would do stuff like fire a missile that homes in on you so each time you shoot you also have to dodge a missile from your own gun as a penalty for grabbing that negative gun. I planned to have a huge boss that the camera would have to zoom way out for, like you’d need a big stack of guns to defeat him etc. but ran out of time. Because of all those ideas I think there’s something here that could be expanded on into an interesting game, but I don’t know if I see enough depth in the game to keep going with it.
Anyway so from here I had to grab some music from incompetech.com and whip up sound effects in Bxfr. I threw in some random pitch changing so most of the sound effects will sound slightly different each time you hear them to avoid being too monotonous. The background I left till the last minute and whipped up some quick terrible buildings in Blender and had tons of problems trying to get a scrolling background working right so you’ll see lots of glitches in that but I got it working literally at 8:59pm one minute before the deadline lol It’s glitchy but hey, 72 hours cut me some slack.
Also a bit earlier I spent some time balancing things for the Player. I’m big on not wanting to bog the player down with tutorials, I like when games naturally teach the Player to play. So there are little nuances for ease of playability since most people won’t do more than play for a couple minutes. If you have no weapons you won’t be able to get a missile launcher as your first weapon because the delay on it makes it too difficult to use as a first weapon, you’ll get overpowered too easily unless you really know what you’re doing and even then it’s almost impossible to make a comeback, so I didn’t want the Player to deal with that frustration. You won’t see the robot guys until you have 3 guns attached so you have more of a chance to beat them, and they won’t start attacking you back or changing what height they fly in on until you have a solid stack of like 10 guns. So the game should have a nice easing curve for people to play without a lot of frustration. I love adding these little details to help guide the player into being able to handle the full experience.
I was also originally going to have the Player’s stack build a lot slower, like they just get one gun per enemy but because of a bug the robot enemies were able to get stuck in a “being hit” loop where they would keep spawning out a weapon every time they got hit but as you got more weapons you would hit them more times spawning more weapons which made you hit them more etc. and it became a huge bonanza of guns being tossed in the air like Oprah handing out schools and hump-backed whales. When I fixed the bug I decided to leave the insane gun bonanza in because it added to the absurdity and I figured people would only ever play the game a few times for a couple minutes and then move on so I wanted them to have a memorable little experience in that short window of time.
After watching some people play it, if I was doing this over I would add something that checks how many times the Player dies and if they die 2 or 3 times without collecting many guns, have it spawn a few less enemies to give the Player an easier chance. For a full game the difficulty curve would have to be tweaked a ton but for something like Ludum Dare where people are only going to spend a couple minutes with the game I should have made sure everyone would be able to get to where they stack a bunch of guns and experience the fun part of it.
I’m proud of the end result. I accomplished my goals going into this and with the energy I have these days now that I’ve got my Vitamin D levels handled I was able to power through the whole weekend working non-stop except for sleep and food. The time pressure was fun, it forced me to make fast decisions and throw out things that weren’t working while also plowing forward on ideas that I suspected would work…no time for waffling or second-guessing which can be a big hurdle for gameDevs on longer projects, feature creep and rewriting stuff that doesn’t need to be rewritten etc.
A MOMENT TO GUSH ABOUT GAMEMAKER + SPINE
GameMaker and Spine were AMAZING together. The workflow is so efficient that I was smiling ear to ear as I worked. It takes like 5 clicks to go from animating in Spine to seeing that animation running in-game exactly like I saw it in Spine. For people just getting into gameDev now where this kind of workflow is more common, this might not seem like that big a deal but man, in the old days I would have to do individual frames by hand and then write up text files with a list of coordinates and timings and image names to try to describe to a programmer how the animation should look and then just cross my fingers that they would come up with something that looked in some way sort of like the vision I had for it, which of course it rarely did. It was like dropping your child off at school and picking him up later and he’s all disfigured lol With proper optimization and memory management for Spine files in GameMaker I feel like I can literally make ANYTHING 2d. If I had the time and artistic skill I could practically duplicate Rayman Origins and Ori and the Blind Forest with this combo. If anything doing Ludum Dare and working under a time limit gave me even more of an appreciation for the tools I have access to. I WISH I had these kinds of tools and workflow back when I was a teenager. So if you’re in your teens or early 20s and you’re getting into gameDev consider yourself extremely lucky, you’ve got a huge head start compared to when I was that age.
I’ll be participating in Ludum Dare again in the future, this was all win/win for me. But for now it’s back to my main project. My Ludum Dare game has actually made me more excited to get cracking on this thing. I’ve been avoiding the art side of it because of the laggy Spine issues I was having in GameMaker but now that I understand the optimization stuff I’m looking forward to dumping a ton of sweet art in there. I’m planning full-screen bosses and can’t wait to get crackin’ on them. The menu system is pretty much done, I just have some last tests and cleanup to do with it but then I should be able to get into the fun art stuff. I’ve got the bosses planned out in my head and rough doodles, I just need to refine them into actual designs and start dropping them in the game.
All in all this has been an excellent start to the year. I’m hoping to keep this pace up the rest of the year and participate in Ludum Dare regularly, but one thing at a time…first I gotta’ finish my main project and ship the damn thing lol Follow along at bulletproofoutlaws.com and on Twitter at @BPOutlaws
Recently I’ve been playing a lot of Startopia and utterly loving it. As such even before the theme voting started I was positive about working on a management simulation. There were many acceptable themes on the last batch; Grow, Adapt to survive, Harvest, Indirect Control; but alas they were not to be. I went to sleep a bit worried, but after waking up (mere 2 hours later!) I had the plan more or less down. Take Big Pharma, but rather than creating beneficial drugs, this lab would churn out harmful viruses.
Code, eat, sleep, code, eat, sleep, code, time’s up!
Nothing out of ordinary there. Slept less than in prior jams, but I really didn’t have time to catch any more Zs.
Never worked on a management simulation before and to make it even harder I decided to do it the proper, efficient way. Rather than having all entities in a list which would get iterated though every AI update step, they are stored in temporary lists based on their current purpose. Seems simple enough, except coding while sleepy is a surefire way to miss a few of those, now crucial, list manipulations. Forget even one of them at any state change and soon resources are permanently stuck to the floor and the droids fail to update their tasks.
In the initial release that happened a lot. Now after a few days, all the bugs have been squished (as far as I know!).
Future and beyond:
The PostJam version is on the works. First I’ll implement some interface improvements and missing features I had no time to do. After that, time will tell. There are only so many projects I can work on at a time, but this feels like a keeper.
All previous Ludum Dares that I’ve tried to participate in have failed miserably. For the first one I had no experience. For the second I had very little time. For the third I had no good idea.
For this one I had a good plan that I followed through with, and I managed my time well. I didn’t try to make anything more than I was planning on from the beginning.
Due to my inexperience with exporting Java programs, I didn’t manage to export the game with the sound library, so the submitted version has no audio. This is however something that I’ve “solved” afterwards using somewhat of a workaround.
When I saw the theme I immediately came up with this idea (I don’t really know why). This was probably the first Ludum Dare I’ve entered where I actually liked the theme, and also came up with the concept even before starting to program.
The idea was to not only use an unconventional weapon, but also to use it in an unconventional way; I didn’t just want to make a normal shoot-em-up game and just switch the gun textures for a banana or something. I actually wanted to use the weapon as more than just a weapon. So I used it as both a health system, and as a level-puzzle-thingy.
In the beginning I planned to actually have enemies in the game, but I didn’t manage to add that in time, so I settled for making a puzzle platformer (although a later version of the game probably will include some simple enemies). So I guess I failed in making it a “weapon”, but rather a tool.
I quickly knew that I wanted to use the limbs as a health system, because it added a lot of possibillities regarding level design. I also came up with the idea of only being able to interact with levers if you have arms to further support level design.
In earlier projects I’ve saved all levels using a png file, but it has its limitations. And since the fun part about Ludum Dare is to always learn or try something new, I decided to use Tiled as level editor and implement methods that read json files. Which made level designing a whole lot more fun to do.
I’ve decided to work on this project a bit more, but I want to finish it in a couple of weeks.
Some updates/changes that I plan on making (and have done) are as follows:
– Make sound work (done)- Add a new type of lever, further enhancing level design (done)
– Add falling damage (done) as a comical effect, and also to enhance level design
– Make some new bigger, more difficult, and more thought out levels (done)
– Add some sort of enemy
– Add some sort of trap block
– Add particle effects
– Add usable items (maybe)
– Add more decorations
– Add more cowbell
– Add sound effects
– Add pressure plates (works without arms, obviously)
– Fix the bad platform physics (done)
– Remix the music (I made it in a very lazy way)
– Add fullscreen mode
ps. Some alternate titles I thought about using were “ARMageddon” and “Man at Arms”. Sadly I think that “Limbo” has already been taken…
I had tons of fun this Ludum Dare, more so than previous ones.
The reason for this is because I had the ability to make everything in 3D this time, as opposed to being stuck with Pixel Art because I didn’t have the 3D software I know and love.
Guess I’ll do a quick good/bad thing now.
I did everything in 3D, this resulted in nice graphics and was, for me personally as I was taught 3D art in school, a much faster and easier process than if I’d done stuff in 2D/Pixel Arted.
I had the initial idea fairly quickly, just build a third person game and then throw unconventional weapons into it, this changed quickly into something more marshmallow focused when I decided to change the setting to an “in the woods” type deal and my dad suggested marshmallows. Thanks dad! (In previous Ludum Dares I had always wasted the first day trying to come with something good, not this time!)
Using Vertex coloring instead of textures saved me a lot of hassle. Totally gonna stick with this again next time!
Everything went so well I even had time to put in a small boss fight!
Performance wasn’t the best for some people and the game started stuttering after a while on lower-end machines or on the web player, this was mainly due to the large amount of objects I was spawning as you throw things and zombies spawn. (The zombie spawning vending machines initially didn’t have a spawn limit!) Aside from performance being low after a while, it started off as pretty terrible on Android, my reasonably high-end Nexus 5 couldn’t even run the game at 60fps! So next time I’ll try and minimize the amount of skinned meshes too I think.
The camera was called “Horrible” multiple times. This is mainly because I was trying to go for a sort of Super Mario 64-type camera, but I realize a lot of people didn’t like that camera either, and in that game you still had SOME degree of control over it, I should’ve added something that gave you some level of control instead of just automating it all the way through. It does have controls on it but I for some reason chose to only let those work on an Xbox 360 controller.
The sounds weren’t that great. They were cobbled together in the last hour or so I worked on it, I should make more time for proper audio next time.
The (art) process
This was the first Ludum Dare I did in 3D, I’ve made countless 3D prototypes and games in the past, just never for LD or public release of some kind (yet).
It started off pretty simple, I needed a character so I made a basic character
I just posted a summary of the whole event on my development blog and but wanted to post my conclusion here as well.
Having a somewhat finished framework ready to go really help a lot in the development since I could immediately jump in and didn’t have to bother with a lot of the boilerplate code. I really hope to get this small framework a bit expanded so things will end up even easier and less hack-ish to code, because while writing a framework you can take your time to design things properly, I did not have that time during the Compo which ended up in a lot of code repetition.
While nobody will watch someone code or sit around for hours on end, I still like to stream stuff, because it kind of forces me to keep working on it and not start some video game or randomly browse the internet. In addition to that it gives some nice conversations from time to time and you feel less as a solo developer. I just hope to get a better solution for the webcam, since I feel webcams make streams a lot more interesting.
It took a lot of time, but in the end it was really nice to have something finished and ready to be voted on.