[My name is Carlos Leituga and I’m an intern Junior Game Designer / Implementer in a Portuguese company, where I’ve been working on a Hidden Object Adventure for a year now. I was invited by friends to help develop a game for the 21st Ludum Dare event. We are the Make A Game team.]

 

It was around 11pm when I left my house with a 1 hour trip ahead until I met the yet to be named Make A Game team. Having memorized half of the list of possible themes, I spent the little I could of brain waves keeping my car on the road, and tried to think of quick game mechanics suited for a 72 hour game development.

I was the last of the team to arrive; I met some new faces and joined in on the ready up ritual. There were still 3 hours until the official LD #21 theme to be revealed, so we started throwing ideas around, writing them down on our white boards and linking them to similar themes.

 Look busy guys…

The awaited hour finally came, and the Escape theme was victorious. We quickly (and sleepily) gathered around one whiteboard and started discussing our previous ideas, along with new ones. Among them, the Survival Tetris game was highly praised. For some dumb reason, I went to my computer and searched if someone already had done such a thing. It existed, and in two quite different forms. In one you only controlled a stick figure, and in the other you controlled both pieces and a round character. We were bummed out.

We tried multiple approaches

It was late, our two hours of brainstorming didn’t end with a winning idea, as we decided to go to sleep at 5am.

As each of us woke up, we agreed that we needed to go forward with one of our ideas. We were wasting too much time thinking of a game to make rather than making one. Our most solid idea was our twist on the Tetris game. We didn’t know it yet, but we would have a lot of fun developing it.

The Idea

Our game isn’t Tetris. It might look like it, and use some of its rules, but you wouldn’t play it like Tetris. Actually it would be a bad idea if you managed to complete and erase lines, because it would be a setback from your objective, which was to save a non playable character from something dangerous at bottom of the screen. You’d be making steps with Tetris pieces so that character can climb to its safety.

Initially we took inspiration from the idol scene in Indiana Jones, the game’s character would be in the central chamber of some ancient temple, and removing said treasure from its pedestal would trigger a huge spiked cylinder that would try and crush you from below. The whole temple would start to crumble, and the character would use the falling debris to escape being grinded to death.

Eventually we started thinking on different treasures and dangers, even on a feature to allow custom tilesets. Though we weren’t glad with the default spiked cylinder danger, it would be easily animated but lacked something, like personality. The dinosaur mommy came into form, as did its egg. Our character changed from an Indy/Spelunker lookalike to a something akin of the great animal taunter Steve Irwin.

Goodnight Sweet Prince

What went right

– Great references

We wanted a quick and fun arcade experience, and for that we had to make the player to play it fast. There had to be a rhythm that could match the speed the loop of which the pieces would appear on screen and drop down.

Every time we had some doubts on how to replicate that feeling, we’d turn to the current best example of a fast paced arcade game: Pacman CE DX. That game has so many small but important details that can be easily overlooked, from the music to the gameplay feedback. And we used it as our way to resolve impasses.

For the art style, we were constantly leaning over the shoulder of Spelunky. We loved the way Derek Yu can mask the mosaic nature of tilesets and we tried to apply what we learned from his work on that game.

 

– Knowing our priorities

By the end of the second day, we knew we were late on schedule. We didn’t have any prototype for some hands on and we had to start deciding what needed to be done versus what we wanted to have in the game.

Listing all of our features and deciding the importance of each helped us to, well, deliver an actual playable game. Leaving out stuff can be heartbreaking, especially on bigger projects, but we knew our challenge, and we knew we’d add all the stuff later.

One of the few annotations that weren’t in moonspeak

What went wrong

– No Streaming

It was a shame, but we had spent some time setting up our SVN and getting our game idea together that we didn’t bother with getting any kind of desktop video stream. We also had a camcorder but lacked a proper tripod to have it up high filming the whole process.

 

– Lack of planning

This was everyone’s first time working with Flash to code a game. That alone made us lose valuable time when we decided to ditch Stencyl for FlashPunk, because the prior was having conflicts with our SVN. Basically, when the XML files that Stencyl saved were submitted to the SVN, they appeared differently to each user, with a modified structure or a bunch of errors that weren’t supposed to be there.

But what hurt our time the most was the lack of planning before getting started with the code. Each was tasked with a particular job, and there was no discussion on how to approach their tasks. This lead to some late changes that kept us from moving forward with development and having a proper prototype of the gameplay we aimed for.

What’s missing

For this Ludum Dare build, we only have two modes available: Survival and Time Trial. We were planning two more modes – Altitude Attack and Score Sprint – as well as multiple goal values for each mode.

The difficulty would also do much more than define how many lives you start with.

We had plans for a startup countdown before the game would begin proper, where a little cutscene would play out with the game’s character picking the egg and crapping his pants when everything started collapsing.

We wanted that the Score was a combination of remaining lives, height climbed and treasures collected. One thing that got in the build was the score multiplier that doubles your points each consecutive step climbed. But you probably didn’t notice it because we didn’t have time to put points coming out of the character’s head when he was climbing.

But worst than everything, we didn’t have time to include a splash screen with our team’s name!

Screen mockups are your best friend

Conclusion

In one year working on a game studio, I’ve learn that game developers can’t get too obsessed with their projects. There has to be a time when a game needs to be finished and released, with or without implementing all of the planned features. A finished game has much more value than a game that’s been in development for years, without a release date.

Though we are finishing the game after the competition, this is a lesson that Ludum Dare has taught our team. In this industry, every project has milestones that need to be met. We had a lot of setbacks and what we delivered wasn’t accomplished without staying up until a couple of sunrises, but concentrating on what we could finish instead of hanging to what we could add helped us reach the finish line.

It feels good to finish something.

 

You can play Eggscape at Ludum Dare or at http://makeaga.me/eggscape.

 

Tools Used

FlashDevelop (IDE), FlashPunk, Audacity, Tortoise SVN, Adobe Photoshop CS4, Google Docs.

Tags: 2D, Eggscape, escape, jam, LD72, Make A Game, post-mortem

Nearly one day after, this theme turned out to be very fun to develop. Can’t wait to reveal more of it, like the really clever name we came up for it!

Tags: 72h, jam, LD #22, Make A Game, Sneak Peek

“alone I art“ is a game about spending valuable time alone with art.

You’re a shady character in a museum. You love art. You love it so much that you need to steal it. But to steal the art, you need to be alone. You can’t have anyone spot you stealing or carrying the art in your trench coat, or you’ll never be allowed be alone with art ever again.

Here you can see how some of our gameplay mechanics work. The AI and pathfinding are on their way.

We’re confident this game is going to be at least as fun as the process of making it.

Tags: 72h, alone I art, jam, LD #22, Make A Game

[My name is Carlos Leituga and I’m a junior Game Designer / Implementer in a Portuguese company, where I’m working on a Hidden Object Adventure for a year and a half now. So here I am again, creating a game in 72 hours with the Make A Game team for Ludum Dare #22. ]

 

 

As we were packing our stuff after making Eggscape, someone said something in the lines of “Let’s do this again in December!”, and since that day in August we’ve been talking about participating once more in Ludum Dare.

As the final week till LD #22 began, we followed the theme voting closely, coordinated our votes and shared the possibilities of each theme that interested us. Having learnt a lot with LD #21, we were confident that this time everything would work out better, even with two fewer members.

 

 The whiteboard calls the shots

The Idea

Something that we might never get the hang of it is figuring when in our timezone will the theme be announced. Finally, at 2 of the morning, “alone” was crowned the winner. After fumbling around with multiple ideas, it was about 5am and only Manuel, the other designer, and I were still awake while the others slept.

We started talking about a game where you played a kleptomaniac at his girlfriend’s house, having dinner with her parents, and stealing stuff when they weren’t looking. This sounded fun, but there wasn’t much variation, and we suspected it would require a lot of scripting to be interesting.

The best part about that idea was picturing the main character trying to conceal every item beneath his clothes, so that evolved into a shady guy wearing a trenchcoat on a museum, that would stray away from his tour group to steal paintings. You couldn’t remain alone for too long or the guide would start searching for you, but this was dismissed since it could limit the player’s movement too much.

 

Always great when the artist nails it better than we do

We then settled with a lone shady character walking around a museum, stealing art when he was alone and no one was looking. His trenchcoat would get as large as the concealed art, preventing him from navigating through narrow doorways. If the painting you were carrying was blocking your progress, you could swap it for a smaller one to proceed. There would be security guards on a constant patrol, and visitors walking around and stopping to admire the art, but running away and warning the guards if they spotted you snatching something.

The tour group made a brief comeback, as a moving hiding spot for the player, much like the monk groups in Assassin’s Creed, but that was cut earlier due to time constraints and issues that where delaying the development of more important non-playable characters.

 

Not even the size of his desk could constrain our artist’s talent

What went right

– An environment that nurtures creativity™

This time everyone was in the same place. There was no design or art by proxy, which made things much easier, specially since the extra hand in art determined the quality of our entry.

There was constant communication between everyone, and when there wasn’t, we quickly rectified that, which help maintain a good mood throughout the development process. If someone started sighing or getting upset, we asked what the problem was and tried to figure out solutions together.

The whole project gained a perfect harmony pretty quickly: the art style match our vision from concept to execution, and our sound choices were on the spot. All this thanks to communication™.

 

Image soon to be available on all of your favorite stock photo sites

– Good “marketing”

We wanted our game to be different. For that, we decided to keep an eye on the other participants. We didn’t want to steal other’s ideas, we wanted to avoid them, so we set up our Twitter clients to follow #LD hashtags. Eventually we started talking with other ludum darers, giving support and sharing links.

This lead to mutual interest and hype between projects. We can’t be certain of this, but hopefully they remembered to rate our entry as we did theirs.

Our updates at the Ludum Dare blog were also well spaced between to avoid spamming people and getting pushed by other posts. The Tumblr blog we made last time wasn’t forgotten, and we tried to use Facebook and Twitter in a controlled manner. Tried.

 

And then everything was about notch’s game

– A team of fast learners

For the second time competing in Ludum Dare, there were some amazing first times.

Manuel was in charge of level design, which he never once worked on before. We needed content, a lot of it, and we didn’t have time to prepare the game for multiple levels, so we all though that a huge museum was best. Though we now realize we were wrong, the map he made is still cleverly challenging. He even added color coding for areas that were the most far away from the exit and contain the most valuable art.

To avoid pulling the programmers from their tasks, we decided to use the DAME map editor to build our level. Learning how to use it was surprisingly easy for me but there was still the issue of exporting it to Flixel. We were exporting our map in LUA, but Flixel wouldn’t identify entities like the paintings, so when everything was rendered, it appeared as a solo background. So basically, Pedro, our engine programmer, spent one hour learning the [email protected]#% basics of LUA to write an interpreter! Just wow!

 

Teamwork!

– Adding value

To encourage exploration and add value to the game, we made the Gallery one of our top priorities. This Gallery is accessed through the main menu and contains all of the paintings the player steals. Having classic, well known paintings wasn’t funny enough, so we made our “own”.

We have in total 72 unique paintings in the game, all of them are scattered in the museum, and each have a title on them. Most are nods to other games, while others are Internet jokes.

 

fArts

 

What went wrong

– Again with the framework

Last time we had problems with our tools, so this time the programmers decided to research in advance for something that suited their needs the most, and found they Flixel. Unfortunately, this engine turned out to have it’s own brand of headaches.

We had problems swapping animations, changing and rotating the guards’ cone of vision, setting up spatial sound and developing better pathfinding than just by points and that avoided getting stuck in objects. Most of these features had to be dropped to meet the deadline.

But worst of all, it was picky with our sound files. Some wouldn’t play completely, others wouldn’t embed when compiling the SWF file, giving multiple errors when trying to stream external audio files. We nearly missed the submission window because of that, forcing us to release the game without sound. Only on the following morning, after the Jam had ended, that we figured out that the problem was related to file size, so we got back to work and solved some minor bugs.

 

At least this time we were able to test a prototype early in development

What’s missing

We made our best effort to make this game rich on content. From all the features we had to cut due to unforeseen problems with the engine, the quantity of paintings and the gallery menu were elements that we had to deliver. Though we should have spent some time looking up how to save the player’s progress.

The guards took so long to implement that we had to drop the visitors and change the setting to a museum at night. The placeholder circle around the guards, used to test their cone of vision that we didn’t finish, stayed in the game with a different color and opacity, and we gave a flashlight to the sprite to pretend it was a circle of light.

There’s a lot of art missing from the level, mostly museum props used either as decoration or obstacles, because not everything was exported from DAME.

And after these 17 days of voting, we read your comments about the game and completely agree that it should have had a smaller map or multiple exits.

 

See? It’s not that big!

Conclusion

Although we had our share of problems, everything worked out better than last time. We took our time planning who would do what and how.

Manuel worked on the game design with me, designed the level and made additional art (paintings and props). Fred took care of the AI and sound. Tiago made all the characters and animations. Pedro and Daniela programmed the gameplay mechanics and menus. And I translated the level into the editor, while also making mockups and acting bossy.

We prepared in advance, setting up a local SVN server instead of using Assembla like last time. We forced ourselves to be original by identifying the theme’s common patterns and avoiding them. We tried to sleep at least 6 hours per day and were well stocked up on food.

There was a lot of stress in the final minutes of the Jam, but it was a great experience nevertheless!

Regarding future Ludum Dare events, we’re talking about of at least finishing Eggscape before competing again, but we also have other side projects up our sleeve. So we can’t decide on Make A Game’s fate just yet. I mean, third time’s the charm, right?

 

You can play “alone I art” at Ludum Dare or at http://makeaga.me/aloneIart/.

Don’t forget to rate. 😉

 

Update!

Here’s a video of Banksy that Manuel showed us when we thought of the trenchcoat guy and swaping art. Totally had forgotten about it!

 

Tools Used

FlashDevelop, Flixel engine, DAME map editor, Audacity, Tortoise SVN, Adobe Photoshop CS4, Google Docs.

Tags: 2D, 72h, alone, alone I art, jam, LD22, LD72, Make A Game, post-mortem

A long night of brainstorming awaits us, and we’re dead tired already.

Tags: 72h, jam, LD #23, Make A Game

Meet Chii! He has been performing a support role in the team since last Ludum Dare. Here you can see him PURRFECTING our art!

We are currently working on our idea, but we don’t feel like lifting the veil, yet.

Tune in for more updates in a while!

Tags: art, cat, LD #23

 

Seems like there is an overwhelming amount of games with planets but we’ve quickly found a way to make it stand out. I mean, it’s not rocket science. 😉

Tags: 72h, jam, LD #23, Make A Game, Overpopulous

 

Go on, get on it!

 

 

Tags: 72h, jam, LD #23, Make A Game, Overpopulous

[My name is Carlos Leituga and I’m a Game Designer / Implementer in a Portuguese company, where I’m working on a _NEW_ Hidden Object Adventure. That one is going to take a bit to finish, so I’m back again helping the Make A Game team to create a game in 72 hours for Ludum Dare #23.]

 

 

«That’s a wrap!», we said when “alone I art” was submitted, «We’re not going to do another Ludum Dare before making full games out of this and Eggscape, okay?»

We all agreed, until seconds later someone reminded us that the next Ludum Dare was going to mark the 10th Anniversary of the competition.

«#&$*@!», I said, before blacking out and waking up four months later and right when the theme was announced.

«The theme is Tiny World?»

«#&$*@!», there, I did it again.

 

What’s the theme again?

 

The Idea

Here’s something crazy: we were going to do a game about a father searching for his kid inside a maze-like McDonald’s park. Complete with tight tube slides, a huge ball pool that would act as quicksand, monkey bars and ropes, other lost kids, and even puzzles involving wooden tic-tac-toe panels and chimes. It would be a metroidvania game with upgrades that would allow you to progress further into this claustrophobic attraction. There’s just this one thing…

We couldn’t do it in time.

 

Save us

 

The 72 hour constraint was hovering over our heads. Nearly four hours had passed and we were still struggling with finding a solid idea. We needed either a puzzle or an arcade game, something quick to prototype and fill with polish. Most of the team had gone to sleep before the rest of us finally settled with the Overpopulous idea.

We were feeling a creative block due to the figurative nature of the theme but oddly enough we opted to go with its literal sense. Sure, the “tiny world is overpopulated” idea isn’t original, so we had to make sure we did it differently.

It’s always amazing (and also really confusing) to look back and try to figure out how we ended up with the final concept of any game, and Overpopulous is no exception. We started discussing a game that mixed billiard mechanics with pinball feedback. Our initial idea wasn’t about colonizing other planets, but to smash through or into them and acquire more mass. It would play like a billiards game where instead of aiming balls into holes, you’d be partially absorbing them. Then we added the colonization mechanic and eventually dropped the mass thing altogether.

 

Here’s the plan

 

What went right

– Cool story, meng

Initially the player was going to control a shuttle in outer space, bumping uncontrollably into planets and satellites. But then we thought, «it’s the first time these guys are going into space, what if they figured everything out but the position of the rocket? They would accidentally propel their whole planet!»

We started planning on making this a surprise for the player, the intro cutscene wouldn’t reveal this till the very end. Even when it was time to make a tutorial for the game, we wrote it as if it was a briefing for the space mission crew, completely unaware of things to come.

 

Don’t believe his lies

 

– Sounds like a looker

Graphics and sound really came together this time around. The art style was on the spot in the early steps of the project and helped us set up the mood and context of our game’s plot.

A storyboard of the intro cutscene was made to make it easy for the programmers to animate, along with descriptions and mask placement of each scene. The referential humor from “alone I art” also came back in the form of multiple planets for you to smash into.

We had our share of sound problems with “alone I art” so we made sure it wouldn’t happen again. We tested multiple downsamples of the game’s music to keep the mp3 files small enough and to avoid any embedding issues, while maintaining a certain quality.

Music was downsampled to 64kbps Mono, except one track that needed to stay Stereo (96kbps) to avoid losing some effects, all at a sample rate of 44kHz. Sound effects were downsampled to 192kbps Mono because anything made in SFXR changes pitch when below that value.

 

Don’t need to squint, click it

 

What went wrong

– Blasted particles

Working with a custom framework made by the team has its advantages, but we had a lot of trouble with the particle system.

At first the system was being made so that it would be rendered through Flash’s Display List, but our engine had a canvas notion for each entity. Since none of the particles would have a defined position, the particle canvas had to match the size of our map, which was 4096×4096.

Integration wasn’t the smoothest, with performance problems due to the bitmap scaling when rendering the particles. But if we made a smaller canvas that followed the camera, the particles would also move with it. Basically, the rocket flames wouldn’t leave a trail, they’d simple move along with the camera.

We decided to go with a plan B and make an animated sprite for the rocket blast.

Eventually we bent the framework to our will and solved the problem, by converting each particle’s coordinates. We could draw 1000 particles a keep a steady framerate. Unfortunately, the particles were being affected by our other major problem…

 

 

Blast processing

 

– Measuring the universe

When we started making the level art, we weren’t quite sure what the scale of our space would be. We ended up planets with twice the resolution that we needed.

This happened due to a problem we encountered with Box 2D, where any physics body with a scale bigger than 1 would screw up the physics. So our whole game is scaled down beyond belief.

Even after fixing our particle issue, these were being rendered nearly the size of the game’s viewport.

 

 

What’s missing

This time we decided that we would merge all of our work a hour before the submission time ended, so we could solve any conflicts and have a stable version of our game ready to be uploaded. After that we kept working on bug fixes, but there were still things we couldn’t finish in time.

The above mentioned particle effects were sadly left out, along with local and online leaderboards, a proper end game if the player managed to find all 40 planets, and some additional mechanics that we planned, like black holes and nebulas that would affect speed and score multiplier values.

The intro is also missing some animations and apparently all natural satellites are made of cheese.

 

Victory!

 

Conclusion

A week before this Ludum Dare, I started getting pretty worried. I wasn’t feeling very creative and feared that we wouldn’t deliver something as good as our previous entries, or at least I wouldn’t be much of a help to the team.

Truth be told, this is the most complete and polished game we made for the competition and that is mostly due to the experience from our past entries. We stocked up properly and planned a lot ahead of time.

Hugo Damas joined our team, ready to pop his game jam cherry helping the other programmers with HUD and score implementation. Pedro Gonçalves manned the gameplay mechanics and physics. Daniela Fontes animated the intro, prepared the menu structure and planet generation. Frederico Freitas took care of the particle system, tutorial and sound effects. Tiago Franco made all the art, except for the planets, which were made by Manuel Correia, while he was talking to other participants on Twitter (which got us into these two videos) and helping me with the design. I drew mockups and storyboards for the game, created the HUD, and occasionally recorded the team snoring.

We had a blast!

 

You can play “Overpopulous” at Ludum Dare or at http://makeaga.me/overpopulous/.

Have fun and don’t forget to rate. 😉

 

Tags: 2D, 72h, jam, ld23, LD72, Make A Game, Overpopulous, post-mortem, tiny world

AAAAAAAAAAAAAAAAAAAAAHHHHH

Tags: 72h, jam, LD #26, Make A Game

And we got a name for our game!
Let me just take note of it…

Tags: 72h, jam, LD #26, Make A Game

While we’re waiting for our first playable, the artists are doing some window shopping and the designers are making up problems for the programmers, like pathfinding.

 

Tags: 72h, jam, LD #26, Make A Game

We are obviously

misleading you on what

our game is going to be about.

Tags: 72h, jam, LD #29, Make A Game

Tags: 72h, jam, LD #29, Make A Game, mockup

Tags: 72h, jam, LD #29, Make A Game

aka “Mole Invaders” aka “Moles From Outer Space” aka
“Surface Scratchers” aka “Terrorforming” aka “Spacedrills”

Tags: 72h, jam, LD #29, Make A Game

 

Pumped? Go play it!

 

 

Tags: 72h, jam, LD #29, Make A Game

[My name is Carlos Leituga, I’m a Game Designer, and once again I joined the Make A Game team to create a game in 72 hours for Ludum Dare #29.]

 

 

We were a smaller team this time: two programmers, one artist and myself in the same room, while another artist was about 1 thousand Kilometers in a straight line from us, and we could only talk to our musician through email. We couldn’t afford to be too ambitious so… no pressure.

It’s been a while since I did any game design from the ground up. With the exception of two months doing freelance work at the start of this year, I’ve been unemployed for more than a year now and I felt a bit rusty. My focus lately has been shifting from completing older design docs, to learning Game Maker Studio, and then deciding that I should read up more on logical thinking for programming, and at the same time spruce up my memory on an easy to learn language that I was still familiar with, Processing.

This led into choosing Game Maker Studio as our framework, besides the other three local team members having some experience with it, during any design downtime I could jump into the sprite or level editor and help them out. Hell, I could even help search for solutions if we’d get stumped by some of the different ways GMS does things, I can say I’m way too experienced in that.

 

This is what this whole past year felt like

 

The Idea

We probably broke our record of how long we took to decide what to do with the “Beneath the Surface” theme. We scribbled 20 subjects on our whiteboard while we discussed. Of all the ideas, I recall two the most: one where the Devil would manipulate events on the surface to make people sin and get pulled to hell, and another one that had a lifeform, on an operation table or petri dish under a microscope, defending itself against probes that would penetrate its shell or shield.

 

Psychology because… deepness

 

The Devil idea was giving us some trouble, we weren’t sure how it would play or what type of events were at the player’s disposal, but without the time pressure we might return to it someday.

The lifeform idea had us debating more about simplicity and presentation, a sign that we were on the right path. The original vision had the player choose between four sides of the lifeform, where energy could be increased to expel the probes, or decreased to be used on the other sides. It reminded me of managing your shields in Star Trek Online’s space battles.

But I guess that vision went to hell when I drew this dumb thing with moles from outer space, flying drills straight into a planet.

 

I’m so sorry

 

What went right

– Graphically sound

So vibrant! It was like everything clicked for our artist from the very start. We quickly had a very visually appealing style that kept us motivated throughout. It would be enough to inspire the remote rest of the team, we hoped, and we were right!

I tasked myself with doing the sound effects for the game but our musician unexpectedly started delivering on those very early. Only in the afternoon of the last day, when we were one team member fewer and getting tired, was when we got a sample of the song, and we went nuts! It was perfect and stayed on repeat for nearly an hour or so.

Technical problems on our end kept our other artist from helping out more, but she whipped out the best game logo we could ever wish for.

 

YOU’RE SUCH A DUMB LOOKING BUNCH OF MOLES

 

– Wax on, wax on wax on wax on

We are getting better and better at polishing our games. And I don’t mean having all the bells and whistles to catch someone’s attention, but in giving proper feedback to the player. We put flashes and screen shakes to good use, for landing a hit on the enemies and getting damaged, and the moon loses opacity after a dash, bouncing back when it’s ready to be used again.

During a game jam, polish is usually put aside due to the time constraints, but by participating more in these competitions, you start to get a feel for how long an idea will take to be made and you can start saving some time to concentrate on the visual feedback of the core mechanics.

 

Our motto for this Ludum Dare

 

What went wrong

– Keeping ourselves connected

Four team members together and two off-site, we could handle this, we just needed to progress a bit further with our work so that the other two could base their work on ours. We even had a second musician interested in our project, but technical difficulties of his own kept him from joining.

Our technical problems weren’t that far off though, suddenly our shared mobile internet stopped working. Our connection went from 30 Mbps to a whooping 128 Kbps and Skype wouldn’t even log in. There goes using Git and Dropbox out the window. We had hit an invisible traffic limit and there was no way to pay to increase that limit, we could share our credit card numbers with the provider’s customer support staff all we wanted, they wouldn’t budge.

Two of us could share mobile internet from our phones, but it had to be done in a hit and run manner so we wouldn’t spend too much traffic. We could no longer have those Skype calls with screen sharing with our remote artist that we had in mind.

Later that night, we fared goodbye to one of our programmers. He had work in the morning and couldn’t stay with us any further.

The remaining three of us then decided that in the next morning we would drive to the artist’s home so we could resume our work with some proper internet, which unfortunately shaved off around 2 hours of possible progress, but we endured.

 

RIP
25/04/2014 – 26/04/2014
“One had to go to work next morning”

 

– More like Game Breaker

Prior to the jam, I toyed around with the 1.3 beta of Game Maker Studio and found out that some of my code had stopped working. Further inspection pointed out that the change in variable scope was the cause. Granted, I’m not a programmer so my code is faulty 99% of the time, which causes anything I compile to crash or freeze or both. The problem is that crashes aren’t as graceful with GMS 1.3 as they were with the previous stable versions, and some of the times the actual software – not the game – would also freeze and crash.

I warned the team about this, but there was one new feature that we coveted: having proper pixelated rotations. We could achieve this by disabling interpolation between colors and resizing the application surface, but 1.3 makes it so much easier to set up surfaces that we bit the bullet and took some time to get used to the changes.

We also had a running joke/issue with the planet’s rotation. Drills would target a slice of the planet and miss it, but they would think they were on the targeted slice and not the adjacent one. The only way to destroy them would be attack the slice they missed. This took forever to solve, but somehow the ghost of that semi-invincible space drill return to haunt us, in the shape of an actual invincible drill that randomly appears during the game. We’re still scratching our heads with that.

Lastly, it was also somewhat challenging to port the game to HTML5. Performance isn’t great and we still haven’t had the opportunity to fix the bugs that aren’t found only in that version.

 

Look at all those beautiful square pixels

 

What’s missing

Too much is missing. Remember earlier when I wrote that we couldn’t be too ambitious? I was wrong, being ambitious is what drives an idea, you just need to keep a list of things you might not accomplish and then cut them when the time comes.

The moles were spared this time, since we decided to not implement the damage they would cause to the surface of the planet, we also didn’t add their reactions to the elemental attacks. Though we should have added a default death to avoid slowdowns when there are too many moles on screen, which is noticeable on the HTML5 version.

 

Such a tease

 

The biggest feature that was left on the cutting floor was the Elemental Combo Attacks. Players would gradually unlock these stronger attacks by destroying the invaders and collecting Experience Orbs. There are three circular slots at the bottom right corner of the screen, two of which are locked. Unlocking them would allow Elemental Attacks to be quickly cued up, creating a combination of two or three elements. Besides unleashing a powerful attack against the incoming waves of stronger enemies, it would also terraform the surface of the planet, creating harsh environments to fight against moles that would come prepared for a different type of climate.

 

Every planned biome was made and the planet’s
surface is randomized on each game

 

Conclusion

After so long, this game jam exceeded my expectations, it was another great experience. I still feel a bit rusty, I mean, I haven’t put much thought on how to balance the game, but that might be because I’m now looking at the current version of the game and forgetting some of the cut features, like some of the drills crash landing instead of going towards the core (I just remembered this!).

There was a great team chemistry and constant communication, to my knowledge there wasn’t one problem that we weren’t all on it and attempting to solve together. And taking into consideration the time wasted fixing issues outside of the jam itself, or relaxing with some TowerFall, we were able to exceed our standards from our previous entries.

Weirdly enough, this is the second game about planets that we made, where the player can interpret some kind of underlying message about colonization or nature. We are on the path to becoming true planeteers!

 

 

You can play “Orbital Burrow” at Ludum Dare or at http://makeaga.me/orbitalburrow/.

I recommend that you download and play the Windows version if you are able to.

Have fun and don’t forget to rate. 😉

 
 

Make A Game team for Ludum Dare 29:

Filipe Caseirito (@FilCaz)
Tiago Franco (@Alarka)
Filipe Jorge (@deejorg)
Carlos Leituga (@CLeituga)
Sara Mena (@_saramena)
“Minty Buns”
 

Tags: 2D, 72h, Beneath the Surface, jam, ld29, LD72, Make A Game, Orbital Burrow, post-mortem