Ludum Dare 35
The Theme is:
Shapeshift

Judging ends in
Click here to start

PlayRate80Star

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.

Posts Tagged ‘timelapse’

Nightshift – Timelapse + Let’s play submissions still open!

Posted by (twitter: @AurelDev)
Tuesday, April 26th, 2016 4:39 pm

Finally got around to editing the timelapse video for Nightshift :) Hope you enjoy!

Next up, I will edit the trainwreck of a first episode of let’s play your LD games. As many of you (five people that were there) know, everything that could possibly go wrong on a stream did go wrong, but it was fun nonetheless, so we’ll be trying on a slightly more powerful machine next time. But, submissions are still open, so:

ADD YOUR GAME TO OUR LET’S PLAY LIST

 

Hi Ludum Darers,

We are Imperial Unit, a 2 man indie developer based in Australia. Ludum Dare 35 was the first game jam we have ever participated in – and we scraped through just in time to submit our game – Roamin’ Hordes.

PROTECT THE EMPEROR – PLAY ROAMIN’ HORDES!

Roamin' Hordes - Praetorian Guard Under Attack

About the Game

Roamin’ Hordes is a hybrid between a tabletop wargame and a tower defence. We tried to think of something different when it came to the ‘shapeshift’ theme and we were inspired by the geometric nature of historical warfare, with ranks of troops arranged in formations, and having to change their shape to manoeuvre and hold the battle line.

Below is a time-lapse video of the game development, and a play through showing the real time large scale combat in action.

The Good

  • One of the goals was to show off huge battles with thousands of troops – which we accomplished by handling unit movement, animation etc. with the particle system in Unity. At the peak of the battle there are around 4000 soldiers displayed and performance remains fluid.
  • We tried a new approach with art, by first creating 3D voxel models, and then turning them into pixelated 2D sprites. We were aiming for the retro style that existed between hand drawn pixel art and modern 3D realism. In the end there was enough detail and animation that you could zoom from the map wide view into individual combat between formations.
  • We wanted immersive sounds to add to the atmosphere of being in a big battle, and spent some time to implement positional sound effects so you could hear the direction of marching barbarians, flying arrows etc.
  • The game only includes one scenario, and we didn’t have a lot of time to test the balance, but it seems to have turned out well – the scenario is definitely winnable, but it usually takes people a few attempts to understand the attack patterns and develop a counter strategy.

The Bad

  • We were a bit slow paced in the first days, and found ourselves rushing and sleepless at the end, which meant several planned features had to be dropped to finish a playable game in time. The main ones were not having unit icons to make them easier to identify when zoomed out, a lack of variety in the barbarian units (we wanted calvary, chariots etc.), and only having one scenario.
  • The pacing of the scenario is not ideal, mostly as a consequence of only having one scenario, so it had to function as a tutorial as well as a challenging scenario. This means the first few waves feel too slow and easy, while things ramp up in difficulty in the later waves – having to go through the early waves again on replays can be tiresome.
  • There were several limitations with the particle system within Unity (for our unconventional use), which meant that parts of the code had to be re-written, and sprite atlases has to be changed and arranged in a specific way to work properly.
  • Too much time was spent background art (about 1.5 days) which would have been time better spent on creating enemy units and developing other scenarios.

Thanks to those who have tried out the game – all the feedback has been constructive and really helpful for us. For those who haven’t played it you can give it a try here.

FOR THE GLORY OF ROME – PLAY ROAMIN’ HORDES!

IU_RH_Units

Imperial Unit

http://www.imperialunit.com

http://www.twitter.com/imperialunit

http://www.facebook.com/imperialunit

Spinstar Timelapse

Posted by (twitter: @gamepopper)
Thursday, April 21st, 2016 12:06 pm

Do people still do these?

Here’s mine anyway, I like seeing these because progress is fascinating.

Go play & vote on Spinstar HERE!

Robot Escape – Timelapse

Posted by (twitter: @rjhelms)
Tuesday, April 19th, 2016 9:57 pm

Whew, another Ludum Dare down! Good job everyone – I’m enjoying what I’m seeing from other people’s efforts in this collective insanity.

This time around, I put together a game called Robot Escape. The weekend had its share of ups (I finished! I had fun! I’m proud of my idea!) and downs (I started over 12 hours late! I lost 2 hours to a power outage!) and I’ll put together a proper post-mortem soon enough. For now, the timelapse:

Check out Robot Escape here!

A Simple Tale – Post Mortem + timelapse (Part I)

Posted by (twitter: @SirGFM)
Tuesday, April 19th, 2016 9:27 pm

Hello LDers!

This LD was quite different from what I’m used. I had a few short slices of time in which I could work on my entry through the weekend, until I was finally able to work almost 10 hours straight on Sunday’s afternoon (the only part of the jam that I did timelapse).

Here’s briefly what went right/wrong:

What went right

  • I finished something
  • I used the theme on the narrative (in a way that I rarely do)
  • Even though running out of time, I was able to explain the theme in-game
  • Graphics were done quickly and (mostly) smoothly
    • Also, the flapping of the evil fairy!
  • I was able to do three (pretty simple) variations for the game’s theme song

What went wrong

  • The idea was too big for the time I had (less than 24 hours)
  • Everything is as rough and unpolished as possible
  • Gameplay is really dumb
  • I was away from my battle station until mid-day, on Sunday

And here’s the timelapse, taken for around half the time I worked on the game.

Later, I’ll write a proper post mortem. I’d like to explain why I didn’t have much time, how I got the game idea, how I quickly done the graphics… etc.

Until then!

Shape Quest time lapse

Posted by (twitter: @GaTechGrad)
Tuesday, April 19th, 2016 5:33 pm

Check out the time lapse video of the development of Shape Quest!

Play and rate Shape Quest here: http://ludumdare.com/compo/ludum-dare-35/?action=preview&uid=19778

For more information, check out the Shape Quest post on my site: http://levidsmith.com/shape-quest/

“CatKoonBut” timelapse

Posted by
Monday, April 18th, 2016 6:02 pm

I just uploaded the timelapse of the creation of my game “CatKoonBut”.
It was the first time for me making a timelapse and it’s super cool!!

 

You can play and rate my entry by clicking on this cool gif!

Timelapse

Posted by
Monday, April 18th, 2016 2:02 pm

Here’s my timelapse of Hungry Blue Fox, thirteen hours in one minute!

Play/rate here!

Timelapse of Making Grokh’s Arena

Posted by
Monday, April 18th, 2016 11:09 am

If anyone’s interested, I recorded a timelapse of making my Compo entry Grokh’s Arena (http://ludumdare.com/compo/ludum-dare-35/?action=preview&uid=83463).

In total I spent about 30 hours making this game, 27 of which were recorded (I forgot to start the recording yesterday morning).

It’s outright scary to see that I spent almost all time programming instead of working on assets and even scarier to consider how much time I wasted moving code around for refactoring purposes. I guess I should look for a more efficient approach to making games. Or maybe a more efficient language than C++ 😉

I was thinking about writing a postmortem too, but I doubt anyone would be interested.

We’re in!

Posted by
Thursday, April 14th, 2016 5:06 am

Fylipp, AndreasHae and I are going to participate in the 35th Ludum Dare Compo.
Programs we are going to be using:

This is our first time to participate, we are looking forward to it.

Timelapse for Mac (OSX)

Posted by
Tuesday, January 12th, 2016 10:01 am

Hey friends.
Trying to be ready for the next Ludum Dare, I’ve been searching for a tool to do the timelapse on MAC.
After some search, I found out that there’s no one simple solution for that, like we have for windows.
We only have one command line for that, which does not support multiple screens, and webcam.

Because of that, I did some home work, and found a way to do that.
I created one script which do that more or less automatically, using some open-source tools.

Basically, I do screen captures using the native screencapture
And webcam photos using imagesnap.

After that, I merge all the files using imagemagick
And to finish, I use the ffmpeg to create the video.

You can download the script here : Google Drive

You need to install imagemagick and ffmpeg, to be able to use this.

In the zip folder, you will find the timelapse.sh
At header of the file, you can change the parameters in the way you want.

Captura de Tela 2016-01-12 às 12.57.20

After that, you can run the script, and press ‘E’ to exit.
The script will combine all the images, and generate the video inside the folder you executed.

Captura de Tela 2016-01-12 às 13.00.38

If you have questions/suggestions/improvements, please, let me know.

Tamamystery behind the scenes

Posted by (twitter: @jezzamonn)
Monday, January 4th, 2016 4:38 pm

(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

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.

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

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.

5-2

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.

hands

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!

friends

GrowForce timelapse

Posted by
Monday, January 4th, 2016 10:30 am

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

Entry page

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

hARBOuR Timelapse

Posted by (twitter: @AurelDev)
Wednesday, December 30th, 2015 6:23 pm

I always liked the timelapses. Even though I like this game less. 😀

PLAY NOW

Timelapse of Double Kick Heroes!

Posted by (twitter: @blackmag_c)
Monday, December 21st, 2015 10:21 am

Hey guys!
We made a timelapse of Gyhyom’s work during the jam!
You can view the whole process of doing the art of Double Kick Heroes on youtube.

Software used to made the game, Photoshop, Aseprite and Texture Packer.
Chronolapse and After Effect for the timelapse.
Enjoy!

If you want, you can play and rate the game here :
Double Kick Heroes

You can read the post mortem of the ldjam here :
Post Mortem of the dead

Mount FuJ Post Mortem – LD34

Posted by (twitter: @roaringcatgames)
Sunday, December 20th, 2015 6:31 pm

 

The Game

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

Mount FuJ is a take on tower defense, or defend the castle style games. You play as an active volcano trying to protect the village that has popped up just below at your base. The village is under siege from an unknown enemy that is sending wave after wave of pikemen and horsemen units. The village will fight back, but it is no match for the army. You must use your volcanic ways to rain down lava balls on the enemy before all of the buildings are destroyed.

[Features that didn’t make it: If you are successful, the village will flourish and grow. However, as the village grows, it begins to spread into the range of your lava, so you have to be very careful to do more protecting than damaging.]

mountfj

Background

Zoe Blackwell – Music and SFX
Loi LeMix – Art
Barry Rowe – Programming

The Team

Left to Right: Loi, Barry, Zoe

This was Zoe’s first game jam, and first game related project. Loi and Myself have been working together since Ludum Dare 30, and have formed Roaring Cat Games under which we publish our work. Our team formed as we were brainstorming at the live Ludum Dare meetup with GameDevLou. This was the first time that Loi and I have worked with a dedicated musician and sound designer (which was awesome).

Tooling

Zoe used Logic Pro to record, mix, and compose music. She user her Casio Privia PX-160 keyboard as a midi controller to write the segments needed for composition.

Loi used his usual package of Adobe products but heavily worked in Photoshop to generate the art assets. However, this jam, he added a new tool into the mix with Spriter2D. Spriter really let him focus on the art and fluidity of the animations when during previous jams he was having to worry more about manually framing animation sizes and pivot points.

I chose to go with libGDX for this game jam as it is the framework I have the most experience with for games. While I’ve been doing some 3D work and learning unity since Ludum Dare 33, we knew we wanted to go with a 2D game for this jam, and I wanted to eliminate engine knowledge as a possible roadblock. We always like to challenge ourselves in some way with our projects though, so I did decide to throw Ashley ECS into the mix. I had used it for LD33, but only sort of embraced the ECS approach. For tooling I used: IntelliJ as an IDE, GIMP for placeholder art, and Git for version control.

Location

We worked the entire Jam at the Game Dev Lou “real-world gathering” working alongside at least 8 other teams. (See all of the GameDevLou games here: http://gamedevlou.org/our-ludum-dare-34-games/)

real-world-meetup

We presented a less finished version of the game as the real-world Jam wound down on Sunday about 7PM:

Brainstorming

Our brainstorm session was a bit longer than usual this time around. The existence of two possible themes really seemed to throw a wrench in our creative process. We kept falling into the trap of trying to force both themes into the game rather than focusing on one theme and discarding the other. Loi and I had also discussed trying our best to find a hack’n’slash to fit the theme, so I think that had us always coming back to “is this better than just building a hack’n’slash?” In no particular order, and with no further explanation, here is a list of some of our ideas:

  • Auto-run with Attack, Duck, and Jump all in two buttons
  • Snake/Centipede style game
  • Save the iceberg
  • Ninja absorbing souls into an ever-growing sword
  • Volcano Game
  • One-punch man training simulator (w/ boss fight)
  • Planet Building
  • Tree vs. Lumberjacks Survival game
  • Avoid the expanding Objects
  • Dark Maze Puzzler
  • Grow and Shrink objects to get out Puzzler
  • TRex growing up
  • Lion hunt and roar

When we got to the end, our top 3 ideas were between a Growing Sword hack’n’slash, One-Punch Main Training Sim, and a combo of Volcano and Protect the Iceberg.

brainstorming-sketch

As a whole we were most interested in the One-Punch Man game, as it had the opportunity for lots of humor, and working with a story/world we all enjoyed. However, as we started designing out how the game would play, we realized that the mini-games were fun as a concept, but boring in actual gameplay. We came to the conclusion that we couldn’t make the game fun enough to move forward on.

Next in line was the Hack’n’Slash with a growing sword. We discussed it, and the game play was going to be pretty simple and fun, and the environment had a lot of potential for interesting visuals and sound. Unfortunately, once we started looking at some of the features that would need to be implemented and the number of animations and art assets required to match our vision, we realized that the scope was just a bit too much. I personally had some major concerns that I wouldn’t be able to figure out how to implement the sword mechanics we wanted in code. I kind of regret giving into that fear looking back, but it was probably the right call. Loi can blame me for dashing his Hack’n’Slash dreams until the next jam.

As we began finalizing our third choice, the volcano game, we all kind of realized it might fit our strengths really well. Zoe seemed confident that she could produce the tense, dramatic soundscape we were designing toward. Loi found the concept might lend itself to a painted style he’d been wanting to try out. I felt there were some interesting challenges in the code, especially with only my second project using Ashley ECS, but was all doable in a Jam time-frame. On top of this, once we all got on board, we began expanding some of the possible mechanics, and the game was sounding pretty fun.

Process

Our process for building out the game was straightforward.

  1. Work up a list of all the known assets (art and sound) we would need
  2. Work up a list of all the programming features we need
  3. Task out the features in order
  4. Build each feature to implementation
  5. Repeat 3 and 4 until the Jam ends

Check out this timelapse of the programming effort over 3 days:

While there was no intention this jam of keeping Loi and Zoe from playing the game until the end of the jam…it still happened. Due to the development tools, having the game up and running where we can all play it isn’t as simple as I’d like it to be. This means that unless everyone on the team sets up their machine for development, the only way to play is to jump on my machine.

I think we should have done more small 5 to 15 minute breaks where we all get together to test a mechanic, listen to a piece of music, or analyze an animation or set of art assets as a group. This is something that was missing from our process this Jam, and I think it did limit what we accomplished.

What Went Well

The art and music for the game turned out fantastic. Zoe and Loi nailed it, and I love the feel of the game with them in combination. The soundtrack is nice and tense, with a subtle yet still noticeable buildup of urgency. Combined with the SFX and the lava animations, it makes for a very cacophonous battlefield scene. Yet, somehow with all the explosions and battlefield tension, there is a soothing calm to the experience as well. About halfway through the jam I could see that the music and art were going to need to take the main focus of the game.

The collaboration between the team went smoothly. We were each able to spend the majority of our time in our own tasks but were able to stop and discuss next steps/changes as needed without any issues. I think being in the same location really helped with that, and I can’t recommend enough that you try to join a real-world meetup if possible.

Coming together on Monday after our day jobs, we were able to pull off a lot of work right at the end. Sunday at the end of our day, we barely had a game. The wave system didn’t work, there were no sound effects, there was no balance to the enemies, and worst of all the game didn’t do anything to highlight the great soundtrack. On Monday we were able to take a step back, prioritize the features to make it a game, and knock them out with just a few minutes to spare for submission. This final crunch period went really well, and it was very satisfying to see how quickly we could get things accomplished under pressure.

What Didn’t Go Well

Coming up with a damn name for the game… This is the first jam I feel like we never had a clue what to call the game. If anyone has any great ideas for what this game should be called leave it in the comments below. We were just drawing blanks the whole time.

I feel like I was the weak link in this jam. I’m not sure what happened, but between saturday about lunch all the way through sunday about 10am, I just couldn’t get anything going. I was writing code, but it was all non-essential background placement or environment building code that I could have (and should have) knocked out towards the last few hours. I think I was dealing with a rough combination of:

  • Exhaustion (I had not been sleeping enough all week prior to the Jam)
  • Doubting my abilities to implement features
  • Lack of clarity on how some of the mechanics needed to work
  • Worry that I may have talked the team into a game that just isn’t fun

I definitely should have started working on having the lava destroy enemies much sooner as that is the key mechanic of the game. I had the lava-firing and charging really quick, and it then just didn’t do anything with it for almost 24 hours. I made the mistake of not building the basic mechanic up front so we have time to tweak and make it fun. On the plus side, I’ve learned that lesson (for at least the second time now! :)) and will be able to remember this instance to hopefully keep it in my mind going forward.

What’s Next

In the end, we feel our game has a pretty fun mechanic hidden inside of it. We’d like to tweak some of the known issues (spamming lava is an auto-win, no visual indicator to know how charged up your lava is) and add touch controls. This would allow us to release the game out for mobile devices as a little time sink. We’ll definitely need a scoring system, and a way to indicate that fun you’ve lost. The win sequence needs some work as well.

Team Thoughts

Barry:

“I was very excited for this Jam and challenging myself with Ashley ECS. While I’m disappointed in my output for the Jam, I was able to build out some pretty generic Systems and Components that will be useful for games in the future, and I plan to clean them up so I can open source them as an additional library for other libGDX developers. I’m very proud of the work our team produced, and I hope the shift in focus on Art and Sound comes across for those playing our game. It was an exhausting, humbling, stressful jam for me, but as always I’ve learned a ton and am even more ready to jump into our next projects.”

Loi:

“So, the whole week leading up to Ludum Dare 34, I was filled with excitement! Excited to create something new! Excited to take a break from RCG’s personal 3D project and get back into designing 2D characters and environments again. In the days leading up to the Jam, I started playing around in Spriter 2D (an animation creation and management program that I had been wanting to learn since the last Ludum Dare), because I was looking forward to making a hack and slash. Spriter 2D would have been perfect for animating action frames, as one of its unique features is bone-rigging and attaching them body parts and objects. Spriter 2D was very productive; it saved me a lot of time with image file management, ease of exporting animated frames, and having a simpler, yet more extensive, animating options that were non-existent in Photoshop. It allowed me to focus more on content creation rather than spending a lot of time on filename and manual frames export, which can be tedious and time-consuming when you trying to create a smooth animation sequence.

As always, I wanted to challenge myself to a new art style every Jam. This time, it was watercoloring in Photoshop. I haven’t used watercolor paint since I was a wee-lad, and picking it back up again felt a bit strange, especially now that I am doing it digitally and my paint brush is my tablet pen. The hardest part in the beginning for me was getting the brush settings just right to give it that wet outer-edge water-effect look. Below is my custom brush settings that I used throughout the Jam (works best with a drawing tablet, as it emulates brush pressure and strokes). It was nice to use watercolor inside of photoshop without the mess to clean up afterwards”.

BrushSettings

 

Thanks for reading, Thanks for playing,

–Barry, Roaring Cat Games

 

[cache: storing page]