Now:
October Challenge 2014
Ends in:
Sat, 01 Nov 2014 00:12:00 UTC

Coming Soon:
Ludum Dare 31
December 5th-8th, 2014
Sat, 06 Dec 2014 01:00:00 UTC

ConstructionPlease excuse the site weirdness. Mike is making and fixing things. Clocks are probably wrong. Colors are place-holder.


Ludum Dare 31:

Ludum Deals

???

 

Recent:

MiniLD #XX


Posts Tagged ‘unity’

My LD game on Greenlight!

Posted by (twitter: @david_erosa)
Thursday, October 23rd, 2014 2:08 pm

Almost a year ago I was posting my “I’m in!” post for the LD #28 (You only get one). That was my sixth Ludum Dare in a row.

Soccertron

I made a game in which you had to play some kind of 1vs1 soccer game and get the ball back when it got out of bounds. It was funny to play with friends, but I just let it sleep on my hard drive. Around February, I decided to give it a chance and started working on the game, changing some (many) mechanics but trying to keep the gameplay. And in the summer I released the game on OUYA ,Gamestick and Amazon’s Fire TV.

Today, I’m posting again to announce that the game is on Steam Greenlight, it’s fully playable and I’m still working on adding more awesoness to it! Like online multiplayer, 4 players, more game modes, etc.

It’d be great if this community could take a look at my game and vote. I’m not asking for a yes, just for your honest opinion.

Here’s the link: Soccertron on Steam Greenlight

Thanks, LD community!

Learning Unity

Posted by
Monday, October 20th, 2014 1:07 pm

First off, I’m already getting excited at the prospect of LD31, it seems to have come around so soon!

I’m new to Unity, and have got the latest version installed (as well as Blender) and was wondering if anyone knows any good resources to help me get a bit further in 3D or 2D and learn in a bit more precise way than the (very helpful) video tutorials that Unity provides. I’m not an absolute beginner as I know a tiny bit about C# and the basics of Unity. Any help would be appreciated as I’m hoping to use Unity for LD31 instead of Pygame (which was one of my most painful and long-winded game programming experiences).

Space Rails timelapse!

Posted by
Friday, September 12th, 2014 5:27 am

Here is the timelapse of how we made Space Rails:

 

We really enjoyed making it, but as with our other games (Macro Marines, Mighty-chondria and ❏♥❀) we spent a lot of time working on a complex system and not so much time working on the gameplay.

This time the complex system was the ability to draw rails freehand in space, and have the trains follow and branch different ways.  Also the supply/demand economy of the different planets has a lot going on behind the scenes.

 

LD30-screenshot-2

 

Will we ever learn?

Troll Away: multi + AR game postmortem

Posted by (twitter: @@_spolsh)
Tuesday, September 2nd, 2014 2:00 am

Comments under our entry encouraged me to share a bit how the game was made. It all started when I have been thinking about idea for game themed connected world. I was considering platformer with switchable environment but in the late evening of first day I came up with craziest idea I ever had at jams. Let’s connect real world with virtual.

troll away gameplay

(more…)

My First Ludum Dare: A Story and Post-Mortem

Posted by
Monday, September 1st, 2014 1:28 pm

harmonyBanner

My

Harmony

Post-Mortem & Story

Hello folks,

I know this might be a bit late but I’ve had a busy week, so here goes anyway. This post is divided into three parts (sandwiched with unashamed self-promotion at either end). The first tells the story of the event and what I went through creating it. It’s quite detailed, so if you’re not interested in that bit please jump ahead to the post-mortem and feedback sections, in which I critique my work and reflect on feedback from you guys so far.

The Game

For Ludum Dare 30: Connected Worlds, I created a game called Harmony, one of the many space-themed entries that made it into the gallery for the event. The game revolves creating an equilibrium in military (often accidentally spelt with two ‘L’s throughout the game, forgive my sins) and economic powers between the inhabitants of six planets so that they can live together peacefully. This is achieved by the player carefully selecting the geographic properties of the planets each of the six races start on and using various powers throughout the game to influence the rate of growth of the civilisations.

The game essentially takes place over three phases: the setup phase, in which the player creates the planets and settles the races;  the pre-space phase, in which the player is given time to balance each of the races strengths pre-emptively; and the final space phase, in which planets start  to interact with each other, the results of which can be catastrophic should the player have failed to setup and balance in the earlier points in the game.

You can read the story (with pictures!), post-mortem and feedback after the jump.

(more…)

Writing a Match-3 game in Unity

Posted by (twitter: @dylanwolf)
Saturday, August 30th, 2014 9:44 am
Dr. Mario (source: Wikipedia)

Dr. Mario (source: Wikipedia)

This year in SeishunCon‘s digital gaming room, I was reintroduced to the match-3 game. I’d played Dr. Mario when I was younger, but more competitive games like Magical DropBust-A-Move, and Tokimeki Memorial Taisen Puzzle-Dama were something very different.

Ultimately, I realized just how many more-or-less neutral decisions are involved in making a match-3 game.

During this year’s Ludum Dare, I decided to jump in head-first. I did a bit of a warm-up the week before, trying to build a Tetris-style algorithm that detected and cleared out lines. This tutorial from Unity Plus was a huge help. Of course, the Tetris matching algorithm–a complete row of tiles–is much simpler than an algorithm that picks out irregularly shaped patches of matching tiles.

If you want to see all of these code samples in context, check out my Ludum Dare 30 repo.
(more…)

Crystal Planet – post mortem

Posted by (twitter: @https://twitter.com/wdebowicz)
Saturday, August 30th, 2014 5:46 am

Crystal Planet

Entry: http://www.ludumdare.com/compo/ludum-dare-30/?action=preview&uid=29762

Description:

You have to send special signal to make connection to another planet.
Signal is a result of adding multiple lasers with different colors (RGB).
Lasers beam are created from generators(flying balls).
You can apply specific color to generator using crystals and your laser.

Your task is to prepare your SIGNAL similar to TARGET signal.

To change target, press [space].

Gameplay:

I started with idea of making 3d “laser and mirrors” type of game. Where you would have mirrors with different colours, and your beam react different on each one. I even succeed but find it very difficult to control beam direction. After fighting 1 day to make it enjoyable I dropped it. Finally I ended up with concept of split colour to R G B code and make objective to generate given colour (RGB code) to connect to another planet.

Graphic:

After last LD where I fight a lot with creating graphic by my own, I decided that next (this) LD I will start in jam. Possibility to use already created assets so I could spend few hours on creating effects, or level design and then focus on gameplay was good decision.

Audio:

First time I used electric guitar for sounds effect and I’m very happy of it. I planned to spend more time on recording audio, but because of loosing time on first idea that I dropped I could use only audio that I recorded for tests. Anyway final result is ok, and I’m sure I will make something better next time!

Evolve:

I’m thinking about possibility to run over planet, explore new crystals and then prepare special signals. Then each signal could create something, or make special attack for different targets.

Do not hesitate to try!

http://www.ludumdare.com/compo/ludum-dare-30/?action=preview&uid=29762

When Worlds Collide

Posted by
Wednesday, August 27th, 2014 4:46 pm

Hi everyone :) the game I created for this LD is ‘When Worlds Collide

You can play, rate & brutally criticize it here!

Direct unity web player link here!

gameplay screenshot

No this is not real space, it’s honestly a gameplay screenshot. Believe it son.

Mechanics :

– Randomly generated solar systems, planets, moons etc.

– Hover your mouse over planets to see planet name, planet population, and planet wealth

– Grapple multiple planets to haul them around the solar system

– Solar system radar displaying location of planets and the sun

– Player health

– Destructible planets and moons

– Dogfight with enemy fighters (pretty tough; got it in last minute)

 

Keys :

‘Spacebar‘ = Grapple planets

‘F’ = Fullscreen

‘Enter/Return’ = shoot

‘R’ = Create new solar system

‘WASD’ = Move up, left, down, right

‘Left Click’  = Hide controls

‘Mouse Hover’ = View planet information

 

gameplay screenshot

This one is actually a picture of real space.

 

Extra : 

The game is a little rough, but I feel pretty confident with how much content I got into it. There isn’t a definitive goal but it’s still an interesting free roam concept :)

It’d be awesome if you guys & gals would check it out and tell me what you think and give it a rate. And again, criticism is encouraged. Have a good one! :)

- Follow Me : @OfficialDingbat

Spacecat Marines!

Posted by (twitter: @IcarusTyler)
Wednesday, August 27th, 2014 4:49 am

It is done! Go check it out :)

In Spacecat Marines you go from world to world in your ship, the Bigglesworth. You have a crew of spacecats with their own unique appearances and equipement, which accompany you on missions. During those you have to defend power-cores in fps/td-hybrid. They also get more experience and level up in rank.

spacecatMarines01

Features:

  • Your unique team of Spacecat Marines
  • Neat Soundtrack
  • Spacecat Marines. With guns.
  • Non-linear progression – chose which mission to do next
  • 12 missions with different challenges
  • A ship to connect you between worlds

spacecatMarines03

I also made a timelapse, showing me working furiously:

-Matthias

Elementry – Beat ‘em up!

Posted by
Wednesday, August 27th, 2014 1:33 am

So we found out a way to finish our game on time despite of all the problems we had (idea for the theme, programming, art) and this is it! I hope you spare some of your time to play our game! Gameplay Fire beats Earth, Earth beats Water, Water beats Fire. Have fun! Btw, this is our second game for Ludum Dare.

http://www.ludumdare.com/compo/ludum-dare-30/?action=preview&uid=41003

Fusebox Post Mortem

Posted by (twitter: @empyrealhell)
Wednesday, August 27th, 2014 12:01 am

This past weekend I participated in the 30th Ludum Dare 48-hour competition and created Fusebox, an energy management simulation game. What follows is a summary of my experiences creating it, and what I learned from doing so. I had a lot stacked against me, and while I missed some milestones that would have taken the game from mediocre to great, I think that I did really well considering the situation. Before we can assess that though, we have to start from the beginning.

Sure-footed as a Mountain Goat

One week before the Ludum Dare competition started, I was at the local rock gym with a friend of mine. They had more than just rock walls there, and in my first (and most likely last) attempt at this whole slack-lining thing, I fell and landed sideways on my foot. It instantly swelled up to the size of a potato, and I haven’t been able to walk properly since. I have made a pretty decent recovery so far, but one thing I can’t do is sit up. If my foot isn’t elevated above my head, it swells back up like a balloon and becomes incredibly painful. Since working on a computer with any amount of comfort necessitates putting your feet beneath the desk, I wasn’t sure how it would turn out.

This is what you get for hanging out with extroverted adrenaline junkies.

This is what you get for hanging out with extroverted adrenaline junkies.

Over the course of the weekend, my foot turned out to be both more and less of a problem than I expected. By lowering my chair, throwing a pillow on my desk, and leaning back, I could actually sit somewhat comfortably for more than an hour at my desk. It required me to be a bit twisted, and it probably wasn’t good for my back, but I was actually able to sit at the computer. Had this not been possible, I had a backup plan of writing a game in javascript from my laptop, since it can’t run Unity. In retrospect, I probably should have gone that route, but I really wanted to try this out with Unity, so I suffered through.

The downside to this was that I couldn’t get into a position that was ideal for either my foot or for writing code. I was at least slightly uncomfortable the entire time, and several times throughout the weekend I had to stop and move to the couch to give my foot a proper rest. This had two side effects. The first was that I lost a lot of development time to laying on the couch with my foot on the back. The second was that in order to try and take advantage of this time I brought my notepad and did as much design and planning as I could while I was away from the computer. This is probably the main reason the game is so complicated and over-engineered.

This is the first time I've taken hand-written notes in years. I had to use one of those weird scratchy tube things to scrape my thoughts in stone.

This is the first time I’ve taken hand-written notes in years. I had to use one of those weird scratchy tube things to scrape my thoughts in stone.

What is it Even Uniting?

One of the main reasons I do these competitions is to force myself to try something new. I’ve used new engines, tools, or frameworks every time, and I’ve never made a game in a genre that I’ve done before. It’s a great way to learn a lot in a very short amount of time, and when you’ve been programming for a length of time measured in decades, it’s not a stretch to try and figure something out in that time frame. Since my current game project is in Unity, and I’ve been struggling with it since day, I decided that I would force myself to figure out and use Unity for this competition. In retrospect, I’m glad that I did, but it definitely slowed me down quite a bit.

I also chose to do a very UI-intensive project this time around, for a couple of a reasons. I felt that my foot might get in the way, and I wanted something I could work on from the couch if the need arose. I also know that I hate writing interface code, mostly due to the fact that I’m not very good at designing interfaces, and I find the whole thing very tedious. I may have been setting myself up for failure here, but the goal was never to win the competition. In all of the work I’ve done on Project Dunwich, I have not even touched the interface yet. At one point I actually had to look up how to make a button. I was starting from scratch here.

So... Much... UI Code...

So… Much… UI Code…

The Thought

Despite using tools and techniques I was unfamiliar with, and dealing with Quato growing on my foot, I felt pretty good going into the competition. I had read through the list of themes, and I focused my thoughts on the highest rated candidates from the first four days of voting. This is by no means a fool-proof method of predicting the winner, and I wasn’t writing any code or committing anything to paper, just idly thinking about the design possibilities. I ran through some ideas while I went about my day, and initially I wanted to make something with more action, since my last two attempts sort of fell flat in that regard. Most of the ideas I thought of with any amount of action seemed either too obvious, or not connected enough to the theme, and UI was another focus area, so I settled for a management sim game.

Once the theme was actually announced, I was a bit relieved that the top theme won out, since it meant I already at least knew what genre of game I would make for it. The idea was simple, connect worlds together through some interface, but give those worlds multiple, intricate layers of connection. I like to make my games hit the theme in multiple ways, and that satisfied that requirement. Connecting worlds to an energy source was the obvious take on the theme, but having them be linked to each other as well added a nice extra layer of depth to the interpretation. I’m not sure any ever notices these little touches, but it makes me feel better about my interpretations.

I'm really happy with how the planet rendering turned out. It's a shame I never got a chance to make that interface actually useful though.

I’m really happy with how the planet rendering turned out. It’s a shame I never got a chance to make that interface actually useful though.

The Look

I immediately started with graphics, since I didn’t think there would be very many, and I wanted to get it out of the way. I drew up a mock interface, some icons for the planet stats, and some graphics for the planets themselves, and actually had something passable by the end of the first night. I have used Inkscape quite a bit over the past few months, but I had never done clouds or noise in it, so that was a fun little challenge to overcome. In the end, I spent less than four hours total on graphics, and I’m glad I didn’t have to fight with them at all once I got into the interface code.

With graphics in hand, I set to create the game objects and renderers that would use them to actually put the images on screen. Unity actually made this really easy, though I have no idea if the setup I used is proper for an entity-component system. Since most of the game objects were just data containers, that didn’t take very long, and well before the half-way mark, all I had left was to write the code to process the interactions on the game objects, and then do a whole lot of UI work. After a brief stint on the couch to rest my foot, I started in on the UI.

It is a damn good thing I don't have to actually draw interfaces. I drew it and I can't even tell what's going on in some spots.

It is a damn good thing I don’t have to actually draw interfaces. I drew it and I can’t even tell what’s going on in some spots.

As I mentioned earlier, I had no idea how to approach the interface. I created things using GUIText and GUITextures, I switched to converting screen coordinates to world coordinates and driving the UI with game objects, and eventually discovered the OnGUI method and settled on using that. Throughout the course of the day on Saturday I created as many interfaces as I could, to enable interaction with the game objects. I could just as easily have started by coding that all into the setup and working on the simulation, but that seemed like it would be harder to iterate on. Once I learned how to make the interfaces, it was a pretty smooth ride of create, test for usability, modify, repeat. I didn’t do things in a very efficient way, there’s a lot of copy/pasted code for UI stuff, but I just kind of zoned out and started writing.

The Logic

By the end of Saturday, I had about half of the interface done, and none of the game logic. That seemed like a bad situation to be in, so I set out to right that first thing on Sunday. Since I had spent a fair amount of couch time writing out notes on how I wanted it to work, that actually went pretty fast. The logic is pretty complicated, there are a lot of moving parts that determine how the hardware will react, and how the planets will respond to their situations. The biggest problem with all of that is that I couldn’t get the interfaces done in time to actually explain all of that to the player.

My half-baked attempt at a tutorial. The best part is that I didn't even get to implement some of the stuff I explained in here. Super useful.

My half-baked attempt at a tutorial. The best part is that I didn’t even get to implement some of the stuff I explained in here. Super useful.

The final interfaces were the ones that told you what was going to happen when you advanced the day, and the one that you manage your circuit board. You know, where you actually play the game. I knew what needed to be done, but by Sunday my foot was in open revolt against me. I spent a lot of that final day on the couch resting, and with nothing to plan, I just sat there mentally writing interface code to draw out how I wanted it to look. The funny thing about mentally writing out code, is that it’s a completely useless activity. When I felt good enough to try and implement it, everything fell apart on me. I had planned on whipping up those last two screens and then playtesting the game for bugs and balance. What ended up happening was a mad dash to get the interfaces working that ended about 15 minutes before the deadline.

At Least I Finished… Sort Of

I decided that I was done, and 15 minutes wasn’t enough time to get any of the last things I needed from where they were to where they needed to be to even be passable. I set to build my project and upload, and then Unity decided to remind me why I hate it so much. Apparently the method I was using to color the planets with HSV colors was only available when you ran the game through the editor. It wouldn’t even compile. Fortunately, HSV to RGB implementations are a easy to code, so I started throwing one together. In the past I’ve worked on them with hue being an angle from 0 to 360. Unity’s method had it as a float from 0 to 1. No sweat I thought, I’ll just multiply it by 255. If that doesn’t make sense to you, it’s because it shouldn’t. All of the planets turned green because I mixed up angles with rgb values, but I didn’t have time to figure out why. Up it went, and just like that it was all over.

I’m glad that I made the choices I did. I learned more about unity and its UI features in this past weekend than I have in the past four months. Sure, I could have scrapped the planet interface and focused more on good UI, and I probably would have been better off spending time on tutorials rather than tweaking button positions. Given the constraints I was working under, I’m really happy with how things turned out. I do have some ideas for how to improve next time though.

  • Simple design with good balance – I had so much time away from the computer that my end product was as overly complicated mess, and there’s really no way for the average player to figure out what’s going on. Having a more simple design with a better balance would have been a better approach. Instead of having four types of compatibility and a two-hundred line calculation for fuse load, cut it down to two stats and spend more time on making sure the numbers work out over the course of the game.
  • Interaction before eye candy – My planets look way better than they need to for a game that is mainly driven by button clicks. If I had put that off until the end, I would have been able to see that before wasting time on them, and I might have had time to implement things like a proper tutorial or a win condition.
  • Playtest as early as possible – I put the core logic off for so long, that by the time I had it finished, I was already in crunch mode. This left me no time to make sure the numbers worked out, or that the game was even fun. With a game like this there’s really no excuse, I could have had unit tests written to test out the formulas and algorithms through all 100 days by Saturday morning if I had prioritized it. Good balance is going to be my main goal for next time.

That about covers it. I had a good time, and in the end I have another game to throw on the website and say “look what I can do in a weekend.” No matter how bad I do, or how stressful it is, that sense of accomplishment will always be worth it.

Must to be Invasion Post-Mortem LD30 (Jam) – Solo

Posted by (twitter: @progex)
Tuesday, August 26th, 2014 1:13 pm

Hi guys, this is a post-mortem of : Must to be Invasion

For those who have not played I recommend you play, to better understand what I mean. I will cite references in the game to practical examples.

What I used:
– Unity 4.6 (2D project)
– Photoshop
– Audition
– Google

 

Time-Lapse
Day 22/08 – Start: 23h – Total work: 5 hours
– 3 hours of brainstorm
– 1 hour enhancement concept
– 1 hour prototype
– Sleep (4am day 23)

Day 23/08 – Start: 13h – Total labor: 16 hours
– 2 hours drive to implement player
– 3 hours collecting the web assets
– 2 pm Lunch / Dinner / Rest / Play / Chat
– Implement person 30 minutes
– 1 hours Implementing player commands (shoot, abduct)
– 30 minutes Implement cars
– 1 hours Implementing fake-physics
– 1 hours tidying bugs
– 1 hours rewriting code to be more readable
– 2 hours placing and arranging scenery animations, camera
– 2 hours writing fake-AI for helicopters
– 30 minutes implementing the helicopters
– “Breakfast” 30 minutes
– 1 hours testing and correcting bugs
– Sleep (15h day 24)

Day 24/08 – Start: 15h – Total labor: 7 hours
– 4 hours Rest / Eat / Play
– 1 hours tidying bugs
– 30 minutes implementing life cycle (person dies -> turns ghost -> abducts -> turns zombie)
– 1 hours Fixing problems in resolving
– 1 hours recreating scenario
– 1 hours and adding difficulty leaving the way I think it has to be the level
– 30 minutes implementing sound
– 2 hours doing input screen and other screens
– end

 

This was my first ludumdare, but not first GameJam. So there are some things I had in mind when I decided to enter:
– Make a game that I already have in mind how to start (like platform, running, football, etc), ie, not risk on land that I have no idea where to start
– Use an engine and language (programming) I understand and used before
– The clear concept is the key
– Eat well
– Sleep well
– Know what your potential. Ex: not necessarily choose the first idea that comes to mind after seeing the theme
– Know the difference between technique and what can be done in 48h / 72h. I often fall into the trap of thinking you could do a game in so long only because I had already had done and know-how, but unfortunately time is needed, not only to produce but to fix things that do not work, improving among other aspects. Ex: Make a spaceship game
– Do a post-mortem of the game and numbering (if possible) what were the failures and what happened as planned. This also applies to personal growth

What I learned and / or should have done
– I need to learn more about other areas (art, sound). Ex: Scenario
– I need to stop spending so much time on things that will not change the player experience, or enrich the game. Ex: animation of the input screen
– Structured better the game, from beginning to end before starting. Ex: no end, and in the middle of the project I thought of putting an end, put two players
– Having planned my time better. Ex: I overslept and spent time playing and doing other things

What will never be satisfied and always will think that I have to improve (for game jams)
– Learn more about the tool
– Structure the game before you start
– Polishing, polishing and polishing. I know it’s not possible, but I feel well and is not too bad.
– Mechanics and Design Level

 

Do not know if this will help someone, I found it necessary to share with you what I went through.
There is a saying: what good is an education if you do not pass along?

For the last, I encourage you to write and share your post-mortem, I would love to read.

I hope I have been as thorough. I swear I blacked out many other details to spare you from them.

Comments, criticisms are welcome.

Thanks for reading this far.

 

Images – More images here


[cache: storing page]