Join us on Twitter and IRC (#ludumdare on Afternet.org) for the Theme Announcement!
Thanks everyone for coming out! For the next 3 weeks, we’ll be Playing and Rating the games you created. You NEED ratings to get a score at the end. Play and Rate games to help others find your game. We’ll be announcing Ludum Dare 36’s August date alongside the results.
New Server: Welcome to the New (less expensive) Server! Find any problems? Report them here.
My first LD entry was not so good (really, I don’t like it at all), but I’ve got a lot of feedback from people, saying something like “Hey, that’s cool! Just keep doin’ the thing” (thank you, guys! There’s nothing more motivating in the world, than your feedback). So I’ve decided to use every little chance to get better in making games. That’s why I’m in for MiniLD70!
The last LD theme wasn’t inspiring for me at all. I just spent the first day frustrated and trying to get something great from “Ancient Technology”. Now I feel different: MiniLD theme looks interesting. I’ve got an idea to make just a clone of a tabletop game for two persons (yes, multiplayer again), that is absolutely not random-driven (like Go or Chess). But it will not look like a tabletop game. Let’s see how cool can I do!
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.
Game Idea and Design
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.
What went right?
Clear Idea and Direction
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.
Game’s Polish and Submission Hour
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.
Cloud Build and WebGL Version
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.
What could have gone better?
Late Design Decisions
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.
Unexplored Mechanics and Balance Issues
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.
Conclusion and Closing Remarks
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:
Have a clear idea and direction right from the beginning helps quickly shaping up the project. Having mixed ideas can hinder development.
Leave an extra time just to make builds and wrap everything up in order to make sure the submission hour is used for submission and showcasing alone.
Don’t be afraid to check other services and opportunities as they might help you solve problems you normally don’t have the power to solve. If we hadn’t checked Cloud Build we would have needed to ask someone to make a Mac build for us.
When possible, compile a Web version. This allows players and users to play the game directly on the browser, something more accessible than a downloadable version.
Important design decisions should be made on the first day instead of delaying them until they need to be forcefully made.
Focus more on playtesting and exploring diverse alternatives when a certain mechanic or balance change doesn’t feel as solid as others.
Find someone to help with the audio in order to create a more distinct, personal and unique feeling to the game.
Some features along with Controller Support and Player Incentives could be bigger focus points for future projects, given there’s enough development time for these ones.
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,
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.
The future idea
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!
I’m just posting a shorter version of my entry’s post-mortem, since I just typed up a longer version of it on my dev blog, here.
I didn’t really expect to finish my entry for this 36th jam, even with my poor planning, but I suprisingly did, unfortunately with many features cut out.
Because I had to cut out a lot of features, the gameplay was not very good, as pointed out by other people here who played it.
As far as a story for the game went, I didn’t put too much time into it, since the gameplay and graphics will strongly overshadow it. It was kept to a very minimum.
I was most proud of the game’s graphics, since it fared better than the other parts of the game. I also had the most fun creating the sprites and stuff.
As a first LD jam entry, I felt that it wasn’t bad at all, despite the lackluster gameplay. If this is a game that you guys would like to be developed further, post LD, it’d be great to hear your thoughts. If you haven’t played Glutenburg yet, check out my entry here.
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.
The team was formed by a programmer, Rodrigo Díaz (@r2d2rigo on Twitter) and myself, Edu Alonso (@sodap_ on Twitter) as an artist. This was our first game working as a team.
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
Both of us have a fair amount of experience at our roles so we didn’t run into unexpected problems or blocks during development.
Making a new take on Chu-chu Rocket was a good idea. It is a great game that needs a more modern version with better presentation and new content.
We don’t have any serious game-breaking bugs that we know of (please do try and prove us wrong and report any issues you may encounter!).
The art turned out pretty decent for game made in under 72 hours.
No nervous breakdowns by any of the members of the team.
We finished the game without too much stress.
What didn’t go that well
We gave too little thought to the game and level design. The gameplay is a bit broken, it’s a weird mix of puzzle and twitch action that isn’t fully working.
Only Rodrigo worked on level design, I wasn’t of much help in that aspect and I think the lack of feedback on my part hindered the final result.
We probably worked too much while thinking too little.
I lost a lot of time on a concept art mockup and in the end I had to change the art style because of it.
We based the game on Chu-Chu Rocket but we didn’t look at any videos or played the game. We played by ear and made some design mistakes that would have been solved by checking our references.
What we learned
A good team of experienced and talented people goes a long way for a successful and stress-free game jam.
We need to think and talk more about game design when making games.
Chu-Chu Rocket is an amazing game that needs a remake.
Concept art should be done fast and with the final style of the game in mind.
Check out your references, don’t rely on your memories.
Real-life events are a blast.
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.
I did try & paste the full post here, but unfortunately it was too media heavy and my embedded twitch stream clips were not working. If you’d like to read more, you can do so here.
Yes – you read that correctly. We finished our Ludum Dare #36 game and the end result was “Why Am I In The Past? Who Cares! Shoot The Romans.“, affectionately known as #WAIITPWCSTR for short (videos included further below).
Ancient vs. Technology comes to a head in “Why am I in the past? Who cares! Shoot the Romans” (or WAIITPWCSTR for short).
You’re in the past for some reason. How long can you survive against hordes of aggressive ancient Romans?
Pick up your gun and blast your way through history in this endless wave survival first person shooter.
Check out the Ludum Dare link and let us know what you think. The premise is, pretty much, as it is in the title!
We had an absolute blast making this, it really confirmed we had made the right decision in setting up Whitepot Studios, and more importantly, gave us a bit of validation that we actually can throw something together in 72 hours and have it be playable and downloadable.
We made the 2D menu graphics/logo/HUD assets made from scratch, and the sounds & 3D assets were free online – most available in Unity Assets Store or FreeSound, although some texturing was done to them.
Something which we hadn’t done before, which was a bit baptism-of-fire-esque was send the link to some Twitch streamers to see them play it live once we had submitted to the Ludum Dare website. It was really nervewracking, and felt like presenting a university project all over again, except this time to anonymous strangers on the internet with little way to immediately interact with them the second something goes wrong.
Anyway, 10/10 would do again. Yes, there were bugs, and yes, people found exploits – which was great! It meant people were playing it long enough to come across these issues and report them back to us.
So, after begging all our friends to try it out, at my time of writing this, we have 50 downloads! 50! Just kidding, we don’t have 50 friends (haha), but we do have 50 downloads according to itch.io, which we discovered is a really nice way to host downloadable game files and get analytics also.
We are definitely doing a post-compo patch, taking into account the feedback we have received and comments we received on the Ludum Dare entry itself.
One great thing about Ludum Dare is the feedback system, which encourages you to leave feedback on other games so people leave feedback on yours. It doesn’t feel like a chore at all if you genuinely enjoy playing the games, giving constructive feedback, and getting new inspiration.
I really pushed myself to the limit for this Ludum Dare 36 game development competition. Looking back at the length of time for all of my live streams on YouTube, I calculated that I spent over 22 hours of development time over two days for this event. Since there is no voting or rankings this time, I felt more encouraged to do my best work since my game will only be played by those who genuinely want to play the game. The game that I developed is called Ancient Adventure, which has gameplay based on classic adventure style games.
The premise of the game basically came from some of my discussion points on the latest episode of the Knoxville Game Design chat podcast, which I am a frequent contributor. On that podcast, we discussed Anodyne, and I made several points about how they got the classic Zelda formula wrong. The following is a list of some of the points that I made, and how I implemented those in Ancient Adventure.
A “compass” upgrade showing where the key items are located.
I created a compass item, which I call the all seeing eye which displays on the mini-map the location (in red) of all of the collectible artifacts. With the mini-map for this game, I tried to make my map more intuitive, by having all of the rooms grayed out initially, and the rooms that the player has visited in a brighter shade of gray. The player’s current position is highlighted in green.
Keeping with the ancient Egyptian theme, I used the classic eye hieroglyphic. It’s the eye that is a popular tatoo and similar to the mage symbol in World of Warcraft. After some research, I found that this is actually called the “Eye of Horus”, which is a symbol of health and protection. The full myth of Horus can be read on Wikipedia. Ironically, the Eye of Providence, which is depicted on top of a pyramid and on the back of the United States dollar bill, has nothing to do with Egyptian mythology. Using this theme made me wonder why there are relatively few games and movies based on Egyptian mythology, since there are numerous games based on Norse and Greek mythology. The only game that comes to mind is Age of Mythology, which is actually based on a collection of ancient religions. There seems to be a lot of untapped material in Egyptian mythology which could be made into games. In the English language, we named our planets based on Roman gods and the days of the weeks based on Norse gods. The best known reference to Egyptian mythology in our culture is probably the Steve Martin King Tut sketch on Saturday Night Live. I wonder if Egyptian mythology has been written out of our history because the culture was overly oppressive, using slavery to build pyramids to their gods, which was at odds with the Abrahamic religions (Judaism, Christianity, and Islam). I will admit that I would have never made a game based on ancient Egyptian culture, if it had not been for the “Ancient Technology” theme for this Ludum Dare.
The point of gathering collectibles.
I used the Egyptian Ankh as the ancient artifact that must be collected to become the supreme being. It is a quick and simple objective and story, but it is at least something that gives a little exposition of the game. I just had in my mind one of the typical gods from Egyptian mythology, who has the head of a dog-like creature and the body of the human. Since there were many Egyptian gods, collecting these artifacts would turn you into the “supreme being”. It’s not a very noble objective, but I think it’s something players can wrap their heads around, since many ancient myths are about gods fighting each other to become the strongest and most powerful. Again, after some research about the ankh, I learned that it is actually a symbol of life. So if I had it to do over again, I probably would have made the ankh the symbol used for the health meter (i.e. “hearts” in Zelda) and made the collectible something different. In this game, the health meter is represented by a bird creature (at least that’s what I intended it to look like) which was used in many Egyptian hieroglyphs. The important thing was to have a symbol which was symmetric, since I intended to split the icon in half to represent a half unit of health remaining. Unfortunately, I didn’t have enough time to represent half health units, so I just doubled the number of full health units. Under the hood, the health value is just an integer anyway.
I tried to ensure that all of the collectibles were spread evenly across all of the rooms. The right side of the map is heavy on ancient artifacts. This is balanced by having the staff upgrade on the left side of the map. It is possible to gather the artifacts without getting the staff upgrade, but having the upgrade makes completing the game much easier. Also the all seeing eye item is in the first room to the left, making it an item that should be picked up early in the game to assist with finding the ancient artifacts, which is the primary goal of the game. I put the all seeing eye in the room to the left, since players of the classic Zelda game are accustomed to starting out left being a dead end.
How to tell if you have collected all of the required items in a level.
Below the health meter, the number of ancient artifacts (ankhs) the player has collected is displayed. The icons are initially displayed as blacked out, which reinforces to the player that there are eight to collect. As the items are collected, they are filled with the purplish color that I decided to use for the ancient artifact item. For the pickup in the game world, I used the same two rotating spotlight effect again, which looked really nice in my game Kitty’s Adventure.
Weapon attack swinging animation.
In classic Zelda fashion, the player starts with no weapon and is defenseless until the player picks up a weapon. In this game, I decided to make the player’s weapon a staff.
In the early stages of development, I spent more time (about 5 hours) than I had desired on getting the staff swinging, collision detection, and animation working. I had to decide if I wanted to animate the staff swing in Blender or the Unity Mecanim interface. I decided to go with Mecanim, and I found that the benefits to be great, because the Mecanim animation also animates the capsule collider and all of the children objects with it. Since I had a light source added to the end of the staff, the light source moves with the swinging staff, which is a really awesome looking effect! The major issue that I had with Mecanim was moving back to the idle state after the swinging animation was completed. I set a Mecanim boolean value to start the swing, but there was no way to set the boolean back to false after the animation completed. The swing animation would just keep repeating. After looking at some Unity Mecanim tips, I learned that a Mecanim trigger (different from a collider trigger) could be used instead of a boolean value, which would set the animation state back to idle after the attack animation completed, which solved my repeating swing animation problem.
By default, the staff had a mass value, which would cause enemies to be deflected when it. It was a nice effect, but it would also push the player back slightly as well. I made a design decision to set the mass of the staff to zero to eliminate the recoil effect on the player. I think it may also reduce the possibility enemies getting pushed into the wall.
In Blender, I modeled a simple staff with a gem on top. There is one upgrade to the staff, which doubles the attack power. The enemies that normally take two hits to defeat are killed with one strike. The upgraded staff is a simple texture swap and a change in the color of the light source. Originally, I had the standard power staff using a green colored gem and green light, and the upgraded staff as a blue gem with blue light. However, I thought the blue color was too close to green and it didn’t show up very well, so I changed the upgraded staff color to red.
One check that I had to add was to not populate an item that has already been picked up in that room. For the ancient artifacts, I had to keep a list of the rooms that had collected artifacts. If the room number is in the collected artifact list, then an artifact item should not be instantiated in that room. The same goes for the staff pickups. If the player’s staff collected boolean is true, then don’t instantiate a staff pickup. If the staff’s power has been upgraded, then don’t instantiate the staff upgrade.
The purpose killing enemies.
In Ancient Adventure, the player is forced to kill all of the enemies in a room to proceed. Once the enemies are defeated, the doors are lowered which allows the player to proceed. The number of enemies remaining is determined by taking the child count of the EnemyGroup Unity GameObject. When the room is setup, enemies are always assigned to the EnemyGroup GameObject by using the SetParent method on the tranform property of the enemy GameObject. If it is equal to zero, then the method which lowers the doors is called. One problem that I came across is that this led to the door lowering method being called on every frame after the enemies are defeated, which caused problems with the door sound effect being started on every frame. To resolve this, I had to create a boolean value which tracked if the door lowering method had been called, so it is only called once when the enemies are defeated. The door sound effect was created by me flipping the pages of a book over my Blue Yeti microphone, and then lowering the pitch in Audacity. I was impressed with how much it sounded like a huge slab of rock being lowered into the ground.
When the door is lowered, the Exit GameObjects are accessible. These are simple GameObjects with cube trigger colliders. When the player triggers it, then all of the child GameObjects under the Room GameObject are destroyed, and then the GameObjects for the next room are instantiated and parented to the Room GameObject. The player is moved to the opposite side of the room, to give the illusion of transferring to the adjacent side of the next room.
One problem the Exits originally presented was that the enemies could go through them (because it is a trigger instead of a standard collider). Since I wanted to keep all of the enemies inside of the room, I added the doors, which had a regular cube collider, which kept the player and enemies inside. I had to move the exits back one unit outside of the room (determined by the exit row or column), because the player could still trigger the exit when touching door.
Another problem with wall colliders in general was enemies getting stuck in walls. In my code, I had it so that when an enemy collided with a wall, it would make a 180 rotation on the Y world axis, and then start moving the other way. However, the enemies were still getting stuck. After some debugging, I realized that after the enemies did the 180 turn, they were still getting a collide event on the next frame. Therefore, I had to wait until the OnCollisionExit event was called for the enemy on the wall, before I would accept another OnCollisionEnter event. There is still a small bug that occurs sometimes, when the enemy collides with a wall, and then immediately turns, placing them in a direction where they can not exit the wall. The enemy turn behavior is defined in a separate Playmaker FSM, which is independent of the wall collision FSM. Usually, after a few turns the enemy will eventually be put in a direction so that it can exit the wall. Again, the chance of an enemy turning during a wall collision at the same time is fairly small to being with, but it is noticeable when it happens, which would lead to players thinking that the game is buggy. Sometimes it seems like gamers put every tiny glitch (whether it be game breaking or not) under a microscope.
While I was developing the game, I had so many ideas that I eventually had to write the down in a text file, and I ranked them from most important to least important. The currency system was a fairly low priority, but I was able to add a gem display value and have the enemies sometimes drop gems when they are defeated. I used the Blender gem generator to make the gem meshes, which turned out a lot better than I expected. The way the light reflects off of the edges looks almost too perfect. There are two classes of gems which add 1 (green) or 5 (blue) gems to your total. The gem dropped is based on the strength of the enemy defeated. Unfortunately, I didn’t have time to implement a shop or things to buy with your gems, so it is purely there as a score value. The gems dropping when an enemy is defeated, along with the health drops, also give more of a purpose to killing the enemies.
What could be made better?
There is really no elegant way to do a 2.5D Zelda clone. If you do a completely overhead view, then you are only seeing the top of the player’s head. If you do an angled view, then there are issues with things popping in that should be outside the player’s field of view. There have been many articles written about this, with one solution being an overhead view with all of the items rotated at an angle. I decided to use the angled camera, and I just use a camera fade when the character enters another room. With the angled camera, to keep the realism, all of the rooms would need to be instantiated in the player’s field of vision, which would not be very efficient. Also, it would be presenting the player with more information than they need to see. The player should only be focused on the current room. One possible solution may be to create very tall walls around the room, to keep them from seeing outside of the current room, which would keep the realism. Another option would be some sort of fog around the room, which would prevent the other rooms from being visible.
I defined all of the rooms in text files, which are assigned as text assets. Walls are 1’s, doors are 2’s, enemies are lowercase letters, and item upgrades are uppercase letters. Using text files makes creating the levels fairly simple in a text editor. The file contents are parsed using the string Split function and the resulting strings are looped over and read as character arrays. Ideally, these text files should use a better format such as XML, but that would increase the size of the level files and the bulkiness of using an XML parser would probably not be beneficial for load times. Alternatively, the level definitions could be turned into bit strings, since each cell can only have a limited number of values. However, it would make it much less manageable, since it wouldn’t be editable in a text editor. The bit string level definition approach would be good for an online version of the game, if the level data was variable and had to be passed between client systems.
Since the character model was created in Blender and the staff swing animation was created with Unity Mecanim, the arm and staff don’t always line up properly during the swing animation. I could try to resolve this by recreating the character model swing in Mecanim as well, so that the arm properly aligns with the staff. Trying to animate removable components on a character model has been a problem that I’ve had that I’ve never found a good way to solve.
There really aren’t any Easter eggs in the game, but there were some subtle influences from other media. On the Game Over screen, the maniacal laugh was a reference to the game over screen from Zelda II: The Adventure of Link. On the game completed screen, I tried doing my best Val Kilmer Iceman impersonation of his Top Gun “You are still dangerous” line. Some of the room layouts were obviously influenced by the dungeon designs in the original Legend of Zelda for the 8-bit Nintendo Entertainment System.
Overall, I was satisfied with the game that I developed for the Ludum Dare 36 competition. Since I have a solid core engine and gameplay, I plan to develop this game further and release the game on various platforms.
I was the programmer for a 3 man team (programmer, artist, soundbro) that made the entry Dino X for Ludum Dare 36. I used C++ with SDL to write the code, and started from only a small math library (clamp, v3 functions, etc.). Overall:
Overall I think our project was pretty successful. We managed to complete something that at least resembles a game. Unfortunately, some basic elements of the game never made it in, such as scoring, due to fatigue. What went well: 1. Physical Location.
I really wanted to get people together in one location that wasn’t anyone’s house so there weren’t any distractions. This worked very well and we were all productive the entire time we were there. I think a large part of our success, at the very least my success, was due to simply not working from home this time. 2. Game Idea
This went by very quickly and we adjusted it a bit once we got started before locking it in. Going into this we wanted to do some kind of platformer, but we brainstormed once the theme was announced and came to a few possibilities, waited a bit, and then all agreed on the final game style that we went with. Once programming and art started, we decided to change it a little bit after a few experiments. 3. Experience
This was an excellent experience. I learned a lot, as did my teammates. The time pressure is a really nice thing for getting stuff done and learning how to do things. I think that not spending a lot of time to try and figure something out and instead just doing it actually helps a lot for the first time you’re doing something. You can learn how to do it properly later, but the experience you get from at least doing it at all helps inform the learning later. What went not so well: 1. Preperation
I didn’t properly prepare ahead of time, so i was starting from approximately zero code, and I’m not quite fast enough to work from that far back. 2. Bottlenecks
Our workflow wasn’t set up very efficiently, so a few times we stalled as people were waiting on me to add features so they could see if adjustments needed to be made, and we didn’t have stuff planned out with enough detail that people knew what to do while their current work was stalling. 3. Timing
We had some issues getting to the location and back, mainly to do with stuff going on in people’s lives at the time. This cut into our start time a bit, but it ended up not affecting a lot because of the next point. 4. Endurance
We started on late Friday/early Saturday, and by mid-Sunday we were mostly out of steam. Most of us had really done something like this before, save for my very much failed attempt at LD33. I think the main issue was that we were just mostly starting out from bad places in terms of how rested and focused we were. 5. Requirements
This was probably the biggest issue. We didn’t have clear standards for how we were going to do assets/gameplay stuff from the start, which ended up causing some wasted work and loss of motivation when some stuff had to be thrown out. 6. Completion
Due to fatigue at the end, some basic things that woudln’t have taken long to implement and would have gone a long way to making the game better weren’t put into the game. 7. Gameplay
The game has issues in the gameplay department. The scrollspeed is somehow too fast and too slow at the same time, the game is too difficult but also easily breakable in terms of difficulty, there is no way to win the game and no score tracking, etc. It has the core gameplay and literally nothing else, so it was half successful, but not fully. Takeaways
Having a dedicated physical location where everyone in the same room that isn’t anyone’s house was a huge boon, and I will be doing this if I participate in the future.
You have to have clear and well-defined standards from the start, especially for art assets. Things like perspective and size shouldn’t be something that anyone has asks about.
Make it so that people always have something to do. We couldn’t afford to have people stalling with no work because of the time constraints, but we did. The original plan was to have the game easily playable and tweakable by the other people when they weren’t working on something, and I had most of that implemented, but not the final parts to make it work.
Having the game be in a playable, mostly-shippable state since about midway through the competition should be a requirement. Putting easy stuff off until later to come back to is simply risking not having those things in the game. We tried for this and I failed to deliver, which affected the final game a lot. Conclusion
The event was a success. Our main goal was to get something running and running decently, so gameplay itself was a secondary concern this time. The game was only a semi-success, since the gameplay didn’t quite come together and it feels like an incomplete game, which it very much is. The experience and feedback that we have gotten will help us a lot on our next LD, when we will now have the skills and speed to try and make a game with good gameplay that feels complete.
Hurray, we succeeded on submitting before the deadline. It was tight but we managed to make something rather cool, it’s a little die-and-retry puzzle platformer and if you like difficulty, this might be your cup of difficul-tea. You can play it HERE. Expect a postmortem post soon-ish this week.
I kept working on it and turned it into a full game, and just launched it on Steam! Figured it could be good inspiration for people participating in LDJAMs to keep working on their entry if they come up with a cool mechanic/idea…who knows, you might be able to to turn it into a full game!
Hope this inspires some people to take their games beyond their Game Jam entries if they think they’ve stumbled across something fun! With a few more months of work you might be able to turn it into an awesome game you might be able to pay your rent with! 😉
Follow me on Twitter at @BPOutlaws, I use it as a devBlog lol
Ludum Dare 35 is the fourth in the series for the ExcaliburJS team. We piled five to seven people into one room for four days to make another game.
What went well
Workflow and Toolset
We’ve continued to refine and improve the way we build games for jams. It’s important that everything “just works” as much as possible. We maintained the same continuous deployment process that we’ve used before to push to a live site, so it could be tested and played within a minute of being checked in. We also used a watch-and-compile task in Visual Studio Code to gain the same benefit while developing locally.
Art & Sound
We had four people putting together art assets on and off throughout the weekend, and it turned out great. We used bfxr to create the sound effects, and a set of littleBits components to compose the background music. Once we had settled on the theming for the game, everything fell into place.
We initially had a grand plan for introducing elements of Hexshaper, and as usual we had to set that aside and come up with a more practical solution that could be completed in the time remaining. We ended up pausing the game and moving the camera over to each portal as it opened and as the player successfully closed it, which ended up providing most of what we wanted.
We only encountered a few bugs in Excalibur this time around, and they were all relatively straightforward to test and fix. It feels better to use the engine each time we do a game jam.
What didn’t go so well
Minimum Viable Game
The game on Saturday
We didn’t have a very clear vision of what we wanted the game to be this time around. Uncertainty translated into not really having a playable game until Monday. This delay was a stark departure from the last couple of games we’ve made, where we made a point to have something relatively complete by Saturday evening so we could iterate on it through the rest of the weekend.
There were a number of things that made interacting with the Excalibur animations API painful. Luckily, we didn’t lose too much time to them, and we now have an opportunity to improve that experience for future users.
Build a playable game as soon as possible
Look for alternative solutions that create most of what you want for much less work
Special thanks to all of the people who worked hard to make this game possible!