Hello my fellow ludum dares. I only need 9 plays to get to a 100 playes in total help me out. And try and SAVE THE OAK.

http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=40092

Hi there, folks! So… we’d like to tell you how was our first experience developing a game in 72h for LD34 with Unreal Engine 4.

Everything began at 3:00 a.m (Spain). Our first reaction on the “two themes draw” issue was… well, laughter! Our first Ludum, and beggining like this…!

We had a breath, and then we decided to make a very very simple game, talking about mechanics. It was our first time joining LD, we didn’t want to be incautious. We had to plan something “accomplishable” for us in 72h without dying in the process.

Finally we decided to make a “choices” game, where you only had to decide which button to push and when to push hit. Relfexes were the key. Also, we wanted to make it frenzy, so the player had to look at both sides of the screen without rest.

And then, we started searching for references and making sketches at the art department. We wanted a Little carácter, but very very glutton, (related to “growing” theme)

Once we had the main ideas and sketches clear, we did a layout, so that the “coders” could have something to work in as soon as posible, and the “artists” could finish modelling.

While the layout was being done, we started with the PJ. It was important thtat this one was the first “final model” to be done, so that the animator could start rigging, while the rest kept on modelling props and scenario.

Lightmapping and Ambient Occlusion textures done, as well, and then, to UE4!!

Once modelling was finished, we did the UVs and then gave them to the RIG department.

Rigging and Skinning finished, so our animator could start as soon as possible.

Meanwhile, all objects were modelled and UVs were done, so that UE4 lightmapping worked perfectly and optimized for HML5.

When every UVs was ready, we started rendering all lightmaps and shadows. Then, we treated them in Photoshop and passed each texture to each material.

We wanted some variety in the suitcases, so we did 3 different textures. It’s a pity, but we couldn’t use them in the end

Once every model and map was done, we put toghether everything in UE4, replacing the initial layout.

In order to optimize and make it work smooth in HTML5, every light was “Cooked” and the used the least amount of opacities we could. We also used simple materials, as well. Almost all lighting work is pre-rendered.

To achieve the ‘growing’ effect, we used morphers, so that we can make it “grow” as he swallowed.

Meanwhile… in the “coding” department…

After the “initial joke” (two simultaneous themes), we took a while to think how we could structure this game, and more important. What did we need?

• A system that pulls out the suitcases in both ways.
• A “suspicious case” detector.
• A “feeding tube”, where we could gather the suitcases.
• A suitcase with some different internal values and a “thruster”
• And a “game script” that could connect everything

We decided to use “Blueprints”, because in this game we didn’t need extremely complex coding, and results with these are just great, they’re easy to do and intuitive.
So, we started to work in separate parts and, the moment we had the layout ready, we started putting everything toghether.

This is a very basic scheme. Each scanner “reads” an internal value the suitcases going through have. A boleean (Radiactive? True: scanners change material to “Green”, False: Leave the suitcase alone!)

Each scanner have three colliders. “In”, changing the suitcase material in case Plutonium is “true”. “Out” turns the material back to normal in case it changed previously (and the player couldn’t grab the suitcase on time), and “feeding tube” collider, which “gathers” every suitcase the player decide to pick.

There is also a “BoxTraceForObjects” collider that “sucks” every suitcase inside it when the player push the button.

Each suitcase is a “dummie blueprint”, containing only a boolean value, mesh with its materials, a thruster, activated only when “sucked”, and some internal values, as speed and direction.

The tube is an array, storing suitcase in the lower part and feeding “Springol” in the upper part. We add a “floating” effect to the suitcase and kept the material color of each sucked suitcase.

To pull out suitcase, as well as point calculation, “radiactivity” indicator, etc… we used the same blueprint to control and communicate them all.

And… well, that is the most important part!! Now… talking about audio…

This was the most “abandoned” part of the Project, but we really liked the result in general. We used, mostly, Audacity. (Free, simple… did I say free?) for the main SFX. We took most of the sound effects from freesound.org, but “Springol” voices were our recordings.

Fort he “feeding tubes” (or the suckers) we used turbine sounds, mostly, and treated them so that it fits with the main idea we had in mind.

For Springol, we only could finish “joy” and “death” sounds. (Poor, por Springol), which are, basically, my voice treated with so many filters. We couldn’t make a proper ‘character’ design. 😛

Fort he music we had, literally, just one hour! We used Logic Pro X and lots, lots of VST, and started playing, just having in mind one thing: it had to be a loop, so it couldn’t be too “messy” for the player (we didn’t want you to get bored of the music).
And that was, literally, the only consideration we could have about music… it’s a pity, but we think the results are really nice, if we consider we only had… one hour!!! L

Anyway, again, we thing the results are quite good. Just take… an ear!!!

So… i think that’s all! We hope you like this game. In the future we will fix some stuff, like playability, achievements, difficulty (suitcase types, time…) and it’s quite sure we’ll be making iOS and Android versions in the future so… keep up!

Cheers!

Only 13 hours before the end of the rating and this is our last post!

It contains only one message to you:

CHECK OUR GAME BEFORE THE TIME RUNS OUT

HERE IT IS: Play Glow&Grow

AND A TRAILER OF COURSE:

Entry page

my first ludum dare…
only 3 more votes needed…
so play
Snow Eater

Less than 12 hours remain to play and rate games! I am going to try and play as many as I can today, and I would appreciate if you would check out my game, Retro Rebound Challenge,  as well.

Overall, my first Ludum Dare was a success! I did actually release something, I used Unity to publish, and I am working on a level editor for RRC with hopes to polish this game enough that I can be released on Steam.

Looking forward to the next LD.

LD34 was a blast for our team.  We’re extremely grateful for the ratings, comments, and feedback that people have given our game so far!  Now that we’re down to the final hours for reviews, we wanted to ask for anyone’s last-minute thoughts, and, to give that some context, we hoped it would be fun to walk through the design process that went into our game’s art and animation efforts.

• Play Sushi Roll here, if you’d like to see the game in action.  (We’d love your review!)

After a while of grappling with the double-themes of the jam, our team got a huge creative charge out of taking the “let’s just start working” approach, which let us divide up our first technical and creative steps.

On the design side, the first thing to tackle was naturally our star and hero, Fugu the pufferfish.  The pufferfish (his name didn’t happen until mid-day Saturday or so) was the first of a few ideas meant to capture the “Growing” theme (among others such as a pig that grew by eating, a snowball that grew by rolling up more snow, and just a man that happened to fall down a hill… whose misadventures made him “grow as a person,” we joked).  While all of these were fun and funny to us, the pufferfish had a kind of instant magic once he appeared on the screen, and gave us all the laugh that sent him rolling along down our creative pipeline.

Blender (free and open source!) gave our team the full 3D production workflow we needed to produce assets for Unity — sculpture, polygon modeling, texture painting, rigging, and animating.

Our team had decided even before the jam to commit to making a fully 3D game, so the first step was to get our fish sculpted in Blender.  This was the first challenge in matching the art to the theme(s), since this meant that our star required two different base sculptures — one to represent both his puffed and unpuffed state.  (The puffed version actually came first, and was saved and then I sculpted that down to his unpuffy self for the second version.)

With a normal model, the next step would be to adapt the sculpture into a game-ready, lower-polygon model.  We actually had to do this pretty differently, essentially making the same model fit both sculptures, in order to reflect both of the puffed/unpuffed states.  This was one of our bigger design challenges, and took a good bit of finessing to get just right, but when it came together we had a version of Fugu that was able to morph (using Blender’s Shape Keys feature) between both states, using a numerical value that we would later be able to drive in Unity.

The same low-polygon mesh had to be adapted to fit both original sculptures, letting us make use of Blender’s “Shape Keys” (“BlendShapes,” in Unity) to morph between them incrementally.

The result was something both simple and perfectly suited to the second theme goal: “two-button controls.”  One button grows, one button shrinks.  The game design decisions (where growing makes you pop off the ground, and boosts your speed) all fell in line as a natural progression from that idea, giving us room to test, tune, and try to make it feel fun.

After a team vote on what would ultimately be our game’s main color palette, Fugu was given his texture pass (painted in Blender) and finalized.  …But not before we all decided to push the design one step further and give our fish even one more level of “hyperinflation” puff.  (Sadly, we didn’t get to use this extra-puffy state by the end of the jam, but ohh, do we have plans…)

(Side note: The wincing puffed face only got funnier when we realized that, as he rolls, he rolls over his face.)

With our fish all ready to go into our world, the logical next step was to fill that world with things that would try to kill him.

First up was the (slightly less-than-menacing) “foe” of the tree, which we tried to keep simple enough to pay off twice over, as the simple low-poly shapes of the leaves were easy to repurpose afterwards into the rocks and pebbles that would block the path.  Navigating over and under these obstacles is intended to set the pace for the bulk of the game’s flow, so it was important to get these into the game early, letting us start to fine-tune them into our terrain generation workflow.

Next up was the first of the true villains, who we designed as the answer to the question of: “if trees force you to shrink, what forces you to grow?”  Enter the natural enemy of fish everywhere: the cat.  Running into one would force you to puff up in order to get by unharmed — too small, and you’re cat food.

(Pretty much the sushi chefs of the animal kingdom.)

The cat was our first rigged/animated character in the game, and took a fair bit of time to get implemented.  We knew we wanted him to have a menacing pounce to avoid, but seeing him in action (in Blender), gave us all another useful creative kick, and we all laughed at the idea that this cat (when bopped by a large-enough Fugu) could be yet another thing that rolled down the hill with you.  (Poor kitty.)

With the cat modeled, rigged, animated, and finally painted, we had (most of) the main art assets we were hoping for (mostly) in place.  We started on the final assets — a quick Japanese-styled pagoda to sit on top of our hill as our deadly restaurant escape scene intro — and started to pull everything together in Unity.  This was Sunday evening.  We were getting close to the end of our art assets to-do list, and (somehow) even a bit ahead of schedule…

Which, naturally, meant it was time to go big or go home — the last idea that had been lurking in the room (initially deemed too much to hope for) was to load in the villain himself: the Sushi Chef.  It’s hard for me to imagine the game without him at this point, but even for his huge role, he was actually a fairly last-minute long-shot of an idea to try to build him by the jam deadline.  (This also meant programming him, after all.)  But, hey, we decided to go for it.

There was really only time for one round of character design, so it was important to get our chef “right” on the first try.  We agreed right away to keep him pretty cartoony, in order to let me design and sculpt him quickly, keep his rig and animation simple, and of course to match him to the cartoon style of the fish and the cat.  Thus, between trying to keep his facial features simple and trying to keep him a bit funny (he is a knife-wielding would-be fish-murderer, after all), I tried to simplify his face by pulling his headband down over his eyes, colorfully emphasizing what had become a running theme of cartoonishly-angry eyebrows in the other character designs up to that point.  He made us laugh on the first try, which we decided meant that he was probably good enough to move ahead with.

He’s a man with a dream.

By the (late) end of the night, the chef was ready to go as a low-poly game model, rigged, animated, and painted, and our fish was free to be chased by a floating placeholder-Unity-capsule no longer — and, instead, by an angry, knife-waggling chef.

Our group parted ways on early Monday morning, leaving the final design work of our game’s logo and game over screen graphics (a last-minute 3D scene modeled and rendered just in time to drop into the final jam build) to be assembled remotely.

It was amazing to see it all come together, once everything was rolling, hopping, pouncing, and knife-waggling together in one combined setting.  That, plus the final versions of the movement/controls, terrain generation, and chef-chasing functionality — and all set to the final music handed off by our team’s musician — really pulled it together into something that we were extremely proud of.

We wanted to say a huge thank you to everyone that played, rated, and commented on our game.  It’s been extremely gratifying to get all of your kind and helpful feedback, and it’s given our team the drive to keep working.  We’re happy to say that we’re already well on our way to implementing some of our next ideas, which we hope will help turn Sushi Roll from a prototype into a really fun little game.  So please stay tuned — and send us your thoughts!

• Try out Sushi Roll here, if you haven’t already.  We’d love your review!

S.A.A.A.M. Post Jam version is out now! There’s a new ending, faster doors, bug fixes and much, much more. There’s even a sharknado for you to find! Why are you still here? Go play it!

S.A.A.A.M.

Tags: fireline games, post-jam, saaam, sharknado, sharks

Intro

12-ish hours remains for voting at the time of this post. Normally, this would be an opportune moment to showcase my game (which I still will), I think it’s also the perfect time to jump the bandwagon and list down my favourite games for others to try and vote on as well. I feel these entries deserve more attention, so without further ado, and in no particular order…

1 Button Wizard X2 by BoxedMeatRevolution

This game can be summed up as “1 Button Magicka”. It has a surprising amount of depth for a one button game, and the bots are actually rather decent. Some people might not dig the art, but it has a certain charm to it that I like. And it’s consistent. Try playing it with a friend. It’s extra impressive that the dev used one button for each mage, actually limiting the number of buttons used at any time to two.

SlimeCraft by jacklehamster

If you told me an RTS existed that only used two buttons, I would’ve scoffed at your face at the notion. I mean, how is it possible to condense resource management, logistics and strategy down to TWO BUTTONS? And yet, here I sit, flabbergasted that something like SlimeCraft exists. It’s actually reasonably easy to pick up and get used to, and can support up to 4 players! Splitscreen! What other RTS can do THAT?

2 button metroidvania by JaJ

Another very interesting entry! I’m a sucker for Metroidvanias, so the concept of a two-button one definitely sparked my interest. Don’t expect any story here, but the game does follow the formula correctly. You can learn new skills, as well as go back to previous places once inaccessible to you. With two buttons, the controls are understandably complex and difficult sometimes, but the whole game is rather polished otherwise.

Frogtale by rzuf

If you loved Undertale, you may enjoy this game. Comparing ANY LD game to Undertale is probably rather hard to believe, but it does come close. The mechanics aren’t the most original, sure, but the humor is top-notch. At least, I found it hilarious. It starts off a little slow, but after gaining a few levels, talking to the quirky NPCs and beating the game, you’ll be left wanting more.

become a game developer in 60 seconds by unprompted

Another entry that totally blew my mind. If you think playing RTS with 2 buttons was difficult and complicated, what about making a functional game using only 2 buttons? I couldn’t believe it when I tried it out, but it works rather well indeed. Sure, the engine is limited, since you only have 2 buttons, but damn is it cool to see the product of your ‘hard work’ actually playing before your eyes.

Final Words

Of course, this is where I’d showcase my game to play. Remember to play the regular version, not the post-compo one, if you intend to vote. I hope you all had a wonderful Ludum Dare. I know I did. Here’s to the next LD jam!

Here’s a timelapse of my sixth Ludum Dare game named GrowForce.

Entry page

If embedded video doesn’t work here’s a link

Tags: final timelapse, ld34, timelapse, unity

Finally got around to uploading the source for anyone that wants it.

Also, there’s not much time left for voting so please try my compo entry and leave me some comments

Try it

THANKS!

If you haven’t tried our game, Box ‘N Bash, and would like to, time’s running out during Ludum Dare! Stack up boxes to fill your quota, but don’t smash the box goblins – and look out for the infamous boom boxes! Work fast and efficiently to get your teetering stack of crates to the tape, all while dealing with your antagonistic foreman.

Sound interesting? Give it a spin before time runs out on Ludum Dare 34.

Tags: box, ld34, unity

We’re entered the final 10 hours before voting for Ludum Dare closes, so time is running out to rate my entry, Grow in the Hole!, a 2D side-on procedurally generated golf game where the ball grows after every hit and gets smaller after being holed, meaning players also have to ensure the ball remains smaller than the hole as well as aim for a low score over 18 holes. Work is also beginning today to turn it into a ‘full’ release, which hopefully should be done by the end of January.

Away from the somewhat shameless self-promotion, I’d also like to point people toward Relay and Glow&Grow, my personal favourite entries from this Ludum Dare.

Thanks for reading and rating and good luck to everyone who took part. Here’s to the next one!

There’s only 10 hours left before the results are out ! 10 hours to try and rate more games, including mine : Stem ! Be quick !

And while I’m still here : I want to thank everyone who has tried, rated or commented on my game ! You guys rock !

(First of all, I was originally concerned about not having enough votes when I started this post, but I’m all good now. That said, you should still play my game because it’s cool, but perhaps consider playing other games too, there’s still time!)

Tamamystery is a cutesy virtual pet game with nothing mysterious or nefarious involved at all. Nope. Why would you suggest that? Also it’s in Flash, so there’s no download or anything, which means you should totes play it!

[Click to play!]

You should totes play this game

Now that that’s out of the way, lets get to what this post is about: How I came to using papercraft for my Ludum Dare game!

The first thing you’ll notice is my freakish hands holding some type of paper-craft device. But it wasn’t always going to be this way…

Once I knew I was going to do something Tamagotchi related, I started off by doing the classic Google image search to get ideas.

So many Tamagotchis…

I also watched some Youtube videos to get an idea of how the Tamagotchi gameplay typically works. I also came across this Tamagotchi device with the little cake on the top, which I liked, and is why I added a bow on the top of my toy.

Apparently if you’re into Tamagotchi videos then you also want to know how to make a Crochet Mini Coin Pouch

So I started creating the graphics of the game. I knew I wanted the game to look like a real device, and so it had to be fairly realistic looking. So I started in GIMP, first by taking photo of an actual Tamagotchi and adjusting the colours a bit. Using that as a basis, I was going to try to essentially redraw it in GIMP, but soon realised that it looked pretty bad, and was going to take a while to do.

(I’m not very good at this way of doing art)

So I ditched that idea. Then I remembered “Hey, I’ve done nice vector stuff in the past, right? I’ll do it in flash!”. I quickly realised that THAT was going nowhere too.

I was hoping the grid would help me make things even, but I couldn’t even get the curves to look right

So I drew this little place holder graphics and moved on. Also, here you can see I had the idea of having a background that’s permanently etched in the game, like some Tamagotchis and small toys do.

The “figuring out graphics is a problem for Future Jez” graphic

Then I tried to figure out what it would look like on paper, and an idea hit me: If I can make it look good on paper, why not just use that as the graphics as is! I have a whole bunch of cardboard in my room (I often use it for craft things for kids), I had everything I needed really.

Even though I wasn’t trying to make it look good, I felt like this sketch was better than my my actual graphics attempts

The actual process of making the toy wasn’t too hard, all I did was draw each piece lightly on the cardboard in pencil and then cut out the outline. I made sure to measure out a piece of cardboard with the same dimensions as the screen so that they lined up.

To put the pieces together, I used Blu-Tack, which is good for two reasons. Firstly, because it’s not permanent so you can move things around. Secondly, it makes the pieces stick out a bit, so you don’t just end up with a flat piece of cardboard, but instead have something with a bit of depth in it. Depending on how much Blu-Tack you use, you can adjust the height of each piece a little bit.

From side on, you can see the layers… kinda. That screen is coming of a little.

To get it into the game, I just took a photo on my phone, put it on the computer, and then skewed it a little bit to compensate for the slight angle I took it at. Then I scaled it to make sure the screen was a nice multiple of the game window size, in pixels, because otherwise you get awkward half-sized pixels or blurry edges due to anti-aliasing, and nobody wants that.

This one is nice in the way that you can clearly see that it’s made of paper, it’s not as obvious in the actual one.

It looked pretty good at this point, but I felt like it needed colour to look more like an actual device. So I added in the colour in GIMP by using layers with the “Multiply” blending mode. If you just transparently overlay a colour, you lose some of the contrast as all your shadows become lighter, whereas with multiplying, you preserve all the blacks as black, and keep the subtle paper texture better. That’s a little tip for ya.

Whee! Timelapses! (click to see the unsquished version)

And to add in the hands, I just took a photo of me holding it with one hand in the different positions, and photoshop’d that in with GIMP (am I allowed to say that?). It would’ve been nice to set up a tripod and take photos of me holding it in the different positions to get the shadows right, but that also would’ve taken a bit longer and would’ve meant I had to skew, scale and colour 4 photos instead of 1.

Whee timelapses again!

And that’s it! I had a lot of fun with using papercraft, I might try to make an all-papercraft game next time. I’ll probably need some better equipment though.

Thanks for reading! See ya later!

Tags: how to, papercraft, timelapse, tools

With the results approaching, some of you might be in a rush, and don’t know what games to play. Then, give a shot to SLUG STORM. We believe the game is really well polished for a compo entry, and we would like as many returns on it as possible !

You can play it here, please read the instructions and feel free to leave a comment ! 😀

I had a lot of fun picking out my favorite games last time, so I’ve done it again. They are still broken up into categories that I think each game excels at. I’ll be interested to see how highly these games rank against all of the entries.

Theme (“Two Button Controls” and/or “Growing”)

Mood

Fun (Engagement)

Audio

Humor

Graphics

Play Ours

If you liked the list, consider checking out my team’s game “Exponential Cris(m)is!”

view this list on my website

Tags: favorite games

TL;DR:

BOOOST Post-compo version is here!

Please compare it to BOOOST Compo version if you have time, and let me know if what I’ve changed is for the better 😛

———————-

Hey guys

It’s the last day, and I’m finally kicking my own ass to put this thing up! I’d been working on it on and off pretty much since the day after LD weekend, and… What can I say, it’s been a thoughtful couple of weeks.

Booosting the ship

I spent a lot of time tweaking the flight physics again, that being the thing that really defines this experience. It was a real struggle getting it between satisfyingly drifty and satisfyingly responsive. This new version is much more responsive in some ways, but does not let you do anything you want. It’s.

A big change was to the fuel system – instead of two bars, there is now one. Left and right flight does not require fuel, but thrusting directly up does. This lets the player manoeuvre when needed without worrying about fuel, but the regeneration and cost is higher than before, striking a new balance.

The top of the game field also expanded, affording the player more time to react to incoming ships, if they’re not invincible. You’re not always invincible while flying up – you’ll only be if you have 50% on your fuel meter and continued burning after the initial boost.

Booosting the enemy

The big bad changed from the wall of flame to an actual ship with armour and engines. This gave the player something to focus on besides what’s ahead. In the earlier levels, interacting with the boss isn’t really necessary, but later, the boss’s speed picks up, and your escape would be made easier if you blew up the boss’s engines, slowing it down.

The idea was to have more variety in the boss’s composition and components, but I haven’t gotten that far yet, and balancing the numbers on this has proven to be very, very very hard. I would love some input on how you perceive the difficulty of the game in its current state!

Play BOOOST Post compo!

Play BOOST original LD entry!

I started the new year off by getting back to my weekly gamedev streams. My original plan for this weekend was to work on my long term project, but I ran into issues even getting it to run, and rather than fight with that on stream, I pulled out my LD34 project, CentiSnake, and started adding some of the items that feedback had indicated would be good changes.

I’m already very close to having the first of those new features added: Custom color controls, allowing gamers to pick the precise color they would prefer. All that remains for that feature is to get it to save the value between play sessions.

I’m also going to add a volume slider, the ability to toggle the retro-CRT effect off, a help screen before new games start, and I’m going to clean up the sounds and graphics a bit more.

I’m excited to see what my actual scores were, and how I ranked, especially since this was my first ever game jam, and only my second game project at all.

So, there’s still a small time for voing, so that’s probably my last chance to post my game’s postmortem. That was my second Ludum Dare, and as last time, I’m so impressed of how many feedback I received in comparison of most global game jams! After saying that, I’ll explain the pros and cons of the game’s development.

Cons:

-Spent too many time fixing bugs that I should have prevented. That lowered a lot the game’s producction.

-Graphics. They are a bit rushed.

-Get some headache when making level design. May beacuse I was so obsessed at making 20 levels. Because of that obsession I made too many tutorial levels

-Pallete. Not sure why but I’m really bad at choosing a color scheme. In most comments of this and other games from mine, people says that colours hurts. May I should tryin at using a Game Boy pallete like in my entry of LD31. No sure if people noticed the level names above because of background.

-Music. Because of Compo rules and because I suck at music, I needed to generate it using CGMusic. Great program if you need music in a Jam, though.

Pros:

-Managed to get some good levels. That was one of my objectives, and I’m glad to have acomplished it.

-People actually liked the gameplay.

-Though I used only one theme, I think I implemented it well. Using growing here would force things too much.

-I think that the difficulty balance is good enough.

-Managed to enter in the Compo!

In conclusion, apart of graphics and audio, I hope to get a decent score in other categories (not in the top 100, though). What matters is that I’d fun making this game and got some good feedback.

Feel free to check the game =) http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=44355