LD36 was our second Ludm Dare Jam attempt in which we created Retro YouTube Simulator. In this post we look into the creation of Retro YouTube Simulator, and the response it has received so far.
Continued below the cut. (more…)
So what happened for my first VR game?
It’s been two weeks since we released Colossorama 36. Thus, we consider it an appropriate moment to share with you some insight about the development process, including its highs and lows, through this Post Mortem. Without further ado, here is the…
Colossorama 36 is a hack-and-slash arcade game where you play as a gladiator and must use an arsenal of different weapons and items to slay enemy gladiators. Each of these weapons and technologies have a set of different stats and attributes and depending on the player’s choices can determine the outcome of each wave. The player’s score is measured by the amount of gladiator heads the player has decapitated.
The development team is currently made up of two amateur yet eager game developers – JorgeGameDev and The ‘Moski. Our first project, The Farming One, was developed in RPG Maker over two years ago and despite not having made another major project since then, we’ve been learning several new skills and tools while discussing potential new ideas.
For the development of Colossorama 36 we used Unity and C#, while using Krita for the game’s art. Our familiarity with these programs ensured we knew what set of tools and workflows were necessary for the game’s development.
The game’s concept was grounded up shortly after the jam’s theme (Ancient Technology) was announced. We settled with gladiator fights to use the Ancient aspect of the jam, while the weapons and items could choose from – aptly named Pantheon Techs – defined the Technology theme.
Being a Game Jam game, one of our major focus was to develop a quick yet fun game loop. Various of our decisions, such as replayability were inspired in roguelikes, as well as the decision to go with some randomization and decision making in order to spice things up.
One such example of these elements is the forcing the player to pick between a set of random Patheon Techs at the end of each wave, even if the player must sacrifice a stronger weapon or item for a weaker one. This together with other elements such as randomity of which gladiators get into arena helped ensure that the game’s loop, despite repetitive, is always slightly different.
Having a clear idea and direction of the project right from the beginning helped establish priorities and decide what needed to be worked on first. This allowed us to quickly shape up gameplay as well as helping setup the art style right from early on.
Since our project was practically always on schedule, we had enough time to polish it and make it as presentable as possible. This, together with the decision to make sure we had everything built by the submission hour, allowed us to focus on setting up the Ludum Dare and Itch.io pages during that hour alone, as well as making sure everything was packaged correctly.
Since none of us had access to a Mac computer, we had no way to directly compile a Mac version. This worried us since it could mean ending up leaving Mac users hanging. We decided to give a look at the Unity’s Cloud Build service to help create a Mac build of the game and thanks to the service we were able to launch a Mac build and support all the three major platforms.
Making some changes to the project in order to export a WebGL version of the game also proved to be a worthwhile effort. With very minimal source changes we were able to create a version of the game that could be played in-browser. Since then, the amount of views (and subsequently, plays) in the Itch.io page has been five times the amount of desktop downloads.
Some design decisions could have been made earlier in the game’s development. One such example is the upgrade system design which design’s was only fully completed during the second day, which ended up causing some delays and content cuts.
Important design ideas like this one should be thought and decided right on the first day, instead of progressively delaying them. This way, we can assure that the design mechanics get practically built in the first day and improvements and content to populate the resulting mechanics developed during the remaining days.
Some of the feedback we have collected mentions how some of the mechanics and weapons are not as useful or as balanced as others. One such example is the jumping mechanic.
Although there isn’t a clear method to ensure every mechanic is well developed, playtesting base mechanics and experimenting diverse alternatives can help us notice which ones need more work and sort out balancing issues.
Audio was also practically an afterthought and something we could have explored much better. We never got into searching for someone to help with audio, which forced us to use royalty free music together with some generated sound effects created with SFXR.
One of the things we definitely want to change in our next project is to find someone that can give us a hand with the audio. This way we can make the game feel more personal, unique and most importantly, distinct when it comes to audio.
After all the development and effort we’ve put into Colossorama 36 we have to say we’re pretty happy and impressed with the game’s results, especially after almost two years of hiatus as a team in which we didn’t get to show any new project to the world.
As a short summary of the previous points and on the lessons we take for future projects:
Needless to say, we’re confident that we’ll be able to show new and more varied projects as time goes along. We can only look forward for developing them, and to get to read the feedback of other players and developers.
Thanks for reading! We hope that you’ve gotten something of this – honestly quite big – Post Mortem. It’s been great hearing all the support and feedback we’ve gotten from other developers and players who have given the game a try.
Right now, one of the things we’re working on is an update to Colossorama 36 with some new features and content. We’re not sure when it’s going to be out nor how many updates are there going to be. But at least for now, even if it’s just for practice, it’s going to be one of the things we’re going to be focusing on next. We’ll definitely let you know when these updates happen!
By the way, you can check our Twitter at @JorgeGameDev and @The_Moski since those are the main platforms through which we share our current projects and progress on what we are doing. And don’t forget to give a try to Colossorama 36 if you haven’t already!
Some of you may be aware I’ve been working on a game called Skyway for the past several months. This has been a huge step for me as I’ve finally gotten really close to completing a project! I just announced it on Steam Greenlight,
Every vote counts! And if you aren’t able to vote, feel free to share the page! I’ll be doing more detailed write-ups in the following days, so be on the look out for those.
Thanks to everyone who’s ever supported me! Let me know what you think of the game! <3 -Matt
This weekend I participated in yet another Ludum Dare. This one was exceptional, however, because there were no ratings. It was also exceptional for me, because it’s the first time I submitted a (mostly solo) Jam entry, meaning I had 72 hours for creating the game. The theme was Ancient Technology, a clear winner compared to the other themes.
Apart from Ludum Dare, there was another important event – moving to our flatshare in London (I’ll study here, woo) from our temporary hostel accommodation. The plan was to move in as soon as possible in the morning, but naturally, got there around 3 in the afternoon. Luckily I could get my hands on a computer for some two hours before that, in a café.
In a way it wasn’t so bad, because for the longest time I wasn’t really sure about what kind of game I was making.
From the very first moments I was considering a bit of a twist of the theme – it is the far future, humans discover ‘ancient technology’ (something from our time), completely misunderstand it but are amazed nonetheless. Like discovering ‘windows’, then placing them in the middle of the rooms instead of in the walls, or discovering forks and knives, then using them like chopsticks. You get the gist.
In a way it’s similar to Asimov’s ‘The Feeling of Power’, although that wasn’t my intention!
So we started out wanting to make a game about defeating titans and gaining their powers, kind of like Shadow of the Colossus meets Megaman. The player would start out as a human-sized warrior fighting ‘limb’ titans (Left hand – shield, right leg – stomp), and then gaining their limb-powers as they progressed, and eventually becoming a titan themselves.
HOWEVER, once we started thinking about it more, we realized we definitely did not have enough time to make this game. So we decided to make an easier-to-make game.
We decided to do shooting, starting first with ricoheting arrows off of walls to hit targets, with certain targets requiring multiple ricochets to be destroyed. After doing some searching online, I found a physics-based game series called ‘Ricochet Kills’ on addictinggames.com, where you play as a hitman using ricocheting bullets to kill your targets. It was pretty fun, so it gave me hope that our game would be fun in that aspect to.
We turned our game into a hunting game, where you have to kill hapless animals.
(disclaimer: none of these were drawn by our artist)
@liyiming-serif came up with the idea of detection radii that would trigger the animals to run away: outer one for player detection, inner one for arrows that land near the enemies. This effectively changed our game into a stealth game instead of an action-puzzle-platformer, which ended up working really really well.
Programming – @zkwen & @liyiming-serif
Bow & Arrow Physics:
At first we had a drag-and-click control scheme like that from Bowman. It’s very intuitive, fast, and makes the player feel like they’re firing a bow. However, @monchang wanted to have a click-and-hold charging control scheme (the one we have now). I personally was against it because I really liked the Bowman control scheme, and this one was kind of sluggish because it required holding time. However, since our game turned into a stealth game, it actually worked kinda well, so that you have to aim your shots carefully, and only shoot down fast moving targets as a last resort.
We had a some trouble with arrow physics though, constantly adjusting gravity, mass, and velocity of the arrows. Our first arrows were really sluggish and didn’t feel very satisfying to shoot. But we increased the max velocity and decreased the mass. Also, our arrows didn’t bounce off of walls very much, only allowing 2-3 bounces max,
but by then we had established that bouncing arrows would not be our main gameplay mechanic.
CAMERA CAMERA CAMERA. We had much trouble with this.
At first we had the classic moving camera centered on the player, but then we discovered this didn’t fit enough content on screen, so you couldn’t see what/where you were shooting. Then we added a character-screen offset, so that you weren’t always in the center, but that made it really annoying when you were inching towards a position, then had to turn around, as the camera would suddenly swing around.
We finally settled on a hybrid (camera does the swinging when you are aiming), so that the camera switching wasn’t as annoying during platforming, but as most of you pointed out, it was still pretty wonky and really needs to change.
The blocks were really slippery and it made it super hard to jump on platforms. @liyiming-serif and @zkwen would like <this to be a challenge factor at one challenge (tbd). To make it easier, we extend the platform or put a block at the end of the platform to keep the player on the platform.>
Art – @monchang
First thoughts on art was to make something really bright and relaxing. When I considered using pixel art as a medium, I immediately wanted a beautiful seaside cliff as the background. The grass tiles used references from pokemon ruby’s end credit scene as the color palette. The sea was just a gradient from light blue to purple and in an effort to use parallax, I split up each wave as its own layer in order to create the illusion of a moving sea in game. Once I had the background figured out, I then restricted my color palette to the ones I had on screen (with some shades of brown for the trees). With the limited color palette to work with, it became easier to focus on contrast and making foreground elements pop. As a side effect, the entire scene stayed relatively uniformed and professional, which was great.
Animation wise I was focused on making the character and the projectiles fun to play around with. Taking on the teachings of Shigeru Miyamoto, the creator of Mario, I made sure to make every jump, shot, walk, and charge as fun as possible. It had to feel really good to just control the character even without the game play elements. And so I put in as much juice as I can animation wise and give the players satisfying feedback for every action.
During the entire process, I made sure to have the programmers implement each art asset as they were finished. I figured that a rolling basis was better than waiting till the end. This proved to be true because we left a lot of work to be finished at the end.
Audio – @fundamental.phantom
The sounds were all made in a couple sittings, pretty quickly. The arrow sounds are a mix of Foley and synthesis. The bird sounds are us squawking and grunting, but heavily processed using downsampling and re-pitching/warping.
However, I didn’t send the sounds to the programmers right when I finished, so they ended up being put in super last minute, and we ran into some problems, most notably the music not looping (sorry, you guys had to listen to the first few measures forever D:, but for those of you who waited, you got to hear it!!).
I really had trouble deciding an aesthetic for the music. Bossa nova was the one that seemed most ‘natural’, but I felt it was over done (I’ve played too much bossa over the past couple years). I was split between chiptune-esque Rnb and a 12-string acoustic/chip mix inspired by Super Mario Sunshine. I tried both, but didn’t really like either one. Then I tried dabbling in more ambient/moody stuff with pads, kind of reminiscent of the Fez soundtrack by Disasterpiece. Eventually I settled on some sort of swing-jazz/neo-soul chip thingy made in a few hours on the last day, but I’m still not satisfied with how it went.
I usually over-complicate things, especially the chord progressions. For this one I tried to tone it down, and go for something simpler, but that didn’t completely work. The A section is in 5/4, and B section is in 6/4. The B section was supposed to be the same time signature, but the rhythms I came up with ended up being in 6/4, so instead of changing the rhythms, I changed the time signature.
*******PS Koji Kondo and Disasterpiece are both AMAZING!!! you guys should check them out if you haven’t*******
Level Design –[email protected] & @liyiming-serif
We designed 8 levels for this game. To keep it easy for players to learn how to control the fairy, our game starts as a regular archery game. The first 3 challenges are tutorials. By the end of the third level, the player should have used arrow firing control and left/right moving control.
Then we make the future challenges much fun by adding the key platformer feature — jump. To hit the chicken that are protected by walls, the player needs to jump on platforms to gain a better position where their arrows can reach the chicken. We made Level 6 slippery bricks vs running chicken. The player can choose either carefully jump on the highest brick to gain long time window aiming at the chicken or aim and shoot chicken within an incredibly short time before the chicken notice the player and become panic then fly away. Giving the player alternative approaches to win the game and keeping difficulties balanced is challenging and fun.
After three rounds of jumping and shooting, we want to introduce a new feature to the player to keep them engaged! And this is a good timing to require the player to rely on ricochet to complete challenges 7 & 8 (given that in previous challenges they should have observed this feature when their arrows accidentally hit the grey wall).
It’s a pity that we didn’t design more challenges that blends all player control skills together due to the time limit. We would love to complete our level design some day in the near future.
Level 1: No hurdle in between the player and the chick
Level 2: Tall pile of bricks enforce the player to indirectly target at the chick
Level 3: The player can’t stand still or the chick will detect the player then flee.
Level 4: The player needs to jump on platforms to get around the wall.
Level 5: The player need to shoot when standing on the platform.
Level 6: Slippery bricks vs. Running chicken
Level 7: Create ricochet arrows.
Level 8: Harder to estimate the ricochet angle because of the moving wall.
In retrospect, we kind of spent a long time doing a lot of less-important stuff like making the ocean move, instead of fixing camera and platforming bugs.
Overall, it was a great first try, I was worried that we wouldn’t finish, let alone produce a fun game. But we learned a lot on the way about workflow, level design, physics, and stuff!
Here’s our LD36 wallpaper:
*PPS – Tori Tori Panic! is an homage to Doki Doki Panic, which is the what the American version of Super Marios Bros 2 is a reskin of (that’s why it’s so out of place compared to the other games). Also, ‘tori’ means ‘bird’ in Japanese.
It’s time to look back on how the making of ‘Burning Light’ went. I’ve compiled an annotated timelapse with most of the development:
Quick note: even though I took part of the compo, since it started Friday, 10 P.M, I actually divided my time into three logical days.
As usual, it took me all of the “first” day to come up with an idea. Before giving up and going to sleep, I decided to post my progress here. As I properly described my ideas, I had a new one that was of my liking.
As soon as the “second” day started, I quickly decided on the overall look of the game. Once again, I’ve used the DB32 palette, which has been my default palette for some time. Because of that, I feel like this game looks a lot like my previous entries, specially with LD32’s Kitten.
Although I decided on doing a quick prototype, I actually failed pretty badly at that… Because of a dumb bug (and because I wouldn’t give up on mathematical correctness over simply finishing something) that took me around 6 hours to fix, I wasn’t done with the prototype until the end of the first 24 hours. By that time, I had no other choice but to go with the idea…
Luckily, whenever I to took a break, I would either play the guitar or draw something. So even though I was running quite late, I also had already done most of the graphics. But I had no actual gameplay… And I didn’t have time to add sounds/music…
I woke up early on the last day and start to draw the UI and the player. From that, building that initial mock into a game was somewhat easy… until the final few hours.
When I started to create the level, I began to notice lots of corner cases. I tried to avoid them and come up with a neat level design, but I couldn’t do it. Eventually, I simply gave up a created a simple and short level.
30 minutes before the deadline, I had finished something (questionably) playable, so I began to package everything. I must say that my workflow for building is really effective. I quickly built a fully packaged game (with all required libs) for both Linux and Windows.
Overall, even though my game was way simpler (and buggier) than It could had been, I’m quite happy with the results. I may do a quick post-compo version, since I’d like to enhance my library’s collision detection… We’ll see…
Now (well, when I get back from work XD), I’ll go back to playing and commenting on games! o/
Here is a post mortem written by Edu ‘@sodap_’ Alonso, the artist half that worked on our Ludum Dare 36 entry, Revenge of Tutankhamun. He writes about the overall experience teaming up for this Ludum Dare, and the right and wrong things learned on the experience. And if you haven’t tried or game yet, well, do it now and provide feedback if you can!
REVENGE OF TUTANKHAMUN, A LUDUM DARE #36 POST MORTEM
Revenge of Tutankhamun is an arcade-puzzle game inspired by Chu-Chu Rocket. It was created in an event hosted in Zaragoza, Spain for Ludum Dare 36. The theme for this Ludum Dare was ‘Ancient Technology’, which inspired us to make a game about traps in ancient tombs and we ended up making something similar to Sega’s Chu-Chu Rocket, a classic for the Dreamcast and GBA.
In this game the player takes the role of the Pharaoh Tutankhamun, who needs to design the layout of the chambers in his pyramid in order to keep his treasure safe from any looters. These explorers will always walk forward and turn in a predetermined way unless given directions by a magic arrow placed by the player. The magic arrows wear out each time an explorer steps onto them so the player needs to keep replacing them until all explorers are dead.
Gameboss Jam Zaragoza
Both of us are members of a small online community of Spanish-speaking indie devs called Indiecalipo in Telegram, where we figured out we should make a real-life gathering for LD36 because it would be cool to meet each other, have fun, and make games. Juan Castillo (@Acrimiens on Twitter), from Zaragoza-based indie developer Mechanical Boss went ahead and started organizing the event.
The event turned out way better than we had pictured initially, as the jam was hosted in a community center for art and technology called Etopia where all the participants could stay for the whole weekend. We had a blast partying and doing gamedev battles on Friday before the theme was announced and then most of us went to bed to come up with an idea in the morning and start working. It was an amazing experience and it’s safe to assume we all are looking forward to repeat as soon as we can, maybe in another place so Juan can concentrate on the fun and the game making while others take the hosting part off his shoulders.
To be fair, the theme ‘Ancient technology’ wasn’t really unexpected, as it had lots of votes in the preliminary rounds, and we had talked about possible directions to take in the jam if that turned out to be the actual theme, for example something like a Ghost ‘n’ Goblins with a caveman having to start a fire and make a spear. However in the morning we deemed that idea too unoriginal and played out so with the help from CremaGames’ Guillermo Andrades (@xyaw on Twitter), Rodrigo and I came up with a new one, a game about traps in a pyramid inspired by Chu-Chu Rocket.
From there, we started working. Rodrigo started implementing the mechanics and used Tiled Map Editor to create the levels, and I started doing some art. I intended to make a concept and then make everything in a pixel art style but people liked the concept so in the end I just made a higher res version of the assets that were present in the concept art. We didn’t have any problems, it was pretty much smooth sailing for the whole process, which was a pleasant surprise for us.
On Sunday we realized we had some problems with UI/UX, it was really hard to control the game and we tried to solve that with UI but in the end that didn’t really help. Sunday night I stayed up until late as I searched for some free to use music and sounds. We still had some time left on Monday so on the train back home Rodrigo made a handful of new levels with a bigger challenge, made a build of the game and uploaded it.
What went well
What didn’t go that well
What we learned
After the great experience in Zaragoza, we are looking forward to working on more projects together and also to attend more real-life events. You should always team up with someon who shares a similar mindset and level of expertise as yourself, that will make things go much smoother. However, you need to strike the perfect balance between thinking and doing.
One more jam, one more post-mortem. Such is the way of life (for me at least!)
Checked out the theme as it was announced (4.00 am around here). I knew what was coming based on the previous voting rounds, but no idea sprang up immediately (which is usually the case to be honest).
The brainstorming began officially in the next morning. Ranquil joined the storm later at which point all I had was a vague strategy game concept about scavenging and stealing technology. Movement of armies would have taken place on a world map and the action on a separate battle map. In the next few hours I managed to simplify the idea down to a single map close to the style of Advance Wars. Nine hours had already passed since the start of the jam so we set out to work with minimal fuss.
Light turn-based strategy isn’t the most demanding of genres and I had in fact created a similar prototype some 4 years ago. Unfortunately, the half-life of a codebase is way less than that and after 5 minutes of perusing I decided to rewrite the whole thing from scratch. That was a good call. The only system I reused was an A* pathfinding system, which I’ve been using for years in other projects including the last few jams.
No severe problems on this front, just a lot of work.
All the problems piled on the graphics artist this time. First off, Ranquil had been working for the whole summer on other projects, didn’t really like the genre and lastly the drawing table broke when only one asset, the character sprite and walking animation, had been finished.
Due to this calamity all non-essential assets were cut, among these battle animations (and any possibility of a separate battle screen). Ranquil shifted focus to other tasks, like audio research (and found a great song right away!). Luckily the drawing board issue was resolved by Monday and the last essential assets, like the desert ground tile and the main menu background image, were made and implemented. Despite the last day push some programmer art slipped in. (I take what I can get!)
With the game itself feature complete and playable only minor tasks remained: Audio implementation, main menu and tutorial. Once again, nothing I hadn’t done before, although for a jam tutorial this one takes the cake! The whole thing was completed with 2 hours to spare, a new record that. The building and uploading process took about an hour more for the tired mind.
Never have had this grave a production setback before, yet thanks to the small asset requirements of the genre the end product didn’t suffer significantly. The 72-hour jam is much more relaxed than the 48 hour counterpart with time for sleeping and breaks. I like that.
Had a good time and, once again, felt genuinely happy about the accomplishment. Now that is a feeling like no other.
And have a nice, relaxing post-jam life!
I’ve been updating my game.
Now there’s more sound, a mute option, tweaked enemies, and better game-play.
You can find it here.
Post mortem sounds depressing! And wrong—the game just came into being, did it not? c; Here’s something about our two-player explosive hockey game (Pucketeers of Atlantis) post jam, at the very least!
Do begin by having a peek at the game to have an idea of what we’re talking about in the first place!
Let’s begin here and now. The final game we submitted for the jam. Well, you can see above. It’s a two-player game, primarily intended for gamepads, where each controls a team of three characters to battle it out in the rink.
The twist: a periodically exploding puck, and little item boxes that pop up from time to time that can be grabbed in order to be activated when the player is holding the puck (two of these were implemented: one making time go slower for everybody except the current pucketeer, and one making everyone else fall over, both offering a momentarily opportunity to go straight for the goal).
It is perhaps not the best take on the theme, ancient technology. The idea was that the puck and hover boots and items to pick up and some of the characters (robots) were supposed to be ancient relics of long forgotten Atlantis, but that is admittedly a stretch in the first place, and it’s not exactly evident in the game itself, but needs to be spelled out.
The final game that you now see wasn’t entirely planned as such from the beginning. The original idea was “(J)RPG hockey”, and there were all sorts of wonky ideas floating around, including turn-based elements, strategy, stats and very exaggerated features of all sorts, as well as closeup one on one sequences when dribbling or tackling.
Not much of that stuck around, partially due to time constraints, partially due to reconsiderations of what would be fun to play, but at least the characters still look kind of like those of early Final Fantasy games (no time for proper human modelling, sorry!).
Extended! Brushed up! Packaged. Networked? There are currently some considerations to do a little more work on this game beyond LD, making it more fun, perhaps allowing a third team on the field at the same time, and perhaps even some rudimentary online play.
Who knows? Such projects have a tendency to blow up and not happen, but it’s a fun thought, and there will probably be some experimentation at the very least. We’ll see!
I’m both proud of, and really disappointed with my entry, “CRTs are Ancient, right?“. Gameplay-wise, I think it’s probably the most polished, and with the most potential for continuation. Content-wise, I’m really disappointed. There’s a lot I wanted to do, and a lot of potential, but I was too focused on all the mechanics to be able to get any of it implemented.
All of my other entries usually take at least 10-15 minutes to play through and get a good idea of, whereas this can probably be done in five or less. There’s one proper level in the game. One. That’s the shortest of any Ludum Dare entry I’ve ever made. Considering how much effort I put into making the mechanics, I’m really sad there’s only one puzzle to use them with.
I think the biggest mistake was trying to make so many features; it’s a stealth game, a hacking game, and a first-person shooter all rolled into one. You use the computer terminals to achieve your objectives, doing things like printing important documents, toggling lights, or working with elevators. You can hide in the shadows and move swiftly, like a ninja, and never have to kill a single guard. You can rambo through and shoot all who stand to oppose you. All these mechanics are pretty decently polished, but I spent so long making them all that there wasn’t any time left to build a game around them.
Level creation for puzzley games is always a pain, there’s no denying that. I was lucky to get four made for Shift back in LD35, and it was a real struggle to get them all working; and the number of mechanics to juggle was *way* smaller. I wanted this to have lots of interesting puzzles built around timing, working with lights, shadows, etc; true light-n-dark stealth is hard to come by these days. I wanted the computers to feel like an important part of the game; out of everything, they’re still the most clearly ancient. But instead, they’re more of these simplistic things that you type away at for a couple of seconds, do whatever it is you need to do on them, and then go back to running/gunning/doing whatever it is you do.
I had these grand dreams of putting some social commentary on them; if you stopped and used “viewData” on some, you’d get these little insights in SCI-style files, where someone at the coropration (aka: me) would have written some info on something or another. An entry on Tulpas, or psychology, social studies, even OS security holes. Social commentary and story building. It was going to be awesome. But when it came time to write them, I realized there wasn’t any time to spend sitting around writing walls of text; not many people would end up reading them, and I needed to focus on level-design or gameplay mechanics.
In the end, I’m happy-ish with what’s out, but disappointed by all the lost potential. Now, if you’ll excuse me, I’m going to go relax in No Man’s sky for a few hours before going back to playing and rating some of your games.
I wrote a post-mortem for my game The Language of the Gods, and I’m publishing it here as well. I hope you like it, and please play my game and tell me what you think!
I woke up at 7AM to see the jam’s theme, “Ancient tech”, and went outside for a long walk to feel refreshed and let my mind wander a bit. Then I headed to a café to have breakfast and do some brainstorming. I really love doing mind maps for jams, it really helps me in finding out ramifications of the theme.
And then I had an idea I really, really loved. It was a story-driven game with the plot involving an explorer in an deserted alien planet trying to figure out how to get back home and discover the secrets of the now long lost alien civilization. Topics would include Good & Evil, the nature of reality, personhood, etc.
And to deliver all of this, I envisioned a kind of atmospheric game, with lots of exploring, some puzzles and opportunities to chill out while you go unfolding the story.
Still at the café, I doodled some concept art:
Problem with this idea? Way huge for the scope of a game jam. But I wanted to make something with this idea, so I considered two choices:
I was reluctant to opt for Twine because I had never used it before. So I chose to make a vignette as a proof of concept and see whether people would like that kind of game or not.
As you know from previous post-mortems, I like to spend the first day of Ludum Dare coding, and leave art for Sunday. However, when I opened Pyxel Edit to draw some placeholder art, I couldn’t stop myself and I ended up drawing a pixel art version of the sketch I made at the café.
For the curious, I used the Dawnbringer’s 32 colour palette, that comes as a preset for Pyxel Edit –having a reduced colour palette helps me a lot in drawing pixel art. And then I found out this app could export a PNG with all the tiles (a tilesheet), as well as a tile map in JSON.
So, TL;DR: no placeholder art this time.
There was a problem, though: Pyxel Edit tile map’s exported files were huge. Even after minifying, they were still heavy. So I added a task to my Gulpfile to manipulate this JSON and only include the information that I needed. The result? Going from more than 500KB to 8KB, something more reasonable for a map!
After lunch I resumed programming and had a bit of trouble trying to import the data. My first strategy was to mimic Tiled’s file format, since Phaser could directly import that. However, the map was not being loaded properly, so I gave up and imported the data into a
Phaser.Tilemap myself. Once I had the map rendering, I included the main character and some passing clouds as decoration.
Since story was important, I decided that the next thing I should do were to display text. I drew a tiny font, using PICO-8 font measurements (3×5 pixels per character). And then implemented rendering of text of up to three lines.
Now that I think of it, I did quite a lot of stuff on Saturday, but at that time I went to bed with the feeling that it was not much, since there were many more things I would have wanted to do.
I woke up on Sunday and did the same as the day before: going out for a walk to get fresh air and clear my mind.
I was worried about gameplay. “Will my game be fun if it’s just an story?”, “If so, should have just made a Twine game?”, “Maybe I should make big levels and allow for exploration”, “Maybe I could add some puzzles to it”.
I started to code events –so I could implement a story– and refine the text display.
After that, I needed to include some puzzles. I knew that in the grand scheme of the game the game’s beginning mistery would have to do with music, so the simplest puzzle I could come with was Simon.
Once the mini-game was created, I implemented the artifacts that would launch the puzzle when being interacted with.
And then this made the first playable version of the game! I uploaded it and added a message once the puzzle was solved asking for encouragement and feedback! I really needed some cheering up –and it worked, by the way!
It was already the evening, and I still had a lot to do. It reminded me a lot of once of my previous Ludums, where I overscoped and I submitted a really rough entry. But somehow I managed to keep my cool and not panic much. It was obvious that I wouldn’t have time to do a lot (or big) levels, so I decided to cut that part without too much drama from my part.
I went to draw some simple animations for the main character and got hooked into Pyxel Edit again, and ended up doing more frames that I wanted to!
It was getting late and I still hadn’t a story in place, so I coded bits of the story in that single level. I made a mistake and I should have hardcoded the whole thing, but I wrote some kind of semi-generic system instead.
Lastly, I drew another level, this one featuring another type of object that was not an artifact: a crashed spaceship, that will add a bit of info to the story. This level also acts a bit like a tutorial, showing the player tooltips about how to move and how to interact with objects. This has been the first time I included an in-game tutorial in a Ludum Dare and I think it worked wonders: nobody asked me how to play the game.
After that it was about 11PM and I still needed to compose some background music! The game already had some sound effects, so gameplay-wise it was OK, but music adds a lot to the atmosphere and mood and that was one of the aspects I wanted to try out and get feedback about!
I used Audiotool for music. I’m still not proficient with it, but I had learned enough so I could comfortable remix some samples and even play a melody with a custom-made sound from a synth.
After integrating the music into the game, I just needed to create a title screen and run a few walk-troughs to make sure everything was OK. I ended up submitting my entry at 1AM, despite I was aiming for midnight, as usual. However, it felt amazing to finish and have something playable!
Audio and graphics:
It’s been a hectic 3-day marathon but we’ve completed our 3D tower defense game, Blocky Hill!
Terrain is an important part of the game; set up boulder traps along long lanes for massive damage, you can even build terrain to place more towers! We hope you like the game 😀
I made the random map generator. Since there are towers that are placed on the sides of blocks as well as on top, it’s important to have plenty of hills to place all kinds of towers, but not to have deep valleys because it blocks the camera. Perlin noise worked great here: it makes these nice smooth hills.
This post is my Ludum Dare 36 post-mortem and will be mostly about the development process I went through when making Crossbow Assassin. I’m going to be honest here, I had no clue what I was doing for this Ludum Dare. I totally screwed up my submission. I had submitted 6 hours ahead of schedule but absent-mindedly went back to edit the description after the submission deadline. This changed my submission from a “Compo” entry to a “Jam” entry. Thankfully, one of the Ludum Dare admins, sorceress (thanks!), changed it back to a “Compo” entry for me. I’m not even sure if I’m doing this post-mortem right.
Anyway, it was my first time taking part in Ludum Dare and my goals were reasonably modest. I wanted to prototype something simple and fun and most importantly, to finish a game. There would be no fancy art or audio, just finish making a game with interesting mechanics. I was psyched and raring to go. Since the jam was taking place in a different timezone (UTC-07:00), I had to plan ahead and rest up. I would be waking at 9am on Saturday, 26 August 2016 and my submission deadline would be 9am on Monday, 29 August 2016. I took leave for Monday so that I could have a day of rest before going back to work on Tuesday.