Posts Tagged ‘postmortem’
For the past couple of months, I’ve been working during my spare time on a project for the Stemfuse Got Game Competition. This competition is specifically for middle and high school Game Maker games. The RTS genre has always intrigued me, and I was very motivated after seeing the 7dayRTS challenge, so I figured a low stakes competition was a good opportunity to try to make my own. With some help from my friends for graphics and music, I finally finished the game, 1800. 1800 is a historically based minimalist RTS that takes place during the Napoleonic Wars and War of 1812.
Anyway, now for some thoughts on the project. First of all, RTSs are hard. Very hard. I was constantly attempting to optimize the game, while throwing on new features to add to the “strategy” aspect. I had a fairly decent vision of the project from the start, but it definitely evolved as I worked on it. The main pitfalls I fell into were not knowing what I was doing, resulting in some highly questionable design choices at the beginning, creating an AI that wasn’t terrible, and reducing lag. Unfortunately I waited until the end to add the AI, and that caused some problems. First of all, it was much harder than I had expected. I really had no clue how to do it and began piecing it together as I went along. Additionally, the AI made the game start to lag immensely as large amounts of units were on the map at a time. This is an issue I never really fixed, but instead tried to minimize in the level design. The original plan was to have 5 countries actively moving units as well as multiple others that were neutral. I maintained this original vision for the most part in the free play mode, along with the warning that it will lag on most computers. For the campaign mode, the American campaign being the only one I actually made, I removed all of the unnecessary countries. This reduced the lag significantly at the beginning of the game, but after playing for a couple of minutes the lag still gets pretty overwhelming.
Overall, I think the game ended up being fairly mediocre in terms of actual gameplay. However, I think that this was a great experience for me. I have learned a lot about what to do and what not to do when making an RTS, and would be able to approach things completely differently in the future. That being said, I’m really sick of RTSs right now and can’t imagine making another in the near future . I think had I chosen to to a turn based game instead, it would have saved me a lot of trouble with worrying about the lag, so I’ll keep that in mind for the future.
Now for the part where you can help me. Here‘s a link to my entry in the competition. If you could spare me about 2 clicks to upvote the entry, that would be greatly appreciated. Even if you don’t think the game is very good, I hope you could just take a moment to appreciate the effort that went into making this and support me. Currently the entry leading in the popular vote has over 500 votes, and is a simple and nearly broken maze game with one level. The effort that went into making that is so minimal that its number of votes is mind boggling. My goal is to get at least 100 votes in the competition, and with your help I can do it.
Thanks so much everyone!
Thoughts on this Ludum Dare -
- I’m kinda disappointed, but the results seem fair.
- Best ranking: 50th for humor.
- I didn’t focus on a concept and the theme enough.
- My concept was you have 1 arm but multiple tools, you have to find ways to carry tools without your arm.
- Didn’t have enough time to do that!
- Instead I spent time on other things:
- I wanted to include palette swapping and NPCs.
- I’m happy I included them, but I should’ve focused more on a concept.
- I coded everything from scratch, which made things take longer. I’m happy I did that though.
- I received a lot of nice comments
- Thanks to the 71 people who rated my game!
- If you haven’t played it, check out The Visitor.
Thoughts on previous Ludum Dares -
- My best Entry is Mondrianism, doing well in everything except humor.
- Second best would be my first entry, The Good Ship Higgs Boson.
- Super Space Goat Thief Standoff!! is definitely my worst entry, but I only spent a few hours on that.
- My best category has been different every time, interestingly.
- As you can see, there’s a clear trend of… um… well…
See you next Ludum Dare!
I feel like I learned a lot from my experience this past LD. Or at least it’s gotten me to think about things.
One lesson I learned, or at least experienced yet again, is never to undervalue time management and planning for the unexpected. For the first 12 hours I dawdled not doing much at all, then for the next 24 hours spent too much time obsessing over details and putting off important stuff (sounds, music, level design). The last 12 hours were super intense and sloppy, and as a result the game didn’t turn out as good as it could have been, and it was unpleasant working that hard.
After I submitted the game (here and on Newgrounds), I got really discouraged by a few comments providing fair and useful criticism. I obviously knew my game would be nowhere near perfect, but I was being really negative about it. I thought that I shouldn’t have even submitted it, because it was a waste of time for people playing it. I felt ashamed and guilty. Deep down though, a part of me knew that these feelings were irrational, and that I was blowing things out of proportion, but I felt sad anyways.
I spent a week or two pouting and thinking about the situation. Idly browsing tumblr I came across this blog post by Edmund McMillen about growing as an artist. Reading this post kind of brought me back to reality. It’s normal to make mistakes and learn from them, and that’s one of the main reasons that game jams like Ludum Dare exist. I learned a bunch about myself emotionally, which I’m not eloquent enough to write about, but they’re in this general domain. Lots of self-reflection, etc. Hopefully I’ll become a more mature person after this whole ordeal.
I don’t know if any of you guys reading this have had similar experiences, not just in Ludum Dare but anywhere in life, but I guess I’m just documenting my experience. I hope this post might be relevant to someone. Sorry for rambling and awkward wordings (it’s late, and I don’t write very well anyways), and thanks for reading. I might participate in the Mini-LD if I have time, but either way, I’ll definitely be back! Thanks to the staff and the community for creating such a great event.
TL;DR: Ludum Dare taught me that life is a learning experience. The blog post I linked above puts it nicely.
“Ermahgerd! 188th for Humor in #LD28.”
Thank you to everyone who took the time to try my game. I am humbled and glad to have taken part in LD #28.
Only scored low on innovation; which let’s be honest, is no surprise. My main goals were to complete a game and learn from the stats and feedback given, which you have given and I have done and will continue to do. Thank you, truly.
Again, thank you; thank you thank you thank you.
“… And why should I care?”
Good question. Let me tell you a short story to give it to you.
Spark: De Sacrificio is a little project that stemmed from an old ludum dare entry I created for LD27. I was very excited with it back then, and had it all planned in my mind: a puzzle/platformer with exploration components. It felt like a cool thing to play, so I did a smallish implementation for the compo. I wanted to develop a complete game from the small prototype I created back then, but because of a few personal problems and my inability to focus on one thing for more than 48 hours, I dropped it.
It would have been the end of it if I didn’t get a hold of a copy of GameMaker back in November. I was curious to test this platform, and decided to brush some dust off Spark to recreate it in this bright new engine. I was really excited, and got a lot of work done in a short time. It started to look really amazing for what I was expecting. The game felt just as I wanted and it was interesting to play and explore.
But for some reason I felt reluctant to wrap the game up and send it on its journey through the Internet.
It took me a couple of weeks to pin down what was this dark feeling I was having towards releasing this small game. In the meanwhile, development got very slow. Staring at the game, replaying the same parts over and over started to feel painful. I caressed the possibility of leaving it in a drawer and forgetting about it more than once. The reason wasn’t that I didn’t like the project, but that I loved it way too much.
I was scared of what people would say about it. I’m not new about getting feedback on stuff, and I have a thick skin for hrash comments. But the reality is that I had put a lot more of myself in this game than I would have ever expected. It’s no use to have a thick skin if you have your most vulnerable parts of yourself out in the open. Spark isn’t just a game for me but more of a piece of myself I digitalized and put in a form that others can experience and live. As someone who is extremely reserved, this is terrifying: it’s like living an open door on my soul.
I knew that I had to push though it. On December the 30th, Spark: De Sacrificio was finished. I knew it wasn’t perfect, but it didn’t matter: I knew I had to close this loop and go on. So, here it is. Spark.
So, going back to the original question: why should you care about Spark: De Sacrificio?
Because it’s sincere.
I put all my passion and knowledge in this game. It’s not a great game, I know it. But I know it is unique, in its own weird way. As I said, even if you won’t notice, there is a lot of me in it.
Oh, and it’s free. But that was a given. See it as a present to other developers who really love this medium as much as I do.
Thanks for reading these ramblings.
It’s maybe too late but I feel like I’m missing something if I don’t write a post mortem for my first LD entry – Tough. Post mortem is a kind of new term for me when I join this community, hope that I can make it correctly. I will prepare timelapse for my next LD entry too.
Joining this LD was an awesome experience for me. I didn’t like this theme. I think it’s too wide because most games can be explained that they fit the theme. But in the end, I think this theme worked out pretty well. A lot of games did take on this theme with their very innovative ways.
What went well:
- Finished the game in time. It’s the best thing since making this game was a new challenge for me.
- Picked a simple idea and built a game around it: a platformer with unexpected ending. Everything was in a reasonable scope for my first game jam.
- Did follow the theme and made a good twist: You only get one life, but the goal is not to keep it.
- Had a fun first day making the game. Even though I were working on the game until 6am of the next day, I felt no stress.
- Learned the first game framework engine (Phaser). I’m just a web developer and a gamer. This was a very motivative way to help me become a game maker too :).
What went wrong:
- Too much time lost on making assets. But in the end, it’s still completely not as I imagined on my head. I intended to make a Franstenken-like character and some brutal wolves.
- Did not use the remaining time to polish up the game.
- The fun was hidden because of the vague gameplay.
- No sounds or music either.
- Did not pay enough attention to the rules. I were using assets of Phaser framework for some background of the game. I felt really bad about this and replaced them all one week later.
- With the lack of experience with basic game design and game framework usage, I got some troubles with the camera, didn’t know how to use tile map, failed to make an endless map generation and made a lot of hacky things.
- The source code of the game was really bad base on my own standards.
What is next:
I’m satisfied with this game. I hope it will be a good starting point for me. I will stay with this idea and make it a clearer goal and a smaller map. The mechanic will be the simplest one for platformer so I can try to create a same game with a lot of game frameworks quickly. And of course, this game is an open source project.
Since there’s less than a day left until ratings are finished and I haven’t gotten around to doing it yet, I figure I might do a little post-mortem of my LD28 Entry One Jump (not to be confused with a couple of other entries with the same name). This was my 2nd Ludum Dare game but the first submitted for the 48 hour compo.
My primary aim during the weekend was to avoid some of the mistakes I did in my last entry (such as time management) and submit something playable in time for the 48 hour compo. Prior to the competition, I decided I wanted to use Unity (specifically the new 2D tools) for a couple of reasons:
- Familiarity (I’ve used Unity before but not for a Ludum Dare entry) instead of trying to learn a new language/engine in 1/2 weeks
- More widespread deployment: Compared to my last entry (which used XNA), using Unity meant that I could easily deploy my entry to the web as well as create standalone versions in one go.
I also decided that I wanted to create a platformer (mostly because I haven’t made one before and also because I didn’t want to create a top-down game where you move something in 4 directions and shoot stuff). The day before the actual theme was announced, I did jot down a couple of ideas based on some of the themes that made it to the final round of voting (although I didn’t actually have an initial idea for the one that eventually chosen). After the theme was announced however, it took me some time to think of a core mechanic that would fit it (To be honest, I didn’t really like the theme although ironically, due to the primary mechanics, my last Ludum Dare game would have been an absolute perfect fit for it). Eventually, I decided to interpret “You Only Get One” as being able to do something that you can normally do many times only once. In the case of a platformer, the primary mechanic is jumping hence the main objective of my game: To simply reach the exit but being only able to jump once per level (which led to some rather strange and interesting level design)
What went right:
- Planning and Time Management: Compared to my last entry, I actually made much better use of my time thanks to the Unity workflow and managed to submit my entry in time for the competition.
- Levels: A common complaint with my last entry was that there were too few levels (about 4/5). Thanks to Unity, I was able to rapidly prototype levels in the editor without having to recompile and restart the game and created around 8 levels for my entry.
- Mechanics: Initially, I thought that being only able to jump once was too gimmicky (trying to design levels based on that mechanic was pretty hard as well as I wanted to make the player use their only jump at the right moment). In the end however, I was pretty satisfied with the end result.
What went wrong:
- Graphics: I’m not a very good artist so I decided to use simple shapes again for my entry. Unfortunately, I didn’t have enough time to change those shapes into something more plausible (but still somewhat crude).
- Lack of background audio: I initially created a small audio loop for my entry but I wasn’t able to get it to loop properly in Unity.
- General Platformer Physics: Although the game generally worked, some of the primary platforming mechanics were a bit buggy (having to create some momentum in order to jump, unintended wall sticking etc.). Some platforming elements such as the moving platforms didn’t work as much as I had hoped.
Feedback for my game so far has been fairly ok (and better than I had originally anticipated) with level design being praised the most and some platformer physics/controls being the main criticism.
Overall Experience and What I’ll do in the Future:
Compared to my last entry, I didn’t enjoy this one as much as I’d hoped (mainly because of the theme) even though I managed to submit something in time for the compo. I did have a fun time however and if there was anything new that I’ve learnt during that time, it’s that I shouldn’t be afraid of submitting to the jam instead (rather than treat it as a place where I didn’t submit my compo entry in time): if my entry needs one more day of polish then I should take advantage of that extra day. During the period of time before the next dare, I will try to make at least some improvement with my graphics skills (or failing that, just collab with an artist friend for the jam instead).
You Set Us Up The Bomb is chain-reaction style game with lots of explosions. It takes place on a military robot base, and you know what? Robots are dicks. It’s time to bomb their metallic rears back to the industrial age. You only get one bomb, but you get to drop it anywhere, and as luck would have it, pretty much everything on a robot base is darn explosive.
What Went Wrong
Time ran out
Oh, this old chestnut. There’s always a list of what I intended to get in there. I’ve never not run out of time in a jam, it’s just a question of will the game be playable before I finish. Even as an old coder I still have trouble with time management. I’ve never been the fastest coder on the planet, so it’s a wonderful feeling to complete a jam. But complete is relative. My first jam I didn’t even submit it; I had these monks walking around an empty procedurally mapped abbey with nothing to do. Since them I’ve improved my focus and priorities, and also my workflow (see what went right), so games get completed, but damn if I’m not jealous of those people who knock out these home runs with time to spare. I feel like I’m getting better, though, but I have to wonder if jams are like speed chess? In Searching for Bobby Fischer, the chess coach Bruce Pandolfini chastises the student for playing speed chess in the park because it’s teaching him all the wrong things: tactics and intimidation, rather than long term strategy. Will Pandolfini yell at me for learning all the wrong things from jams? I actually took a chess class in college and he was the instructor, but this topic didn’t come up…
Bugs in the base code and libraries
You only get 48 hours, you don’t want to spend any of that time fixing bugs in your base code or third party libraries. I must have spent about 10 hours tracking down numerous issues. None of these issues were the fault of my game code – that’s not to say I didn’t have bugs there, but those bugs resolved themselves rather quickly. First I had to isolate the code in my game, and if that didn’t reveal a bug in my game, I had to test Flaxen, my base code which relies on two other libraries. I found some bugs there that were head scratchers. But worse then I had dig deeper into my dependencies and found several issues in HaxePunk, which I either fixed or made a work around. That’s 10 hours I could have used polishing my game.
Didn’t hit all of my core feature list
Remember I said I had a list of what I intended to get in there but I ran out of time? Well, first, I wanted to have trucks go on patrols between tents, bunkers, and stockpiles, but instead they just wander randomly, which actually makes some of the middle levels a little harder than the early or late levels! I intended to show damage on all objects, and set them on fire if they were going to explode. The robots themselves were supposed to run screaming before exploding, and I wanted their body parts — notably their heads – to fly up toward the camera with some funny quips before landing. I also wanted shrapnel – when something exploded, parts of it could fly randomly a large distance, potentially hitting another object and setting that one off. It’s still playable without these things, but I think the game would be much more exciting with them. Also the game should get harder – each level requires like 65% of all “points” to be exploded to pass to the next level. That number should rise as the levels rise.
What Went Right
Sticking with familiar tools
I think I’ve finally got my process down. Photoshop and Filter Forge for the art. Audacity, a mic, and bfxr covered my sound needs. I would have used Renoise to compose some music had I the time, but with five minutes to spare I sang an improvised song about not having time to create a song and hooked it into the main menu. Hey, you gotta move quick in the last hour! I used Sublime and Haxe 3 for development. Flaxen, the framework I used preciously for LD27 came to use again here, except this time I separated out the code base and put it up on GitHub. Flaxen ties together an entity component system (Ash) with a game library (HaxePunk). It’s actually really fun to start throwing components and systems together.
Focusing on the making it playable first
Several times I stopped myself from going down tangents before the core idea was even playable: polishing art, tweaking sounds, working on higher level code elements. And it’s a good thing, too, because it took me much longer to get the core idea playable than I anticipated. This was the difference between a incomplete but playable game, and a more fleshed out idea that’s not at all playable.
Explosions are furn! Ehrmegerd!
Despite everything that didn’t get implemented, the core explosions and destruction are actually fun to behold when you get a good chain going. The effect turned out pretty well, I think, layering a randomly rotated explosion image (shown at the top), applying a layer of fire particles, and then after a pause a layer of smoke particles over the top. It’s especially fun when you get beyond level 14, where the game starts repeating with the maximum number of objects on the screen. Why are you waiting for the perfectly timed bomb drop? Just drop it already, the game gives you another bomb if you fail to meet the quota, just destroy some shit already, will you???
You can play You Set Us Up The Bomb here.
As before, here’s the link of the game http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=11311
What went right
- The idea of shooting and having to get back your own weapon I had been inspired by the indie game that I watched at the RockLeeSmile channel, called Heavy Bullets, a game that you have a gun with limit shots and have to get them back, because there are just the few you got.
- Next, the “arena idea” was inspired by the game Super Crate Box. To make it different, I made them shot instead of running, and spawn all over the place, instead of just the top.
- The music itself was completely accident, but I hope get more “accident” more often as I get more experience. xD
- Something unexpected, is that people related everything being killed with one hit with the theme. Well, I’m glad it happened!
- The preparation to the jam also work very well! I felt much more secure with the project, so I could work without many worries.
What didn’t went right…
- Had to skip a time that I saved to sleep to be able to do the art. I’m sorry guys, but I don’t think that “don’t sleep” is something to be proud of and I always try to avoid when possible. Makes you do bad decision more often, hard to think and makes bad to your health.
- Somethings are still broken, for example, if two big guys spawn at the top, they will just shot fire to each other and you can ignore them. I planned a change, but at the moment that I am writing this, I didn’t updated yet. As a possible solution, maybe they could get stronger after some time?
- Is not really a miss, but now I start to think that better animated>detailed art, I guess? I don’t regret, I miss do detailed pixel art, but maybe a “artistic freedom” would be welcome.
- DAMN WALK-CYCLES! My main problem with is not even the difficult, but time spend on them. Even with just 2 frames, it barely worked and add more on the updated version was a pain. So, here’s the lesson here, always stylize your walk-cycles or at least, think well if they are really necessary.
What was my evolution till now
So has been a year since I first participated the Ludum Dare and I can’t say anymore that I’m a rookie anymore.
I just noted after the jam, but unexpectedly, Blue Harpoon game ended up very similar to the first game that I submitted, Skydef.
Analyzing all my games up this far I can say:
- I’m more worry if the people will understand my game.
- I’m more focus and calm during the jams.
- My games usually don’t have a explicit narrative, but the characters and the world that the game takes place seems original and has potential of growing up or derivative other game/stories about them. This can be bad actually, it is easier to absorb something that we are familiar with. Also, I still miss be able to develop more the world and characters personalities…
- The games are very unfinished, unpolished and lacks feedbacks. This is another serious issue and even worst, make my games look unprofessional.
- Made 4 games that are “arena-like”, time to think other possibilities of gameplay.
Still not sure how to deal with these things, but sure they are things to look forward.
As a personal achievement, was the entry that I most had work on it. Skipped a day of sleep, rated more games, work harder on the updated version and write more about it.
About the time spend, after jam, I may have my doubts if was really worth the updated version, but on the jam, the work that I had, I have no doubts that was my, or near of my, limit. I don’t see myself don’t sleeping two days in a row, I’m sorry, seems wrong and even dangerous to do it. But I’m also glad that I did, I think I can endure working more time now, in case I need and also I glad with the result, but as I said, if possible, not sure if I want do this again…
After all these games, lessons I can definitely give to rookies about game jams
- Your game will be better if you do it more simple than you think.
- Be smart, focus the core of your game and think well of how you can add the details.
- Think twice about that walk-cycle or fancy animation, it can be very time consuming to do it.
- Reach the main mechanic of the game as soon as possible.
- It is already very tough make a game, make one with very limit time is almost impossible. Be proud of your work.
- Think if the player will understand what was your goal when he’s playing.
- Have fun!
If you haven’t already, please play and rate our game, Match Girl!
This is my 6th Ludum Dare entry, and the 2nd time working as a two-person team with my artist xellaya. Our previous game was a psychadelic side-scrolling rpg about a crazy cat, Hyper Furball.
This time we went in a totally different direction, and created something dark and creepy. Here’s what the game looks like in action:
Like last time, let’s go over what went well and what didn’t.
What went well:
The Game Concept
The concept actually came really easily this time, unlike last time where we had to go through a number of different ideas before finally settling on something. The theme this time (“You Only Get One”) was a good one–pretty open, but also restrictive enough to focus you on something specific. Doing a “you only get one life” game definitely felt like it would be a cop-out here, so we definitely wanted to stay away from using that idea. Like always, we were busy on Friday night, so we didn’t really start to work until Saturday, but I actually had the initial concept of an “only one light source” platformer while trying to get to sleep on Friday.
We’re veterans at this by now, so we don’t really have many kinks in our process. Especially on my side with the coding–I don’t really have to figure many new things out by now because I can just look at my previous projects and I can just copy-paste code as needed. Instantiating new objects, making timers and counters, doing screen flashes, doing the jukebox screen, that’s all easy stuff for me now. And of course, cranking out music is second nature to me now, after doing so many of these. That’s always more of a “break” for me than actual work, to be honest. Working together with xellaya is pretty nice now as well. We definitely don’t think along the same wavelengths, and generally don’t share the same vision for things, so it’s fortunate that we manage to find a way to make things work out. I think we’ve managed to strike a good balance, such that I allow her a good deal of freedom in making artistic decisions, while still pushing back when something could be reworked to better fit the game. I think it’s important to make sure that there’s enough communication about the needs of the game, while not just being super-controlling and nitpicky about everything. In the case of Match Girl, we ended up redesigning the enemy graphics, which initially looked like this:
Which was cute, but not quite what we needed. The redesigned enemy looks like this:
Which is definitely more creepy and obviously harmful. To make it pop out more, I increased the saturation, so in the end we have this:
Initially I had the match as the only light source, and in order to get that working I just took a big fat black texture, painted a transparent circle on it with a gradient, and pasted that onto the screen. Then I got the idea for the candles scattered around the levels and realized that I needed a better solution. I spent a little bit of time going into the rabbit hole trying to work it out with blending modes and getting into FlashPunk’s drawing engine, but then found some dynamic lighting code that someone else had already written up (https://github.com/SHiLLySiT/Lit). I tried it out and it worked! I remember making one or two tweaks to how it worked (probably changing the blend mode), but it ended up working great and I’m really thankful that I found a quick and easy solution. This was really key to making our game work well!
Now, this was actually something I really worried about, because level design is really tricky to get right for a puzzle platformer, especially one that you haven’t carefully tweaked and refined and playtested. I also wasn’t confident whether or not our mechanic would work well enough to make for good design. I knew in my head that the match concept was a good idea, but whether it would actually translate to fun levels was something that I really couldn’t know until I actually sat down and tried it.
During the initial planning/prototyping phase I also thought that it would be nice if we had at least one other mechanic other than the matches and the enemies/obstacles that kill you, so I thought of the moving blocks and implemented those (was still using placeholder graphics for everything at this point). It was later on when I was making the spotlight for the exit door that I thought of the concept of candles/torches that would be pre-placed in the level, and that actually worked really well for level design, since they function in so many ways. Not only do they illuminate tricky areas, but they also serve to give a sense of atmosphere, and they also serve as good reference points while memorizing level layouts. They also work nicely with the moving blocks in some levels. The fake white blocks were the last thing I thought of–the idea for that probably came while I was color-shifting the block textures for the different worlds.
Initially I had single set of 25 levels — 5 for each world. After I had all of the different mechanics nailed down, I knew I wanted each world to introduce something new, except for the last world which would pull everything together. I also knew how I wanted world 1 to flow: Introduce movement and the goal, introduce matches, introduce jumping, and introduce restarting.
So I had my 25 levels, but I realized that some of them were probably too difficult for inexperienced players. So I dumbed down some of the levels, made them easier to memorize and execute, and added more torches. Then I set out making 25 new levels for hard mode, where I tried to really be aggressive with the difficulty. This was the very last thing I did, and I was rushing frantically to design all of hard mode in about an hour or so. I’m really glad that it turned out so well the way that it did. I’d say that I’m a bit lucky that I managed to get such decent level design even though it was squeezed in pretty last-minute.
What went not as well:
Not being in the right mindset
This didn’t end up really hurting us that badly, but I was actually feeling really lackluster and discouraged on Friday night due to just being in a bad mood in general, as evidenced by a post I made that night. Luckily I still managed to come up with the concept while trying to sleep, and ended up shrugging it off and diving in with a good start the next day. I don’t really think there’s much I could have done about this, but it was one of the worrisome things that happened this time around.
Underestimating the amount of work
I should have learned by now, but I guess there really is no such thing as a Ludum Dare that I finish early and don’t spend 100% of my effort on. I keep on trying and telling myself to be less ambitious each time, but somehow I always end up pushing all the way to the deadline, almost without fail. I think that’s a good thing–it’s part of the reason my games have become so polished–but at the same time, I need to prepare for it and expect my entire Monday to be taken up. (and ask for that day off from work in advance)
Story and plot
We kind of slacked on this this time around, but that was sort of a conscious choice, as again we were trying to be less ambitious. I think it was also that we didn’t actually really have any good ideas for plot and storyline that would explain things well. xellaya wanted the ending to be open-ended, and I thought that was fine by me as well. I certainly didn’t have enough time on my hands to do anything more about it anyways. ^^; I don’t think this really hurts our game much, as I feel like it doesn’t -need- a story this time, but it is true that this is something that we missed out on.
This one is a little debatable, actually. I don’t think there’s anything wrong with the music in our game, actually. I think it’s really effective, for the most part, and I’m proud of it as far as soundtracks go. I mean, who doesn’t like a kickin 8-bit fakebit NES-style chiptune soundtrack? We’ve already gotten a bunch of positive feedback on it, and I’d recommend you check it out too.
However, it might not have made the most sense for me to limit myself to 2A03 instrumentation and try to be really pure in terms of using only 2 pulse channels at a time, etc. I think I just happened to be on a 2A03 kick at the time and wanted to do this fakebit style, which is fine, but perhaps it would have been more appropriate to go with a more “9-bit” approach, with darker soundscapes and non-chip sounds in the mix. Who knows–maybe the melodies wouldn’t have turned out nearly as memorable if I had gone that route, but it -is- true that some of the later tunes are a bit “energetic” as opposed to “spooky”, which is probably the one qualm I have about the OST. Really a minor point though, as I’m still really proud of it.
All in all, a really great success for us this time. It doesn’t have the “raw”, unadulterated fun that Hyper Furball did, but it’s a “cleaner”, more solid game, I think. I’m really happy with how it turned out. I’ve only gotten to watch one person play through it, but it was super awesome to see how they handled the different mechanics and got through each level. I hope you guys all enjoy it too
If you didn’t played, please, here is the link http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=11311 /o/
Don’t forget to play comp and the updated version!
Because it got so big, I decided to divide the postmortem, so, let’s get started:
How it was made:
Before the jam
The thing is, work alone is all about time management, how much time you will spend at which task will set how good will be, but in other hand, get more time to certain task makes the other tasks have less time, so, get the equilibrium is the real challenge here.
Before the jam started, I made a graphic to more or less know how to use my time and a list with when I should do what. The goal wasn’t to roughly follow these things, but to just make feel save to switch tasks, because I would know that if I took more one hour at some task, I would have less with some other and not just mindless (which WORKS with some people, just making it clear) do everything I can, until the deadline for example.
Having the planning, I could feel save and wait for the theme came out.
As soon the theme came out, I started thinking in what I could do, so I made a mind map of theme using mindmup.
Mindmaps, working relating everything you can think with the theme, this is very useful to not get stuck with the first idea and speaking of which, I almost did about a guy that would fight for a coin to a cola machine, crazy isn’t?
I abandoned the idea because for the idea work, I would necessary do some cutscenes to the player understand that he’s fighting for the last coin to the cola machine, because the coin itself would not make part at all of the gameplay, so, if I couldn’t make the cutscenes in time, I would be with a confusing game, that I would have to explain with some other way of what is going on, which is not ideal…
In other hand, the idea that I took worked very well, you would have a weapon and would have to throw it AND take it back, because you only have that ONE weapon. It would make it clear why I choose this idea because it would be clear just by playing it, even if I did less things, less art, one enemy, no sound, the core of what I was thinking would be reachable much faster. I think, the ideal thing that you will try to do when making a game, is to reach that “core” as soon as possible. Your game will work without that fancy menu that you thinking, but will not if the player don’t get it what you tried to do.
The idea being set, I started to do…
So, was still the first day, I decided to program a little before go to bed, that because if I had a trouble with it, I could think in a solution before and after the sleep. It is good to do this because you will have a fresh mind about the problems that you had before, also, I didn’t want to sleep very much at the end of that day.
The idea of being a 2D arena was because I wanted to study the new features of the unity. Every jam that I work alone I have a goal of what I want to learn, usually on the fly.
I had some troubles to do the controller and with the 2D layer system of the unity, but, the 2D animation system is wonderful, one of the best I had seen I think.
However, I could not do the program isolated, mostly because of the mecanim system that unity uses, so I started to do the…
Do a pixelart game was because had been a long time that I wasn’t doing and be a demon at some kind of ritual was just because…well, I wanted to do demons. lol
Yeah… I started to get nervous that I wouldn’t be able to make the art of the game…
When I started to make I took references like Frogatto and manly, Savant.
However, it didn’t worked as I planned. For some reason, I think small pixel art character in a big scenario looks wrong and because I didn’t want to lose time making a camera control, I wasn’t even sure if it would work with the gameplay, I didn’t zoomed.
Also, hard to animate. I liked what I achieved but maybe it would be better a simple art but better animated? I don’t know for sure…
Having the art and the programming I hoped to make the…
Music and Sound Effects
This really made me happy. Music and SFXs were always, along with animation, my weak spot. I saved a good amount of time to do this, but really, I didn’t expect to be able to do something.
At day two, last day of comp, first I tried to put a bunch of samples together, but didn’t work. Then I tried again to compose the music, looking tutorials but mostly trying things out and for my big surprise, this time it worked!
Being the first ludum that I was able to compose the music and sfx by myself.
The SFXs were made by using free generators. I’m not completely happy with them, but at least, they are there.
Having everything was time to submit! Yay!
Wow! Are you still here? I will try to do a part 2 as soon as possible, telling what went right and what didn’t.
Thank you so much for reading and for playing!
If you still in 2013 when reading this, good holidays!
Postmortem – You Only Get Juan – Jam Entry
Massive Explosions! Full 7.1 THX Sound Surround! Sexy Characters!
…our LD28 entry didn’t actually contain any of these things, but we still had fun making it. Our team consisted of Ludum Dare newbies (first LD for one member, second LD for the other two) and despite having to work around a couple of christmas parties, our entry turned out pretty good.
Juan Track Mind
Our group of local game devs all met up at a nearby Starbucks just prior to the start of LD48, and from there smaller groups were formed as the theme was announced. While brainstorming concepts related to the theme, @craigpfau came up with the title ‘You Only Get Juan‘ while the mechanics and story by @JackTai_ and myself followed suit.
What Went Right
To make the most of the theme (and not just rely on the ‘Juan’ pun) the game mechanics all revolved around the theme of ‘you only get one’. The game mechanics matched this theme in three ways:
- Juan is the only character that the player is allowed to ‘catch’ for points
- The Juan Direction bus used to get Juan can only move in one direction (to the right)
- You only get one shield charge (used to deflect ‘non-Juans’ away from the bus) per Juan caught
The use of the theme to direct multiple aspects of the game mechanics is something we are quite proud of.
What Went Wrong
Time was a major factor (as with each Ludum Dare I suppose!). However, with everyone having Christmas parties and other social functions that same weekend, time was more limited than ever. Most of the work got done on the Friday night and Monday morning (at least on the programming side). There were some glitches that certainly would have been worked out if the full weekend could have been dedicated to our entry.
Another issue was the use of GameSalad as the engine. While GameSalad made it very easy to prototype the game Friday night, exporting to HTML5 from GameSalad leaves something to be desired. The game had multiple different issues across browsers, specifically sound being intermittent or non-existent, text displaying improperly, and general physics nuisances. In the end the game seemed to work best on Chrome, but unfortunately it still did not quite run as intended.
Another Ludum Dare down and another good time had. Happy New Year Everyone and see you in April.
edit: You can play/rate it here:
This is the first time we participate in a game jam, though we have been following ludum dare for a long time now. After a couple of weeks, it’s time to write a post-mortem about this great experience.
What went wrong:
One thing that made its way into the final game, is a bug where the closest rotation angle for the people to reach an objective was incorrectly calculated. In some scenarios people would make a 358° spin just to face 2° to the left. It seemed to happen only sporadically, but it turned out to be very annoying. (we already fixed this in the post-compo version)
Other point is the player controls. Since movement controls are the only one availables in this game, we wanted to make them not the trivial “move with arrows or ASDW”. We wanted controls that could make you feel uncomfortable, sightly anxious. One movement at a time, you are not in control all the time. I think we got there, but sometimes the controls feel awkward, even frustrating.
We must rework it, and should be the most polished thing since it is central to the gameplay, but we are definitively not adding stuff such as pathfinding or any kind of ai assistance.
Level design / level editor:
In the middle of the development, we faced one of our biggest dilemmas: to build or not to build a level editor. We ended up not building the editor with the only purpose of not getting distracted by stuff that’s not essential.
We left the levels design for the last couple of hours. Time constrains + no editor =
We have one big json file per level, each one containing info about position, collisions, behaviors. Making all the pieces fit together resulted to be very tricky. Position trial and error, and after we got things as we wanted, we had to iterate trying to make it not so frustrating nor boring (no editor, trial and error again).
Result? Levels not properly balanced, and things like the chapter 3, with so many people getting stuck because there is no clue about what should be done next.
What went right:
We used our custom ECS microlibrary (no docs, it’s not finished). Having all the behavior decoupled, allowed us to make big changes really easy, and the code to feel more maintanable and robust.
For example, I can add the “contagionFocus” component to any object, and from there the object will infect near objects, whose once infected will also have the “contagionFocus” component.
The only drawback here might be that performance optimizations are a little bit harder, though for the jam we didn’t need to worry about that too much.
We used webmake to have node-style requires, and jshint for static code analysis. Having everything orchestrated with grunt allowed us to have jshint watch any file changes, and throw an error if any issue was encountered. This reinforced best practices, but also saved us time by anticipating syntax errors or typos.
We were pretty familiar with the workflow / tools / language so it definitively made us go faster.
Rest & food
No crazy stuff. We ate healthy food mostly, and didn’t skip any lunch or dinner. We only had some beers after the first journey right before sleeping. We had a reasonable time of sleep, and that allowed us to make it through the sunday energetically.
We worked really well together. Our thoughts were mostly aligned, and we complemented each other very well in terms of skills.
We are amazed with the quality and the power of the feedback received. Every negative remark was highly constructive.
We feel there is a big room for having fun developing this idea. And a big oportunity for learning and experiencing with some stuff we haven’t done before.
Iterate and polish what we already have: quirks and known bugs(player movement, collisions, AI), redesign and fine-tune the levels, improve the graphics, sounds, and UI in general.
New game modes. We thought about adding some game modes apart from the story mode (survival, infect others?, multiplayer?).
Procedurally generated levels
Happy new year everyone, see you next LD!
Hello, LD folks! This is a post-mortem of everything I’ve made in 2013. I just feel like I must write one. We don’t end years often, do we?
This year started with the end of Ludum Dare 25. Results weren’t high, but they were higher than anything I’ve got then. Let’s call it a beginning of a beginning.
Also, I joined One Game A Month. In the first month, however, I almost failed. I managed to make a very short game about 2 days before the month’s end.
Then, MiniLD 40 came, so I made a game. Actually, I’ve made 2 games in February. The second one was, perhaps, my first serious game. I found out that I can make games.
I didn’t participate in MiniLD 41. I think I went somewhere then. I managed to make a game for 1GAM though, so I can’t say I wasted March.
April came next. And LD 26. I participated in it, and I did better. I was making several other games, I still didn’t finish them. Well, it was a very productive time. I had been on some kind of peak then… until I fell.
Yep, I fell. It was summer, but (so?) I didn’t participate in MiniLDs. I made 2 games for 1GAM, but eventually I broke my own combo. I missed the LD 27. It wasn’t because of my lack of motivation, but who knows if it could bump me up?However, I didn’t lose fully. Since the September, I was programming. Not really making any games, just programming. So, I didn’t really do anything during the autumn.
But then, in November, MiniLD 47 came. And that was the first time I pulled a game from beginning to end since April. And results were great! I put effort into everything. Even graphics, though before I thought graphics isn’t my thing.
Now, Ludum Dare 28 passed. I’m glad with what I’m done. And it’s only the beginning.
Here is what do I want to tell. Imagine yourself playing a game, where you fight against armies of enemies. And if you get killed, you lose absolutely nothing. What will you do? You will bravely attack them, won’t you? That’s Ludum Dare. What do you lose if you do something wrong? Nothing. So why won’t you put all your efforts to it?
So far, in 2013 I:
- Participated in 2 Ludum Dares, 2 Mini Ludum Dares
- Made 8 games (out of 12) for 1GAM
- Made 10 games total.
- Left 3 games unfinished.
- Made 48 posts in LD.
- Made 14 500×500 images, 8 nice little sprites.
- Composed 3 pieces of music for games.
- Made 17072 screenshots for timelapses.
I don’t rate a lot of games. Well, who rates games on the New Year’s Eve? Anyway, here are several good games with little rating I’ve noticed:
And you might want to rate my game: Maverick.
Happy New Year everybody! I wish you to do everything you can and aim for the best!
Hi guys and fellow devs,
Just wanted to hop in the postmortem wagon and let you learn a bit more about how I worked on “One”, my LD28 entry. English isn’t my mother tongue, so be ready to read approximate french-glish.
If you’re interested, you can first test my game here.
When I heard about the theme, I got a little disappointed because I voted against it, for the simple reason it didn’t inspire me that much. I almost gave up on participating. My first idea was to make a game about getting only one seed in an arid world, but it was too complicated and, in my opinion, not original enough.
I was a bit depressed that saturday, the sky was dark. Thinking about the LD smoking my cigarette outside, I suddenly decided to cheer myself up by cheering other up, and I decided to make the happiest and cutest game I was able to do in 48h.
With that in mind, I thought about the theme again and remembered that one dream I used to have which filled me with happiness. In this dream I wasn’t flying but jumping so high, and falling so hard ! It was fun and magic. I decided to turn that into a small game.
For those who didn’t play the game, the game is about a little child who learn to jump up to the stars. Little light balls help you to get higher and higher.
I’m what you could call a experienced dev, with more than 20 games released in my career, and 4-5 game jams. After several years, I’m now experienced with scoping a game. My advice is to always go for the simplest idea you can have. Because during the course of development, either for a full game or a jam, you’ll always spend twice the time you planned on small things like researching, debugging, adding signs and feedback, etc. We always tend to underestimate the details, so focusing on the simplest idea and growing from there is often the best solution.
I used Flixel, which is, in my experience, one of the best technology for game jams, for two reasons : it’s perfect to create very small projects in a very short time, and it’s meant to be distributed online, as it’s Flash based. The second is useful for LD because people tend to test games with Web version more (it’s far from being enough to get a lot of ratings, but it helps a bit).
My idea for One was so simple I managed to tackle gameplay code in a couple of hours. I love when it goes that way, because I know I can use plenty of time to make art, music and moreover add signs & feedbacks.
Several people have been surprised, playing One, that there isn’t any instruction. Well it’s been a choice. I love to do game jams to experiment with ergonomics. Having no instruction is a risky challenge. If it’s done right it helps immersion and focusing on the message of the game. If done wrong, it simply ruins the whole experience. So far, I don’t think anybody really got stuck in the game, so I would say I’ve done it right this time !
Here are a non-exhaustive list of simple things I implemented to make sure players learn how to play by themselves :
- Control scheme : as intuitive as possible, only three buttons (left, right and up). Duplicated on ZQD and QWD
- At least one bonus is visible on screen at start, encouraging to reach it and learn to jump and move.
- Audio feedback when touching bonus and also when reaching the current max altitude, hinting a bit on what to do.
- Midgame, my texts help a bit, by notifying that there’s more to discover upward.
I’ve worked with Photoshop. I’ve made backgrounds mainly using a brush to get this cloudy aspect. I didn’t want to spend too much time on animation so I made only a few poses of the character, mixing pixel art and painting techniques.
Surprisingly, I spent most of my time on music, with at least 4 hours spent on it. I must say I got a little carried I really enjoyed making it, so I wasn’t able to stop until I was satisfied with that small piece.
What went right
This LD went really well, for the main reason I did a game with a message and an intention in mind, I think. Working with the purpose of sharing a bit of love and poetry is wonderful. I managed to do a little something I’m proud of in far less than 48h because I didn’t get too ambitious and managed to focus on a simple idea and make the best I could of it.
What went wrong
The game was a bit oversized, and loaded from a website it discouraged some of my early testers. They complained it wasn’t working because I forgot to add a preloader : the page showed a blank page for around a minute. I hope those early testers didn’t rate the game too bad. I also stupidly forgot to proof-read my texts and let a small typo in the game (which I corrected later, as I learned it was allowed).
Make game with love, message and passion, focus on a simple idea but don’t forget about the little details ! Happy new year everyone, and let 2014 be filled with hope, love and plenty of wonderful games ! I think games can help the world be a better place, so keep going guys, I love you all.
You can reach me at contact [at] cuvegames.com if you have any question or feedback which I would love to have.
Here it is my post mortem about 0RBITALIS. For this game I got inspiration looking at other themes in the final round. It’s hard to make a game that is as vague as “You Only Get One”, but when you couple it with “Gravity” and “Chaos” it’s much clearer what you can actually do. I have always been interested in games which explore how simple rules (such as Netwon’s laws) can generate beautifully complex behaviours.
Most of the “features” of the game are actually consequences of the strong time constraints Ludum Dare imposed me. For instance, mi initial idea was to have a moving camera that could zoom in and out, but I didn’t have time to code it properly. And this automatically lead to a “stay in the system” mechanic. The vector fields that you can see in the background was a debug tool I used to test and calibrate planets’ masses, but when I realised that it was fitting nicely with the style, I decided to leave it there.
Since the very beginning of the voting period, 0RBITALIS got a lot of attention: so far, it’s both the most voted and commented entry in the 48 hours competition. I think part of its success is due to its aesthetic: it’s simple, yet effective. I spent lot of time polishing the game rather then designing more levels. This can really do the difference, especially when games are picked almost exclusively by how appealing their screenshots look like. 0RBITALIS has doing unexpectedly well. For this reason I am already working on a full-game version that will include both more levels and new mechanics. There will be probing missions, for instance, which require to scan a celestial body for a certain time. I am already working on landing missions as well, but I’d rather keep them mysterious for now!
Since I *hate* menus, 0RBITALIS won’t have one. I am working on a different system, however, that looks like a star chart. Player will be able to select levels and to change settings just touching and connecting stars. I also collected lot of statistics about levels but… I’ll keep them for another post!
If you liked the game, you’re more then welcomed to vote it or leave a comment on its LD48 entry page. If you want to follow 0RBITALIS news and further development, you can find me on Twitter as @AlanZucconi.
Hi Everyone, our take on the theme was an action/arcade game based on a randomly generated grid that was filled with colors and mines. The player could select one color to reveal at a time, thus showing the safe cells. This game came out much harder than we expected since there was little skilled involved. We ended up creating special abilities to balance it out: such as armor, reveal, jump, etc. Also, we tied each ability/color to a positive character traits: courage, perseverance, resilience, and forgiveness. Here’s a run down of the good and the bad:
What went right:
- Polish. The game had logo, sound, artwork, and there were no bugs.
- Although difficult, the game was generally fun.
- The visual design was minimalistic, colorful, and most importantly, something we produced within our skill and time limitations.
- We experimented with a new creative process and the result was not too shabby. We plan to keep refining our approach.
- Easily published for Web, Windows, and OSX using Unity. We wanted the game available to as many people as possible.
What went wrong:
- The game was really challenging because we didn’t have enough gameplay elements to empower the player. We could have identified this sooner and planned accordingly.
- It was more based on luck than skill. It didn’t feel like you can improve skill and overcome the challenge.
- We aimed for 5 minute game session, it averaged 30-45 seconds.
- The introduction story was conceptualized after the core mechanics. It was trying to provide purpose via a “spiritual elements” concept, which was too abstract for such a literal game.
- There was no tutorial or instructions. We just tossed the player into deep waters without teaching them how to swim.
Even though our creation is essentially a “glorified minesweeper variant’, we are very happy with the game. We are continuing to work on it and making it the best it can be.
How it went?
Well, plan was to finish something playable on first day, and polish in on the next.
We got something playable in the end of the second day, as a result, met on the evening of monday and worked since 6pm till 5:30am to turn it into its current state.
- We used google doc to collect all ideas on first run(no discussing ideas, just writing them) and then going over discussing them, works pretty well to see where team wants to go
- We picked theme simple enough considering we did not work that much together before
- We had loads of fun
- Cat’s are fun to play with(our host had a playful cat)
- It was good working at one place – It was easy for the team to brainstorm and talk about progress and issues
- We failed to finish something playable on first day
- We did not test programmers teamwork on warmup, turned out there were issues with some parts of our project causing git conflicts -_-
- On first day we kinda failed to divide work well, as a result some people were not working 100%
- Also programmers were waiting for designers to make some first graphics to be used in game, while instead should have used whatever as placeholders and start cracking
- Only one programmer from the team was familiar with tool used, so without him it was hard to progress initially
- Playful cats are distracting
- If somebody from the team gets distracted when working at one place, it’s easy for others to get distracted too
What to do differently next time
- Be more familiar with tools to be used
- Try to divide team members work types beforehand better
- Finish something playable on first day
- Don’t wait for graphics from designers, use placeholders
And Happy New Year!
With a little over a week left in the voting process, I figured I would put together a postmortem on my first ever Ludum Dare entry, You Are The One.
What went right?
- Design: I have only taken part in one game jam previous to this Ludum Dare. In that project, I dreamed far too big and tried far too much. When designing You Are The One, I knew I had to keep it simple. The game would be 2D, use basic physics and cameras that I was already experienced with, and require as few assets as possible. It would also avoid complicated mechanics until it could be played start to finish. I didn’t mind cutting features from my initial design, but I was determined to at least implement the 5-level progression and celebration screen.
- Audio: Audio was a big concern of mine initially. I had no plan for music, and I wasn’t sure how well the sound effect generator I was using, sfxr, would fit into my project. Luckily, the sound effects were perfect and matched my retro/basic art style. While wondering about music, I came across a program called GXSCC that could translate a .midi file into a chiptune sounding .wav. I’ve played guitar for many years and use TabIt to store all my tabs which, turns out, supports exporting to .midi. With this knowledge, I put together 2 small loops for the game and they came out perfect.
- Completeness: I think there’s something psychologically satisfying about finishing a game. My entry needed to be finish-able, and more than that, it needed to push the player to do more. That’s where the idea for level-specific collectibles came from. If you collect all the items, the ending congratulates you on your hard work. If you don’t, it still congratulates you but hints that there’s more to do. I wanted my entry to feel like a real, full game that just happens to be really short. I think I accomplished that to some degree.
What went wrong?
- Adherence to Theme: While there is an extensive use of “one” as a theme throughout the entry, adherence to “you only get one” is a bit flimsy. Each level has one color shade, one item to collect, and the player character is literally a “1″ with feet and eyes. While clever, it would be a stretch to say these attach to the theme well. The real use of the “only getting one” comes from the player only getting one direction they may progress in. This is a bit different than just getting one direction of movement, because the player can move both left and right on some levels. While matching the theme, it’s a bit convoluted as an implementation. I wish I had spent more time riffing on “one” as a limitation instead of “one” as a concept in and of itself.
- Enemies: My initial design called for one enemy per level, and a progression of difficulty stemming from that. Level 1 enemies would be stationary obstacles, level 2 enemies would shoot at the player, level 3 enemies would move around, and level 4 enemies would both move and shoot. Finally, level 5 would combine all the previous enemies the same way it combines the previous level’s movement styles. Unfortunately, I did not find enough time to design or implement enemies and opted for pits and spikes as the primary hazards. To give you an idea of how little time I would have had for enemies, I only implemented the spikes in the last 2 hours of the competition.
- Difficulty: I like to speedrun Mario platformers, specifically Super Mario World, as a hobby. As you may imagine, this colors my design philosophy when it comes to platformers. I tend to design levels to be rushed through at full speed, and completed through a series of expertly timed jumps. This can be problematic for people with different play-styles or less patience. My game is definitely too hard in its current form, but I hope the “skip level” button will enable all players to see the full game.
What did I learn?
- Unity’s 2D tools are… okay: While starting the new project, I noticed Unity now asks if you want to use 2D or 3D defaults. Since I was new to working 2D, I got excited and went with 2D. While many of the defaults assisted my creation process big time, most of the 2D tools went unused. Without a 2D Character Controller, I would have to use a rigidbody2D in its stead… and I wasn’t really prepared for that. Additionally, I had some trouble with the standard Character Controller colliding with 2D colliders. I eventually settled on a mix of the two systems, using the standard 3D components while taking advantage of the 2D scene view and sprite importer.
- A great game begins with a great plan: I accomplished almost everything I wanted with this project, and I chalk that up to a smart, flexible design. The project began basic, and added complexity, such as the items and spikes, only once the groundwork was in place.
- Ludum Dare is tons of fun: Not much more to say than that. I had a total blast taking part in the competition, from brainstorming to wrap-up. I look forward to joining future Ludum Dares! Just need to figure out how to do those awesome time-lapse videos between now and then.
If you haven’t played my vertical-shmup-with-nonviolent-options, it’s here.
After going for a more novel (read: difficult to implement) time-travel-based game mechanic in my previous LD entry, I decided early on that I wanted to do something simpler this time, but focus more on executing it well. I also had space on my mind thanks to the recent beta release of Starbound. The first idea I had that I really liked was a top-down shooter along the lines of Elite or Escape Velocity, but where those games offer you numerous upgrades for your ship, you would only get one: maybe it’s a single weapon, maybe it’s a tractor beam, maybe it’s an afterburner or cloaking device or extra shields. To keep it simple, I decided to go with a vertically scrolling shoot-em-up to allow for simple, linear level design and not a lot of story to write, allowing me to focus on the mechanics. The first generic space pirate name that came into my head: Spacebeard the Pirate. Arr.
Things that went right
I think I did a decent job making a game that accommodates the different play styles offered by the different ships. If not, at least I learned from it. Namely, that offering three different mutually-exclusive options for how to play adds a lot of time testing every single level edit.
Art: To make the player ship, I just drew one “base” ship and changed the color, cockpit position, and weapon/device attached to the wings. This approach worked wonderfully as it allowed me to give each ship a distinctive look with little time and effort. I applied the same modular approach to enemies as well and was able to create a decent variety while maintaining a constant style.
Things that were cut
I originally narrowed down the range of ship abilities to choose from to four: a weapon, tractor beam, repulsor beam, and cloaking device.
The first three made it into the final game. The cloaking device would have allowed the player to sneak past enemies for a limited time. Of course, that would require more complex enemy behaviors, which I also dropped due to time concerns in favor of a simple back-and-forth-while-shooting movement. It also would have been difficult to make a fun stealth game on top of the rest of the game (and pointless considering ~75% of players wouldn’t experience it in one playthrough), so I dropped the cloak ability. Near the end I needed an NPC and was pressed for time, so I guess you could say the cloak ship still made it after all.
Things that went wrong
The cockpit is one pixel off center on all of the player ships. Somehow I didn’t notice this until it was too late. Grr.
Theme? Apparently the people commenting on the game aren’t picking up on my idea that you only get one ability on your ship. Whatever—I didn’t care much for the theme anyway because it was too restrictive in how you could interpret it (See: all of the games where “you only get one [life/projectile/unit of time].” No matter how good many of these games actually were, 100 other people used the same exact mechanic).
Pacing. Too much of the player’s time is spent waiting for enemies to come on screen. When tweaking the scrolling speed, I tried to find a balance between giving the player enough time to deal with the enemies and obstacles on the screen and moving forward fast enough not to be boring. If I ever work on this game more or make another vertical/side-scroller, I’ll give the player control of their ship’s speed and limit weapon ranges so less happens offscreen.
Level design: in retrospect, it was a bad idea to make the levels entirely out of asteroids. This probably confused a lot of players who picked the repulsor or tractor beam and wondered why they couldn’t manipulate the ones which were part of the level boundaries, which were poorly distinguished from the movable ones.