Hiya!

First of all thank you for another Ludum Dare. This was my 5th and its been a blast like every other in the past. My entry for LD34 is Drone Racer.

I think we can all agree to some extent that the theme for LD34 was a little bit weird. On top of that having two themes makes it even more confusing. Sometime I brainstorm about theme one and other times theme two. I even tried to mix the two themes together hoping that I will come up with an idea that somehow involve both themes. I can assure you now it was a very bad idea. But for some mysterious reason my brain just wants to combine the two themes together. I lost couple of hours in the beginning arguing with myself which theme should I focus on. In the end, as you may have probably noticed in my compo entry none of the two themes were clearly reflected. Oh well…

In every Ludum Dare I participate, I try to experiment with new mechanics and gameplay ideas. My first idea was to fly a drone in a high security facility and steal vital intel without getting detected. The drone is equipped with smart technology that can hack into any remote device. For the sake of theme/simplicity, one button allows you to hack open the doors and the other button allows you to hack into the security cameras and pause them off for limited amount of time. Every time you perform one of those two hacking actions the global threat level grows, guards become more and more vigilant and it takes slightly more time to hack into successive devices. There you go both themes are covered, my brain wins. Yayy. Now its time to write code.

Before calling off my first night, I was able to fly a drone in an empty space. It was a decent progress. I prepared a big list of all the tasks I had to do the next day before saying good night to my computer. I kept pondering in my sleep if the game is still doable or not, both asset and code wise. In any case I have to re-evaluate it again the next morning. As I was going through the list of tasks I have to accomplish in the next 36 hours, I felt that the scope of this idea is way bigger than I originally expected. Producing all the assets that could deliver the right mood and compelling gameplay will be a challenge. Since I suck at art anyway, it’ll be harder and more time consuming for me to create all the assets within such a short period of time. I steered away from it for a while and thought what else I could do that involve minimum art. Lately I have developed an obsession about owning a drone and hoping to take part in some sort of drone racing (just for fun) in the near future. Thats when Drone Racer came to life. Although I was tempted to make a two player split screen drone racing game but my previous game jam experiences reminded me that if you want people to play and enjoy your jam game it has to be single player. Racing with bots is not much fun so I turned myself towards making it a challenge based game. And voila, here is Drone Racer equipped with six unique challenges, each grows in difficulty than the previous one. Every challenge focusses on various aspects on drone maneuvering capabilities.

This looked more achievable compared to my original idea and equally fun. I sat down to work and the next thing I know “its time to submit”. The compo was over and I didnt even realize where all that 36 hours went. I was feeling proud and accomplished. Once again I did not failed. Things turned out great and I had a game. One more fun filled weekend came to an end. Now its time to get away from my computer and see if the world around me still exist :D.

If you haven’t played and rated Drone Racer yet, please do it before the rating period is over :D. Thanks for playing!!!

Till Next Time!

Anshul

Tags: #LD34 #LDJAM #LudumDare #GameDev #IndieDev

If you haven’t already checked it out, go play our game Grow Your Hoard! and give us some feedback! We’ve found an artist that is interested in helping us make a full game out of it, and we want to know everyone’s thoughts!

I’m glad that I took part in another Ludum Dare. This being the second one, I was hoping for a nice challenge to present itself. The first Dare was not too hard, but this one took a toll on me. How? It had me questioning the very existence of what I was even doing. It took me about half the time of the Compo to think of a proper idea, and I just barely finished in time for it. Instead, I submitted to the Jam since it’s only my second time around. So here’s the good and bad.

Also if you haven’t played this yet, head on over here

Mobile port screenshot

The Good

So basically there was a lot of fun involved in making this game. I did not put a huge amount of effort, yet I still got some nice positive reviews from various individuals. The game evolved rather quickly from a simple idea of possibly anti-gravitation snake to what it is now: a bouncy fun time of anti-gravity stuff and you dodge spikes while trying to collect coins. Overall, I’d say that not just the idea was the best I could think of at the time, but I had numerous friends who kept me going. As mentioned, it took me 1.5 days to figure out what I actually wanted to do. The original idea was terrible, and my friend xkaype who also entered kept giving me the best optimism I’ve ever heard. They didn’t give up on me, and neither did any of my other friends. To that, I am very thankful towards all of you guys!

The bad

Alright so this is the part where I will tell a story of a guy who entered this Jam and basically had no clue what they were doing. Seriously the original concept was alright, but due to numerous logical flaws in the code, the idea wasn’t going anywhere. You were supposed to be some kind of square shape hopping on platforms to reach either a sun or moon tile which would be the two ‘buttons’. They’d change the time of day and plants would grow and the player would have to traverse the level using this idea. Once I introduced a dual-layer mechanic for more interesting ways to lay out the puzzles or whatever one may call them, it got flawed. I lost interest in it due to this, and on top of it all, the game didn’t feel right to me. I had to start all over which was the best idea, but I hated having to do that.

Overall

I’ve looked into all the comments given to me so far which most notably is the complaint that spikes spawn right below you. Yeah that was a bad design choice. To be honest, I couldn’t think of another way to do it. Fear no more! I’ve actually fixed this for the Android port or any future ports. I’ll continue to look at the comments for anything that people may suggest for the future, but right now I think the way the post-jam version has been redone is fine. Anyhow, I hope everyone enjoyed Ludum Dare! Good night!

I have seem many entries still using Web Player only and not providing a Web GL version as well. Is there any particular reason people do this? I personally like the idea of having both there. Since I use Chrome and Web Player isn’t supported having a Web GL version is a necessity as I really can’t be bothered switching over to Firefox.

Thoughts?

You can now lose at Litterlings – yay!
I also added some stats to the Game Over Screen.

Play it here!

Ludum Dare 34 has ended and it’s time to present our game and think about what went right and what went wrong. This was our fourth Ludum Dare, but second with a bigger team. As always it was an amazing experience for us and we had a lot of fun and a little time to sleep. 😀 We are really happy with the amount of work done and how polished the game turned out to be. The themes for this edition weren’t bad and we came up with an idea pretty fast. We’ve created a game called SAAAM.

SAAAM

In our game you play as a Crewmember 341. He wakes up in his cryo-stasis pod on a vessel called Trieste. He’s a mechanic and his job is to maintain the vessel assisted by S.A.A.A.M. which stands for System Automation, Assistance, and Analysis Matrix. The player is faced with a series of choices whether to listen to S.A.A.A.M. or to disobey. The game features three different endings based on the choices you make. Will you be obedient? Will you do what S.A.A.A.M. wants you too?

What went right?

SAAAM – Final Room

SAAAM – The Vessel

• Art – The game turned out to be a visual feast. We’ve really tried to focus on consistency of art in the game and it turned out great for us.
• Script – Funny and creepy at the same time. It created a very unique, comedy-horror atmosphere. A lot of players were expecting a jump scare somewhere along the way. 😀
• Polish – We’ve finished the level design pretty soon and that gave us a lot of time to polish the game. Make sure every little thing makes sound, every light is tweaked properly, every corridor is interesting and unique etc.
• Voice Acting – Once again we’ve cooperated with Elijah and he did an awesome job as always.

What went wrong?

SAAAM – Starting Room

• Slow pacing – A lot of players mentioned the game’s slow pacing. It would be good, if we had more narration and choices.
• Lack of option to skip dialogues – If you want to discover all of the three endings, you’ll have to listen to S.A.A.A.M’s initial talk three times. And this is a lot. We had an option to skip dialogues in the dev menu, but it didn’t make to the full game because it wasn’t release ready.

What’s next for S.A.A.A.M.?

We’re now working on a Post Jam version. It will include all of the things that you, the players, suggested and much more! The Post Jam version will feature one additional ending, bug and glitch fixes, faster doors, skipping dialogues and many more. You can expect it to come out in the last week of voting. And what we do after that, will be based on the results.

In conclusion, we think that this game has a lot of potential. We strongly feel that this is an interesting concept and turned into a full game it would be a lot of fun. But for now, we have to focus on a Post Jam version of S.A.A.A.M.

Go play the game here

If you liked the game please leave feedback in the comments for us. We really appreciate this.

Fireline Games

Tags: fireline, fireline games, ld34, post-mortem, saaam

First time I ran it just worked, figured it would need some optimisation because ludum dare. Thanks to the default mapping of the ‘touch’ part of the apple tv remote to the dpad it worked out of the box, literally just switching targets and hitting build.

After that I took the time to try and figure out controls that made more sense, still want to try auto gyro steering as well but that isn’t easy to ‘just implement’.

If you haven’t played crooked town yet click the gif below to our game page!

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

Hello everyone,

It’s been a week already since we made BoltStorm, hectic snake-like dungeon shooter. If you haven’t tried it yet, we recommend you do:

PLAY HERE!

Bolt Storm indeed!

We did some major bug fixes right after the jam and now we’re working on gameplay and visual fixes for problems reported by the players. As for any other jam game, BoltStorm still needs a lot of work. If you have any feedback that you’d like to give, please do so as it will help us improve the game.

So How did we start with BoltStorm? To keep it short, our goal initially was to come up with a small concept and polish it well. Three main points of focus were: Simplicity, Juiciness, Progression. We managed to focus on first 2 points, but the progression part was lacking as the time ran out. We had more plans regarding progression but we ended up with something very simple, where player grows in size and as they level up, game becomes gradually more difficult by throwing a lot of enemies at them. Maybe we will expand on that later on.

Kickback, Screenshake, Damage feedback, Permanence.. just a bit of juiciness.

What needs to be noted is that we took examples from Vlambeer’s Art of Screenshake. If you are an indie dev and haven’t heard of it, go watch it HERE! (by Jan Willem Nijman) You will be surprised to learn that simple visual feedback in your game can make a huge difference.

There’s more to write about, but that’s it for now. If you’re interested in our projects or how we make games, find us on Facebook or Twitter and ask anything you like! Meanwhile we’ll be playing and rating your games(maybe Stream too?). Send us your games!

Cheers.

Tags: BoltStorm, dungeon, juice, Knights, screenshake, shooter, simplicity, snake, vlambeer

Hey there! We’ve made a trailer for our game! Check it out here:

Also we uploaded our game to itch.io, so now you can play it from there!

Play our game!

This is the post mortem of Box ‘N Bash, as told by Budaniel (me), the programmer an artist for AAGH Games. Box ‘N Bash is the first Ludum Dare we did not livestream, which was a little unusual feeling but it was a conscious decision because were trying something new this time.

We had been aiming to start on 3D game development using Unity and decided that making a working game in 72 hours was the perfect time to figure it out. Aside from some tinkering around, I didn’t have any experience in C# or 3D graphics, which is a bad start seeing as both of those fall under my jurisdiction. My concerns were alleviated when a working prototype came together early on, and we finished on time, despite some last-minute bug fixing.

The evolution of Box ‘N Bash

The good:

• Learning a new (to us) engine in 72 hours
• Finishing our game on time is always a good thing
• We got a little bit of our trademark humor into the game

The bad:

• We left a number of incidental elements on the cutting room floor, such as the doors opening when the Box Goblins came out, as well as already-recorded sound effects and voiceovers
• The balance might be off, but everybody testing it had different opinions on its difficulty level so we just had to wing it and hope for the best

The WTF:

• The voiceovers didn’t come out as clear as they probably should have

The Future:

• We plan on producing a WebGL version this for the AAGH Game Center, our game portal site.

Well that’s all for this post mortem. If you haven’t yet, give Box ‘N Bash a look.

We’ll see everyone again next LD!

Tags: 2.5d, post-mortem, unity

Hey!

We wanted to thank you for all the feedback on Blobitronica! We were so excited that it motivated us to continue to work on our project! We added a post-jam version of our game, so do not hesitate to give it a try to see the differences! Of course, the old version is still available.

Have fun!

Play here!

PS: more to come 😉

Hi, thought I’d post here the gameplay from my little game (PLAY HERE) for those who don’t use Twitter.

As always, any feedback is appreciated, you mean everything to me! 😉

I made a short gameplay video of my LD34 entry, ‘Hoarder’.

Vote for it here!

So far two developers have been awarded with the Stuffed Beetle trophy (feldaar and Drury).

Can you eat a hundred berries in Tubutten Beetle too?

Last weekend was a particularly busy one for me. I ran two kids programming clubs on the Saturday so I really couldn’t get any enthusiasm to start until Sunday.

Unusually, I hit on an idea for the theme quickly. I’ve been doing a lot of physics simulation work recently and I thought this would be a good chance to try modelling buoyancy in a game.

Link to my entry: Bloon

Most of my effort at the beginning went in to creating the physics model. If you look inside the project, you’ll see a lot of the variables required to get this working such as the mass of the helium, the balloon itself, and the displaced volume of air. Of course all this only served to produce the final upward force which gets bigger as the balloon inflates.

The results were unexpected (to me at least.) It seems that far from giving the balloon a gentle lift, inflating by only the tiniest amount caused it to shoot up like a rocket. To make it controllable at all, I had the reduce the inflation speed to about 1/10th of a millimetre radius per second.

This tiny change meant no real visible difference between a buoyant balloon and a sinking one. So to exaggerate the effect, I actually scale the visible representation of the difference in radius of the balloon by 10,000 times. Other than that it does represent relatively realistic physics. But I did make a number of simplifications:

• I assume a sphere rather than a balloon’s actual shape;
• the mass of helium doesn’t account for the raised pressure inside the balloon;
• there is no consideration of air resistance or air pressure related effects.

Time was getting on, so I moved on to modelling the bird animations. The individual frames of animation are all hand drawn using Scratch’s built in drawing tools. These tools are crude, but they do the job. As reference I found a sequence of photographs online showing the various frames of a crow in flight. I was pleased with the final animation.

Creating the crow animation frames

I later added the highlight to the beak to help with collision. (The balloon only collides with the beak, you don’t have to avoid them entirely.)

I was particularly pleased with the generation of the sound effects. My first thought was to get hold of some balloons and record some samples. It turned out to be difficult finding anywhere selling packs of balloons on a Sunday afternoon. But although I did eventually find and buy a packet, when it came to making the sound effects, I decided to give JFXR a try to see if I could synthesize the sounds I wanted. It turned out I could. More or less. But then… disaster! I had been working on a MacBook in Safari and there is a long term problem exporting audio. I soaked up several hours trying desperately to find a work around. In the end, I downloaded Firefox, remade the sounds, and then exported them from there.

By then, time was running short. I quickly put together a small audio loop for stage introduction in Otomata and rushed to get everything together before the deadline.

In summary, I wish I’d spent more time on creating and tweaking assets and less time dealing with technical issues and balloon shopping, but such is life in game development. I am pleased with the results.

Hi!

I’ve just made 2 videos of my game – walkthrough and timelapse. Go check them out, I found the timelapse pretty cool! And if you are interested in the Space Pilot game, go play it & rate it!

I’m here! 

Check out the new and improved post-Ludum Spirit-uality!

I wanted to make the game somewhat more polished as the first submission was very raw. The sounds didn’t get replaced like I wanted. Hopefully I’ll have a better idea on how to get more video-game-sounding effects for next time. It’s still lacking in gameplay, but I’m proud of how it fits the themes of Growing and Two Button Controls.

PATCH NOTES

Bug Fixes:

• Controls can no longer be set to the same key
• Spirit now regrows normally after reducing to smallest size

Gameplay:

• Revamped the final Boss. Will no shoot you until you or it are dead
• DOWN: hold to prep attack, release to launch bolt
• UP: spam to raise shields to block the boss’ projectiles
• Lengthened the world by ten times for those that need it
• Pressing ‘esc’ now exits the game
• Game over when the spirit is hit when it’s already the smallest size
• Six more good deed encounters
• Tutorial now displays what happens in-game when the user presses UP and DOWN

Graphics

• Jerry fist pumps on six successes in a row
• Jerry will have a fit if he misses a good deed when he’s on a streak
• Sky: changed the texture, and now fades in and out to go from night to day more clearly
• Added screenshake
• Spirit hovers slightly in place
• Replaced default window logo
• Many textures were retouched

So it’s almost been a week since I finished All Ways Down, and seeing as everyone else is doing one :-), I figured I’d do a bit of a post mortem of the game/experience, looking at what went right and what went wrong. Like many who entered, this was my first Ludum Dare, and whilst at times it was stressful( especially the last two hours), in the end it was an amazing 3 days and I had a lot of fun taking part. Overall, I’m very happy with how the game turned out, though there are plenty of things that I think could be improved (more on that at the end). The jam also meant I got to learn a bit about Unity webGL exporter, which up to now I had not really been following.

What went right:

• The mechanic: The basic concept started quite simple, ‘a rolling ball that has to be a certain mass to finish a level, it does this by consuming objects and growing. Player can spin the world?’. From this I sketched out what I thought a level would look like with a simple storyboard for play and put some ideas for level hazards underneath. Thankfully I was able to implement this mechanic and it worked.

• Thankfully most of the core development went quite smoothly(unless you count Unity crashing twice), with no major issues or bugs. 

• Sound: This is an area I generally find the hardest, but I’m quite happy with the end result, and have got some positive feedback on it.

•   Unity webGL, a day before the jam I decided to update unity. In hindsight this could have ended up going very wrong but, in the end it meant I learnt more about unity’s WebGL exporter, deciding from the start that I would use WebGL as my target platform.

What went wrong:

• Whilst not wrong per se, based on feedback the ball could be a bit heavier at the start of levels, so that it moves around the level a bit quicker.

• Deciding to make 5 more levels 4 hours before the end of the jam, resulting in no playtesting of these levels.

• The size of the web player. I would have liked the actual game screen to be the max size allowed on this site, but unfortunately as this was the first time I had used the WebGL exporter I didn’t realise that the export size set in Unity doesn’t include the custom Unity bottom bar, thus cutting off bits of the game screen when its embed size is set at the same size as export. Meanwhile exporting without the Unity bar means you need to provided the functionality that makes it go fullscreen. I really wish I had known all this before the jam, and not learnt it in the last two hours when I was trying to submit 😀

Whats next:

I think I’ll be developing this game further post comp. I’d like to make more levels, add in a couple of hazards and puzzle that didn’t make it due to time, along with polishing the graphics and adding more effects, maybe even a camera shake . I’d also quite like to port it to mobile as I think its control mechanism is very well suited for the platform.

Overall I’m very happy with end result, and looking forward to working on it a bit more and making it even better 😀

You can check out All Ways Down jam page here.

Here I am!

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

I don’t think I’m the first person asking this here or somewhere else related. Is there an online place, public, with all the LD games made so far, since the first event? I’m not necessarly asking for a game repository (although that would be nice), just a online database with the information of all games.

Thanks

We’ve created a post-jam version of our game to fix some graphical inconsistencies and added some things people have been asking for. This is our first post-jam version, which we created mostly because we enjoy playing the game ourselves. Thanks to everyone who played the game and given us feedback for this game and all past and future games.

Play it here

We’ve been talking about updating the AI, and maybe some other things as well. We’ll have to see. Feel free to post a comment with suggestions and other thoughts!

Looking for a challenge? Check out my game: Arc. My High Score is 42. I doubt you can beat me. Prove me wrong! c:

One thing that’s been problematic with my entry is players not perceiving subtle speed differences to discover how their inputs and actions actually affected their speed.

I think this little bar below the score will help a lot with that and make it much easier to learn the game without further instructions.

Further small tweaks and details in that gif:

• berries actually float up if you are going too slow or falling down (this helps a bit with understanding what’s going on, the berries are blown up by wind and you are chasing them)
• the first berry I’m catching there will always appear in the same place at the same time, unless you boost past the 250-500 range faster than it can spawn (this will make sure every play through can start out more easy and equal instead of waiting for a random drop)
• hitting a spiked berry beyond ignition will kick it away (this will help recognize the difference between touching a berry with and without fire protection)
• the beetle now lights up fully in the current speed colour (not just dark red tint, but also bright red/yellow/white)
• berries don’t overlap any more, but they may still hug each other a bit

This marks my first day of forking the LD version and continuing work (besides some FPS hassle I didn’t touch the game after jam) and I already got a huge list of things done (everything above as well as a lot of bug fixes, mechanical tweaks and designing future features).

Post-jam version of GROW is slowly taking a better shape.

Good job on the game jam everyone!

My game was Pyromaniac 3 — 2. Please check it out and leave me some feedback here.

This was my first Ludum Dare competition aside from the most recent Mini LD, but for me the Mini LD was more of a trial.

I started off on Friday night brainstorming and eventually, with the help of my friend Paul, came up with the idea of a growing fire. From there I kind of just went with the idea and programmed in whatever I thought of.

FRIDAY:

1. Set up basic side scrolling player controller and camera that followed the player.
2. Made a particle effect for fire.
3. Made a particle effect for the player.
4. Made a test level that consisted of a ground, a player, and nothing else.

SATURDAY:

1. Drew placeholder art for trees and the ground.
2. Created a skybox that looks like the night sky (the fire looks cooler against a dark backdrop).
3. Gave the trees the ability to be flammable.
4. Ironed out bugs regarding the distance from which things are set on fire.
5. Drew placeholder firefighter art.
6. Implemented firefighters with very basic AI (run towards the player).
7. Made a particle effect for the water stream of the firefighter and the water stream of the firetruck.
8. Implemented the water stream for the firefighter and gave both the player and firefighter health variables.
9. Made and implemented a fireball particle effect for the player to shoot.
10. Implemented the taking of damage when hit with water.
11. Implemented the firefighters’ taking of damage when in contact with fire or fireballs.

SUNDAY:

1. Drew placeholder art for the firetrucks, houses, and bushes.
2. Implemented firetrucks (but not the firetruck water particle system).
3. Implemented a win condition and death condition.
4. Implemented UIs for those conditions.
5. Made a main menu, about screen, and level select.
6. Realized I didn’t have any levels for the level select, so I made 4 basic levels.
7. Set up a system for unlocking levels based on game completion.
8. Decided not to replace the placeholder art because it was like 5:00 o’clock.
9. Fixed a bug where the UIs weren’t responding to clicks.
10. Added an Easter egg where there is a 1/100 chance that when a firefighter spawns it spawns as Bono and has as much health as a firetruck.
11. Play-tested for about 30 minutes and discovered a game-breaking jumping bug.
12. Attempted three different solutions to the bug before fixing it 30 minutes before submitting.
13. Set up an itch.io account and uploaded a web version and download version of my game.
14. My friend came up with the slogan “15 years after the critically acclaimed fire-fighter fighting simulator, Pyromaniac 3, there is finally a sequel: Pyromaniac 3 — 2.”
15. Uploaded the links to the game on the Ludum Dare website (at 8:30 because I didn’t realize there was a submission hour).
16. Figured out how to upload the Unity project and uploaded that as my source.
17. Polished the game page.
18. Did my homework (cause that wasn’t my priority, obviously).

Thanks to everyone who has played and given me feedback on my game, I appreciate it greatly!

Tags: _benhumphries, compo, game, ld34, Ludumdare, ludumdare34, pyromaniac3--2, unity

I finally got around making a video for No One Can Hear You Honk In Space, my sidescrolling space shooter for the LD34 Compo.

click image to watch the video

So if you’re interested in seeing a playthrough but haven’t got the nerve to play it yourself, go ahead! There are some minor problem with the game that I never encountered until recording the video though – most notably the small jumps in the character animation, not sure what’s going on there, maybe a framerate related issue.

Finally, if you like to you can play and/or rate the game here. I try to play the games of everyone who’s leaving feedback, so there’s that.

-Shellfish Games

Our best video producer has proven worthy of his craftsmanship and created this wonderful video:

I think it is really good. What do you think? Write it in the comments and play our game: Legendary Legionnaire Massacre 2

– Jonas

After a few days of playing and rating games I’m ready to let this LD go. I usually dislike when nobodies (i.e. me) write super boring “I spent more time writing this than working on my compo game” post-mortems, so instead have poorly optimized .gifs showing cryptic gameplay and horrible bugs I can’t figure out, and a list of the tools I ended up using, for archival purposes:

(Link in case the gifs piqued your curiosity http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=61928)

Tools used for My Dino:
♦ LÖVE
♦ Atom with the love-ide package (Anyone using LÖVE should give it a try, it’s pretty good)
♦ Paint.net
♦ Renoise

Good luck to everyone, and Merry Christmas!

So one thing I always try and do is come up with some original music for my Ludum Dare entries and I dare say some of them work better than others.

Original Music always brings out the best in even the worst games. Personally, I use Caustic for Android partly because I’m used to it now, and partly because if I do need to step away from development I can go somewhere completely different and still work on something to do with the game.

One of the earliest pieces of code I wrote in Ludum Dare was a Background Music script for Unity that played a track from the start then looped it from a fixed timecode when it reached the end. ie, a track might have a 4 second intro before getting into the main song, so at the end it’d loop back to the 4 second mark and continue.

It’s not perfect, and there is probably a much better way of doing things, but it does what I need it do to (and one of the cool features is it lets you control its volume through PlayerPrefs so you can even tie it into an options screen)

The music I’ve made, over the last 4 Ludum Dares, well I’ve compiled them all (for better or worse) on soundcloud.

The first LD game I made music for was as much an experiment in music as it was in making a game. I am Sigma (Theme: Entire game on one Screen) played more or less of the music the deeper into the game you went, eventually playing every layer on the very last screen.

For my MiniLD game Behind the Screens (whose theme was ‘Pong’) I made two tracks with similar rhythms but different instruments to produce two different tones. One quite laid back and subtle, the other 8-bit style chiptune.

The less said about the development of Caber Toss (An Unconventional Weapon) the better, but it involved suffering, sleep deprived, through a birthday party with no less than 14 under 8’s. The music for this one was made in an hour, shortly before submitting the game.

Kaiju A-go-go (You are the Monster), while not having an original name (I had no idea it had a namesake when I named my entry) had 4 short pieces of original music. The intro, the level loop, the boss theme and the outro music. Each of which is quite short, but I think work quite well.

My current entry, Eva Ness goes to Hell, while again mechanically frustrating (I did decide to make a 2-button platformer) contains 2 pieces of original music designed to be slightly unnerving, invoking a hellish landscape and with the boss theme, add in a little mix of church organs.

Hi everyone, today we are making our first post to present to you our game!

We are proud to publish this trailer of “Switchies” !

We have to warn you this may be a difficult and frustrating game so please preserve your computer from your own wrath,

and check out our game here (don’t forget to give us some feedbacks!)

For more addons we update new versions of the game on our website: switchies.xyz

I would like to add that we all are students, it’s our first year and more our first game! (that explains our poor english level as you can see)

Good luck to everyone, and Merry Christmas!!

There’s a pair of Let’s Plays playing an early build of hack.source.net by AngiePlaysGames and Garedactyl, enjoying the 2-player hacking FPS. Thanks to both of these Let’s Players for playing our game!

If you haven’t tried it out yet, it’s available in the link below:
http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=20557

AngiePlaysGames:

Garedactyl:

I just updated the server part of Birds of Borg – it now shows more prominently, whether there is a chance of having a multiplayer game with a real opponent. I hope more players will have the chance of trying the internet multiplayer variant, because it’s way more fascinating to play against human enemies!
The game itself didn’t change at all, so I consider this to be within the compo rules.

Thanks for voting!

Tags: action, html5, multiplayer online, nodejs, phaser, Singleplayer, web

Title: Grow Big and Go Home

Description: Play as a worm trying to return home while avoiding crows and picking up DNA sequences that allow you to evolve and grow body parts!

Growing Theme: As you progress through the game, you obtain DNA sequences that allows you to grow new ligaments that grant new abilities. The first DNA sequence gives the player tentacles and the player learns to duck to avoid enemies. The second DNA sequence gives the player legs to jump over obstacles. The last sequence gives the player arms to climb up trees. The player grows from a worm to a bipedal creature.

Two Button Controls Theme: To comply with this theme and keep the game as a platformer, I had to restrict the player to only two actions:

1. Only being able to walk right with the right key.
2. Only being able to perform one action with the spacebar.

Things that Went Well:

• Conforming to both themes – I was really happy I got both themes in and didn’t just stick to one. Having two themes was challenging, but rewarding.
• Pixel graphics – I’ve never been good with pixel art, but being restricted to creating only 8×8 sprites with just the PicoEDITOR on my iPhone actually made creating pixel graphics much easier. Although my flexibility in animating these sprites was very limited, it gave the game a nice retro look which is what I was going for.
• Music selection – A lot of people who commented on my game loved the music since it went so well with the graphics. I got the music from OpenGameArt with a public domain license. Ironically, the music was used in a Ludum Dare 33 entry. You can listen to it HERE

Things that Did Not Go Well:

• Text/Fonts – This was my first game and I am still new to Unity. I had trouble finding a quick and easy tutorial on placing and triggering text that would appear in the game. Instead, I had to resort to making all the text into sprites/prefabs and using that. This is why the text looks blurry, out of place, and distorted compared to the rest of the assets.
• Sound effects – Although the explosion sound effect when you get hit by an enemy plays fine, the pickup sound effect after getting a DNA sequence is really distorted compared to the original sound clip being used. Still trying to figure out why that happens…
• Lack of save state/lives feature for the player – A lot of people think my game is too difficult and should have save states/lives. Besides the fact I haven’t learned how to implement that feature in my game yet, I didn’t really think this game needed either of them. The game is actually very short. In the walkthrough video I created below, you can see me beat the game in 1 minute and 10 seconds! I thought this was very doable after a few tries, but then again, when you’re coding a game for two days straight and constantly testing and playing the game yourself, you lose track of how a new player will adapt to the controls. Here, I learned that I should have other people test my game before publishing to see how quickly a new player gets used to the controls.

Overall, I’m really glad I entered Ludum Dare 34! I learned a lot in the process and haven’t done a coding jam session like that since my college days, so it felt great!

Thanks for reading and playing! Play and vote for my game if you haven’t already!

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

Cleaning a computer is easy. A button click here, wait a few hours, button click there, wait a few more…. BORING!!

Take cleaning to the next level. No more mbam, no more avast. YOU are the anti-virus. With the new VRX hardware, you can put yourself in the game and fight those nasty viruses in this endless dungeon crawler. But be warned – you are foreign to the computer too, so be careful where you shoot as you might hurt yourself. Trust me, it hurts A LOT.

Still in dev – made this for a game-jam held between my co-workers. Was quite fun! This is my first official game using GameMaker Studio so I hope you like it.

http://ludumdare.com/compo/minild-60/?action=preview&uid=54496

The Darkness is now available here

We have put in a countless number of hours working towards releasing a heavily polished, completely balanced version of our Ludum Dare 34 entry. It includes a full video tutorial, a complete rebalance of the game mechanics, fancy new images, new effects, and an extreme degree of performance enhancements.  If you enjoyed our entry this season, consider picking it up for the incredibly hefty sum of five U.S. dollars!

Hi. I’m playing Ludum Dare games right now on Twitch. Feel free to join and I will try to give you some feedback on your game.

I’ve been tracking the daily progress of voting for this Ludum Dare to help answer some questions about why the judging lasts for three weeks.

In today’s snapshot,  64.5% of games has reached LD33’s milestone of 17 ratings (it may be higher or lower this time, more is better obviously!) Headline: There’s been over 75 thousand votes/ratings cast so far!

As expected, the rating happening right now is only a tiny fraction of the peak right at the beginning. Here’s two graphs! GRAPHS!

One shows the number of games being rated each day, and the other shows how many games had reached 17 ratings on each day.

GRAPHS = SCIENCE

I’m finding this pretty fascinating and curious about which way the trends go. Far too early to draw any conclusions about what % of games will eventually get a rating, but here’s one thing that the data shows to be an absolute fact:

Every dev that’s rated 25 games has enough ratings on their own game! The system works!

After playing 50 great games, I really wanted to share with everyone a few that I found that really stood out and interested me in some way.

Cultivate – Compo

Story-based games in these short game-jams always impress me so much, it must be so difficult to find the time to write in between brainstorming ideas, implementing code, designing assets etc. So when someone nails a story-based game as well as Cultivate, I am very impressed. The game makes great use out of both themes, and the story is genuinely engaging. Definitely worth multiple playthroughs.

Vines of Darkness – Jam

This kind of game is the reason there is a mood category for judging. The paranoid atmosphere this game creates was well done, it really felt like I was slowly losing an impossible battle against the vines as they came creeping in.

Punch Beat – Jam

This game is really simple and arcadey, and makes great use out of the two buttons. The graphics and audio are super polished, and the game (once finished) could easily find a place in the mobile market. While there is room for improvement in the mechanics, the potential of this game is clear as even in it’s current state it really captures the simple pleasure of punching robots in the face.

Two Buttons – Compo

This game is really similar to an existing web game called multitask, and is similarly frustrating. However, it manages to somehow seem fair, and is really addictive. It’s graphical style and gameplay are really bare bones, but it has that something about it that makes you want to beat your high score every time you play.

Shameless Plug

Homeworld – Compo

This is my game, a super simple arcadey shooter defense thing. I would really appreciate it if you guys could check it out and give me feedback. I am really happy with what I was able to do in 48 hours, and while there are some valid criticisms, most people seem to be enjoying it

Hello everyone. It’s not top, but just a small list with several strange entries – which very different, but, in some ways, exude murky atmosphere of vagueness (besides, it’s just good games). To add a little more weirdness in this post, I changed the colors of the screenshots on black-and-white.
Without another word – play and decide yourselves Э_Э

You and your parasite
~true psychedelic delicacy with handmade animations~

Melissa – A Game of Choice
~bloody, yet stunning… we always have a choice~

yaschiki
~shoot mockingly, wet pants~

They Call It Lucy
~experiment from outer space~

La forêt
~categorical gamescape~

————————————————————–
If you have found something like that among the thousands of entries – please, suggest in the comments!

”Garbage Can you escape?” is the game I entered together with Daniel, a friend of mine this Ludum Dare. It’s about a nefarious garbage-stealing villain that tries to escape from prison. Check it out here (please do 😉 ).

What went wrong

• Graphics could’ve been more polished: we’re both not spriters, but we tried our best. If we would’ve had some more time, I would at least have redone the prisoner sprite
• We had no time for power ups

What went right

• We didn’t run out of coffee
• The teamwork went well. I was afraid that Daniel would get left behind because he has less experience programming, but that didn’t happen, and collaboration went smoothly
• Music went at least sorta well. That is, I was completely new to tracker software (which I’m gonna keep using from now on, loving it), so I had to figure out some things still during the Dare.

To boast my ego a bit, here’s the theme for the main menu:

Okay, that’s all! Please give Garbage Can you escape? a try!

So, I participated in the recent Ludum Dare, took 3 days to work on the Jam game, so of course the next logical step would be to start playing other games, maybe further tinkering with own entry, that sort of thing?
Well, yes, that would be the next logical step. But Christmas-preparation-madness had other plans. Ironic, considering how that holiday time is supposed to be about rest, but not entirely unexpected. ^^”

Nonetheless, I’ve managed to shell out a few hours to spend on further development, even if I’ve still got a long way to go. Behold, a prettily formatted and scrolled text!

If you’d like to play around with the current version, it can be found here (the recent changes can be found under “Post-Jam” category, of course). I won’t blame you if you won’t; it’s still very unfinished.

Now then, today or at latest tomorrow I should finally start gathering some coolness. I’d love to do that earlier, but it’s so hard to find the time recently… ^^”

Intro
Under most circumstances, I’m the kind of guy who moves on to the next project once the first is completed. But thanks to the overwhelming support and feedback from the LD community, I’ve decided to try and polish this game and make it a little more enjoyable! And thus, I present to you… Garden Grow 1.1! The changelog is available on the entry page, but I’ll take this time to explain them a little more in depth.

Ooooh, pretty!

Changelog
– Art
First major thing that was addressed was the art! I’ve seen many comments on how the graphics feel disjointed, since the background is far more detailed and higher res than the characters. After doing a bit of research on how to make fluffy pixel clouds and do pixel dithering, I finally managed to unify the aesthetics of the game! This was what took up the most of my time, seeing as I had to redo most of the art from scratch.

Side by side comparison

– Saving
The player can now save progress! Every flower you earn is kept in your browser’s cache, so you can return to collecting flowers later and actually grow the garden! What’s more, a few different things are being saved as well, namely Birds and Magic. Birds records the number of birds you jumped on. Magic records the combined number of boxes you collected and the number of times the player has jumped on a thundercloud. What’s the point of recording these information down, you ask? We’ll get to that later.

– Garden
Flowers now bloom according to your score! Small flowers are worth one point, medium are worth 10, and large are worth 100. Simple! Right now there are no 1000-point flowers, though, so the game won’t reflect your score properly in the garden if you manage to exceed 1000 flowers. Right now, this feature is a tad buggy, with the larger flowers spawning in front of the smaller ones. This will get rectified in the next version.

– Balancing
Birds now give 3 flowers instead of 5. Thunderclouds give -7 flowers instead of -3. So all in all, it’s harder to gather flowers now.

Moving Forward
Right now, the game is being set up for at least one more iteration. The Magic variable is a clue already. So, what can you expect in the next build?

– Garden support. Flowers worth 1000, and the option to buy a NEW garden and start from scratch when you reach 10,000 flowers. Old gardens will turn into floating islands and float in the background.
– NPCs. More NPCs are going to make an appearance, and they’ll do a bit of talking as well. But the main reason they’re there is mainly for….
– Economy. Trade flowers, birds and magic with NPCs to grow your garden more effectively!
– Mobile version. MAYBE. I’ve never done anything like this before, but it’s worth a shot! The game was made with mobile in mind, after all…
– New soundtrack. Not very likely, but I might give composing another go! We’ll see how it goes.
– Microtransactions! Nah, just messing with ya.

Before I sign off, I’d like to thank everybody that played, commented and rated on my game. Your support is what drove me to make these improvements, and hopefully you’ll come back to play a second time! And if you haven’t played my game yet, well, give it a go! If you plan on rating the game, though, be sure to play the original one.

Hi!
I did some balancing and graphics to my game, so here is the post-compo version.
Play it here!

Thanks for playing!

Today we release our very first Seasonal update to Pigeon Jump! Our free to play Arcade Action platformer.

Included in the update, 5 new skins, 1 new bread type, 3 new pigeons and a festive all around theme in the spirit of the holidays!

Pigeon Jump on Google Play

Hey! Since I’ve got so much awesome feedback from you guys, I thought to write a little summary of the lighting I implemented in Neon City Getaway. I’ll go over the overarching stuff here, and if you’re interested on the actual implementation, take a look at the BitBucket repo (more specifically, the GameStage.java file).

Graphics

The graphics in this game are as simple as possible, and it’s achieved with the combination of 2D and 3D graphics. The 2D graphics are quite roughly drawn sprites and there’s just six sprites overall – the car, four smoke particles and a skid mark sprite. The key here is randomization – for example, the smoke is achieved by spawning smoke particles with random size, transparency and rotation. Nothing too fancy!

The 3D graphics are rather “lame” as well. The textures are 48 pixels squared, and are pretty much just squares drawn in rows. The 3D models were done in Blender and the rather crude textures were mapped onto the cubes and planes, all sized the same.

Blender in action

The tricky part was to combine the 2D sprites and the 3D blocks. I already had a crude prototype working at this point where I was cruising around with my 2D car and didn’t want to touch that part of the code, so I had to figure out a way to bend the 3D stuff there as well. I ended up drawing the 2D stuff in its own pass and the 3D stuff in its own. The result “works”, but is tremendously limited: the 2D stuff is really drawn on top of the 3D stuff, making it look really off at times, especially if the camera was to be zoomed or rotated around. For this game, though, the limitation did not impose any problems.

Lighting

To start off with the lighting, we have the unlit scene (the leftmost picture). This is a combination of two render passes: the first one renders the 3D scene (the road and the buildings) to a framebuffer, which is then rendered to a full screen quad. Next, the sprites (the car, smoke, skid marks) are rendered on top of the full screen quad. Obviously, this isn’t looking that nice, so onwards we go!

From left to right: Lighting off / Vertex lighting / Box2DLights / Combined lighting

The second picture shows the 3D scene rendered with vertex lighting. There’s a single point light placed on top of the car, so it lits the area around the car. There are also two smaller points lights placed right at the bottom edge, with blue and red tints, to simulate a cop car. These are always at the bottom edge of the screen so you don’t actually ever see the cop car. This is almost the final result, but we are still missing shadows. Rendering shadow maps for a scene like this would be overkill since there really is just a single plane which receives shadows.

So, instead of full 3D lighting, I used Box2DLights. The third picture shows the scene rendered without the vertex lighting but with the Box2DLights enabled. As you can see, the buildings become dark as they’re “in the shadow”, as does the road that’s behind the building.

The rightmost picture depicts the final rendering result. This is the combination of the vertex-lit 3D scene with 2D sprites rendered on top of it, and the Box2DLights light map rendered on top of all that.

Cheats!

The lighting is done by cheating all the way, just like you would imagine. For instance, the skidmarks and smokes are occasionally drawn on top of the buildings since there’s no depth testing against the 3D scene when the sprites are drawn. However, it just fits in this kind of game where the player focuses on the next corner and the top edge of the screen instead of the particles. The shadows overlap buildings and so on… but it all works for this specific game. For example, the car could theoretically be drawn on top of the buildings, but that will never happen because the camera is placed right on top of the car. No building can make its roof reach “over” the car.

Is this the best way to do things?

Absolutely not. This is something I managed to manifest in 20 hours of jamming and compoing. It’s cheaty, it’s only suited for this game, and it all could be done in a better, more efficient way.

Dear LD-friends,

We made a little video – please check it out!

Or even better, play and rate our game; we will do the same with your game 😉

Cheers!

Last week I decided to participate in my first game jam, Ludum Dare 34! I had no prior experience in doing game jams before LD34. To my surprise, I actually published a game in 72 hours and I didn’t even feel disgusted by the result! The resulting game is called EXPURGET, a fast paced arena shooter where you must survive an onslaught of vicious alien lifeforms. I like the game, so I slapped the word “demo” under the name, because perhaps I’ll expand the concept in the future. EXPURGET was published as a Ludum Dare entry just four hours before the Jam Entry deadlines. The entry feedback has been tremendously helpful and I appreciate all the comments because they will aid in my improvement as a game developer. The weekend was an interesting experience, so it seemed like a good idea for me to do one of these “Postmortems” many developers like to do after game jams.

First, the tools I used for EXPURGET

• Godot v2.0 as my game engine
• LMMS as my audio sequencer, along with ZynAddSubFX as my primary soft synth
• Photoshop CS6 for art/graphics

Why I decided to do my first game jam

The simple reason I wanted to give LD34 a shot was to exercise my game design skills. I came to realize I would exhaustively work on game concepts for months or years and ended up with a game that I did not think was fun. I’m confident in my knowledge of programming, so it was clear to me that I was lacking in my ability in game design. Creating a game in 72 hours seemed like the perfect way to prevent me from working on unnecessary details for months and design a fun game quickly.

I would argue that you can’t exactly “teach” game design to someone. Game design is basically how a game “feels”, the mechanics, and how well the visuals, programming, and music all mix to create one cohesive experience. Everyone has their own opinion on how they think their game should feel and what the player should be thinking when they’re playing their game. That opinion is generally formed by the designer’s experience with other games they have played in the past. (Whether or not a game designer should have immense experience with countless video games is a bit out of scope for this postmortem).

Chances are, if you grabbed two different people and told both of them to design two different games with a given set of rules and mechanics, the two completed games will feel very different to each other. Ludum Dare is in fact a great example of this. We’re given a theme to derive a game from. Two themes won the vote in Ludum Dare, one of them was “growing”. A lot of developers immediately had the concept of planets and flowers growing (just look at the entries!). Although many of them had the idea of plants growing, all the games feel radically different from each other. Therefore, game design is very much a personal expression.

What I think went well in EXPURGET

• The art resulted in something much better than I imagined. I do not try to be an artist and I consider it one of my weakest skills in game development, so I try to focus on my strengths like programming and music. This year I seem to have adopted a style of 2D art that works for some fictional settings. It is basically vector art, but I paint over it with some very rough brushstrokes. A key aspect to the art is cutting the edges off of the simplistic shapes to give it an “imperfect” and rough look. Once I saw the art for EXPURGET becoming more attractive, It really motivated me to continue working. Feedback on the art was more positive than I imagined. Ultimately, I think the art contributed tremendously to the aesthetics of the game.
• The dialogue in the intro of the game is something I really enjoyed. I didn’t have enough time to draw characters for the two people conversation in the intro, so I used distorted circles and the color of the text to indicate which character was talking. It was an efficient solution I think. To my pleasure, a comment on the game’s entry noted the meta/self referencing in the dialogue.
• Incorporating both themes of the game jam is something I’m pleased with. Out of all the themes that could have won, “Two button controls” was probably my least favorite. I was tired of the lack of control schemes on mobile games, so I was displeased to hear that it was one of the themes that won the vote. After an hour of brainstorming at the start of the game jam, I made it work out. The other theme that won the vote was “Growing”, which I had absolutely no ideas for until the final 24 hours. The idea was that the monsters would grow visually and in strength the longer the player survives the onslaught.

What I would have improved in EXPURGET if I had more time

• Monster getting stuck on top of the player’s head is the main criticism I get on the game and I suppose it’s a fair one. The final hours of development was spent on getting enemy A.I. to at least work, making it work well was an after thought. The monster in question was actually supposed to shoot projectiles at the player, and not jump or fly in the air. I scrapped that idea, because I didn’t have enough time to program enemy projectiles and test them out. Basically, I knew about this issue before I submitted the game so my quick fix was to make the collision box for the player’s bullets taller, so if the monster got stuck on their heads they could at least shoot it. This turned out to be a solid fix for me, but I think some players didn’t catch that they were able to do this.
• The speed of the player’s movement and rate of fire is too slow. In the final hours of development, I had to grind just to get the enemy A.I. to behave properly. The result was that the enemies were very fast, yet the player would fire bullets too slowly and did too little damage in time. I would have increased the fire rate if I had more time to test.
• Challenging the player to reach difficulty 50 without testing if it’s possible wasn’t a good idea. With my best effort, I can only get to difficulty 40.

Conclusion

I couldn’t be more pleased with my first game jam. The most important thing I’ve learned was that the core of your game should be easy to conjure and fun from the start. If you have to go through months of heartache and suffering to find the fun in your game, take a step back and reconsider what you’re working on (unless you have reasons why you’re not trying to make your game “fun”). The essence of your game should be there from the start, thus any other ideas will then derive from it. I’m looking forward to participating in future Ludum Dares and other game jams, and perhaps collaborating with others.

Thanks for reading. You can follow me on Twitter (@xodene) for updates regarding EXPURGET and others game. For other thoughts on game development, check out my developer blog.

It took a bit of time, but Linux and OSX builds of Eda are now available on itch.io!

Thanks for all the feedback from those who already tried it out, I’ll definitely continue to work on it and apply the great advice received.

Tags: linux, osx

Greetings from Heart Lamp– This was our very first LD entry and we’re … mildly proud of it.

The Idea: Create a metroidvania-style platforming game where manipulating your size determines which of many branching paths will be open to you– A mindblowing journey into your circuit board.

The Process:

-Friday Night-

1 member of our development team recovers from a hang over while re-watching Venture Brothers, 1 member prepares to hog tie professional Santa Clauses (or whatever the hell they do at ‘Running of the Santas’), and 1 team member bowls a 156 (a personal best). However, texts about the theme are shared. We go with “Grow”.

-Saturday-

 Main Character Design and base code for a platformer are completed. Sprites for blocks and trees completed.

-Sunday-

Pools and pipes are tested and implemented. Some old music we did for other projects is shoved in there too.

-Monday-

Furious level building (because we have basically nothing playable) along with enemies, bullets, keys, obstacles, and doors.

The “Final Product”: A level. Like, one very difficult level… that we think is a lot of fun.

Here’s everything we mostly succeeded to cram in…

Purple goo makes you big, yellow goo shrinks you. The pipes were supposed to refill the pools but now they’re just decoration.

One falls, one breaks.

Get ’em.

They all do the same thing: make you big when they hit you. The difference is: one crawls, one flies, and one gives your the business with bullets. Or just freaks out. One or the other.

.

While we may not have accomplished all we set out to do, we had alot of fun. In it’s current form NanoBit is a game about staying small. Originally we wanted there to be some advantage to being big (stepping on enemes, breaking blocks when hitting them from below) but these were lofty aspirations. If you give it a play please stick with it. If you don’t want to stick with it (because the verdict so far has been that it is VERY hard) then check out our Post-Ludum Update for a version with checkpoints; It will be much more fun for cowards like you.

Thanks for all the feedback and constructive criticism and we hope to have you playing with us again in the future. If you are at all interested in seeing a bug-free full version of NanoBit released, let us know! We would love to develop something closer to the original idea and even add a two-player mode if enough people are interested.

Stardust

My schedule has finally cleared up a bit and with that comes time to work on improving my game. I know the major complaint I received was that people did not know where they were or where they were going because there was no reference points. I decided to add an arrow to indicate direction and some coordinates to track position. I also plan to give you an indicator of how big you are!

To other developers, how much do you improve before releasing the improved version or next revision? I have an entire list of things I want to improve and I imagine I’ll do it in phases but I’d like the opinion of some of the more seasoned developers.

Happy Holidays and Pleasant Gaming!

P.S. I plan to release update 1 later tonight.

Hello! I show you my first game ever, my first LD obviously.

This is just a survival game where you have to try to survive the most time possible, without limit of time and without limit of mocos to kill.

It’s really hard, I know, but this happens because I had no time to do all I wanted (ok.. ok.. I really want a hard game too 😉 )

I made a video gameplay to show you some tips:

Link to the game – Survive the Moco

My experience

As I said before, this is my first game, and I did it in the 72h of this jam. It was a very good experience.

My participation in Ludum Dare was presential, so the best part was when I saw the face of the people playing my game, some players were really frustrated with the difficulty of the game and other were really proud when they got the best time. Really funny.

Things that I wanted to implement and I had no time:

• PowerUps: Better weapons with limited ammo.
• Moco abilities: Each Moco could have one ability for each size.
• Procedural map: The map is random, it is going auto-generating where you move. (This was implemented but I had mouse problems in random places)
• Stamina: Your speed changes with rest or something (Maybe only for this version without powerUps)
• Stronger enemies: Stronger enemies appear from time to time.
• Scores: A high score ranking.

Thanks for playing!

Here’s how our time management looks like for the Squ Jam entry!

Here’s a quick list of lessons learnt:

• Art takes time – for the first time, I (Wan) planned to focus on art rather than code, and unexpectedly I ended quite happy with the results, given my average drawing skills. The hard part instead was that I’m not used to spend that much time squeezing out assets, and for a rushed coder like me it certainly was a good lesson in patience.
• Review your technical bottlenecks *before* the jam – Every other LD we end up making a platformer, and every. single. time. We spend ages on issues with collisions management and the integration of TilEd (our map editor). The main reason, in the end, is just that we’re not very experienced with physics engines, and it shows: a large part of our time & energy was spent on it, instead of happier things such as level design.
• Spend more time on level design – Of the total 5.5h logged as “Level design”, maybe 3h max was spent on the final levels. It’s still more than our previous entries, but we do seem to procrastinate that task… Too bad because that’s where you get to show that cool gameplay mechanic, and overall, for a platformer, good or bad level design make or break the fun of a game (emphasized for future me :P).
• With good hardware, audio is easy – It’s a more advanced lesson targeted at musicians, but I just discovered how important a good audio interface is. I bought one right before the jam, and not only I was finally able to record noise-free voices, but also the overall mixing and sound-picking for the music felt much easier. The game features no less than 6 – short – music pieces, yet I managed to wrap up satisfying tracks in less than 4 hours.

“How to make art as a s***ty artist”. The making of Squ’s assets probably deserves its own post :P

Overall we still made a great deal of progress in time management since our last entry together, learnt a lot of things and had a huge amount of fun as usual. Thanks for reading! Now go play and rate our game 😉

I managed to finish off a few well needed post-jam improvements to my game. Hopefully I’ll be able to keep up the pace and make some features that I knew I wouldn’t be able to do in the Jam.

Enjoy!

Grow Your Hoard! is now on Android, Linux, and OS-X thanks to simple Haxe porting! You can hit me up at @JohnDoughty6 on twitter if you have any problem running any of the builds!

Thanks to everyone whom has given us feedback already this LD. We’re glad you guys have enjoyed the game and we look forward to bringing a more realized version to you guys soon with all your feedback in the game!

Earn Your Title Now

While we’re writing full-length report about our team’s LD#34 experience you can roll some wheels in our jam entry Wheel Roller!

May the random be on your side!

The original subject of this post was  supposed to be “My Top7 LD34 games”, but I want to share a more important experience. After 4 crazy days filled with stress, domestic arguments, team tensions, heavy editing and a ungodly amount of unhealthy food…Fluffy Horde made to the LD.

My first reaction was to send the link to friends and other devs. Unfortunately it was pretty late of here in Brazil and only one person (game/dev) was online, “At least one person is online…Lucky!” I thought at first. I was deadly wrong.

Since I don’t want to drop names, let’s just call him Skinner. The chat conversation went like this.

—

Me: Dude, Just finished my first LD game! Want to play it?

Skinner: Sure! Why not.

Me: Did you make one?

Skinner: Nope.

Me: Cool, here is the link.

(Minutes after)

Skinner: Do you want the real talk or the friend talk?

Me: Just be honest with me.

Skinner: It’s messed-up.

Me: continue..

Skinner: I was not sure what to do at first and then After a while I figured-out how to play it, I found it boring as hell.

Me: Go on…

Skinner: The intro was more or less, the art is just ok and the game itself is shit.

Me: I think the intro is pretty good.

Skinner: hehhhh we can go with that….

Me: Let’s see what people think

Skinner: Yeah….

——

Then he went on being sarcastic saying this would be game of the year. After the conversation was over I was a bit depressed.

Calling a fellow dev game “shit”? How constructive is that? Don’t get me wrong, he was right in many things he pointed-out and we already made some tweaks based on his feedback, but he could do that without being a total asshole.

I come from the Ad industry and it’s very common to redo work here and there, but being a dick is different thing.

After the storm…

The following days were amazing! We got some awesome feedback from people all around the globe! Here are some of them:

Even a mobile company contacted in order to make a deal with us. After all of this positive vibe, we will turn it into a full game!!

Assholes are just like the bunnies in Fluffy Horde, they are everywhere and they can be very misleading, but you can always turn things around.

PS:

My TOP7 LDJAM34

Slash Quest

Parse the Sky

Double Kick Heroes

Conga Master

Orb Lords

Harvest

Riders on the Steep

Hey!

So this was our second Ludum Dare and I’ve decided I’d like to do a small post about how it went for us. Our team made Nuclear Arms 2: Garbage Day. It’s very loosely based off of our Ludum Dare 32 game Nuclear Arms

Our first game was a platformer and it was our first time using Unity, we all got familiar with it then so during this round everything went much smoother. For this round we created a top down endless runner, we decided to try both themes (Growing and 2 button controls). The growing theme was implemented by growing your ship when it gets hit by garbage, causing you to have a larger hitbox and make it more difficult to dodge obstacles. The 2 button controls came in just by moving left and right. We also had a 3rd/4th functionality of pressing both buttons to fire lasers and shake garbage off at the same time, but in retrospect that was a bad idea as most people found it difficult to control your ship and do these things at the same time. If we had another go at it we’d probably just add a separate button to do it, but we wanted to stick with the themes.

This time around we didn’t have our art guy, so we had to make due with what little artistic skill we had between us (As well as taking some assets made from our last game :p). In the end I think our game turned out fairly well visually. I even had a good run at making the run procedurally generated. The majority of the obstacles you see in the game are generated at random, but there a some set pieces that spawn every now and then which are a bit more handcrafted to make things more interesting. I’m glad I got to work on it as it’s something that interests me in game development. Had I more time, I would have most definitely improved the algorithm. At the moment it’s possible for powerups to spawn inside obstacles, which kind of defeats the point.

The last and final portion of our game comes in from our portraits and voice overs. We decided to record ridiculous phrases and one liners to throw at you while you play. We kind of made it just for fun, but the comments on the page suggest that people thought they were pretty funny :D.

Anyway, if you managed to get through this whole post I hope you get the chance to play our game Nuclear Arms 2: Garbage Day

Well, this was the last thing I was expecting, honestly…

In the space of about one week, I’ve made a game, polished it, added features to it, polished it again, made a trailer, setup a store page, and put it up for sale.

One week.

This is why Ludum Dare is amazing.

 GAME PAGE HERE

LUDUM DARE PAGE HERE

Introductions:

Hi everyone, I am Luc, I am an artist and game designer from the southern tip of Africa. This was my first time game jamming alone, my goal was to create a game for the compo, but alas, it was not ready in time. Below are the details of exactly what I feel went right in my first solo game jam, and what went wrong.

A brief Caveat to my game concept was that Eskort Mission was not on theme, I had a game idea before hand that I wanted to explore in the jam.

What Went Wrong:

AI: this represents the first time I was tackling AI, and its spotty at best. My games enemies path-finding is mostly dodgy, the solutions to the collisions, even more so. I need to explore the Gamemaker grid system in more depth to fully fix the problem, but for now enemies are a bit too effective at running at the player, therefore are too hard for uninitiated players, and are not fun. Furthermore their path-finding can often drag them through vehicles and building unopposed. My tired minds solution was to have objects slowly move enemies out of their collision boxes… which makes for some weird bugs and sticky movement.

Tutorials and Communication: From feedback I have realized that players feel a bit lost. The procedurally generated maps become labyrinthine and finding cats was difficult for most player. The cats AI also stops following the player at a certain distance. Interactions with the cats therefore feels sometimes arbitrary and at worst frustrating because finding them and making them follow the player is difficult. To  mitigate this I find I need to add communicative devices to let players now how my systems are working.

There was also feedback regarding finding the way back to the chopper. I tried to provide an arrow with an “E” to make it easy to find ones way back, but given how many players got lost, this is evidently not effective enough at communicating. I need to explore other options, perhaps a mini-map, or a arrows in the heads up display.

Players also remarked on how the games goals were not explained. The lack of an appropriately explication of the games goals detracts from the overall experience.

bugs: There are some occasional graphical and drawing issues which cause some strobing between tiles.

What Went Right:

learning to code: I set out with a few challenges to meet in this jam, the most predominant of  these was my resistances to coding (what I do is not so much coding as scripting and will be referred to as such from here on). While I have scripted before, in both Unity and Game maker I was an artists and used them mostly as tools for getting my art on display. Forcing myself to create a complete game play loop within the 72 hours really taught me a lot about successfully creating a game.

the first thing I learned is that it is important to get a game play loop in as fast as possible. Too often I find myself stressing over the feeling of the shooting, The random generation of tiles looking good, or the specific timing of the enemy firing rate, and leave the games loop to the last few minutes of the jam, making my games feel like galleries of activities rather than games. Focusing on finishing the game play loop timeously allowed me to better assess the problems with the game play at an earlier stage of the game jam. This left me time to fix things things (though there are still many bugs and issues, make no mistake :D).

Making Lists: Completing my scripting tasks timeously would’ve been impossible without setting out lists of what I wanted to complete and at what times I wanted to do things. This both gave me a feeling like I was approaching completion, as well as keeping me on track for completion and ensuring I didn’t get distracted.

Planning: I had a plan of what I wanted to do before the jam, while this meant I strayed from the theme, ultimately this helped me be determined in creating the kind of game I had envisioned. However I was also flexible with this plan, compromising on frivolous details and many of the features of my original concept (which was about guiding reckless soldiers who resemble lemmings away from danger and to the Evac helicoptor).

Art: I did all the art in the Sunday of the jam, I was rather chuffed with how quickly I managed to get it all out. Though the tile sets were not quite what I wanted, and the solution to auto tiling was not very robust, meaning the layout of tiles was hap-hazard rather than planned.

List of excuses:

Ignoring the theme: In the end I acknowledge that this will count against me, and In future I may find that sticking to the theme will provide a enjoyable and stimulating challenge.

Not sleeping enough: This seems silly, but going to bed late in the morning really affected my productivity. On good sleep I was able to fix problems quickly that in my tired mind I was unable to work around.

Travelling and sickness: A spot of Gastro and having to catch a flight on the last day of the compo ate into time I would’ve liked to spend fixing bugs.

Conclusion:

For the first time doing a jam by myself I was proud to have made my thing, broken as it is. While jamming alone is a great learning experience, I did miss the company and camaraderie that comes from a group game jam.

I really hope you guys enjoy my little game about saving cats.

regards Luc

Hey, everyone!

One thing I tried this Dare was to log information about how people were playing our game, Flutter, and where people were dropping off.  Now that we’ve had time to collect a good amount of data, I’ve written an article about it.  Check it out by clicking here.

Click! You know you love Graphs!

It’s all about that forest magic and a bit of finger dancing today. Just don’t get caught with your Mushroom Hat off!

Check out Dizzy Dazzle by Tselmek & Ted Wennerstrom

Play around with Enliven by Patacorow & lonebot crew

It’s not too late to submit your game or a game your pals have made. You can send it to Larry in this fancy form thingy -> over here.

Tags: Dizzy Dazzle, Enliven, Larry Chupacabra, Larry Does Ludum, ld34, Youtube Showcase

Still far from complete, but I liked where I reached, hope you like it too! o/

You can play it here http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=11311

This was probably the first Ludum Dare in which I was actually almost completely happy with the end product. What I amount that happiness to is the personal goals I set for myself. Instead of having my goal be about making a complete game at the end, I made it about having a game full of music and art that I was happy with. Another goal I had was to try to make another story-based game. I wanted a cohesive experience that used art, and music to help the story telling. My last goal was to not get bogged down by programming. I didn’t want something difficult, I wanted something simple that I could whip out. I knew that programming was the one aspect of LD that (at least in recent times) has bogged me down and de-motivated me to the point where I was not happy with my product. Don’t get me wrong, I love programming, but gamedev programming has been hard for me recently and I wanted to continue my break from it. I also had a bonus goal, which was this: Live record my music. Instead of using all of the software instruments to create my music, I wanted to record it myself. At least a little bit. I succeeded.

With these goals in mind, I knew there was a high likely hood that my success hinged on the theme. So I decided that if a theme was chosen that I didn’t like, I would go with my own theme (I choose the theme “Isolation” for this). A lot of people wouldn’t agree with this, however this time around I didn’t want the theme to be the challenging factor, I wanted it to be a guiding factor. Sometimes if I make a game based off of a a theme I don’t like, I’ll produce a loveless game. Luckily there were two themes for me, which worked out super well. I think that the dual theme was a great point about this LD, many games were produced that were fantastic, as well as a good variety of games.

What follows is a day by day account of my process.

The First Day (theme announced at 6pm)

So I started out by going to the store and buying my game jam food. If you want a list it goes a bit like this:

• Chips (for home made nachos, I have refried beans I don’t know what to do with)
• Cheese (running low)
• Bananas
• Yogurt (running low)
• Those small cute oranges that I eat like candy
• Rootbeer (lots)
• Instant-freezer food

You may notice a big lack of classic junk food, which is amazing for me and Ludum Dare. If anything, doing the “healthy” snack of dinky oranges (all gone by the end of the jam) and bananas worked out well. Also, this is the only time I really buy myself a pack of soda, so it was a nice treat.

Usually I use the walk to and from the store as a chance to brainstorm, but I didn’t really get very far with that. The most critical part of LD is the brainstorming. Thats bolded for the people who just skim the text and look at the pictures. So I went to place that would be perfect for brainstorming. “The Cube” is a room at my school used for orchestra rehearsals and various performances. At night, its vacant, with a piano, 8 speakers, and a whiteboard. I had a lot of pacing space, and would listen to music and just think. I think the hour or two I spent doing this was by far the most productive of my whole LD. I got an idea I loved, as well as an idea for my music, my art style, and a vague idea of the themes and lessons I wanted to use in my story.

At the end of this brainstorming session, I knew I wanted dancers, I knew how to get that dancing, I knew what music I wanted, I knew the art I wanted, I knew the themes and lessons I wanted to use. What I didn’t know was how it would all go together, and what sort of gameplay it would have. I knew I wanted to you to be able to “control” your dancer, but I didn’t know what sort of goals and penalties there would be. At this point I was still trying to make a full on game.

I then set out on my music creation. I wanted three movements, the first upbeat, ignorant, and happy. The second was isolated, dark, and pensive. Third was to be a waltz which would be happy (but not overly), but also matured. I worked mostly on the first movement and got it out of the way, I then moved to the third and got the basic waltz and melody figured out. Never doing a waltz before it was hard, and so I had to draw inspiration (and the basic um-chuck-chuck) from another song. Its all part of the learning process after all. That would be the end of the first day (it was around 3am).

The Second Day (starting at 9 am)

I had to focus on art. I knew exactly what style I wanted to use. It was a style I saw in a print Kusaka Kenji at a museum that gave the perfect sense of movement. Because it was a jam, and I didn’t want to waste time on something I am the worst at in art (I’ll improve later), I actually took my palette from a print of his. Part way through I realized I wasn’t getting what I wanted, and decided to scrap it and start over. I had decided that I didn’t think out the form well enough and it lacked a cohesive feel. However, after I got a snack and a step back, I realized that what I had wasn’t bad, but I still needed form. To do this I layered on top my “isolated” motif, which was an orthagonal overlay that stood separate from the backdrop. In the end, I got a background I really liked (and still do). I started programming at this point, and throughout the rest of my daylight hours (only till 4:30pm!) I would intersperse my programming with the rest of my art creation. In the evening I transitioned into more music creation. I was going to record my (improvised) second movement at around 10:00pm. That time came and I set up my microphones (2 on the piano, two on the room, and one below the piano), headphone mixes, and had my drop in engineer take a couple pictures while I finished the routing.

Here is a picture of my recording set up (not seen are two room mics behind and to the right the camera):

Brief postmortem on that session goes as such:

Pros:

• Workable audio
• Good sounding piano
• Considerable lack of bad notes played (I’m not a great pianist)
• Good excess sounds

Cons:

• Shoddy mic placement (the two on the piano needed work)
• Too dry of a room

One important thing to think about is that the piano is great for a number of reasons. It sounds great when you play it, but it also sounds great when you tap it, hold sustain pedal, brush the keys, scream into it, and do all manners of things.

My goal for the end of the day (night?) was to have all of my music done and mixed. I finished my recording at around 1:00 am and then moved to work on my waltz some more. Throughout the night I would hop around my three pieces of music, and got closer to the goal. At one point I realized I wanted some background noise to my second movement that you probably never even noticed. So for a few minutes I went outside and played around with various ways to record rain. The sound I went with was the sound of water hitting the leaves of a shrub. I finished my music and finally got to bed at 6am. Much later than I wanted.

The Third Day (starting at 9am)

At this point I was slowly realizing my goal of entering into the competition was going to be a bust. I knew I had to make more art (I hadn’t made the “branch” sprite yet), needed to write a story, figure out gameplay, and compile it all together. Because I only had around three hours of sleep I’m not fully sure how this day went. The biggest part was the creation of the story. At this point I wasn’t sure what story I wanted, or how I wanted to tell it. After talking on IRC I realized I wanted something like a one sided conversation in letter form. Although for some reason I totally forgot about it until midway through writing, its somewhat like the lyrics to the Juliet Letters (lyrics start at ~0:50):

Parts of the text were inspired by this album as well as the Les Misérable soundtrack. My line of text “I saw the world reborn, you saw it move on.” was a direct reference to this song (which has the most emotional impact on me of the whole musical):

I got the text all written, went to refine. I choose themes and emphasized them, I created reoccurring motives. My goal throughout all of this was to make it feel as if you were peering into this fellas private notebook, which was somewhat a stream of consciousness, going straight from his brain through the ball on the point of the pen and finally bleeding into the paper. This is how I rationalized using silly out of place phrases such as “Am I a fungus?“. That specific line was more or less an inside joke with myself that I was dying to put in, and was relishing the reaction people would have when it came at the time it did. Hopefully people realized how it related to the line “Our failure taught me that I can grow. This death just feeds my growth.” Throughout my text writing process I was brainstorming names for the game. It was only when I ordered my text in its appearance in the game did I realize I wanted the last line to be “I finally learned how to dance.” Which is a bit surprising as dancing is the core of my whole game. Funny how that happens.

After writing the text I had to decide how to put it in the game. I realized I wanted a kind of collage that would transform throughout the game. To do this I used photoshop to create my text in .png form as well as place them to my liking. Although this meant a lot of dull and repetitive work, I think it was a good choice.

By the end the night I had my story written, made the text placements in photoshop, semi-exported manually into the format my game could read, and had the timings done. I had also improved my dancers dancing and created the branch sprite. I had a mostly complete game at this point. I had more I wanted to do though. I wanted to add shaders to improve the mood and feeling, I wanted to fix my mixes (turns out doing final mixes late at night isn’t a good idea), as well as add refinements to the dancing. I went to bed at around 2:00am

The Fourth (and final) Day (starting at 10am)

Nothing new really transpired through the day. I added in shaders, improved the timing of the text elements, finished up the dancers, finalized the song’s mixes, title screen, and added in the ability to go fullscreen. The only hitch was fullscreen. It seems like the window resizes when going fullscreen, which would mess up just about everything in my game. The art was made to order, it is the exact same size as the intended resolution. While this is bad practice in general, it was a necessary one for LD. Also a good practice for my computer, as photoshop tends to slow it down, especially with large images. I eventually hacked in fullscreen support (overwriting framework calls such as love.graphics.getWidth()) to not destroy random aspects of my game but also have it centered on the screen. This along with one other minor thing (making all of the text white in the second movement) was my only real hacky programming I did throughout the whole of this LD. I packaged and submitted 30 minutes early. Although in reality it takes me about 1 hour to package and release so I was only done 30 minutes into submission hour. Only at 6:30pm did I finally get a chance to breathe, and say hello to my programmer pet, Monty.

Post Mortem

If (and when?) I do a post-compo release I have a few things I would fix for sure. First of all is the music. While I like the feel and how it turned out, I need to refine the melody and give it a bit more form (in all songs). I also need to re-instrument it to be more unified throughout the entire game. I also need to redo the art, make a palette that fits the game more, as well as give the colorful part of my backdrop more of a formal idea (so it can stand by itself). I would also separate the art more so instead of it all fading in at once, I have bits an pieces fade in, as well as for the orthogonal layer I would separate it into lines and have each line move in independently. I would also redo bits and pieces of the text to make the times at which they appear more often as well as remove all of those spots where nothing was happening. Also dancing, I have ideas on how to improve the dancing.

Pros (what worked):

• Music, many people enjoyed the music I made for it. And while the second movement didn’t get as much attention as I hoped, many people enjoyed the waltz
• Mood, I think my art and manipulation of it throughout with the music and text worked well
• Brainstorming, that initial brainstorming session was necessary and helped a ton in the long run.
• Goals that intentionally avoided things that may cause me to burn out.
• Use of theme and subtheme to help create larger themes
• Wavetables for dancers
• Story and text
• People had multiple interpretations of the story

Cons (what I would do differently):

• More attention to methods to manipulate the dancers
• Definite decision on how to display text and allow interaction without interference between the two.
• Make the dancing more dynamic, dancers slow and speed up, twirl on impactful points, maybe spin around eachother.
• Team? For this type of game, it would’ve really helped to have someone just program while I do everything else. Naturally this isn’t how it would actually work out if I teamed.
• Try doing my crunch work early in the morning rather than late at night. Dunno if this would work but late at night my productivity drops a ton.
• Try to come up with more ideas on how to add personality to the text.

Lessons other LD’ers (and game devs) should learn:

• Brainstorm is key to success. Write it in a notebook, move around, listen to loud music, cross things off, write things in.
• Push yourself, but at the same time realize the limitations that are already imposed. The main difficulty of LD (or other short game jams) is knowing how much time you have and what you can do with it.
• Realize what you are good at, and capitalize on that. This is of course unless you are trying to improve on your weaknesses. Then go for that instead.
• Don’t be afraid to make what you actually want to, rather than your standard run of the mill game. Or make a standard run of the mill game if thats what you want.
• Don’t be afraid to draw inspiration from other sources, it will add a unique flavor to your game, as well as possibly push you to do something you never did before.
• Find a simple thing you can implement, and then build off of that with the time you have left.
• Have fun, don’t be afraid to dance.

• My twitter
• Soundtrack for this game
• Itch.io page for this game
• Ludum Dare page for this game

Tags: ld34, ld34 Postmortem, love2d, post-mortem, postmortem

Have received a lot of positive comments and decided to continue work.
So I’ve already done some after compo in the game.

Changelist:

• new visitors: womens (scares of dead bodies) and hungry dogs (eats meat)
• ability to hide bodies on the basement (from 4 level)
• particles for reputation, structure and exp points
• camera shake on receiving damage to elevator
• notifications of peoples waiting on other floors
• people stay randomly in elevator
• combo kills (try to kill 3 at once!)
• tutorial windows
• tips on game over
• random objects on floors
• elevator going up faster on start
• smooth acceleration
• new bubbles for messages from people
• other fixes and balance changes

Some of ideas I received from comments.
And I will be happy if you play Evilator and leave some feedback.

Play Evilator!

Know issue:
Lag after few seconds of playing in WebGL. Will find it soon.

TODO:

• Level colors (for queue notifications)
• Peoples queues on floors
• Implement fear state
• Build for mobiles
• New art for the game
• Icons for upgrades
• More content

Just updated the Kongregate version of my Ludum Dare 34 games which can be played:

HERE

Note this is not a compo version so don’t use it for rating, if you want to rate play:

THE COMPO VERSION

I have really enjoyed making this update and realizing just  how bad (and wrong) some of the original code was. This means that some of the main features of this new build are bug fixes, but I have also updated spawning script to make the start of games more varied and fair and I have changed the UI to make it easier to understand along with some balancing and optimizations.

I will most definitely continue to update this game but for now only on Kongregate so as to not get the compo version muddled up on itch.io. However when the voting has finished this will also be updated to the latest version.

And as always, thank you very much for playing my game.

If you want to see what the changes to this version, here are is the Change Log:

V1.02v0
Features:
+ Added tile type display, building name will be green if it is the optimum type for the terrain type
+ Added some useful messages to give the user more information about what is happening
(e.g. that a building is already at the maximum level so can’t be upgraded any more)

= Changed fog to use curved edges similar to how the kingdom border is done
= Changed scenes to be loaded additively
= Changed resource display poll resources to be more correct
= Changed resource cost display to show current resources/net and cost resource/net change separately to be more clear
= Changed cost resource display colours to show effect of building/upgrade/attack where the cost will be red if possible
and the net will be dependant on the final net (i.e green if the effect will end up being positive, red if negative)
= Changed team spawning to be randomly generated to give more variety and be fairer at start (will mostly start with positive net for all resource types)

Balancing:
= Reduced amount of gold produced by towns
= Changed attack cost when attacking a different team to include the base cost of the tile dependant on the terrain type
= Increased starting resources to 100 for each type (from 20)

Bug Fixes:
= Fixed bug where lines would end up between tiles at certain zoom levels, now uses a default material with “Pixel snap” turned on
= Fixed bug where display tiles would not be destroyed when new instance of the game is loaded
= Fixed bug where upgrade cost was inconsistent/wrong
= Fixed bug where the cost for building/upgrading buildings was applied incorrectly
= Fixed bug where resource display was incorrect
= Fixed bug where team start locations where stored in a static variable making them not be reset on starting a new game causing
an infinite loop when trying to find a new start location
= Fixed bug where buildings could be downgraded to negative levels
= Fixed bug where you can attack tiles if you click on a development button when you can’t build upgrade
= Change internal method of accessing upgrade data to make it more difficult for me to make mistakes and made it work properly

= Other optimisations and bug fixes

Started working on the post-jam version yesterday. Wrapped up the first task today, have a look.

I won’t be releasing anything before I’ve finished the gameplay improvements as well.

Meanwhile, try learning to fly.

Tags: gif, graphics, post-jam, progress

– – –

If you like to play a game over Xmas designed for young children.

Please try out our Pixies Flowers.

Feedback are welcome.

best wishes

from

puppetmaster and sammakko

– – –

Tags: godot engine, xmas

“Networking programming is hard,” I’ve heard, “don’t do it.” It’s been a common consensus among us programmers that online multiplayer is simply not a beginner-friendly material, let alone a game jam material. At the time, having bits of experience programming networked software in college, I agreed with this consensus. This left a strange hole in my large library of games: I have no online games listed. Perhaps it was the Ludum Dare 34 keynote that motivated me to kick this bad habit. Either that, or the Shia LaBeouf’s video mentioned in the keynote.

Either way, hack.source.net is the first attempt I’ve ever made at an online multiplayer game, and an open-source one to boot. Despite being a bug-laden, lag-filled, unoptimized experience, I’m proud of what I was able to make in the short time given throughout Ludum Dare.

What is hack.source.net?

hack.source.net is a 2-player online first-person shooter that allows one to hack and disable up to two buttons from the opposing player’s controls at any point in the game. Born out of this Ludum Dare’s theme, “two button controls,” hack.source.net forces both players to improvise as their best abilities are taken away from them. The game is played on the keyboard and mouse, providing each player with the following abilities:

• WASD or arrow keys to move or strafe. In the latest version (v1.5.1), only one directional key can be hacked at a time.
• Move the mouse to look around. This cannot be hacked, so both players can turn at all times, even if a directional key is disabled.
• Left-click or left-Ctrl to shoot a slow-moving bullet. This cannot be hacked, so both players can play offensively at all times.
• Esc to bring up the hacking menu. While this is up, the player can still move and look around, but cannot shoot. This cannot be hacked.
• Right-click or left-alt to briefly conjure up a shield, reflecting any bullets back to its source. Players cannot shoot while their shield is up. This can be hacked.
• Space to jump. This naturally provides players access to higher vantage points. This can be hacked.
• Hold left-shift to run, doubling their speed. This can be hacked.
• In addition to these buttons, the radar can be hacked and removed from the opponent’s screen as well.

Combining hacks allows for a variety of strategies to emerge. For example, one could leave the opposing player in the dark by disabling the forward key and the radar. Another may disable the back key and the shield to discourage the other player from playing defensively. Yet another could take the upper ground by preventing their opponent from running and jumping. It plays like the video below, which has an older build that does allow hacking two directional keys:

What went right

Using a Game Jam to learn something new

Historically, I’ve used #OneGameAMonth to learn new features in Unity 5, such as path-finding and the recent UGUI framework. This is for multiple reasons: for starts, even if my game turned out to be bunk, I still took something new and important away from it. Learning just one aspect of a game engine also helps me creatively, developing games that mechanically revolves around one focused feature. As of late, I’ve been focusing on creating Not a Clone mobile remake for so long, I haven’t had an opportunity to learn new things about my game-engine-of-choice. As such, I took the risk to learn and practice the latest UNET framework, using the hacking mechanic to justify the mandatory online connection. Even though the game is very rough on the edges, it’s still lauded for an interesting premise.

Utilizing Unity Standard Asset’s FPS controller

From experience, I knew that the majority of my time during this jam was going to be spent learning network programming. As such, I had to come up with how the game was going to be played as quickly as possible. In this case, I chose to use the first-person controller that comes with the Unity Standard Assets rather than the third-person controller. It comes with the game engine, after all, and it reduces the number of problems I would have to deal with such as camera placement. The rest of the design decisions came naturally from this first choice:

• Players would fight each other with slow-moving bullets. This would give meaning to the built-in run button.
• Neither player can hack the shoot button. If I were to allow it, both players could disable each others shoot button, leading to a stalemate.
• Since the directional controls can be hacked, a player could potentially be cornered. For these situations, a defensive option is necessary, thus giving birth to the reflective shield.
• This game favors implementing as many useful abilities as possible to balance out the hacking ability.
• And so forth.

Quick GUI generation

Seeing as menus are a common thing that needs to be implemented in every game, I created a simple GUI manager in my Template Unity Project before the jam. Originally, the GUI manager, along with various example menus for the most common functionalities, was made for a single-player experience. To my surprise, the same code proved to be a time-saving feature for this game as well, allowing me to create a large number of menus in a short amount of time. The hack menu, for example, was simply a re-purposed pause menu that doesn’t stop time, and includes an extra hierarchy of menus that lists all the buttons available for hacking.

Incremental building, frequent testing

Perhaps due to my exposure to Agile development, I always develop with an hourly milestones in mind. In practice, this meant that the first few hours were focused on following tutorials to sync the position of two players, and testing to make sure this worked. The next few hour is focused on syncing the rotation of both players, and testing to make sure this new feature behaved properly. Next hour was on shooting, and so forth. Even the most basic feature was put into its own milestone, followed by thorough testing. To help this, I used tools such as version control (Mercurial + BitBucket) and continuous integration (Unity Cloud) so I can stay focused on coding and testing.

This strategy proved vital for this project since I was just learning network programming, and thus, prone to making errors and mistakes. By testing often, especially after a new feature has been implemented, it helps reduce the time spent on technical problems by keeping the scope of changes small.

Last minute graphical polish

I have a bad habit of focusing on graphics too early in development, which leads to a beautiful game that needs gameplay polishes. This time around, however, I worked on graphics last, which provided me more time to work out technical problems. Unfortunately, technical problems defined my entire development process of hack.source.net, so this isn’t saying much.

What could have been better

One day wasted

As it turns out, I was planning to work with barcode on MaskGarden on the first day of the jam. They overslept, however, and arrived at our real-world meeting place at around 5:00 PM. In a bit of a pickle, I’ve decided to start on my own project at around 1:00 PM. Those doing the math and correctly assuming we live in the Eastern timezone will realize I lost 16 hours. Yikes!

Slow testing, debugging

Network programming is hard. This bears repeating: network programming is really, really hard. A huge annoyance I needed to deal with while testing was the actual setup itself. For a single player game, testing a feature is as easy as clicking the play button on Unity. For networked game, I needed to build the game (a long process on its own), play it, then press play on Unity and connect the build to Unity. I would have to test both the game running on Unity and on the build to make sure when either sends a message to the server, the other receives that information. And this is before I notice something goes wrong! If something goes wrong on the build side but not on Unity, I then have to stop both, host from the build, then connect Unity to the build to check for any errors that may appear on the console. And if I make a fix, I need to go through all this process again to verify it’s gone.

Needless to say, testing and debugging a networked game is a time-consuming process. Since I was just learning how to code with networking, technical issues would occur often, and the grand majority of time developing was taken from debugging and the many attempts at fixing bugs. This experience sure gave me a whole new respect for network programmers.

Missing features

One major feature I never got around learning, let alone implementing, is the latency prediction in most online games. This is pretty huge: I knew that I needed to keep the data sent to the server to a minimum, so I could have drastically improved the user experience by making predictions to player movement and bullets. Sadly, the debugging process alone was enough to punt this feature out of the scope of the jam, leading to a very laggy game. As someone who prioritizes the user experience above all else, this is very shameful.

No play-testing

Sadly, I was never able to find the time to have the game play-tested by other players. Consumed both by the debugging process and hosting the real-world meeting event at the same time, there simply wasn’t enough time to ask others to play, let alone setup. Given this nightmare situation, I simply went with the fastest, minimal plan. Naturally, this resulted with an unstable, laggy, difficult-to-setup game.

Convoluted setup process

The current game requires setting up your computer’s firewall properly, and knowing how to obtain your own IP address to send to your friend to connect to your computer. Due to the minimalist peer-to-peer network setup, a lot of Ludum Dare judges could not actually play the game. This obviously breaks down the most important feature in Ludum Dare: the online feedback of other developers, letting you know what you can improve on next time. It would have helped if I knew how to make the process of connecting 2 players easily, such as creating a lobby server everyone can connect to and find others online to compete with. Obviously, this is well beyond the game jam scope, but it would have been nice to have.

That strange moment where a stranger was staring at what you’re doing

At the same time I was developing hack.source.net, I was also organizing our real-world meeting. Fortunately, the meeting has gone very smoothly, with our participants creating 8 new games, including become a game developer in 60 seconds. That said, the weirdest experience I had throughout this event was when we were visited by a certain tourist. To clarify, we reserved a quiet community room in a makerspace building, so while the makerspace receives a lot of tourists, the room itself remained a quiet and productive place. We did have, though, one persistent visitor who was curious enough about game development to ask if they can see what I was doing. I agreed to this, but immediately regretted it when they sat next to me, staring silently while I try to figure out what I was doing before. This experience only lasted for about 20 minutes, but it was the most awkward moment I had in a jam. I can only say I’m glad I was the only one who suffered from this.

What will I do next

Chanced are very high the next game jam game I’ll work on will not involve with networking again. The time spent on testing and debugging alone is enough to make the task unfeasible in a short amount of time. That said, for any longer-term projects (such as #OneGameAMonth), I think it’s worth learning how to create latency prediction and lobby servers to create a more streamlined experience. Improving hack.source.net, especially down-grading the power of hacking, will need a lot of brainstorming and efforts that won’t be easy to do alone. Efforts on that game will probably remain stagnant for a while as I finish developing Not a Clone.

Also, to avoid the same strange visitor incident from happening again, I’ll need to let the building organizers know that we don’t accept tourists into our area.

Tags: hack.source.net, postmortem

So, over the 30-some-odd games I’ve rated, I’ve actually seen quite a few cool games, and so today, I would LOVE to show you guys some games from us little guys who aren’t complete geniuses, yet.

First up is All Ways Down, which while it’s not very fancy, there is DEFINITELY some cool potential for this one.
Here it is!

Next up here’s the Rap Game, a fun, oddly strategic, fighting game, where you actually don’t hit anyone.
Here it is!

The Serpent’s Shadow is by far the most innovative game I’ve seen. It’s use of shadows, bunny eating, and the classic Snake mechanics is genius. Check it out here!

These are my favorites so far, so check out my game maybe, leave a comment, and I’ll see yours too!
Hero Feed Co.

Looking for a holiday game jam to participate in? Look no further than the SUPER MLG CHRISTMAS GAME JAM! It’s a Christmas themed jam on GameJolt that runs until the 27th of December. The winners will be featured on my YouTube channel. This jam should be loads of fun and I hope to see some of you folks there!

~Keep it indie~

JAM PAGE

Have you ever wished you were a cat locked in a food factory with a voracious appetite? Now you can be!

If you haven’t voted for Fat Cat yet, head on over and check us out! Thanks!

Rendered in the art style of our Jam entry Wyst

Play it Here!

Merry Christmas from Game Devs Osnabrück!

Hi people!

We are “Team Glitch Happens”  and we made the game “La Mano Loca (Sticky Hand)”.

If you’re interested, check it out here: http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=66113

These are sketches of the level design of the game (Sorry, but it’s only in Spanish)

Thanks for all and Merry Christmas!

With the Christmas break starting, we finally got the time to write proper post-mortem and finish the post-LD version with improved graphics for our LD34 game “The Tournament”. You can check it out here. We also uploaded the source code if you are interested to take a look.

The game was designed to be an arena manager simulator, where you manage team of robots to get as many victories as possible. You don’t have the direct impact on the fights (as you are just the coach – not the gladiator), but you can choose the fate of the defeated opponents, suggest tactics to your fighters and choose who shall face each opponent.

What went good:

• Team communication: With the team of 6: 3 programmers, 1 graphic artist, 1 music artist and 1 UML guy, this could easily become a nightmare. Fortunately using trello turned out to be a pretty awesome solution for our needs.
• Splitting into prefabs: Our game is written in unity, and it’s known for being a little bit problematic when working with teams of programmers. But since from the very begging we decided to split every bit of functionality into separate prefab we did not had a single merge issue during the whole jam.
• Paying attention to the audio: I have to admit, that for me personally audio was always the thing I paid the least attention during the game jams. But oh boy was I wrong. Without the awesome soundtrack, the game would not feel even slightly as complete as it turned out to be.
• Creating mock-ups: It seemed like a waste of time, but they highlighted UI issues we would otherwise discover very late and with the final assets ready. It also greatly simplified the work of the graphic artist and allowed him to focus on delivering the best assets he possibly could without having to worry about the details.

What went wrong:

• Starting late: We had the idea for the game since saturday morning, but assembled the team and started working on it sunday at 12:00. This turned out to not be a great idea and resulted in less amount of sleep than we would like to.
• Too many features: Our initial plan was to deliver almost twice what we were able to finish in the time we had. Cutting features late was really hard and if we had started with the more humble plan at the begging we would still had a lot of time for balance and polish at the end.

Overall though, the Jam experience was a blast for the whole team. We learned a lot and had a great deal of fun Can’t wait for the next LD 😀

PS. Our music artist uploaded the Full OST to the soundcloud. It’s pretty sweet:

Tags: post-mortem

Just wanted to highlight these awesome games. Check them out.

Frank & Stein by vegapomme27 

Frank & Stein is just a really well made compo game. Graphics, sound, are all top notch and work together really well.

Rude Bear Recreation by Alex Rose

Rude Bear has the most fun gameplay of all games I played here. Mechanics are really simple but feel awesome to use. And the game has a lot of checkpoints, so it is not frustrating.

Hey there, folks!

This Ludum Dare has been very meaningful to me, beginning with the fact that I started working as a freelance programmer to make other people’s games while trying to live, it was about time (after missing 3 Ludum Dares), for me to make a game of my own.

To be honest I started this journey because I wanted to experiment with Unity’s WebGL and the WebSockets implementation, which turned out not being as hard as I expected. In the middle of the weekend I began to work on Tama Battle which ended up being my entry for this edition.

Combining a bit of RPG, a bit of Multiplayer and a bit of RANDOMNESS I created this little game, that is already turning into something bigger. Yeah, because fuck it, I want to make this a brilliant and beautiful game, something people can enjoy everywhere (Mobile & Browser based), because that’s why I “signed” into being an independent game developer. Not to make someone else’s games.

And that’s why I’m happy to announce the following new features coming by the start of next year (start of January):

• Android support (I might consider going to iOS too depending on how enjoyable it is on Android devices).
• Unlockable Skills: Using experience points, you’ll be able to unlock skills from a skill tree divided in three essences (Fire, Water, Earth).
• New Stat ‘INT’: Will determine the chances your pet’s got to execute any of the skills you’ve unlocked for him.
• Fight Buffs: Let’s say you loose three fights in a row. You’ll have a chance of being blessed with a buff that will either lower incoming damage for the next fight, or heal for every hit you make, etc.
• Daily Challenges: To put some incentive into keep on playing the game, there will be Challenges ala “Hearthstone” that will affect your fights. And if you complete them, will give you sweet sweet rewards (Either a ton of exp, some extra stat points, or something I’m keeping a secret!).
• Gold Accounts: By supporting the development (it will be priced at 2,99$), you’ll receive a life-long experience boost (you’ll level up faster than normal accounts). This will also be on Android, and depending on how supportive you guys are, that could mean no Ads forever! 😀
• Stat and experience gain balancing.
• Resting will no longer be timed, and will be like a clicker. The faster you press the Rest button, the more you’ll heal your pet!
• Bug fixing!

There will also be a website for the game ready sometime before this month ends (http://tama.devmidgard.com/), be sure to check it out!

And that’s it for the moment, you can go and enjoy some christmas season fights while there’s snow on the game!

View & play the game here: http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=11046

Cheers,

Midgard.

Oh, I almost forgot, there’s a hilarious gameplay video someone made (really appreciate it!):

Time for another post-mortem! If you haven’t yet, you can play Earth Invader here!

For this Ludum Dare I didn’t actually learn anything new… I was very focused with my own project that I didn’t learn anything particularly new. I actually started developing a new engine which would support 3D, but it’s way too far from being complete, so I decided that I would use Unity, since in my new project I’m going to use it anyway, so might as well begin practicing!

What went right:

• Unity

This was my first time using Unity to release a game, and it went pretty well! I’ve tested before with some tutorials so I already knew that it was fairly easy to make something. The work flow was really smooth and wasn’t so difficult. Although I did want to make this game with my engine, it was good learning and worked well.

• Krita

At first I was going for pixel art with GIMP, but then I thought, well, I always wanted to use Krita and try  another graphic style. And so I did, and I’m pretty satisfied with the result! Krita is a great tool, even though I don’t have a tablet to draw I was able to use it well! It was difficult in the beginning to adopt a whole different style, but I guess it was worth it

• Audio

As always, I used Bfxr for sound effect and Bosca Ceoil for music. It worked like the last Ludum Dare, nothing new, but the result was nice. I did have some difficulties with my composition, since I still only know the basics, but the result was something I was happy with

• New experiences

In this Ludum Dare I tried some of new things. Uploaded the game at itch.io, did screen recording (I wanted to make a timelapse, but didn’t work well)… It was really fun and really good learning for my future projects!

What went wrong:

• A lot of setbacks

This Ludum Dare was pretty harsh for me… I was really tired from work, then I spent the first 12 hours just trying to think a concept that I was happy with, then the energy went down in my house, and so on…. Yeah, not the best situation…

• Sudden change of style

Although I’m happy with the style I adopted later, I already had some assets done so I had to remake them (I didn’t really, just made some touches to adapt them), so it got a bit inconsistent.

• No playtests

I really wanted to have more playtests, but I didn’t have any… I really need to start searching for people that are willing to do that…

Conclusion

This was a really difficult Ludum dare for me. Not so much on technical part, that went pretty well, but setbacks from life. But still I managed to overcome them all and finish a game that I’m actually satisfied with! I really didn’t expect that… Even now I’m still pretty tired from the last part of the year, but I’m going to rest a lot this holiday! And let’s hope for a great year that’s coming! For the next Ludum Dare I hope I can finish my engine, get some more composition practice and make better animations! Congratulations everybody! Keep up the great work and let’s even work harder next time! Happy holidays!

PS: Sorry it’s a bit hastily, I’m a bit short in time here ^^;