Posts Tagged ‘postmortem’
This was my first Ludum Dare, I’m very glad I took part and I’m already looking forward to the next one.
Thank you to everyone who played and rated my game.
I’ve played a lot of wonderful games and got a lot of inspiration.
Now, my awful screenshot:
and my humble ratings:
What went well:
I finished: Something was submitted!
The concept: I think the idea behind my game holds water and although it’s a small idea, I’m rather pleased with it.
Feedback: Thank you everyone who commented. There was some very instructive feedback and it’s good to know that some people enjoyed playing.
Time management: Since I was at work all day Saturday and Sunday, I didn’t have a lot of time, but I got (most of) the bases covered. My to do list was handsomely ticked. Even though it was lacking polish, my game was a game and you could play it.
Napping: A really useful strategy to refresh the mind.
Not so much:
The graphics and general presentation were very basic, as reflected in my scores, and I didn’t have time to do any music at all. I need to think more about the appearance and feel of the game as a whole – and avoid settling for some coloured rectangles and filters in GIMP.
Likewise, the controls were very unpolished. A bit more tweaking and they could be slightly less painful.
I made the game too difficult. Early on I thought it would be too easy, but I pushed it too far the other way.
What to do next time:
Plan in advance to get some time off work over the weekend. Unfortunately though, I can’t take Sundays off during December.
Brush up on my pixelling skills and general beauty-a-bility.
Be more participatory(?).
If you want to play: http://www.ludumdare.com/compo/ludum-dare-30/?action=preview&uid=38469
The game is here: Planet Sweepers. Here’s a postmortem.
For Ludum Dare, I’m a firm believer of using the theme for inspiration and as a restriction to stimulate creative solutions – and then ultimately not letting it get between you and producing a good game. It’s a starting point, not a destination. A muse, not a contract with a client. (more…)
When we (alvivi and me) decided to participate in the LD for the first time we knew the hardest part would be to have a good idea. We talked a little bit about the possible subjects and when it was the time to talk about connected worlds we didn’t have any idea. Then, the results came and we had to work on connected worlds.
The firs night (the LD started at 3:00 am here in Spain) we were very tired and didn’t know what to do. We decided to go to sleep and try to dream a cool idea. That didn’t happen. On saturday we talked about many crazy things. An intergalactic jail, a puzzle game, and even a worlds dating game (it was very strange, worlds with faces talking on a date).
We didn’t start with Starcular until saturday night. That gave us 48h to make a game. At the beginning we were not very confident about the idea, but then the levels came out, the graphics, animations, mechanics… At the end of the second day we were happy with the game we were doing. I think that’s the main goal.
What Went Well:
-The game mechanics gave us more possibilities than what we thought at the beginning. That made the level design easier.
-The graphic style was simple enough to work fast and give a good impression.
-The music we found with CC Attribution (3.0) fit very well with the rhythm of the game. We were very lucky.
What Didn’t Go Well:
-We had to close the physics very fast to start making appropriate levels for them. Many people think the main character doesn’t move very well. They might be right.
-We would like to do an introduction video to tell the story, but we didn’t have time and we dismissed it.
In a few hours we will see the result and will try to learn from your opinions and improve to do better the next time.
Starcular LD web page: http://www.ludumdare.com/compo/ludum-dare-30/?action=preview&uid=42345
The results will be out
tomorrow in a few hours, and I’ve yet to write my post mortem… >_< Ok, let’s do this!
(also, here’s my timelapse for this LD’s entry!)
Since there are a quite few gifs and images (which add up to almost 2MB), I thought it was best to not keep everything on the main page…
The rating period is slowly but surely nearing its end, and I thought it cannot hurt to write a postmortem for the game I made three weeks ago. I wish I would’ve promoted the game more (it’s my first online multiplayer game after all!) and I wish I could’ve played more games, but my master’s thesis was jealous and demanded I spent more time with it. That being said, I have a free minute now, so here goes nothing!
Three weeks ago, when I was still young and inexperienced, I thought that “Connected Worlds” lends itselfs perfectly well to making an online multiplayer game. (Nevermind that I never did one before, haha.) That being said, there are some obvious design problems that I needed to solve – and that ultimatly led to the current design:
- LD rating is 3 weeks, and people likely won’t play all at once. To tackle that, the game should a) be able to be finished single-player too.
- Even if people are online at the same time, they probably won’t arrive at the same time – and likely don’t want to wait either. For that reason, I made the game drop-in/drop-out: The first player to join starts a new session that ends when the last player leaves or the game is won/lost. Any player that arrives in the meantime just spawns next to the torch. (I briefly entertained the idea of one permanent session, but I wouldn’t want to do the level design for THAT, phew. Also I highly doubted that players would come back often enough for that to be interesting.)
- Synchronisation is hard. So, uh, nothing twitchy. More slowly. With tiles to walk on.
- Synchronisation might not work correctly. I have no idea what I’m doing after all. So, better do a co-op game and nobody gets pissed that the enemy had an advantage.
Okay, so a scalable drop-in/drop-out co-op online multiplayer game. This is basically what I spent my complete first day on, and I had no idea what I actually wanted to do gameplay-wise yet. I implemented a chat though: Just text that appears on top of player’s heads.
After a good night’s sleep, I arrived at the idea spawning from the Olypmic torch relay: A flame had to be transported from A to B – in this case between two kingsdoms. Slowly everything clicked together: It was dark, hence the flame is important. If you drop it, it’s not protected anymore and slowly dies down, and you have to drop it sometimes because it’s heavy as hell. And there are multiple obstacles that you have to dig through or build across. You can do it alone if you react fast, but it’s stressful always to drop the flame, dig/build a little, pick it up again, transport it, drop it etc. – it’s much better with friends helping you! So yeah, here we go – a game that you can play alone or with “any” number of friends.
The game is made in Unity and with the SDK from (and hosted by) Yahoo Game Networks. Free hosting for up to 5000 daily users? Yes please.
There is a server, but it doesn’t do much – it mainly keeps track of the users, items on the floor and already dug-out rocks so that it can inform new players. It also distributes events. The only thing that it is really authorative about is when an item is spawned, picked up or dropped to avoid item duplication.
On the client side, you are the only player that moves directly – and you send messages to the server how you move. Because movement is between tiles, those messages are few, and they will arrive in roughly the same interval in which they are send, so on the other screens you move the same way, just with a delay. Each player object has an event queue – move, dig, build bridge etc – that will be executed in that order with the appropriate delays, so it’s no problem if messages arrive to quickly either.
Making the server mostly non-authorative and using that message queue system is what helped me be able to finish the game in such a short time, I think.
What didn’t go so well?
- No sound effects. I wish I had some, but I finished the level itself in last second, and well – that was a bit more important, I guess.
- Nobody invites their friends to play. I wish I knew why. It’s super easy – just share a link – but many people commented that they had to play alone. I suppose they do have friends, right? Maybe even game developer friends?
Apart from that, I’m actually largely content! Sure, there’s not that much gameplay, but it’s fun – and sure, the graphics could be better, but hey! 48 hours and first time online multiplayer! I’m certainly not complaining. Which leads me to…
What went well?
- Online Multiplayer in 48 hours, that’s what!
- The whole thing is surpringly stable, if sometimes a little laggy. I would’ve expected to have more problems with an online multiplayer game.
- Development wasn’t as hard as expected. I was always a bit wary of networked multiplayer in any form, but it turns out that it wasn’t that bad to always have a server and often two windows running. Might be because it was only 48 hours and a small-scoped project with no necessary security though.
- The Drop-in/Drop-out is cool. And it also has the side effect of allowing people to spectate games. Apropos drop-in/drop-out…
- The game is a lot of fun with streamers! Allowing for a variable number of players that can join anytime, and streamers having an audience already made for great fun a lot of time.
- The chat is refreshingly different. Having text appear on top of the heads is cool, but seeing it being typed live is surprisingly even more fun!
- Trust in the process. Seriously, don’t worry if your design is not complete yet. I didn’t have any core gameplay ideas until 12 hours before the end and I still finished with something. Just work towards that goal until then.
- Keep a ToDo list. Workflowy is superb for that. Helps me stay on course and motivated.
- Keep your design simple and modular. Especially if you do something big technology-wise that you haven’t attempted before. If you finish early, you can still add more features! I would’ve loved to have enemies and defending each other, or wind zones where you have to keep the flame safe, and… but time ran out, and the current state is very playable.
- Test early. I started testing long before I had actual gameplay. I guess networked games are special in that regard though.
…I’m quite happy with the result, and I’m seriously considering doing a game with online components for next LD too. So much inspiring online stuff this LD, damn! And maybe I’ll even get a chance to gather more networked multiplayer experience by then, but knowing me, I won’t and I’ll just dive right in. Wouldn’t have it any other way, really.
Do you have any questions? Feel free to ask them in the comments or on Twitter!
And maybe you have a free minute or two and want to try my game? (And maybe ask a friend to join you! Friends are pretty cool.)
Out of all the themes this LD, the only one I had a solid idea for was “Lost In Space.” I had even made a detailed design document with all of the controls, mechanics, level design and goals outlined. So when I found out that the theme was “Connected Worlds” I had no ideas; all I could think about was my “Lost In Space” idea. So I repurposed my idea to work with “Connected Worlds.” Basically you play as a single astronaut in a ghetto spaceship that was sent on a mission to reconnect two planets by deploying a communications satellite. These planets used to be connected by a single satellite but it broke, disconnecting these planets from each other.
I made this game in Unity in around ~35 hours.
What Went Well:
-Physics! Unity’s physics is a key part in this game!
-The Satellite controls. Deploying the satellite and manoeuvring it is very lifelike and a lot of fun.
-The Spacescapes. They are pretty awesome, if I do say so myself.
-The Satellite Model. I really like it!
What Didn’t Go Well:
-Physics. Sometimes the ship’s physics glitches and it starts spinning and flipping. This is really cool for the player inside the ship but it ruins the game.
-Textures. Why do spaceships have so many textures!
-The glass effect on the window. I needed something to make the windows look windowy. This did the job but I don’t like it very much.
Now, if you haven’t played Satellite yet you can play it here!
With less than a day left before judging ends, I figured I’d share the timelapse recap I made of the livestream of my friend and I making Melody’s Long Ladder Home using Stencyl. It’s just the entire 12-plus hour livestream (done over three days), condensed into less than 23 minutes.
If you still want to try our game, you can try it here.
Having taken part in 5 Ludum Dare events now (from LD26-30), I think I’ve gotten the hang of making a game in such a short period of time (kind of). I’m just going to say straight away that I’m actually quite happy with the game I’ve made this time around, but it still could be better.
You know, time management is strangely one of my strong points in Ludum Dare. I somehow managed to fit everything in, even after feeling incredibly tired by the end of it. There was plenty of time for all the art and music that I wanted to go in (kind of).
“The Art of Screenshake”
If you know of Vlambeer, you’ll know their games are incredibly polished, and they put a lot of work into “game feel”. When I saw Jan Willem Nijman’s presentation “The Art of Screenshake” I made sure that I used his tips and tricks, and made them my own to make sure the game I made was really enjoyable and felt really nice to play, even if the graphics or gameplay mechanics weren’t exactly special. I feel I achieved that, as not only in Bounty of Corruption, but also my last LD game “Flesh Hunter” I got many comments about how well polished the games are. Ultimately, I think that a polished game that is fun to play will do so much better than a game that follows the theme word for word. Speaking of Vlambeer, a lot of the comments on the Ludum Dare page say that it plays a lot like Nuclear Throne, made by guess who? Nuclear Throne was a huge inspiration for this game, and it’s clear to see that.
It was clearly going to be “Connected Worlds”, but I was almost completely unprepared for this (in the end, I personally think that the game is miles away from the theme). I wanted to either make a dungeon crawler (hooray for originality!) or a big space game where you have to travel to different planets, both of which were based around randomly generated levels. Both of which are also probably the most common type of game made for Ludum Dare with a theme like that… This was my greatest weakness. They say that you don’t need a good idea to make a great game/app, but I don’t have any idea, let alone a single, terrible one (same with names)
While the game was very polished, and I’m happy with the content that was added, it’s missing a lot. I feel like this game needs more variety in gameplay, more enemies, different weapons (upgrades even?), etc. It also has a half-assed introduction and outro, but if I’d spent time making those really nice, I would’ve spent less time on other things that are more important for a 48 hour game making competition.
Like all the games I’ve created for Ludum Dare, I plan to add loads of features, but most of which never get finished, or even started sometimes. For some reason Bounty of Corruption feels a little different, as if there’s an urge to add things for some reason. Anyway, here’s a list of stuff I’m going to try and add:
- Networked Multiplayer (I’ve got a super basic prototype already functional! See below for video)
- An introduction/outro, as mentioned earlier
- More enemies, such as a final boss.
- Balancing. Yep, while the game’s balance isn’t that bad, it’s definitely harder for people who have never played it before, as there isn’t enough ammo spawning in. Also, some random generation needs fixing, cacti can spawn on top of the enemy portals…
And there you have it folks, a game I’m proud of, and what I could have improved upon. I recommend you check it out for yourself, you might be pleasantly surprised!
Rate my game here! http://www.ludumdare.com/compo/ludum-dare-30/?action=preview&uid=20850
Here is the postmortem of Grow Your Planet. Before you read it, go and play it!
And skip to the conclusion is you find it too long!
What Went Right
For our first Ludum Dare, it went really well, actually. Following is a list of what we are really satisfied:
The Main Idea
We found the idea of making planets grow in a pot at home quite easily, and we found it really cool. Moreover, it fitted the theme very well, while remaining original (we didn’t want to make a platformer with two overlapping levels or such other quite obvious ideas).
We aren’t so good at pixel art, and hand-drawn graphics add a personnality to the game (I think so, at least). People seemed to like the style, Ylang did a really good job here. Many thanks to her!
Stencyl is a wonderful tool that I’ve been using for some while, so everything went quite smoothly. No bugs, no unsolvable problems, no features that needed to be removed due to their complexity… The main challenge was the use of the image API, for the “taking pictures” part of the game, but here again, it wasn’t that hard.
What Went Wrong
Nothing Just kidding. Actually, nothing went really bad. Some things could have been better, though:
The Platformer Levels
To reinforce the “connected” part of the theme, we decided to add levels of some sort—and we chose platformer ones—to make the planets interact which each other. Sadly, this decision was made too late, and I ended up not having the time to make them. As a result, I made a small, poorly implemented one that can be completed in 5 seconds, and duplicated it to make three levels. This is the main thing to rework in a post-compo version.
The game is not polished enough: it lacks transitions when you unlock a new planet, and the ends abruptly. For the next time: do not finish 30 seconds before the deadline!
I am quite new to this, so I did not really communicate about the game. This is a thing to improve for next time, to gain more visibility.
What Went Neither Right Nor Wrong
Maple did a quite good job here, but the music was made at the end, too quickly, we did not have the time to record it and I implement it poorly in the game. Next time, we should begin to work earlier on this aspect of the game.
We slept enough (too much?), and we respected the delays we fixed ourselves for each of our goals. We took it maybe too easy and relaxed, which caused the not-so-good platformer levels. It is strange to say that, but we’ll need to sleep less next time!
We had a lot of fun and are very satisfied with our first Ludum Dare game. We could do almost everything as planned. Just need to sleep less and to communicate more. Beside that, we did quite well, I think.
I’ll post a timelapse soon!
My Entry into Ludum Dare 30 is a little game called Connected We Run. It is an endless platformer game, that you control both characters using the same controls.
What Went Wrong
- Lack of theme inspiration, some themes you can get really excited about, and others just fall short. This was definitely one of the themes that lacked excitement for me.
- Clouded direction, the resulting game suffers from a lack of solid direction. Initially the game was going to be a platformer that you would control the two characters to reach their goal platform/door (similar to Beyond The Horizon by Lazdo) I ended up scrapping that idea really early because it resembled two of my past entries to much (Through The Blue Sea LD23 and its “sequel” I Threw The Red for mLD34) At that point I thought about Endless runners, and decided to go in that direction.
- Platform generation, The first day of the game I spent a good chunk of time getting the platforms to behave the way I wanted them. I wanted the dark and light characters to only collide with their respective colored platforms. A platform not of the matching color you would simply pass under. In the end it never felt right, the light character could jump up into the dark platforms, but it served limited purpose to do so. Then on Sunday morning I decided that the player should just be blocked into their respective sections. And that led to the breaking of my platform generation. (Up to that point you could jump ontop of any platform)
- Platform generated except the first five, nobody has mentioned it in a comment but it is one of the things that has bothered me, the first five platforms were positioned by me to fill the time before the generated platforms reach the player. I did it this way to simplify the player spawning (There is none, and that is why the Restart button didn’t work)
- Speed of the platforms, The speed was intended to start slow and slowly build up speed. It does build up speed, but at such a slow rate it is hard to notice.
- Title screen, While the title screen show a lot of good information, it could also be improved visually. I really like on the end screen where the text is mirrored. I am glad that I found time before the end to add in a title screen, because what it was in the initial submission was barren and white.
- Restart Button on the end screen, initially there was one but when I updated it before the compo ended (adding music, sound, and a title screen) I had to remove the restart button because it was not functioning at all. So I inserted a message in its place to refresh your browser to replay, I didn’t think it was a big deal in a 48 hour Ludum dare game, but several comments have mentioned it.
What Went Right
- Global Leaderboard was a great idea for this style of game, I have used them in the past, and always declare the base code for one, but it has been a while sense using it. The Leaderboard as several people have pointed out has no semblance of security, its just a page that gets queried with your name, score, and the game ID. I have never had the response to any of my past entries that I have had to this one, so I have never bothered with any attempts to secure my Ludum Dare leaderboard. That may change soon.
- The score, although there have been some criticism of it seeming to be random, I enjoy the range of numbers that it produces. The score is calculated based on the times of the character. The first of the two characters that go out becomes the multiplier. Then when the second character goes out the score is calculated. (Lowest Time * (character 1 time + character 2 time)) So while you can continue to play after one of the characters is out, your score will ultimately be lower than someone who took both characters farther.
- Music and sound was a last minute addition, in fact I submitted before there was any music or sound, and ended up finding some time after to add them in. I think they both add a lot of the game, and it wouldn’t feel quite the same.
- One of the other criticism has been that when one of the characters fall out the game should end. I made the decision to keep the game going and to use it as a scoring system because of how I defined connected worlds. There was a blog post that I saw early on (I didn’t save the link) that showed several different images of connected worlds. The post looked at the definition of Connected worlds, and how it differs from a mirrored world. I then came up with my definition of how the connected world works, and build from that. The platform generation is independent and different in each world, so I felt that the characters should be able to function independently of one another.
I think I almost always say I am going to continue the game in my postmortem, and then I rarely do. But I’m going to say it again, I will be making a postcompo version of the game, with fixes and improvements largely to the title screen, platform generation, leaderboard, and overall increasing the speed of the game. What is going to be different this time is that I will be making a Youtube video series of the improvements to the game. The series will start on Monday September 22nd, after I finish up the Ludum Dare 30 Games series.
Trappy Tomb was conceived as a response to the poor score for ‘innovation’ I received from my previous LD entry ‘Midnight Minigun’. Mulling how I could do something innovative I decided that client-server would be a fun way to interact with the LD community, and since I’d have very limited time I’d also attempt to integrate User Generated Content. I didn’t want to overly burden the player with creating things so I figured that playing with or against the recordings of previous plays would be a fun way to generate content and promote interaction. The death messages idea was influenced by the LD28 entry Rude Bear Resurrection and the mega-replay idea was an homage to Super Meat Boy. My own interest in collective insect behaviours also came into the design though my original ideas of collective problem solving ended up on the cutting room floor.
Trappy Tomb is set in an Indiana Jones / Tomb Raider style environment viewed from a top-down perspective. The player can move and jump. Jumping results in flying kicks which kill the bats that populate the tomb. Pretty much everything in there is lethal – spikes (timed, triggered and fixed), boulders (always triggered), pits, lava pits, bats and arrow launchers. There is also optional loot to collect. The game is split into two parts – a sizeable onboarding level in which you cannot die and your replays are not recorded, and the main Trappy arena.
The onboarding area has an important additional function beyond simply teaching controls – it shows what you get if you win, which is a statue personalised with your message and score for all to see. These show the game is beatable as well as providing motivation.
Without further ado here are two composite images of the main tomb complete with the death location of the first 2000 plays (left) and the breadcrumb trails left by those players (right). Click for larger views.
You can clearly see that the vast majority of players die in the first couple of hazards – some static pits. I’ll come back to this below. It’s also perhaps apparent that the climax of the level is a bit lacking- again see below!
You have 2 minutes to complete the level (ample time). If you timeout or die a dialog pops up asking for your “message to eternity” and you can see these being quoted as ghosts die while you play – I can honestly say it has been utterly hilarious seeing what everyone has put and I’m thrilled with this feature. However it was exploited badly at one point by trolls – more below. If you win you enter an inscription for your statue and are returned to the onboarding area where you get a special ending sequence and can see your statue in all it’s glory.
What went right
* The client-server system. I chose FatFractal for the server backend and it worked really well. It doesn’t require much setup at all and there is no server side code needed. You simply log-in a user and push your objects to the server. You can then pull them back with a rich query language. The player position is sampled every 0.2s and frames are interpolated on replay. When a ‘died’ state is encountered the death message is displayed – these are usually hilarious, so thank you for those! I’ve included a few choice quotes below
* Artwork. This LD I decided to leave all the art until day 2 and this decision paid off as I got less bogged down in pixelling than previously and hence have more gameplay in there. The hardest part for me was selecting a colour palette – I needed everything to be readable and to separate sprites from the background and I’m pleased with how this turned out. I borrowed a few colours from other games and built up from there. Tools were Pixen and Zwoptex
* Onboarding and level flow. In my last LD entry I had many people rage-quitting because they died within the first few seconds before they’d even mastered the controls so I was determined to pace the start out and give the player a chance to get into the game. I’m really pleased that I managed to do this in the time and I think it meant people were ready when the real challenges came. I was generally happy with the building series of peaks and troughs of intensity in the level itself though I ran out of time so it ended a little abruptly. The first obstacle was probably a bit too hard as well as it claims about 60% of all attempts
What went wrong
* Controls and physics. Disappointingly I failed to iterate enough on the player controls. I partly put this down to using a new framework (phaser) for the Jam so I had to find out about how the physics system worked as I went along which was not ideal. It turned out that with some really simple tweaks the experience could be much improved but the damage was done and no doubt people’s enjoyment suffered due to the over-large hit-box and slippery movement. Essentially people feel a bit cheated when they don’t think they touched spikes etc but die anyway and I can sympathise with this! The post-compo version (with about 10 characters of code changes) is loads better
* Open to abuse. I really should have seen this coming, I really should, but I figured it was unlikely that the game would make it outside the LD community and so everyone would ‘play nice’ with their comments. Alas it was not to be and on one occasion I was confronted with some extremely offensive language that caused me to take the game offline immediately. It took a few days to work out a solution and thanks go to Gary at FatFractal for his support (t: @gkc). I settled on a system whereby all comments are immediately added to the local game, but will not appear in anyone else’s game until I’ve moderated them via a holding area. This actually has the side benefit that I can read all the comments as they are added
* Ran out of time. I had to ruthlessly cut features, for example I really wanted the ghosts to be more than just eye-candy, I wanted to have collective triggers that required ghosts to coordinate in order to open secret doors or get the ‘big prize’ etc. The idea being a community that self-organises to achieve a collective goal much like a colony of ants might… Was a shame to let that one drop! Similarly I underestimated how long it would take to create the traps and layout the environment. The game stands and falls on its level design and although I’m reasonably happy with it, the ending is weak and it kind of fizzles out a bit. I wanted to have a final large room with all sorts going on and some more timing based flame and spike puzzles but there simply wasn’t time. Still – by the time the make it to the end the few who’ve got that far were probably glad there was no more
This Ludum Dare was easily the most challenging and yet satisfying I’ve so far undertaken. Tapping into the creativity of the community for my content turned out great as I knew it would because YOU ROCK!. The amazing comments I’ve had have lifted me beyond words (especially around the trolling incident) and being featured in a selection of YouTube videos has been a total blast too. Here’s my favourite of those along with the truly final words – courtesy of you, from the selection of 3100 messages…
* jump. Jump. JUST JUMP, YOU FOOL!!!!
* i’m not laaavint
* the lava is not nearly as hot as my rage
* I see dead people
* i love fat eggs
* fat eggs are gross
* DO NOT TRY THIS AT HOME
* I SUICIDED FOR THIS: JUST GO LEFT
* DAMN i got nervous… must be close…
* Wonder how many of these are me?
* This particular bat is a win cheat
I could go on all day, but why not just play for yourself and see?!
This guy did and just about kept his cool:
In general I’m really happy with how APOLLO turned out, and I’ve gotten some great feedback on it already Just thought I’d do a quick summary of how things went this time around, how I improved over previous LDs and hope to improve in the future.
What went well / improvements made:
- Aesthetic – I was able to nail the feeling I was going for with this game, through the look, sound, and how it plays. One of the things I’ve noticed in the past is how I stay deep in my comfort zone when it comes to visuals for my jam games, but I think I did an ok job of pushing things a bit further this time around.
- Sound – Though I didn’t compose original music for the game (it uses a track called “Past the Edge” from incompetech.com), I’m proud of what I did with the sfx. In the past I’ve fallen back on basic SFXR noises, and though I did use SFXR in my workflow, I think I did a much better job this time of creating sfx that fit into the mood I was attempting to create.
- Gameplay and originality – My 2 previous LD games suffered from a lack of originality imo, they each ended up being somewhat similar to gameplay mechanics that already exist. I feel like with APOLLO I was able to create a game that was entirely about my idea, and didn’t need to borrow gameplay concepts to round out the experience. I’m sure there are games out there it’s similar to, there almost always are, but I think I created a much more unique game than my previous LD entries.
What didn’t go well / areas to improve:
- Perceived complexity / learning curve – I wouldn’t say APOLLO is an especially complicated game, but due to the UI and presentation it can come off that way. The main problem is that a new player is bombarded with a lot of information, and for some people this is pretty hard to process. I didn’t want to make a straight up tutorial, as I wanted part of the game to actually be about learning how to navigate the world and use the actions available to you, but some easing the player into the world would probably have helped a lot.
- Visual clutter – Mainly, too much text. Kind of ties in with the previous point, there is just a lot of text onscreen at any given time. I personally like the aesthetic that this gives to the game, but to a player it can certainly be overwhelming. A goal I’ll set for the future is to try and do better at only showing the player what they need to know, and create better focal points on the screen.
- Pacing - I actually really like how slow-paced the game ended up being, but I’m marking it as an area to improve because I think it’s important for a jam game to be really easy to jump in and start playing right away (something that I think really helped NXTWPN10). I think it would have been possible to do this with APOLLO without sacrificing the slow, looming feel, by doing more to grab the player’s attention right at the start and not forcing them to hold up and analyze a quite dense screen’s worth of information before making their first move.
That’s basically what I’ve been thinking about regarding APOLLO since the jam finished! Making it was a really fun experience, and of course getting to see people’s reactions to it was even more fun. Many thanks to everyone who gave it a try!
Ludum Dare #30 was my fifth successful Ludum Dare, which brings me to a 50% success rate. Yay! Time for a post-mortem.
By the way, you can also play my game.
What went right
The engine. I wrote the engine in C++ this time, and took notes from an article called “Programming M. C. Kids” Iz-Tavares and Chang. The platformer physics turned out rather well, and the game feels responsive but not crazy. There was even enough time for some tricky shader effects, and I’m going to show those off in a GIF:
Core gameplay. Once the gameplay concept got to its final, simplified form, I could focus on implementing it and writing levels. The level format was just ASCII text, so I could crank them out pretty quickly, and I ended up with 9 levels.
Sound effects. Just a couple hours with a microphone (and some music software) were all it took. There are 13 sounds with an average of 5 variations each, and the engine picks a variation at random each time a sound is played. The effect is rather nice, especially for the footsteps.
Dialogue This was the last piece of code implemented, but it gives crucial context to the game. The writing isn’t great, but I’m really glad it’s there.
Analytics. I keep a record of every time a level is beaten or restarted, along with a couple other things. Here’s a chart of the statistics for each of the 9 levels. You can see that about 60% of the players who start the game finish it, and players who get to level 8 restart it 2.5 times, on average.
What went wrong
No tutorial. The game doesn’t exactly throw you into the deep end, but it does very little to tell you what you’re expected to do. This was painfully obvious once I watched someone else play the game. For everyone who played my game: thank you for taking the time to figure things out!
The worst part is the double jump. I was careful to make it so you could beat the game without the double jump, but there are some places where you have to restart if you don’t know about the double jump.
Slow start to the project. Looking at the commit logs, the game didn’t even respond to input until 16 hours into the contest, and jumping didn’t work until 21 hours had passed. I spent the time refactoring, messing with base code, and other things that don’t make games.
Not enough time on graphics and music. With only an hour and ten minutes left to go, I cranked out a music track and a bunch of sprites. I spent less than 10 minutes on music, and that’s including the time it took to start up the sequencer. I picked out two chords (Cm9 and Gm9), hit record, and rendered the result to disk without editing it at all. I even used the default patch you get when you start a new song!
Special thanks to Obsolete Entertainment, who put footage of gameplay for Dreamless on YouTube. In general, thanks to everyone who posts videos of the games they play!
Hello! Designer/programmer/artist here. Here’s a little write-up on my Ludum Dare Jam entry, Honko’s Worlds.
It is a dungeon crawling game where you shoot enemies with beams, collect gold, potions, special weapons and keys.
It plays a lot like one of those top-down zelda games.
You can try the game here:
I started making the game planning it to be a competition entry, but decided to make it a jam entry halfway through the second day when it became clear the game wouldn’t have enough content by the 48 hour deadline. On the third day, now that it was a Jam game, CBoyardee offered to make music for it, and made three great tracks.
I am very happy with how the game looks, and with many of the game’s enemy encounters. Those I think are its strongest points, it turned out really good.
But many, many issues came from a lack of foresight and planning in general while I was doing this. I only had the vaguest idea of what the game should be during the first day, I was like on autopilot. I knew I wanted to make some sort of top down dungeon crawler, but that was it. Most of the ideas came together through pixel art: I was just drawing game-ey things (monsters, tiles, keys…) and imagined how they could fit together as I did em. I should have stopped and should have taken a walk or something, to get those thoughts straight and order up some more solid idea.
The biggest mistake, a consequence of this improvisation thing, was planning a much bigger maze than what I had time to finish and polish. Once I was done making a basic shell of a game, I started sketching up a plan for the dungeon’s maze, and made it really huge. I always underestimate how much time it takes to actually put those rooms together, even when the rooms are simple.
Here’s a map of the game I was planning:
That maze I drew up and then proceeded to implement is about three times bigger than the final entry’s size (which is already pretty big!!)
Most of that larger maze actually works gameplay-wise and is filled with enemies and items, but I didn’t have time to give it any tiles/graphics! When there were just a handful of hours left, I blocked off the unfinished 2/3rds of the game and focused on adding to that first third instead.
As I mentioned in the original post though, you can actually visit that huge unfinished section of the game by exploring the finished section completely and finding two gold keys (their locations are marked with two Xs in the map above)
The unfinished area starts just north of the two consecutive gold gates. Of course, without tiles to see where the walls are, that area is more or less impossible to explore. If you reach that unfinished area at all, you can consider the game beaten!
One of the biggest consequences of all those cuts to the game’s maze is in relation to the theme (the theme of the Ludum Dare competition was “Connected Worlds”). The gold keys you can find in the current maze were supposed to be hidden in “side worlds” with their own enemies and visual styles, but I had to cut all of that. The idea was to have this castle be a “hub level” of sorts, from which different worlds were accessible.
To access a new world, you have to find silver keys within the hub level, which opened the way to one of the side-worlds.
To make progress in the overall game at a higher level, you need to collect gold keys in those side-worlds. This would let you access a larger portion of the castle. Those gold keys mark your overall progress in the game.
Its quite frustrating to see how many hours I spent laying down walls and enemies for those unfinished sections. If I had kept the maze small, the game would have had a lot more content, could have been a lot more complete!
One good consequence of cutting off so much of the big maze however: I could take the unique enemies I designed for the cut-off areas and place them all in the smaller game, making the enemy encounters feel very diverse. My original design, by comparison, was probably way too repetitive with its enemies.
Some other regrets with the result:
-The subweapons. They are pretty generic, they don’t have much diversity, just extra damage, some spread shots and some projectiles that fly a bit further. I thought of the subweapon thing on the second day of the jam, but only started to implement them in the final few hours, so they’re not really elaborate. Ideally, I would work on them further, to make them feel more like magic spells. Something that is exciting to find, where collecting a lot of them feels like you are really expanding your inventory of actions. Some weapons could have non-combat applications, like freezing a lake to allow passage or breaking through a weak wall. Some could have special effects over the enemies hit, or have defensive applications. But this would also mean I would need to add some means of managing your subweapons inventory. Perhaps you could only hold 10 of those weapons at any given time, and could store them in some storage space accessible at save points. Speaking of which…
-Save points. The game has no saving or checkpoints, and that’s a huge bummer. I just didn’t have time to implement those. I was already cutting off so much from the idea and had so much more to fit in, saving was just never on my radar throughout the jam. I need to make saving a higher priority in my jams in the future, it really sucks to lose 20 minutes of exploration all of a sudden!
-Gold. There is absolutely no use for it in the game right now, its just some sort of score. Of course I thought it would have some use at some point, but it never coalesced during the jam. I would definitely add a shop that sold unique subweapons and potions, or could maybe upgrade your main weapon, or raise your maximum life.
All in all, I am pretty happy with this game despite all the flaws, and with some more work, it could turn into a solid little indie title. I have a lot on my plate right now, but I might revisit and spruce this up a bit sometime in the future.
I also put up a time lapse of the entire process of making the game: The pixel art, the design, the programming and even the last-minute sound effects.
You can watch it below: