This jam I:
+ Gamified turn signals: Oal accepted signaled collisions.
+ Played levels 1 to 7: Blobo felt challenged in most.
+ Modeled 5 blocks, 5 colors: LittleThor felt voxels were cute.

Next jam I could:
– Playtest levels 8, 9, and 10: Blobo said they are too hard.
– Playtest until I win: TheMeorch would restart after a mistake.
– 3 hrs of audio: Oal wanted music. LittleThor wanted effects.

When you play Auto Racer, how do you feel?

LD34 – Stardust

I was not very fond of the two themes that made their way to the top of the list. After an hour of brainstorming different game ideas I found it actually wasn’t that bad. I ended up with three ideas that I chose between. The first being an endless runner that involved dodging food as it makes you slower, until you can not run. The second idea was also an endless runner but involved some action with a jump and an attack, very unoriginal. The third idea is the one that I went with.

Game Idea:

I ended up going with a space object, or at that time a comet, that would fly through space collecting smaller objects until it became a star. Overall the gameplay was unoriginal but the slight variant and my love of space made be go with it. Instead of rushing into the barebones of the game I decided to do some research after I decided what kind of game I was going to make. I read up on various space objects and their respective sizes to get an idea of various stages the little comet can go through.

There were a few additional ideas that I came up with but they didn’t make it into the game. I didn’t get to add any other objects or special upgrades or even easter eggs. I spent a lot of time in Monodevelop trying to figure out how to fix my code or do simple things. I had played around with Unity before but I had never actually made anything outside of a tutorial before. I have programming experience in other languages though and some game logic experience from the past two ludum dares that I participated in that helped me get the game done in time.

The fact that I was able to finish the game, and have it up and playable amazed me considering this was my first time with Unity in terms of real development. I feel like with some more practice I will be in better shape for Ludum Dare 35. I also want to work on my audio and pixel art skills. Here’s to next time!

Check out Stardust!

Found me 😀

This was a game in itself!

By the way, Digicross recieved an update few days ago. It is not the official download since it’s post Compo.

Download post Compo

See Digicross Page

Hi!

We are super exited to announce that the post-jam web version is ready now!

PLAY & RATE HERE!

Just click embedded game and enjoy We added something even more cheesy.

Click following screen to see the gameplay animation.

Tags: 80s, ld34, starwars, synthwave, tkgames, unity

Zach here (the code simian for our entry)
So this particular jam was probably the smoothest one for us to date. There was a small hiccup as I tried out the new JSON tools for Unity (which fails silently on unsuccessful deserialization), and eventually came to find out it couldn’t deserialize Dictionary objects (it can only deserialize objects already handled by Unity’s own serializer), but only an hour or two was lost. I was also learning something mostly new to me (the entire game used Unity’s new-ish UI system), but that also went over pretty well.

So what was the x-factor?
Sleep.

In all previous jams, we’d push ourselves to the limit, pull all-nighters, really try to squeeze as much productivity from ourselves as possible. I usually take the Monday off from work as well. This time around, we took a much more relaxed approach; we didn’t really even get started until around noon on Saturday. We didn’t stay up super late, ate regular meals, and attended social functions that came up.

As a result, whenever we were actively working on the project, we were fully charged and able to put in our best effort.

So I guess there really is something to be said about getting adequate rest. It’s probably fine to crunch as the deadline approaches, but to do it from the start is pretty much suicide for a project.

We ended up with a game with relatively clean code, few bugs, and actually managed to get in just about every feature we’d originally planned on. We didn’t really get to playtest a lot, but the compulsion loop was fairly sound. Ingredient gather is a bit boring and tedious, but overall, we’re both very proud of what we managed to accomplish.

The mechanics are pretty simple, and I personally approached the game as though it were a sub-portion of a larger game (a crafting system). That may have also contributed to the lack of stress.

So, be sure to check out our entry!

Hello everyone,

Our team regularly participate Ludum Dare event but this time was our first experience with Unity engine and i must say it surprised us. No person from our team worked before with C# so it was a bit challenging and we made it!

We developed our game in biggest in Siberia hack space which named IT Loft. Over 20 teams making their games in the same time in same place and it inspiring for creating something special because we have local challenge here in IT Loft and every one want to provide their best

All the people taking a part in local Omsk Ludum Dare event (OLD34)

So our team was a bit confused by two themes at once (so as you i think) so we decided no to pick one but use both. While brainstorm the concept of small micro management game was born. So we have small and extremely cute mushroom elves whos trying to build their kingdom. The bad thing that sun is extremely dangerous for elves so  they should finish growing the mushroom tower before sunrise and evil ugly orcs want to destroy mushrooms and eat it. You as mushroom elves commander should take orders for your people and you have two option: watering the mushroom or fight the orcs. You should keep balance because the number of elves is limited and you have to grow the mushroom tower  in time. So this is our concept.

Our designer at work

Of course we made all the work ourselves so our designer made all the graphic, we write some soundtrack and code all the gameplay. We put a lot of efforts in this game and it developed with all our love. We hope you will enjoy playing it and put the mark what it deserve

This is the link for our Ludum Dare entry.

Cheers,

Monochrome Bears team.

Tags: MonochromeBears, OLD34

Colony XG-29 is a strategy and resource management game where you take on managing a fledging human colony on an outer rim planet. It was developed solo in 72 hours using C# and Monogame.

Details and download link

Here I’d like to talk about the design process, what went well, and challenges I encountered.

I am quite verbose. So to save your scroll wheel on the main page, everything is below the fold.

Theme

I’m pretty bad at predicting the final theme. Like the last LD, I had barely thought about either of these themes in advance. It took around 2 seconds to rule out two button controls. Then it took around 2 hours of brainstorming to settle on a direction for growing, which was too much time.

Initial Designs

“Why not both?”

I did come into the LD hoping to make something turn based and mechanic heavy. That probably meant either a TBS or a card game. I don’t know what happened, but I must have had an aneurysm because for some reason I thought “why not both?”.

The original design idea was to grow a colony of settlers using cards to place buildings and perform actions. I didn’t have a really good sense for how the game would play out. I think I was expecting the cards to be a secondary mechanic for the turn based unit and building management.

One of the first major decisions was setting. A space colony seemed to make a little more sense than a historic or fantasy setting. Having some sort of abstract stockpile of things that could be used on demand didn’t seem to fit those settings.

Development

“Hexes are future-y”

I have written a lot of engine and other game code over the years with C# and Monogame/XNA. Other than my core engine, I pulled in some of the card rendering and basic interaction code I used in mini-LD 60 (but then ended up rewriting a lot of it). I also have a bunch of code to support a hex grid with structures, rendering, and camera controls. Going into the LD, I didn’t really want to reuse the hex rendering logic since I’ve used it for several projects and it’s a bit of a beast, but hexes are future-y and fit the theme. Eventually I was also able to crib some of the tutorial system from LD 33.

That all makes it sound like I just had smash a bunch of bits together and call it a day, but I definitely wrote more new code this LD than any previous one. Wiring up the hex grid rendering code to the point where it showed terrain took almost all of Friday evening, if that’s any indication.

I wasn’t really sure how you would select or generate cards. I knew I wanted some sort of pack opening mechanic integrated somehow. While trying to think about how it would work during normal gameplay, I hit upon the initial drafting mechanic. It fit really nicely with the theme as like selecting supplies for a space ship. As soon as I had terrain rendering, I switched gears and implemented the card rendering and built out the initial card drafting screen because it made a good simple test.

After hooking up some basic cards on the map and the resource system, I started to get an inkling that I was just building a turn based, single player, Offworld Trading Company. I really wanted to differentiate the game. I had originally thought about military units fighting off aliens as sort of being a primary component of the game, but wrote it off for time as things were dragging on. The game needed something more, so I put in the aliens and built up the combat and AI. Supporting direct unit control for player units was going to take too much time. Instead I was planning on having turret-based defenses, but once I had the units in it was easier to just drop one in as owned by the player with some small AI tweaks. I had the units pop back to your deck when idle because I didn’t know what else to do with them. With that hooked up, I never felt like I needed to circle back to add defense turrets. Automating the units after placement gave the game more movement, kept it from dragging with micromanagement, and meant you didn’t have to fill the board with a giant turret ring.

I knew I needed a way to get more cards from very early on. I wired up the black market, and set up a system for card pack vendors. That system really highlighted just how few cards there were. You’d open a pack, and get the same cards every time. The problem was that I was already behind schedule. The goal I’ve had with LDs is to have a complete and playable game Saturday night. That leaves Sunday for testing, audio, UI polishing, balance, etc. I didn’t hit that point until Sunday afternoon and the last four hours of the compo window was a mad dash of building a bunch of cards to fill in packs and blank spots in the economy.

This game continues my tradition of terrible names created at the literal last seconds

Compo -> Jam

“Making a better game won out”

It was and incredibly frantic weekend, and I didn’t have time for audio, but I did it! I made a compo game on time! One little problem. I hadn’t actually played the game. It ran and the features mostly worked, but I had ran out of time before playing it with all the debug cheats off. After some food, some errands, and some relaxing, I reevaluated what I had made. It was technically a complete game, but it wasn’t fun.

I had to make a tough call. I had created a game within the compo restraints, but I was very disappointed with it. I had taken Monday off as an LD recovery day, so I had flexibility. In the end, making a better game won out.

“Why does this tiny colony need this many hospitals?”

There were a lot of problems with the compo version.

• You very quickly had more resources than you knew what to do with – This is still a problem to some extent, but it was worse in the initial version. You could not practically spend your resources fast enough. To address this, I created reusable cards like the DarkNet Channel to act as money sinks, and created disasters to eat chunks of your reserves. I strongly considered adding resource caps that you needed to expand, but ran out of time.
• You had to wait too long for population to grow and the last 200 citizens took ages – I added in the random chance for colonists to arrive, and added the Offworld Shuttle as both a population pump an money sink. I also magnified the effect of happiness, which hadn’t increased population enough in the late game
• You constantly had a ton of dead cards in your hand – one of the problems is that if you bought a pack of cards, you got all of them. If you wanted a specific card, you’d get several duds as well. I added in the resell mechanic, the direct vendor purchase, and the recycling card to help keep your hands small.
• The aliens were only a thread because you had so many useless cards in your deck you had to skip to get to a military unit – I strengthened some of the aliens, and increased the costs of the military units
• Buildings could go anywhere. There was no reason to not just plonk buildings down wherever – I wish I had time for more of these, but I added the Network Hub and changed to Vidplex to change based on the surrounding buildings.
• There wasn’t enough variety – Originally the only event you could get was the black market. I added random disasters, colonists, and the direct sale screens as alternatives. I did make a handful of new cards as well, but I didn’t want to flood the game with slight variations on the same cards, they needed to be unique.
• You spent more time reading tooltips than looking at the card – I improved some of the card-mouse interactions, and specifically added the hover effect that pops cards in hand forward.
• Happiness was pointless after a few dozen turns, you really had to let a shortage get out of hand to offset the happiness from buildings – this took a lot of thinking. Futzing with the formulas would either make the early game too difficult, or it was confusing. Eventually I settled on the adding the health mechanic. After a certain grace period, the illness value periodically starts ticking up by one, and every turn the population goes down by the illness number. That doesn’t make a ton of sense if you stop to think about it (why does this tiny colony need this many hospitals?), but it solves several problems. It can have significant detrimental effects if you don’t deal with it, health buildings are a resource sink, and it acts as a sort of ticking clock beyond the aliens.
• You didn’t know when the aliens were coming, so you had to play zoomed out and constantly scan around for alien movement to deploy your units – I added the notification queue so you can see them coming.

At final count, I had 7 units, 24 buildings, and 38 cards. For as much time as I spent on them that feels like such a small number.

What went well?

I really feel like I nailed the content workflows this time. I figured out a way to skip one step to import content with monogame, but I also saved tons of time ignoring the XML-driven content system I’ve used in past games. Instead I focused on generating all the card rules and text in code. I’ve picked up great C# techniques since the last LD that were really clutch. The last time I tried game data via code, it meant constructors with tons of parameters and/or lots of switch statements and special cases all over, but now I can make this so succinct. This is all it took to get a card in game:

That’s so much simpler than the XML deserialization nonsense I had been dealing with, and delegates make special cases so much cleaner.

I took good advantage of C#’s async feature. It was very convenient for the card playing logic. It made it really easy to create a code flow like click -> wait for animation to complete -> prompt for a cell on the map -> actually play the card. No need for a bunch of state variables or deep callback chains, it’s all one code path. (FYI: If you’re thinking of going down this route with Monogame, by default your tasks may land on a second thread, which can cause unexpected race conditions. You can fix this by rolling your own SynchronizationContext)

I found a bug in my engine that has been there for probably ~5 years. This is an improvement over last LD, where I ran into a lot of issues with the control layout and interaction code that led to significant rewrites afterwards.

What went poorly?

“I should have known better.”

I should have known better. Mini-LD 60 was a card game, and it ate so much time. Building a turn based strategy game on top of that was madness from the very beginning. I never had time to stop and consider how much work I had set myself up to do, I just kept going. Not submitting for compo was disappointing, and this was ultimately the cause.

Even with an extra day, I didn’t really have enough time for audio. I just couldn’t prioritize it over making the game playable and intuitive. Making music was out of the question, but some simple sound effects would go a long way. In retrospect, I probably could have reused some old audio with the jam rules, but wiring it up and mixing it still takes some time.

Cards have a rarity that impacts how often you see them in packs, but you basically can’t tell and it doesn’t matter. Every pack has a rare, but since there are so few, they’re sometimes practically more common than other common cards.

There isn’t much of a reason to explore once you’ve found the three basic resources.

Future plans

After the extra day of balancing, I’m super chuffed about this game. I’ve played through it a few times after submission just for fun, which I haven’t done for an LD game in a while. I’ve got tons of ideas for cards and mechanics. I really do want to see this thing through. Art will be a very large challenge, though. Programmer art is not a cohesive style. I’m thinking about clean and solid colors, maybe something like this?

[looks like I didn’t put a shadow under that smokestack… whoops]

Title: Auxochrome

Description: Time travelling action platformer where you play as a color retriever to collect chromosphores from enemies in land ruled by auxochromes!

Growing Theme: You start of small, can run fast and jump high, but as you eat chromosphores (pixels) you gain color and are able to then scale in size. Once you become as large as the boss, you are as strong as him, however you lose your speed and your jump strength which can make it very difficult to save the land!

This was my first jam and I would like to call it a success!

Things that went well:

• Art
• Theme: Growing (We loved the theme idea and came up with an idea relatively quickly)
• Programming (There was a lot to program in 72 hours and for the most part we got everything implemented that needed to be there)

Things that did not go well:

• Time management

I didn’t use my time well and rightly so. We only planned to do the jam the day of and even though the theme gave us an idea, we didn’t have much of a direction until we put the boss on the podium (and that was in the 11th hour). So, the reason I say time management is because I realized after I hit submit, that I forgot two super important things.

1. The small enemies were impossible to kill

2. The enemies didn’t scale

Oh and we didn’t have time to fix the broken SpriteFont sooooo we left it in there. But the things we left out and the reason why I am about to ask this quesiton is, the engine was a success the gameplay needs more. So with that said, if you could now:

– RIP MY GAME TO SHREDS –

It would mean a lot to me By ripping it to shreds you are helping me for the future version as to what might make the game more fun. Please let me know of gameplay elements I may have missed, story elements I can add or anything else to make it fun!

Things I already know to implement in the full version:

• More weapons
• Easier enemy deaths
• Enemy scaling
• More story to focus the world (to tie in the greyscale)
• Everything else that goes with it being a full game (more levels, menus)

I am going to start a devlog on it soon but wanted everyone to play and if you could vote and leave a comment that would be great! We are going to start work on the full version in the new year! Thanks for reading and playing!

PLAY AUXOCHROME HERE!

Tags: auxochrome, postmortem, yuotta

This LD I made a tetris-like base builder in space!

Sanctuary Station in action!

I made this as a Jam, because I did not have Saturday off and wanted to spend 2 days on the LD. (basicly a compo entry, with only two sound effects sourced externally.)

The Concept

This game started out slightly differently – I had prepared/pre-thought about games for most themes, but this theme combo stumped me a bit. At Sunday 1200 I finally had a concept, which was more about the guys in the pods than the pods themselves. A few hours laters I realized matching the pods to the central hub is actually the fun part!

The Bad

• Spent too much time on the lil guys in the pods & them walking about
• The pod movement is a tad klunky when you change direction or collide
• Could have added more sound FX, more appropriate music (always the last to go in)
• Only 2 levels, of which one is more a tutorial

The Good

• Pivoting when finding the fun
• The ‘clunk’ of airlocks joining
• The learning curve – the two missions have good ways of ‘starting’ fully when the player gets the mechanics
• The visuals – simple sprites, with moving light from the guys and (easy) star-field background go well together

The Result

I am very pleased with the results, and plan to make this into a proper game – I see lots and lots of ways to add depth and variety.

Please play it & provide feedback!

So after a little more time and effort, and motivation from the awesome feedback, I have finally uploaded spin-circle HD to the Google Play Store.
Thanks everyone for your comments, they are really nice and up-building.

Ludum Dare Entry: spin-circle
Google Play: spin-circle HD
Free to download, no Google+ required, but available.

If you would like my to play your game, please leave a link in the comments. I’ll be happy to check it out when I have time 😀

Tags: ld #34, spin-circle

Hi.

This was my first Ludum Dare, and I dare (get it?) say it went fairly well!

I made Polygonal Expansion, a strange rhythm-based game pre-loaded with a single royalty free song that hardly manages to maintain tempo.

Anyway, I had so much fun coming up with an appealing concept while also figuring out how on Earth I was going to program that. I feel like this was a worthwhile experience, and will probably take part in the next one as well. Enough babbling, though. Let’s reflect.

I hated the Two button controls theme. It’s really more of a restriction than something to build off of. The first thing I did in my Post Jam Update was remove that restriction as far as I could. Growing, on the other hand, led to the conception of so many great games. Okay. Let’s continue.

Development

I came up with the concept within about half an hour of the theme announcement, and started working on the game that night. It was in working order, which is a foreign experience to me. After some sleep, I continued my work and had a full-blown engine on my hands that was — and is — more versatile and complex than anything I’ve made in the past. (Am I disappointed that some of my best programming came from 40-ish hours of work and sleep deprivation? No. Okay, maybe.) I honestly don’t know how I came up with it, but whatever. It works. Mostly.

Anyway, It was Sunday night by now, and I had school the next day. Instead of stressing myself out, I figured out how many hours I had and needed to finish up this game and submit it, then did the school thing. I got back from school, did all the things I knew I needed to do, and submitted. And got scared, as expected. The people who have played it so far seem to be enjoying it, barring a few things. I fixed a majority of them in the Post Jam Update. (Again? Really?)

The Good and the Bad

First, the good: It appears my inability to let my work fall below a threshold of quality has really helped my game stand out a little bit. I usually strive to at least make my games enjoyable to play, if nothing else. (Frankly, I can’t stand when games have awful controls or just don’t feel good to play.) I got everything I wanted to get done done in time for the jam, and ran into no real major issues at all.

The bad: Uhm… I lost some sleep? Honestly, this went surprisingly well for being my first strictly timed attempt at making a game. No real problems came up.

Finally, the Future

I feel like this game has some potential to be somewhat entertaining, but I am wary of the bias I have toward my own work. I will be waiting until after judging is over to continue with potentially developing this into a full project.

Until then, I can’t wait to see which games win what categories and if any of my top games so far will make it! Good luck and good work, everyone. It’s been so much fun playing ~1/28th of the games everyone made, and I can’t wait to play more. Truly inspiring stuff.

Happy Holidays, everybody.

-GogglesKitty <3 (Scandalous Twitter Link)

Hi! Try the game here 

I was hesitant to add a WebGL version for a while, but I decided to do so… just to make it easier for some to check out my game, Retro Rebound Challenge. The WebGL version has a slight sound issue when the ball hits an object… it sounds a bit “raspy”. If you decide to play this version, I hope you can overlook that as it is beyond my control. If the ball sound does factor into your rating, please check out the Windows or OSX versions.

I tried various “blip” sounds, and for some reason the WebGL version rips it apart. I will continue to work on a solution.

I am also interested if you feel I should continue development. I have some unique ideas for this game, including an editor so you can make your own levels. Is there room for another pong-type game?

Hi guys, what are you waitng for?

Click the link and try our new creation! GARBAGE RUN

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

I’ve made a short drawing timelapse of my LD34 game.

Hey, we added our game to the GameJolt and now you can play it from there!

Play our game!

Keep the rhythm and save the day…on Mac!

OSHIYA! PUSH! now available on OS/X!

Play Game