Hello everybody ! Our first update to the game to remove some bugs that were quite important. Here is the patch note (yeah it's short...)

Version 1.0.1

BugFix : Jump has been upgraded as it was really tricky to use on platforms
BugFix : Wooden Crate Fix that prevented the crate from detaching from the player that could be game breaking
Mac OS X support
Lijnux binaries (untested)

Itch.io Page

LD Jam Page

Known Issues :

Player tends to "Moonwalk" sometimes

As soon as the theme was announced I grabbed a pen and notepad and started mapping out ideas.

I decided the keyboard world idea was the most original and also simple enough to create in the available time, so I slept on the idea and began fleshing it out the next morning.

Some mechanics evolved or were cut but the idea remained mostly intact. I decided to focus purely on programming the core mechanics to being with, so by the middle of day 2 I had a playable prototype but the characters were still grey capsules. I spent the second half of day 2 designing, modelling and animating the game's characters and objects.

I made myself a to-do list for day 3, prioritising the elements that were most lacking.

When I woke up on the morning of day 3 my game still had no sound whatsoever, so I set about creating sound effects using household objects (and recording puppy barking noises with my own voice...), once the sound effects were in place I grabbed my acoustic guitar and recorded an arrangement of the theme tune, which I had hummed into my phone the night before.

I was able to get through most of my to-do list but as the deadline was approaching I decided to abandon the ideas of difficulty settings or multiple levels, and just make sure what I had was as polished and balanced as possible.

I was anxious about not having the tutorial done so I got that made probably earlier than I should have. I found myself remaking the tutorial pages as I updated the game's mechanics and controls, which in hindsight was wasted time. Once I realised how long the tutorial was I added in the page numbers, just so a player wouldn't be put off by clicking through seemingly endless pages.

I uploaded my game a few hours before the deadline. After playtesting it in my browser I realised I'd made a huge error by choosing the Alt key as one of the controls (it kept bringing up a menu in the browser and shifting the whole game on the screen, distracting to say the least). So I hurriedly reprogrammed the controls, updated the key sprite and reuploaded.

With a couple of hours to spare I was totally burnt out but satisfied with what I had created.

I think a deciding factor in how things played out was my choice of a relatively simple idea. I think it has the potential for added features and greater variety, but I was able to execute on the core idea due to its simplicity.

A couple of things I think I could have done better:

Firstly, brushing up on my knowledge of the softwares I was using before the event started. I wasted quite a bit of time looking up how to do things that I knew before but had simply forgotten. I should have anticipated what type of methods I was going to use and practiced ahead of time.

Secondly, I started with great planning and work rate but as the event progressed my focus started to drift. There were times when I sat there spacing out, weighing up in my head what to do next and wasting valuable time. Burnout was partly to blame for sure, but I could have done a better job of small-scale time management.

Overall, it was a great experience. Honestly I never would have thought it possible to create something like this on my own in such a short time frame.

So thanks Ludum Dare for the inspiration to push myself to the limits and find out what I was capable of!

Here is a full timelapse of my LD38:

https://www.youtube.com/watch?v=IVGMHO0HJ4A

Play the final product here!

https://ldjam.com/events/ludum-dare/38/$15179

First off, heres a link to our game:

Link to Mac & Windows versions: A Small World After All

Second, a reflection of our game:

We made a stealth game, where the objective was to collect a certain number of items in a grocery store before time ran out without getting caught by people you know. Our initial goal was to create a 2D game that focused on stealth abilities, such as holding a shopping bag in front of your face or knocking over items in another aisle, while collecting items. We were able to enact the element of collecting items while avoiding people from your past, but we didn’t get to implementing the more nuanced stealth mechanics. And our concept of a simple top down 2D game quickly changed to a 3D game with the addition of our assets.

We used LMMS for our background music, but most of our assets were from the Unity asset store (no one in our group has any artistic abilities!).

Something that definitely took more time than expected was putting together the grocery store. In addition to the basic layout of the store taking a lot of time, it took a big portion of time to fill the shelves with items. We also had a lot of issues with pushing things and then the changes being overridden by someone else’s push, which resulted in a lot of repeated work. A couple things that were broken at the original build time were the animations of some characters, which we thought we had working. Also the functionality of our Main menu system was a little broken, when starting the game the credits screen appeared first. One of the characters that was supposed to chase you stopped working. And finally the timer that had been working the whole build was suddenly not working.

Some things that we plan on changing throughout this next week:

• Improving the animations of our NPCs. This was something that just didn’t seem to work during our final build of the game. We need to dedicate a little more time in redoing this part of our game

• Fixing the timer is and needs to be one of the most important things to get done. It is a key component that our game currently lacks

• Implementing more sneak functionality into the game. Right now there isn’t an obvious way to determine if an enemy character is looking right at you so its hard to avoid them. This is something we will implement.

• Make it easier to see the NPCs

Overall for our first game jam, this has been extremely enjoyable and informative. It really tested our skills as game developers that we have been developing for about a semester.

Pictures during development:

Thanks for checking us out!

Hey! I just released a postmortem blog post on "Leucos"! You can check it out here: http://wp.me/p8d1dY-9A

Due to the fact that I was ill and didn't have enough time to fully piece together a game, I have decided to remove my game from judging. My game so far works to an extent, but has many frustrating errors and bugs. When I went to debug these, I found that they were caused by my lack of organisation and messy programming. However, I really do like the direction of the project and when I get time away from school, I will completely re-do the project, organizing my scripts and such as much as possible.

As a side note, I hope that everyone else had a well polished outcome. Despite my failure, I am proud to say that I have never had as much fun developing a concept ever.

So I'm making my post-mortem for Daylight a little bit late. I don't really have a sleep excuse, because it's been two and a half days since I submitted it. The real reason why I'm doing this so late is because I don't want my post to be caught in the tsunami of post-mortems that lasts for a while. That's right, I'm greedy for views. And no, not the Drake album.

When the theme was announced, I was pretty sure that I was going to make a game about sailing and exploration, but I decided to brainstorm just to make sure. Then I realized: "Hey, why don't I make a game that I designed for my video game design class for a whole month? That would make sense." And so that's what I did. (Note: I didn't write any code for it before. We simply had to design the feel of the game.) The problem was, Daylight was meant to be in black and white. And the last time I made a black and white game for the compo, it totally flopped. (Maybe it's also because I hadn't used Lua before. That's a slight problem.) I don't know why I like making games in two colors, but I KNEW that this time, my game had to be color. So the first night, I design the player and the platforms, and then made a blue background. Hey, that looks good. So I added some brown blocks with green grass. That's not bad. What if I just go completely against my previous idea and feel for the game and go into a tangent that leads me to who-knows-where? And so it was settled. The main idea behind Daylight is that you're on a small planet, stranded, with nowhere to go except up. By jumping up through the platforms and fighting monsters, gravity gets weaker. Do this enough and you can jump off of the planet and return home. I was in a minimalist phase when I designed the game (more minimalist then I am now), so I wanted it to be simple. Simple colors, simple designs. But people move on.

My character was originally a full human character. It looked out of place, like the cheese in Mouse House. And I wanted my artwork to be strongly connected with the feel of the game. I turned our protagonist into a white cube with a tiny eye. I added some breathing effects, and voila! This game doesn't look bad. I'm not an artist, so this is actually an accomplishment for me. The next day, I changed the gravity so it would vary with the player's height. Then I started working on making the planet and all its platforms. I was surprised when I was done with this in three hours. So I worked on making the monsters. This should take long, right? Nope. I was done. The last thing I had to do was add the energy. As the player jumps, they lose energy, and the only way they can get energy back is by defeating monsters. Implementing this didn't take long. Now my game was looking pretty complete. Problem was, I still had 24 hours. So I went to bed, not sure if I should be happy or sad.

During Sunday morning, I made my artwork better. I added a sun, clouds, stars and flowers, things that I didn't need for the mechanics of the game. Now it was time to make some music. I haven't had time to make LD music before, and I was surprised at how easy it was. Even with my broken keyboard, which shuts off at random times for no reason, it only took me an hour in Garageband to come up with something good. I added it to the game along with my sound effects that I created with sfxr. I had a commitment for the next 6 hours, but I still had time to brainstorm. I decided to make the energy fields checkpoints if the player ever falls off of the map. I don't want the player to rage quit when they fall all the way to the bottom and have to start climbing all over again. Then it was time to submit, and even with the new layout confusing me, I was able to get my game in with time to space. That time was to sleep.

What went right My artwork went better than expected. I put a lot of time into it with Piskelapp, and I got a lot out of it. However, I'm still shocked with what others can come up with. My graphics work on a simplistic level, but the other graphics are so... real. My art isn't terrible by any means, but I would love to see what others use to make theirs. Piskelapp probably isn't a great long-term setup. Music has been lacking in all of my games (especially the ones on Khan Academy, where it isn't allowed). I was excited to finally add some noise to my games, and sfxr worked great for the sound effects.

What went wrong The main thing that I can do better next time is aim higher. I was done with most of my game in a day. Games in game jams aren't meant to be polished. I should strive to complete more. My game performs terribly. I sort of told myself that I shouldn't focus on performance, but the game uses up 5% of my CPU. That's not a lot compared to some 3D games, but it's enough to make Chrome crash in Windows 8. Maybe it's my computer. I need an upgrade. My code could be neater. This isn't a big deal,but it looks like my dog threw up on my screen. Also, I'm writing code twice, just because it's easier for me to copy and paste. :P

Daylight is posted here on Ludum Dare and is available on itch. Please give me some feedback! I haven't firgued out how to embed links in posts yet so it's here: https://ldjam.com/events/ludum-dare/38/$24615

I've been holding back on playing games until the rating system comes out, but I'm wondering if that's a good idea, seeing as hearted comments apparently will play a factor in the new "coolness" system and I don't know if ones made before the ratings system is implemented will apply. Currently, I've just been looking at the blog posts and finding games that look appealing, and bookmarking them to play later. I did check out a couple of the browser ones, but I didn't really play them critically as I would when rating a game.

Yeah, I'm not really sure if that is a good idea, but I don't want to forget to rate games that I will comment on but never leave a rating for. That also leaves concerns that this might happen with my team's entry as well. Not to mention, it's pretty hard to browse for games from the games page alone. The spreadsheet helps though. (https://docs.google.com/spreadsheets/d/1HWYo-es4weXRFnUBhKAUHX9rCodGiczvyIsWRkx9eoo/edit#gid=0)

Hm, might as well take time to plug my team's entry again.

Check out Terraform, a game about mining resources and constructing buildings on a small planet: https://ldjam.com/events/ludum-dare/38/terraform

The Theme

Before the theme was even announced I came up with my game name. Recent world events had spawned a meme "The Mother of ...". So I thought it might be fun to have that as a game name.

I have a habit of attempting overly ambitious games for LD, so I guessed it would be quite appropriate for my LD game, no matter what I made (or failed to make) :P

As usual, I stayed awake for theme announcement, but I went to sleep soon after. In the morning I joined IRC and discussed the theme (and game name) with friends, and the idea which quickly emerged was a literal "Mother" who lives on a "Small World", who has "All of the games". That reminded me of mini games, and the famous C64 title "Lazy Jones".

Because of my participation in One Hour Game Jam, I have good experience churning out mini games in a short space of time, so I had no fear making several such games for a 48/72 hour LD Jam.

So everything seemed to fall in place quickly this time: The design was well formed, it fit my skills and experience, and made use of the game name I was dying to use!

Saturday

I usually start LD by drawing graphics. And this LD was no exception. I began making a (shared) tile set that I could use in the mini games, and searching the web for inspiration for what the overworld would look like.

Day one was mostly directed at making the overworld, this small planet which would link to the mini games. This was completed on Saturday, along with all the game music and several sound effects.

Sunday

When I woke up on Sunday I realised I'd probably need the 72 hour Jam to finish. I began by coding the transition between overworld and minigame. Then started designing the mini games: deciding on their (common 20x20) size, the types of games I would have, and drafting out the levels for them all (as 20x20 bitmaps where each pixel is a tile).

In the latter half of the day I began writing the shared code for the minigames, and sucessfully completed 1 mini game with that code, which played correctly, and linked in/out of the overworld correctly.

Monday

Progress seemed slow, but I anticipated that adding more games would be faster, because of the shared code. While the progress continued at a relatively slow pace, it accelerated through day three, with the latter half of the mini games being added in the space of 3 hours!

Towards the end of the day I tweaked some of the level designs, because some seemed far too difficult, while others looked a bit untidy. In hindsight the levels feel too easy now, but I think they are enjoyable enough :)

I attempted adding particle effects, but I didn't really have time to perfect their appearance, so I ultimately decided to remove them.

And that was my LD weekend. :D

part 2 of this postmortem is here: https://ldjam.com/events/ludum-dare/38/the-mother-of-all-games/the-mother-of-all-games-post-mortem-pt-2

Play it here : https://ldjam.com/events/ludum-dare/38/the-mother-of-all-games

I will be streaming for a good portion of today the many wonderful games people have made. I always have a lot of fun making games for Ludum Dare and now that I have actually started streaming fairly regularly on twitch I have been looking forward to playing all the wonderful games people spent 3 very long days making and showing them off to anyone who was interested!

If you have a game you would like me to show off check out my stream over at https://www.twitch.tv/drazil100 and type the command !addgame followed by a link to your game in the chat (make sure its the version of the link with the name of the game and not the link with the $ sign as that doesn't work for whatever reason)

I will be starting in the next couple minutes and will be bookmarking every game I play so I can leave a comment and go back to and judge when the judging opens up!

Read on if you want to hear a technical breakdown of Gravity Architect's dynamic gravity field engine!

It supports tens of millions of voxels all exerting gravitational force onto hundreds of particles (512 on PC, 128 on mobile) simulating at 90fps (60fps on mobile) on a single CPU core.

In Gravity Architect, you can place any amount of mass with massive amounts of detail into world. Every tiny piece of matter is summed up to produce a dynamic, warped gravity field.

Here's a quick video showing a particularly complicated gravity field:

https://www.youtube.com/watch?v=nGUH-4uwhj0

The gravity field tree was built with SculptrVR's dynamic Sparse Voxel Octree (SVO) as a starting point. SculptrVR's SVO typically only store 13 bytes of data in each voxel: 4 for RGBA, 1 for VoxelType, and 8 for a pointer to a block of 8 children. For Gravity Fields we added 7 more bytes bringing the total up to 20: 4 bytes for float Density and 3 for center of mass (one byte for each of X/Y/Z).

Most games with dynamic or planetary gravity have a small, finite number of gravity sources, and each one usually has limited range with discrete hand-off between gravity sources. This is because gravity calculations usually scale in complexity with the number of sources. To keep computation manageable, these games limit the number of gravity sources in the play-field.

In Gravity Architect, we use the stored density and center of mass in the octree to compute accurate local gravity independent of the total number of gravity sources!

The key thing enabling this is SculptrVR's built-in "Filter" step when making changes to the octree. Every time a voxel is changed, that change is filtered up through all its parents. The built-in filter step only averages color (to make a sort of mipmap as you reduce detail), and decides based on number of on children whether to render a parent as solid or empty. For Gravity Architect we extended the filter function to average density and also do a density-weighted average of center of mass. So if a Child's density is increased from 0 to 1, the parent's density will increase by 0.125 (1/8th), and its center of mass is shifted toward that child in X/Y/Z.

Now that we have variable resolution of density and center of mass in the tree, we can cheaply compute an approximate local gravity! For each particle, we do a tree traversal, and only subdivide nodes near the particle. That way, a higher resolution of voxels is used near the particle, and a low resolution is used far away. Here's some pseudocode for this traversal:

Vector ComputeLocalGravity(Vector ParticleLocation, float Precision) const
{
    //Start with gravity zeroed and accumulate from voxel sources.
    Vector TotalGravity = (0,0,0);

    //Begin tree traversal at the root node
    NodeStack NS = {TreeRoot};
    while (NodeStack.HasNodes())
    {
        TreeNode CurrentNode = NodeStack.AdvanceToNextNode();

        Vector ParticleToNodeVector = CurrentNode.GetLocationOffsetByCenterOfMass() - ParticleLocation;

        float GravityCoef = CurrentNode.GetVolume() / ParticleToNodeVector.LengthSquared();

        float NodeAngularArea = CurrentNode.GetWidthSquared() / ParticleToNodeVector.LengthSquared();

        //Compare the approximate angular area of the node to the desired Precision. Subdivide if the 
        //A) the node has children and can be subdivided and B) The node's angular area is bigger than desired
        bool ShouldSubdivide = NodeAngularArea > Precision && CurrentNode.HasChildren();

        if (!ShouldSubdivide)
        {
            //Accumulate this node's gravitational pull into the total
            TotalGravity += CurrentNode.GetDensity() * GravityCoef * ParticleToNodeVector.Normalize();
        }
        else
        {
            //Visit all 8 children of this node next
            NodeStack.PushChildren();
        }
    }

    return TotalGravity;
}

Not too bad, right? The value "Precision" is basically the angular area of a node below which, that node will not be subdivided. We tuned Precision so that gravity feels great, but computations are minimal and each particle visits only ~50 nodes to compute its gravity.

One last thing to note: Even though we only visit ~50 nodes to compute the local gravity, each particle visits a different set of nodes. Also, each and every voxel down to the tiniest spec across the world will still contribute to the local gravity calculation. This is because that tiny voxel has had an effect on both the Density and CenterOfMass of its parent nodes going back up the tree.

I hope you found this interesting!

You can vote for Gravity Architect on the the LDJam site here:

https://ldjam.com/events/ludum-dare/38/gravity-architect

Download and play it (Vive, Oculus, and Daydream only) here:

https://nathansculptrvr.itch.io/gravity-architect

Thanks for reading!

-Nathan

Game jams is not a best place to show your OOP patterns knowledge. And well, code written on LD has no chance to win «Best Architecture Ever» award. Just look at this God-object class of our Protolife game:

Class with ~1K lines and 26 dependencies? I would have a serious talk with myself about this code.

But good practices still make life easier even if they take longer. This is how we decided to define our micro-buildings. Here is a simple turret:

More powerful turret:

«d» means «blue block», «e» means «yellow block», capitalized letter means «anchor point», e.g. turret muzzle.

Yeah, hardcoding all the coords would be much simpler, but this pattern system allowed us to quickly add new buildings – as fast as we invented them. This part would be first candidate for DRYing – so we DRYed it.

Do you guys use the best practices in your code? SOLID? GRASP? Unit tests?

Tags: ooc, programming, Solid

Game jams is not a best place to show your OOP patterns knowledge. And well, code written on LD has no chance to win «Best Architecture Ever» award. Just look at this God-object class of our Protolife game:

Class with ~1K lines and 26 dependencies? I would have a serious talk with myself about this code.

But good practices still make life easier even if they take longer. This is how we decided to define our micro-buildings. Here is a simple turret:

More powerful turret:

«d» means «blue block», «e» means «yellow block», capitalized letter means «anchor point», e.g. turret muzzle.

Yeah, hardcoding all the coords would be much simpler, but this pattern system allowed us to quickly add new buildings - as fast as we invented them. This part would be first candidate for DRYing - so we DRYed it.

Thought i'd finally get round to writing the post-mortem for the game we developed during the dare. This will be my first time writing one of these, so be kind.

Our completed game page: https://ldjam.com/events/ludum-dare/38/the-room

Team

Our team for Ludum Dare was just me and @joshua-sellers , who are both programmers who studied at university together, and decided to eventually try one of these Ludum Dares. We had to use my little knowledge of Blender and Gimp for the models and art in the game, as we had no one with proper art experience.

Theme

When the theme was announced, we had a few ideas, some of them building up civilization on a small planet. We eventually settled on an escape room idea, because we both like escape rooms and puzzles, because its only one small room, we felt it fit our interpretation of the theme, and it seemed like something we could achieve.

Day one (Hope)

We started quite late in the day, around in the afternoon, mainly cos we are night owls. We made steady progress with a number of core systems in the game, such as the camera, interactions and inventory, as well as a complete whitebox and most of the models. We used Google Drive to save and share our project, but more about that later. We finished working on it around midnight and were really happy with out progress so far.

Day two (MIA)

The next day was unfortunate, as my teammate got caught up with real life stuff, so I was left on my own for about half the day. He made up for it though with hard work and good stuff. We made excellent progress this day, however, getting the inventory and puzzle flow working nicely and completing our first puzzle, the safe. There was some tension though, as we had disagreements on the best way to code something, which, I suppose, comes with the panic and stress of making a game in a short time.

Progress after day 2

Day three (Cutting it close)

So the last day, we tried our hardest to make everything work right, complete any of the unfinished puzzles and add the finishing touches, such as UI art, sounds and menus. It was tense, as both Google Drive caused problems and the LDJam site going kaput. We eventually submitted our game about 1 hour 30 mins before the deadline.

Finished

In the end both of us were really happy with the finished project, and our friendship remains intact, happy days. We learnt a lot from this experience, and hope to continue working on the game and make it into a full experience. A few of the puzzles were cut from the final release, as we just ran out of time to add them. What did we learn from this? Mainly this:

USE PROPER SOURCE CONTROL

Google Drive was a nightmare to use, it kept syncing different versions of our game, and overwriting some but not all the work at varying intervals. We ended up splitting the work into 2 separate projects, but even that brought issues when adding one persons work to another project.

Second thing we learnt is maybe spend a bit more time designing the code structure. I am mostly to blame for all the hard coded scripts in the game, just to get everything calling each other within the time frame. I can't wait to get back into the code and refactor it all into neat functions and scripts.

Working with @joshua-sellers really helped this dare though, as it kept my motivation and focus and made the whole experience fun. I gave an earlier LD ago before, but I gave up after the first day cos it wasn't fun and was just stressful alone. Kudos to all Compo entries and solo Jamists for your dedication. Maybe i'll do Compo eventually, but Jams are fun with friends.

While I could ramble on for another 4535 or something characters, I shall end this here. I hope you'll check out our game, be kind, because we are two new programmers and this is our first time doing something like this.

Hope everyone had a good Ludum Dare!!!!

Also a question to those Ludum Dare Veterans, what are the rules concerning bug fixing after submission? The page on this website say its ok if the problem wasn't working correctly on upload, but there is a major bug in our game which could make it impossible to finish the game, which I only found today. I'm scared of updating the drive files and gamejolt now, with the bug fix, in case it disqualifies the game. Thoughts?

So my game had a huge BUG that broke the entire game but I just fixed it all!!! So if you tried it or want to try it check out the new version !!! ALSO, POST YOUR GAMES IN THE COMMENTS I CHECK A LOT OF THEM!!!!

my Game

https://ldjam.com/events/ludum-dare/38/giant-1

I've seen many postmortems already. Do I need to imitate them and make one for my game?

After some tinkering with the Unity Post-Processing Stack I was able to get a working WebGL version of the game! It only works properly in full-screen mode (due to what is seemingly a bug in Unity's WebGL export). I've also released two patches to the standalone versions fixing most of the major bugs I've found so far.

Check it out at the Game Page.

Ever wanted to imagine about small worlds? In Caelium Alpha, you can build an orrery of the planetary system of your dreams.

Please note that the current build of the game has a strange bug where many planets will get plopped at once and cause strange, but cool formations. I intend to fix this in a post-LD version of the game. I’ll also try to add the ability to plop moons, which is not currently available. Thanks for your patience.

Play Caelium Alpha

(This is a cross-post from my site to share with more ludumites)

I took part in Ludum Dare 38, the theme was "A Small World". I was coaxed into it by an internet friend, and came up with a technically compelling idea. You can play it for free on itch here and the LDJam page is here.

Digital Backwater was a mad dash from conception to completion and I enjoyed every minute.

This is a quick postmortem of what happened before I get swept away by work again.

The Idea

The leftovers of digital interactions are all around us: abandoned forums, dwindling chat rooms, folders hiding forgotten in the corner of your desktop, old embarassing comments on social media. I'm intrigued by this phenomenon and wanted to explore it a little.

The idea was to have a persistent, synchronised world between players, and give the players tools to mess it up. The hope was to build a system that would accumulate "detritus" at an accelerated rate, but somehow keep the scope small enough to finish in a day, which was all the time left in the game jam.

What Went Right

• Concept to Implementation

  The idea sort of just "came together" - there were no really significant hitches getting it working. The biggest task was actually the typing input and getting that into the tilemap in a way that didn't suck.

  For reference, the whole project was done in less than 24 hours clock time, maybe 10 hours work time.

• Player interaction

  Players just kind of picked it up and ran with it. I quickly got requests to add more glyphs (there was only the alphabet initially). One guy wanted to write his name everywhere. Lots of people like messing the blocks up, a few like putting them back in order. Chat "feels" physical when you're moving around, but because of space constraints, conversations (from what I've seen so far, anyway) are brief.

• Persistence

  Using firebase for the persistence "just worked", for the most part. Once I had the data model sorted out, I was honestly surprised how smoothly it went. I'm not saying that there weren't hiccups, but multiplayer is rarely simple.

What Went Wrong

• No Sound

  I ran out of time, plain and simple. Unfortunate as it kinda does take away from the immersion, but this does seem to matter a little less for web games? I'd love there to be some beeping and clicking though, and maybe a little quiet melody as you (and others) move around.

• Database Design and The Usual Networking Issues

  Firebase has preferred ways of doing things that I hadn't quite thought through before diving in. There's still a few problems that cause issues like block duplication/deletion and in general any shared data seems pretty dangerous. As with any shared concurrent data, race conditions abound.

Firebase

For the synchronisation and persistence, I used libraries from Google's Firebase project.

At it's core, Firebase is a collection of libraries to handle a lot of the "baseline" stuff an app needs (web, mobile and I think desktop too?). They offer analytics, authentication, cloud storage, crash reporting, a nosql database and quite a lot more by the look of it.

I was only interested in the authentication and database, so they're the only things I touched this time around.

The only authentication system I used was the anonymous authentication - basically upon connecting, a user gets a unique ID to use for their session and that's tied to all their database access, can be used for access control and so on. From what I can tell Firebase also has a whole host of other authentication systems built in, which is nice if you're into that.

The database is a json-based nosql "realtime database", which basically means the client keeps a hold of a copy of relevant data and syncs changes to and from the server. There's a few different ways to access that data but because of the local copy, reads and writes don't always have to hit the server straight away, and it will apparently try to reconnect and resync changes if the connection is broken and re-established, working off local data in the meantime.

This isn't so great for real-time stuff but I imagine it's very useful for "normal" apps, and it'd suit less dynamic backend stuff for games too.

That said, I used it for everything - from player movements to the world state. This meant that there was no server to write on my end and let me get the multiplayer code done in a morning. It's somewhat an abuse of their system and I doubt it'd scale super big, but it worked surprisingly well for a jam game :)

That said, it's no magic bullet.

• The player movement stuff is a little jittery as it is, and the game only has tile-level movement. Looks like it'd be very choppy for high fidelity stuff.

• This kind of thing is pretty much client-authority by nature. Unless you put something between the browser and firebase (which imo would hurt the convenience of firebase) you've got to keep that in mind. I didn't pay enough attention to that particularly when implementing the map modification, and as a result there's "fun" bugs like duplicating blocks when more than one player is involved.

  That said, you can build validation logic into your database to curb particularly egregious cheating. Anything that would benefit from to direct programatic access the game state at large is going to be better suited to a more traditional server though.

• Your data is live and fragile, and you can't (or I couldn't find a way to) disconnect clients. That means you probably want to look into adding versioning to your data model where appropriate - handling migration/"upgrade" of persistent data between versions might be tricky.

• A small stumbling point was that the anonymous authentication can give the same ID to someone if they join in a short window from the same address. I ended up with a user syncing to the same user record from multiple sessions, which consumed a lot of needless bandwidth and caused awful flickering. Basically, you probably don't want to use the user ID as a key for session-specific data.

Thoughts for the future

I've actually been thinking of building a similar system of synchronisation and messaging for web apps - not for persistent data, but for soft-real time stuff. As firebase doesn't seem to handle real time stuff very well (or at least, not very cheaply), maybe those two systems could work in harmony nicely?

Ever wanted to imagine about small worlds? In Caelium Alpha, you can build an orrery of the planetary system of your dreams.

Please note that the current build of the game has a strange bug where many planets will get plopped at once and cause strange, but cool formations. I intend to fix this in a post-LD version of the game. I’ll also try to add the ability to plop moons, which is not currently available. Thanks for your patience.

Play Caelium Alpha

Hey, I'll make this brief in case if this was explained already:

If I posted my game but want to make a few changes on the published game-page, can I edit the page without being disqualified from the voting round?

Thanks!

Bugs fix and added a online score ranking to the default ranking. Play and comment! :D

https://ldjam.com/events/ludum-dare/38/limited-space

http://doppelgunner.blogspot.com/2017/04/ld38-postmortem-lottery-you-judge-them.html

After some good resting and rendering the timelapse some 3 times (because of dumb reasons), I'm finally ready to write the post mortem for my latest entry, It's a Small World.

Usually, I try to write about my jam in chronological order, but I it always feels "without a point". This time, I'll try to write about relevant things that worked (or didn't) for me, choices that were good and bad... The kind of stuff that I feel a post mortem should be about.

Timelapse

If you want a better look on how my game was made, you may watch my timelapse!

I took a picture every two seconds, which summed up to almost twenty one hours of recorded footage into just ten short minutes.

https://www.youtube.com/watch?v=macOZQo9QfY

I didn't record the first "few" hours, during which I was only planning the game. I would also stop recording whenever I left the computer. So I definitely used way more than only those twenty one hours... Only with stuff that wasn't interesting to record.

Tools and tech

First thing first. I like to brag about this, so... Bear with me.

Once again, I used my tools to make my entry. I have a (not so) small framework written in C that handles some common stuff (rebind-able stuff, loading/rendering assets, some physics, tilemap etc) that uses SDL2 to detect events and manage the window. I also have a small "music synthesizer" (or tracker, if you must call it that), that parses a MML-like language into a chiptune-ish sound.

Usually I try to use it in a "optimized" way. Therefore, I try to use as little memory as possible, write neat and (arguably) fast code... The kind of stuff that you should only care about before releasing a game or if you have the time. For a jam game, I shouldn't care about those stuff.

That's why I'm proud to say that this time my game seems to need around 40 MB of memory to run! Instead of over-optimizing, I did everything the simplest way that I could think of. Instead of bothering about reading things from a file only when needed, I load the entire game before starting it and that's it! I also alloc a predefined amount of memory for every "sub-scene", no matter how many or how many of it would be used.

All of that helped my in being faster at using my own tools... Which had been an issue for quite some time, now!

So, tl;dr: It's a game jam! Get things done FAST! Optimize when and if you have time.

Theme

I don't really like repeated themes. But when I think that LD#23, which theme was "Tiny World", was 5 years ago... Yeah, maybe it's time to let them row again...

I actually had some trouble having the initial idea. Most of the stuff I thought about didn't really "shine" for me, and I wasn't sure how to implement the only idea that I did like.

After thinking a lot, I came up with a way to use it. Since it was based on creating small stories within the game, it was also quite easy to limit the scope if needed: I simply wouldn't add more stories if time were short.

Planning

There are usually at least two mistakes to be made here: planning too much and planning too little.

This time, I decided to try and err for the excess. I spent the first 4-5 hours only planning the game. Since I had the idea of doing something that wasn't gameplay oriented, I didn't have to worry too much about getting a prototype done quickly. However, I really needed to know how it would play out, and if it would be actually feasible...

After all that time, I had a pretty good image of what the game was going to be and some rough ideas of how stuff could be implemented... I also used that time to mentally plan how the scope could be reduced if I ran out of time, which did happen!

Even though I had drawn sprites for more interactions, I decided to dump those in favor of polishing the little experience that I was building. I started actually adding the content that I had drawn/planned for the game around 4 hours before the end of the compo. That's the time that seemed necessary to add content and write the songs for the game.

Luckily it all worked out, but I only because I decided to drop stuff (and because I knew what to cut out).

tl;dr: Beware planning too much! Plan enough to be able to get through most of the jam without having to re-think the idea. Also, if possible, try to always know what can be cut if needed (and implemented that last).

Assets

I was able to draw an acceptable sprite in around 20 minutes, which I'm pretty proud of! However, I learned (was reminded, actually) that drawing is way harder than I remembered...

Usually, I impose pretty harsh contraints on my art. I only use a 32 colors palette, my sprites have to be small and fit within a power of two size, I try to avoid using lots of colors per sprite, sprites shouldn't have outlines... Those are fun stuff that may help you find creativity, but it can backfire.

This time, I didn't care that much about the size restriction, about outlining stuff nor about colors (though I did use that palette!). This helped me in drawing the environment, in making the sprites somewhat readable, and led to the fun fact that all hitboxes are somewhat displaced from their actual sprites.

But drawing an OK background is still too hard. I got pratice that more. Also, I have to learn to only do the most basic assets for the prototype/engine development.

tl;dr: Screw roofs! They are too damn hard to draw! (and background, in general)

The engine

I spent most of my time implementing the engine. I only had it somewhat finished and started to draw the final version of the tilemap 10 hours before the end of the compo.

I honestly don't know what to take from this. It kinda worked out, but I should try to make stuff simpler (so I may implement them more quickly).

I must say that I ran into few weird/funny bugs. It was almost smooth sailing... Except for that one time that I passed a pointer's address instead of its value. Debugging that was really fun.

Audio

I added audio, once again! I literally did it on the last hour... and it came out almost OK.

I have to go back to planning it while creating the engine, so integrating audio into the game is quicker. But it was somewhat OK... I don't know...

That's all

I don't know what else to say... and I'm almost out of characters! So it seems like a good time to stop. :)

Thanks for reading all that!

This was my first Ludum Dare. I've been aware of the event for a long time and had planned to participate before, but this is the first time I followed through. I've been at kind of a personal and creative lull so far this year, so I was looking for something to awaken my passions and thought this might be it.

If you're not familiar with Ludum Dare it's a weekend game jam and competition that happens every 4 months on the internet. You are tasked with creating a game in either 48 (hard mode) or 72 hours that fits in (optionally) with a community selected theme. You can read the rules for more details.

This time the theme was 'A Small World'. I had a few general ideas including creating a game that took place on the Small World Disneyland ride, but eventually settled on the idea of becoming a giant that tries not to step on people in a small world. I thought that it would be simple enough to do in a couple of days, kinda funny, and that it could have an interesting control mechanic with draggable feet.

Here is a link to the game:

No Step On Hyoomins @ Itch.io

I also recorded a time lapse video of the creation process. Doing that or something like a live stream is pretty common for these game jams:

https://www.youtube.com/watch?v=ZYQxab8NXqo

Another thing that is pretty common is writing post mortem that talks about what went right and what went wrong, and that's what you're reading now! One of the great things about the videos and post mortems is that they're educational to newcomers. I looked over a few of them myself before signing up for this now, and now I'm happy to add my experiences to the available pool.

# What Went Right:

1. Using PhaserJS

I am a web developer who uses JavaScript every day for work stuff, so I thought I'd be better using a language I know well. Last year I saw a fun talk by Rachel White about PhaserJS and really wanted to use it for something.

Phaser made a lot of things a breeze. The built in support for various file formats for things like sprite sheets, bitmapped fonts, tilemaps and more made it super easy to cobble things together quickly. The community support and docs were top notch. The drag and drop and interactions work on both mobile and desktop flawlessly. The scale manager and game states are amazing.

Maybe some of these things are pretty standard in modern game frameworks, but I really appreciate them! I've only written games years and years ago (Basic, Pascal, C) when things seemed much harder and any frameworks that existed were much more limited in scope. Even if these features are standard, I think they are executed very well and in an easy to understand manner in Phaser.

2. Using phaser-node-kit

One of the most painful aspects of JavaScript web development is setting up toolchains. You can develop a Phaser app just using a text editor and phaser.min.js, but you'll have to include each file in your HTML individually and worry about things like namespacing and order of dependencies if you're writing client side JS code.

We tend to use collections of tools to get rid of some of these limitations by using things webpack that allow us to require files and modules and pack them into a couple of optimized script files, but they are a pain to set up. I found a package on NPM called phaser-node-kit that did a great job setting up a boilerplate project and coupled it with browserify and a local web server to make local development a breeze with no dependency issues. Note: a local web server is required for running phaser games because of cross origin security policies.

3. Cramming before the jam

I felt a little unprepared going into the jam since I haven't done much game development, so I spent a few evenings of the week leading up to the jam studying various topics.

I started by reading Game Jam Survival Guide, which I got a free copy of years ago as part of some promotion. It was still sitting in my Packt account waiting for me. This gave me a few good pointers and a better idea of what to expect. A few things I took to heart:

• Reducing scope to fit available time and keeping things simple
• Thinking out of the box with the theme / using a thesaurus etc. for various interpretations of the words
• Not worrying about elegant code and using hacks to get things working
• Optimizing for fun in the first 15 seconds of game play since that's how much most people spend
• Funny or "Joke" games tend to do well

I also went through the HTML5 Game Development with Phaser tutorial on Lynda to get up to speed on the framework. It was pretty helpful beyond the documentation to see how a full game goes together. I didn't write much code before the actual jam, but after watching this tutorial I had a mental palette what was available and how to accomplish certain things.

I also spent some time downloading and familiarizing myself with various asset creation tools. I looked at Tiled, Texture Packer, ASEprite, Pyxel and Spriter. I mostly watched video tutorials and made sure I understood the basics of how each tool worked just in case I needed them for the jam. I ended up using Tiled, Texture Packer, and ASESprite to set up a map, create a sprite sheet, and create animations.

I was really inspired by the tutorials for Spriter and totally into the way the animation tools work! I didn't get to use it this time, but I'll be looking for an excuse. I used to do a little bit of Flash development, so the process was pretty familiar to me and it looks like it makes animating a lot more fun by moving limbs around rather than redrawing entire sprites as one would with ASEprite.

4. Not working 24/7 on this

In total I spent about 12 hours working on this game out of the 72 or so available for the jam. I didn't stay up too late at night, though I had a small cache of sugar free red bull just in case it came to that. I got off to a good start on Friday night. On Saturday I had pretty much the whole day free with zero distractions, but I wasn't really feeling up to the task in the morning. I visited my parents for a bit instead. When I got back home, I had another fairly productive few hours in the evening. On Sunday, I went for a long hike with the family, then worked on the game for an hour or so before a weekly dinner with have with our whole family (my family, my sister's and my parents). After dinner when we got home and put the kids to bed, I was able to get most of the basic game mechanics completed.

I took part of my normal work day on Monday to put some finishing touches on the game including titles, sound, music and packaging.

When it was done, I felt pretty good about what I had accomplished. I wasn't feeling burned out or exhausted and I didn't feel guilty about shutting out my family during the family because I hadn't (too much). I could have probably come up with a much more impressive game if I had put more time into it, but this was a good compromise for me.

..continued in Part 2

..continued from Part 1

5. Hacky collision fixing + hacky things in general

I had a lot of trouble with collision detection since the two shoes I used were pretty oddly shaped and had some transparent areas that detected as false hits. As far as I know, the basic arcade physics mode in Phaser only supports a single collider per sprite that is either a rectangle or a circle. Neither of those worked too well for my long and oddly curved shoe sprites. I was hoping to find a pixel perfect collider or a good solution to the problem but I couldn't find one.

There is a P2 physics mode that uses more advanced polygon colliders, but I didn't want to sink more time into learning it and possibly breaking something else after already sinking quite a bit of time into research and trying out things that didn't work. I ended up writing a really dirty secondary collision filter to reject collisions based on a bunch of x,y coordinates and a switch statement. Probably spent 2 hours on this problem alone, but the quick hacky solution took about 15 minutes more and solved the problem to "just about good enough" level.

There were other places where I saved some time by using kind of sloppy coding practices such as attaching arbitrary properties to sprites to keep track of things - things that I wouldn't let myself do for normal production code but I allowed myself to do because game jam! It kinda felt good in the way that getting away with something harmless but a little naughty feels good. It was a little cathartic too.

6. Passions Awakened

Probably the biggest thing that went right is that now I'm excited about making another game in the future and learning new game systems like Unity. This is easily the biggest win for me!

# What Went Wrong:

1. Wanting to make my own assets

One of the rules of the 48 hour compo that is not part of the 72 hour game jam is that you have to create all your own assets instead of just using freely available ones. I had originally hoped I'd be able to create all my own assets, but in the end it would have been just too time consuming. I think the first few I picked up, I was hoping to use as placeholders and then replace eventually but there wasn't time to do that! Maybe in an even simpler future game, or if I get more proficient at graphics work.

2. Not including buildings

I originally wanted to create buildings hazards and things you had to avoid stomping on, but I wasn't able to get that done. I was thinking about using a tileset with buildings, but I couldn't find a set I really liked. I would also have had to implement collision detection with specific tiles and add destructive terrain. All this would have taken a lot more time.

In the end, I found a kind of simple flat 2D tile set from James Arndt that featured some streets and grass. I did a little bit of image processing and rotation to get them into a Tiled compatible format. Since they were so simple, it was pretty easy to spend a few minutes laying out a very, very basic map.

I thought I could add some buildings later on, but didn't have the chance. I decided to just leave it as is and concentrate on the mechanic of avoiding tiny humans. However, since there were no other obstacles, I had to greatly inflate the number of random people wandering around on the map.

I kind of wish I had spent a little more time laying out the map and making it look more like a city. I also wish that I had added a few more buildings and things so it wasn't just an empty lot with a bunch of people wandering aimlessly!

3. Kind of a gross feeling game

I originally wanted to make this kind of a friendly and funny game. The original working title was 'Gentle Giant' and the point is to NOT step on people. My original mental pitch described it as sort of a reverse 'Rampage' where you try not to destroy stuff.

I think it didn't dawn on me that I needed to have something happen visually when you stepped on people in the early stages. I ended using the blood pool because it was a strong visual indicator that something bad had happened. Later, when I was debugging collision detection, I wanted to make sure the blood pools were spawning in the same places as where the people sprites were getting stepped on, I 'froze' the people sprites in place instead of removing them from the game. I kinda liked the way that looked, so I decided to leave 'bodies' in. Finally I wanted a font to match the game a bit and I ended up going with a drippy bitmap font.

When I got to the end of everything, I took a step back and looked at it and though "this doesn't feel good to me at all". I think there's certainly a place for kind of gorey stuff in videos games, but it's not necessarily the kind of game I wanted to make. Hopefully some people find it a little funny, but I'm also sorry if you tried it and it was an unpleasant experience for you.

My next game will probably have more puppies and kittens.

Gives me time to playtest and fix all the bugs! And oh boy do I always end up with a lot of bugs... :cold_sweat:

My entry Rogue Basement had a low frame rate and high CPU usage at launch. I took a little bit of time to optimize it so it would run better. (This is within the rules; it doesn't change gameplay at all.)

So now your basement delving sessions will be a lot more responsive! And you can make the window nice and big without a huge performance penalty, even though the home screen warns you about it.

Hi all, this is my first game jam and my second game I've ever "released". I had a blast doing this and I'm more inspired to work on my long time projects after this!

The game itself is just a small, slightly wonky endless physics based bullet hell game. I made everything except the font that is used in the game. It is a quick game and you'll get everything you really need to know on one play through.

Give it a try if you wish! Download https://darrell-wulff.itch.io/earth-moon-smash-sqaudron

I used ldjam.com's API to download all the game infos (after asking Mike!) and did some text searches. This is a list of every game that claims to be a roguelike. I haven't played them myself yet.

If you want to see any more lists, let me know! Or clone the source yourself and run queries of your own.

Compo

• Echo Lands
• DIMPOCK
• Rogue Basement
• Train World
• Tiny Dungeon
• Dungeon World
• Spaceworm

Jam

• Roguelike One
• A small tower
• Rogue of Worlds
• 6-Sided Sojourn

To make playing our game easier, we've put together a web build for the game that you can now play from your browser instead of having to download it first.

You can find it on itch.io here:

https://stuckinaliftstudios.itch.io/krabs-killer-robotic-aquatic-battle-shockers

I've did some new update for some of the poor experience part, wish the game can bring ya more impact though :)

*Link: * https://ldjam.com/events/ludum-dare/38/a-small-world-wide-web-the-day-since-i-was-trapped-in-china

Planet or Die! is now playable on any screen size, the game will adjust it's window size to be equal to your screen size which is calculated on game launch. Version with this implemented is 1.0.2.

https://ldjam.com/events/ludum-dare/38/planet-or-die

Game Description:

You are Stilles 33, the tiniest planet.

Scientists continually change their definitions as they refine their understand of the world. Pluto used to be a planet. Eris used to be a planet. Your classification as a planet is now at risk!

Use powerful rhetoric and all the best logical fallacies to outwit your opponent and convince an impartial academic crowd that you are actually a planet.

PS: If you are looking for a better way to search through games or want to play random games visit this google spreadsheet: https://docs.google.com/spreadsheets/d/1HWYo-es4weXRFnUBhKAUHX9rCodGiczvyIsWRkx9eoo/edit#gid=0

I would like to add a web build of my game to make it more accessible but i fear that it might be against the rules.

For anyone interested this is my game: https://ldjam.com/events/ludum-dare/38/statera

Getting ready for voting? Mu ha ha!

Play it here: https://ldjam.com/events/ludum-dare/38/mf100-hack-the-jam!

Hi Everyone!

Just made a quick update to fix some bugs and errors in game I hadnt been able to address earlier in the week. - Fixed a collision detection issue - Fixed an animator functioning bug

Thanks all enjoy my game, I appreciate all the feedback you guys sling my way in rating time.

Cheers

Hi, great people.

Thanks for all those great entries. I really like Ludum Dare and its games. I have participated in the last 4 jams and this is so inspiring for me as well as every game developer out there. When the judging time, I really want to play as many games as possible, however, this installing and uninstalling get quite boring.

Well, this is quite normal I guess but I am wondering why Unity developers don't build the game for the web? The web build actually minimizes the effort to reach your game by people and I think this also encourages the players to play your game more than the other downloadable forms. When there is a very convenient option like this, why don't you use it?

Here is the web build for my game. https://itch.io/embed-upload/457855?color=222034

It was my first game jam and I'm pretty happy with the results

Hello, I would like to go through the games more systemaltically. The problem is, that in the "games" part of the website, the games appear in no particular order, nor can I sort them or remember where I was last (like "I checked the first 30 games, time for break, later I can go from there and continue"). Is there somewhere a hidden function for this and I am just blind?

So I fixed some issues with the art and finally, the mouse tracking issue fixed! I was surprised as to how simple it was to fix! I thought that it would take much longer.

Anyways I will keep asking for more games So I can see as many games as possible! I planning this week to play them all!!!

For the new version go to https://ldjam.com/events/ludum-dare/38/giant-1

What's your gamedev background?

I'm a professional junior software developer, and I'm two thirds of the way through a part-time game design degree. I've done global game jam for the past five years, but this was my first Ludum Dare. I worked with two other students on my course who did the artwork and music.

What game did you make?

I made K.R.A.B.S. (https://ldjam.com/events/ludum-dare/38/k-r-a-b-s) A local multiplayer fast paced action game in which you play as a robot hermit crab battling to collect the most resources before time runs out.

How did you come up with the concept and did you stick to it throughout the jam?

Honestly we spent far too many hours struggling to come up with an idea, finally settling on the idea of being a small creature trying to grow bigger and not be eaten. We quickly switched to making it local multiplayer. I don't question where my team's artists come up with their designs, I want to retain the little sanity I have remaining.

What was most challenging about the jam?

This jam went surprisingly smoothly, the only thing we had trouble with was getting the game playtested as it's a local multiplayer game and we spent most of the weekend working from our respective homes alone.

What was most enjoyable about the jam?

Getting into the flow of development is always incredibly rewarding, and the satisfaction of trying out new things and seeing them work is the best feeling. I had enormous fun making the visual effects like the lightning and electric sparks by playing with the particle system. Learning about unity's image post processing was also something I'll take away from this experience.

Are you satisfied with how things went?

Very. Global game jam always leaves me feeling exhausted and I've not always been happy with the games I've made at the end of it. I guess the extra day for Ludum Dare prevented that, and by keeping what we made simple, I wasn't fighting bugs in the final hours. There are of course things about the game I will probably go back to and improve, most notably the instructions screen, the game needs an options menu and a way to track scores over multiple rounds, as this ended up beyond the scope of what the time we had would allow.

What, if anything, would you do differently?

I would take the Monday off from work, trying to concentrate on my job while my mind wanted to focus on finishing a game wasn't productive for either task. Coming up with a concept sooner would probably be beneficial too.

Fun story: I originally recorded a frame for the timelapse every second, so I ended up with over 100,000 frames, taking up about 15GB of space, and crashing every program that tried to do anything meaningful with them. :) I deleted 9 of every ten frames (I literally decimated them!) and then I made the timelapse.

https://www.youtube.com/watch?v=pPh_Qj5URBw

You can play the game too. :)

https://ldjam.com/events/ludum-dare/38/for-a-small-world-this-place-sure-has-big-problems

Sorry for any error in this post but English is not my first language. I'm trying to express and share my experience as best as I could. If you'd like to read the original version, please visit my blog (Chinese)

4/24/2017, 16:23.

I get out of the bed, with my neck and left shoulder hurting like hell. The vomiting has gone. It seems that the medicine I took is taking effect.

Five hours ago, I just won the battle against myself.

I knew the Ludum Dare last year. At the time seeing this competition, I was like striken by a thunderbolt, and decided to be a part of this next time when the event is held. So in Ludum Dare 38, I choose to participate in the Compo group. As a developer for about 10 years, I'm quite new to the game developing: I have been working in game companies for only a little over 2 years. I need this to know where my limit is and how capable I am. And, isn't it awesome to build a game in just 48 hours?

With these thoughts in mind, I started my FIRST Ludum Dare.

DAY 1, 4/22/2017

Working on the theme

The event started at 9:00 A.M. on Saturday in China. I didn't woke up until 9:40, because I needed enough energy to cope with the super tight schedule.

At the time I saw the theme, A Small World, I lost all the clues, thoughts and imagination immediately. The theme seemed not attractive at all: everyone today talks about how the internet makes the earth a small world; the earth is just a tiny tiny world in the whole universe; blah, blah, blah. Yeah, we have heard this all. How's this theme gonna be innovative.

I smoked for like 2 cigarettes, cooled my head down, and tried to interpret this phrase from another angle of view when my cat came and meowed at me. Looking at her pretty face, I had something in mind at once. Yes, my home is the whole world of my cat 'Doggie', and it is small! A Small World!

So I made this plan up as soon as I could: My cat, 'Doggie', is trying to be the ruler of the world. Not by violence but collecting all treasure in the world and hiding them in her treasury. The stupid Human, which probably is me, will try to prevent Doggie from doing this. It's a story about the cat queen defeats the stupid human.

Prototype Making

I designed the game to be an RTT game with 45° top-down view, like Commandos, Desperados and Shadow Tactics. But my game is kind of different: the map is quite small (just with the size of my apartment); there is only one enemy (me); the cat can move vertically frequently in the scene due to her extraordinary jumping ability.

I spent about two hours working out character control and NavMesh setup. I rarely used the Unity's NavMesh before. For the projects in the company, my team chose the A* Project, a super powerful 3rd-party navigation library. But I thought it was too much for this small game. Anyway, LD is about learning new things and challenging myself, so I decided to learn Unity's NavMesh.

After the navigation was done, I implemented the enemy's modules of sight sweeping, target searching, state switching, and the cat's module of collection treasure and hiding it in treasury.

By then the game had already with a rough shape. I planned to put the detail adjustments in the final few hours. The clock read the time for dinner, and I had worked for about 7 hours. The progress looked quite optimistic. I put a short video of the prototype on YouTube, and blogged for my progress.

After dinner, I started to put some bits and pieces into my game, such as the tooltips with mouse hovering on interactive objects, jump controlling on OffMesh points, etc. I tested and refactored my code as well.

Back to Reality

Everything looked perfectly until I met the first real trouble caused by myself.

In the very beginning of my design, the enemy's behavior was rather simple: patrolling, looking for the cat, staring, and chasing. It was a linear process, and several if ... else could get it done. However, when I tried to add a new behavior, "listen to the cat's meowing and go investigate", the old 'system' was corrupted and unable to develop at all, as the new behavior was too complicated for it. Even more, the old AI system was neither flexible nor extensible. I had to admit my design was like a pile of sh*t.

Struggling with all kinds of thought and fatigue, I decided to re-implement the whole AI system before going to sleep.

I decided to use FSM for enemy's AI. By separating the decision-making and action-control, the logics became much more clear and controllable. The improvement in state managing and back tracing was satisfying as well.

The implementation of the new AI system finished at dawn, around 5:00 A.M. The sun was rising. I wrote down a blog for my first day's progress, set my alarm, and lost my consciousness as soon as hitting the bed.

(To Be Continued) Part 2

And here is my game; I do hope you can try it out and leave me some comments and thoughts! https://ldjam.com/events/ludum-dare/38/this-world-of-mine

Sorry for any error in this post but English is not my first language. I'm trying to express and share my experience as best as I could. If you'd like to read the original version, please visit my blog (Chinese)

Part 1 is here

DAY 2, 4/23/2017

I opened my eyes after a dozen times of alarm rings. It was 10:00 A.M. 5 hours of sleeping recovered my energy, and there was another hard working day ahead.

Building the world

As I finished the core gameplay part last night, I started building the world as first priority.

Considering my poorly trained 3D modelling skill, I gave up the thought of building the world with Blender, and chose Qubicle Voxel Editor, a voxel art editor which I bought months ago but never installed on Steam, for modelling the furnitures and characters of my game. I know some skills of drawing pixel arts, I can handle it, and voxel art fits perfectly for indie games. Perfect choice!

The game scene is based on my apartment in real life. For a nice and clean game scene, I removed the kitchen and toilet. Modelling, exporting, refining textures, placing in the scene...the game scene looked better and better as furnitures were created one by one. Looking at what I had built, a huge satisfacation embraced me. I just realized this is why I threw myself into making games, and the best interpretion, for me, of the theme A Small World.

I got more and more skilled in modelling voxel items. I started to making the treasures (socks, cat toys, smartphones..) and the super star: Doggie. 'These are just like moasic masks in porn videos.' My fiancee laughed at me. I still love my works.

I planned to make Blender for IK animations for Doggie, but I had no time to learn how to do it anymore. At last I abandoned Doggie's limbs, and made her a slime-like creature jumping around.

It was over mid-night already. It tooks me 5 hours for modelling, and 2 more hours for animation. I also coded something during the art works for rest, including adding hideouts in my voxel apartment.

I hadn't designed the level. My game had no UI or instructions by then, and was not tested. I knew I had to work the whole night to meet the deadline.

Vomit and race against time

I'm not sure if I ate something poisonous, or it was all because of stress. I started to vomit and trapped in the toilet. After eating six pills, I asked for a day off with my company's team leader.

In the darkness, my lamp and the LED screen was like beacons on the night sea. I kept working on the final parts of my game in non-stop. I wanted to record a Meow from my dearest Doggie, but she refused to make a single sound no matter how I teased her. This little btch must understood my language. Desperately, I mocked and recorded the *Meow myself, when I found my throat hurt so much to barely say a word.

Glimmer broke throught the curtains, and I finally came to the ending part. I'm not really satisfied with my work so far: the connection between jump animation and cat movement was not very smooth; the UI was ugly; the sight detection of human was rather inaccurate; the collsions behaved awfully sometimes; and I should have chosen a better way controlling the camera... But It was 7:00 A.M in the morning - 2 hours before deadline. Not only it was too tired to make any large adjustments, but the time also not allowed. I had to give up many designes. Even the human's model (which I forgot to do it totally) is a capsule.

The clock kept ticking. I felt myself was crawling in mud, with a tank behind me, rolling to me slowly. Sometimes I just made a litter bug-fix or adjustment, and twenty minutes aleady passed.

In 8:59 A.M. I submitted all my works.

Last Hour!

I went for packing my game in WebGL, making people easier for playing. But when the package came out I was quite frustrated: the scene was poorly rendered. The environment light was so dim that players can barely see the details. My best guess was the light map was poorly set. So I went back to the editor, adjusted parameters, and packed the game again and again like crazy. Luckily, I got the intended result.

The rendering job took me about half an hour, and there was only 30 minutes left. I prayed for my network being good, and submitted my entry.

My should hurt, eyes heavy. But I made a game in 48 hours! FOR THE FIRST TIME!

Lessons

Ludum Dare exposes my short barrel board: I'm lack of knowledge in so many techniques, and I overestimated my capability. Before this, I was always lazy, not trying to know every aspect of a certain techique, skill or practice. Such bad attitude almost made my Compo challenge failed.

Ludum Dare makes me learnt and improved as well. I realized that,

Never underestimate your limits. Always with a heart of eagerness and fearlessness. You never know what awaits you. All you can do is to advance, even if you can't see through the mist.

And there are some more of my thoughts:

• Do not try to make a commercial game, which is unrealistic. Ludum Dare wants what is nice and small.
• Knowing my effectiveness. Try to make a rough schedule before start, and arrange time and energy properly.
• It is so difficult if trying to learn everything in Ludum Dare, which I should've learnt in normal days.
• Do whatever I'm capable of. I'm not trying to make a science study here.
• In emergency some code can be ugly. But try to refactor the code often (I did it after finishing each module). It will save life when something goes wrong.

If you've read all the way down here, please accept my sincere appreciation and biggest thanks! English is not my first language, so there might be errors in the article. And here is my game; I do hope you can try it out and leave me some comments and thoughts!

https://ldjam.com/events/ludum-dare/38/this-world-of-mine

It’s our first time we took part in a Ludum Dare ever. We were kinda prepared for it by doing weekly meetings. Also many of us (6/7) were LD first timers. In foresight I already excuse my bad English since I’m not a native speaker.

Expectations/Reality

E: quick prototyping

R: quick development of single parts but sloppier merging than a pickled herring

E: coordinated balancing & debugging

R: testing like 4 year olds high on sugar (I COULD TEST THIS TOO!!! (hasn’t even finished the last test..)

E: non-frequent participants may interrupt the workflow

R: dependent on day/nighttime + general motivation (sorry guys for fooling around <3)

E: autonomous working

R: this actually worked pretty fine until a higher level of complexity hit most of us.. (we remained strong though, and gained back power after caring for our bodies )

E: doing a lot of playtesting

R: Error 404: playtesting not found.

Pros and Cons of our experience

Pros: - tons of new things, much learned - fun creating a game with joined efforts - did very good for our bodies - reached our aim (finish a complete playable game in 72h)

Cons: - aggressive tensions towards the end - too many people leading to too many ideas - people not knowing what to do - insufficient preparation Although we hate and love each other at the same time most of the cons root in the preparations and insufficient communication. So hopefully they will all be eliminated at our next Jam :)

This Jam We Learned (TJWL): - knowing your limits (workwise, conflict wise, limit wise etc.) - don’t take stressed induced comments to serious (seriously!) - a good team needs a leading force (not a dictator :D) - you can achieve much more in a team - leaving your comfort zone can be a great experience - lighting and effects are an art form and have to be assessed early on - the importance of game architecture - think through every design aspect of the game to the end - always pitching a game idea with a core game loop can be very helpful - animating is hard don’t do it if you cant - balancing takes time but it’s worth it -> we didn’t do it though..

All in all it was a great experience and we hope no bodies were harmed through the process of your developing too.

We love you, your bodies and our game : https://rac-games.itch.io/the-last-acorns

Another great Ludum Dare in the books (my 4th), and as always, it was a blast. While we wait for judging to begin, I figured it is a good time to work on this Post Mortem for the game I created, Contamination (https://ldjam.com/events/ludum-dare/38/$18772).

The theme was “A Small World”, and the idea for my game came much easier than I expected this time. After about 20 minutes putting together the idea, it was off to work. All my previous LDs were 2D, so I decided to give 3D a shot, and I think it works quite nice with this game. Man, Blender is a monster… I can get simple shapes done, but anything else will take me a very long time… time I don’t have in the Compo. Luckily, the models for this game are simple, and something I thought I can do in Blender so I went for it.

After some sleep, it was back to it on Saturday, and the day was spent putting together the game: enemy germ AI, green cell movement and splitting, player movement and fire. All game movement was done with a tweening library, not physics. I second-guessed that a few hours later when I could not really manage collisions since these were kinematic objects, but it did not become a problem since I decided I wanted all the game objects to be able to pass through each other (and used triggers instead), otherwise movement would become too cumbersome in such as small space.

Sunday was spent putting in the remaining game play: adding the Super Germ, tweaking the germ and cell spawning, etc. The afternoon was spent creating sounds and music, adding the HUD, and adding a title screen and instructions.

So, What Went Well?

• The idea came to me rather quickly, so I didn’t have to sweat it out. I also felt like this was a game I really wanted to develop. That kept me motivated throughout the Compo.

• The tweening library worked like a charm. What a time-saver.

• Even though the game has “simple” objects and effects, they did come out better than I expected. I was successful in creating 3D objects and particle effects.

What Could've Gone Better?

• I have to either get better at Blender, or find another tool. I don’t do art well, but working in Blender seems like I am fighting the tool, and not my lack of modelling skills. Yes, I get it, lots of keyboard shortcuts, but it is hard to work that way if you only get in there from time to time.

Please check out my game and let me know what you think.

Ludum Dare Entry https://ldjam.com/events/ludum-dare/38/$18772

Hello everybody. Like every year, I play many games from this Ludum Dare & this time, for Game Side Story (http://www.gamesidestory.com/), I want to stream these games & make a youtube video (with a montage) after. Right now, I have already played 40 random games in two videos of 2 hours. Youtube version, shorted, with no blank, will come soon.

Even if the Ludum Dare website is a mess (sorry guys, but the Games Page is horrible), I will try to play for a short time to some games and I will try to warn you when I make a livestream. I speak french, so the stream will be in french, but feel free to come when I'm online, to ask me to test your game on stream.

Livestream : https://www.twitch.tv/skywilly

Youtube channel : https://www.youtube.com/user/GameSideStory

Congratulations for all. I hope someone will stream my "game" just for fun. Inception !

Destruction Zone, my Compo Entry, was a fun little game to work on that surprisingly went with fewer hitches than I had anticipated. Here are the things that I took away from my Compo Entry.

The Theme

This was actually one of my bottom themes. When 9:00PM EDT rolled around I bellyached about the theme for a little bit, but ultimately an idea hit me. Since I couldn't think of something planet-based, I took "small world" in what I thought would be a fun direction -- you are a little drone on a collapsing space habitat, and your small world is what's left of the platform. I'm happy with how I adapted the idea in such a way as to make something usable.

What Went Well

Getting the concept implemented didn't take nearly as long, and wasn't nearly as difficult, as I had feared at the beginning of the Compo. I also feel like the enemy AI, while simple, works fairly well.

What Went Wrong

The amount of time I spent trying to get the Bomber to work properly, as happy as I am with the result, is way too long. I feel like there had to be a better way to go about programming it. Perhaps making a list of towers at the start of the game and having destroyed towers remove themselves from the list would have been a far better method than having the enemy's AI handle that content. I wouldn't have had to worry so much about its target invalidating, or its reaction if no more towers are left.

I really wish I had known about coding rebindable controls before I entered this event. The Compo version of the game has hardcoded WASD movement, and hadn't thought at the time that people that can't use WASD might struggle with the fixed controls. This had to be fixed as an optional post-compo version, but I'm happy to say that aside from rebindable inputs (including using left-stick on a controller to move, though you still have to aim and shoot with the mouse) the game runs exactly the same as the hard-coded WASD version.

The UI, especially its scaling, proved to be something that I didn't expect to have difficulty with. I apparently didn't set up the RectTransforms up properly for the title screen and status UI, and then went and changed my game's resolution while it was still scaled for a higher resolution (so that people with 720p monitors could still play). I really should have, rather than using the end of the compo participation time to get in early and ensure I didn't get hit by any snags, used that time to more thoroughly test the various builds under the lower resolution. Then maybe instead of having to post a critical bugfix after the fact I'd have actually had, as far as I'm aware, a relatively bug-free release.

Another thing that proved to be a problem was my inexperience with Unity. However, as it's the best I have for making games, it was either enter with an incomplete, novice understanding of the engine or not enter at all because I don't feel like GameMaker Studio fits my programming style, and don't feel like RPG Maker MV would have been a suitable engine for a compelling LD entry. My inexperience really is the thing that interfered with my progress the most all throughout the event with documentation look-ups and needing to make tiny iterations on some of the code to get the functionality working properly.

Lessons Learned

The biggest takeaway that I've gotten from this is some degree of confidence. I set a challenge before myself -- enter my first Ludum Dare under the compo and complete a game in the time limit -- and I knocked it down. While I'd have continued on with learning Unity and improving my skills regardless, the fact that I succeeded gives me some small level of vindication. As LD38 was approaching, I had a number of days where I was questioning my capabilities, and overall worthiness in entering. Not only did I succeed, but I proved myself wrong in the process. I can do this. I did do this. And this is the first real game I've made outside of the scope of the course I'm taking.

I'll definitely be entering more events to come. And next time I hope to do even better.

Timelapse

https://www.youtube.com/watch?v=J0ZuLaK2oNo

https://www.youtube.com/watch?v=1ilWTOb63Q4

*Game page : * http://mojogamejam.com/game/13/

We hastily assembled a YouTube channel so we can show you some gameplay footage of our ludum dare game Murder Mitosis. It is a game for up to 4 players, but we have invested way too much Jam time into developing AI players. So go play, even if you're on your own. :nerd:

https://www.youtube.com/watch?v=Xv7xLFa_K0s

As brand new YouTubers we also have to call on you to like and subscribe, I guess. :wink:

Play the game:

https://ldjam.com/events/ludum-dare/38/murder-mitosis

What is the game about?

In Beer in Mind, play as the bartender of a small pub located in a downtown suburbs. You will find soon enough that the world is not as big as it seems and that your customers have their own secrets.

This game is a point & click, all playable with your mouse.

=> Page entry

The original ideas

A few days after the submissions, we thought it would be interesting to share with you a bit of how we spent this 38th edition of the Ludum Dare at the PixelStuff team. We were 7 in our team for this edition, 2 designers, 4 developers, 1 sound designer.

The first day, we mainly gathered ideas and set up the whole gameplay mechanisms we wanted to make in an ideal world. This allowed us to choose where to cut functionnalities we could not fit in the 48 hours left. Our brainstorming highlighted that we were deeply interested in gameplay axed towards simulation and management games. We liked the idea of having a small place to manage for the player. At first, we thought of using the environment of a desert island, planet, ecosphere... and the idea of a bar came in.

We chose this one, it fitted the theme perfectly: a bar is a small world itself, with its own rules, its usual clients and its ressources (beer, tv, doritos...). We also liked the idea to put together a gameplay and the proverb "It's a small world".

The ideal version of Beer in Mind is a game where the player would have to manage his bar (ordering supplies like beers, changing music or tv programs according to the people in the pub, make money, ect...) and be the witness of storylines evolving within the bar. Groups of character would interact positively or negatively and you would have had to be sure those who didn't liked each other would not meet if you wanted to keep your bar safe, you would discover that some of them knew each others without knowing it... and many other ideas I can't list here.

48 hours left to make a game

Finally we kept a few interactions available and linked them to scenariis to provide a prototype of how your actions on the environment could affect the characters you're interacting within the bar.

We chose to keep at least:

• The idea of serving beers to clients,
• Being able to turn on/off the tv
• Calling a cab/the cops
• A few other elements only usable in some specific cases (no spoilers)

We put aside the idea of complexifying the gameplay by adding ressources management and money management and focused onto the scenario. It was a pretty challenging stuff to create and find a tool simple enough to allow the team to make quick edits to the scenario and adjusting the timings.

One of our developer adapted during the 24hours a nodal tool interface to edit datas we would export as a JSON file to change the scenariis deployed in the game. The whole thing is also completed by a random quotes generator created via a .CSV file.

The last hours were mainly dedicated to creating scenariis, implement them, testing them, correcting bug, creating the UI, the game overall looks and integrating them in Unity so that everything worked fine.

What we learned/What is the future?

We knew from the start we would not be able to add everything we thought of, which would have created a deepest experience of the game.

Today, Beer in Mind needs polishing on the clickable items, the timing of the scenarios, be more dynamic, have more player rewards in UI interactions, a more coherent graphic direction and a LOT of user testing to polish it.

But we're kinda happy with how it turned out. A bit disappointed too.

We had to do a lot of concessions into our original idea: from a management-simulation game with a red link scenario in the background, we ended up doing a point-and-click with advanced interactions onto objects and people.

The good point is that we are feeling within the team that there is a good game idea to dig and we will probably continue it after those 72hours, and even if the game we ended up with wasn't exactly what we wanted first, it was a pretty interesting prototype to make.

If you read all of that above, thank you for your time ❤️ You're awesome!

My submission for this Ludum Dare is named Make Me Beautiful. I have to thank Jupiter Hadley for the name.

This was not the first time I participated, but it has been a long time since I posted a playable build. This time I was happy with the result opposed to the last few times I never had a good enough result to share.

This build of Make Me Beautiful for Windows can be found at Itch.io.

https://smallgaming.itch.io/make-me-beautiful

What I should repeate nex time

I had enough knowledge of the used tools. The newest tool I used for this jam was Pyxel Edit. It is a great drawing tool for 2d graphics. I been using Pyxel Edit for the last few months on a lost most daily basis. Knowing the shortcuts and the functionality Pyxelf Edit has to offer increased the productivity. So redoing sprites took less time then when I was using Gimp. This resulted in short iteration loops.

I been using Unit since 2013. Learning to work with unit the way I want to work as a software engineer took many hours of prototyping. Wormhunter in April of 2014 for Ludum Dare was the turning point for rethinking how I must use Unity. MonoBehaviour does not offer a good structure to work as a software developer. My personal preferences is to add only 1 script on a prefab. In April of 2014 I started with thinking about a solid structure on top of Monobehaviour that satisfies my preferences. That structure has saddled now and I am happy how I work within Unity.

The scope of the project was just right. Often I just set the scope too big for Ludum Dare. This time I thought of a function I could reuse. The code for the creation of different elements of a planet was reused 5 times. The code is so modular I could easly plug in a new animation or element to create. Make Me Beautiful only has three (overall) types of states for the player: Idle, Moving and Creating. There were only 3 game states: start, game, result. There were any NPC to implement either. This to saved me a lot of time.

Balance between work and rest. I never had so much off time. I slept on the 1st day from 14:00 till 18:00 and on the 2nd day I went to a party during the day. I did had my laptop with me and I did some work. It was not nearly the amount of work I could have done when I would have stayed at home (and not eat cake, NEVER!).

Knowing what my limitations are. I can not make music and I am not the good pixelartist. During Ludum Dare I will not try to improve those skills either, outside Ludum Dare sure why not if I have the mindset for it. So I just except my limitations and make something with what I know and works for me.

What I can improve on

I did not have a complete vision of what Make Me Beautiful was. Until the end of day 1 I had no clear vision of the complete game loop. That's also one of the reason I could sleep during that day. Starting without a complete vision is risky because of the chance to procrastinate to solve the problems that needs to be solved. Procrastination can lead to the biggest failure: not having a playable submission at the end of 3 day. Still not having the complete vision was a little chain reaction of things to improve on.

The implementation of the game loop was done on 3th day. That was way to late to think or make changes to the submission.

There was no option to let other people test play Make Me Beautiful during the 2nd and 3th day. Getting feedback on your art is easy via social media, but feedback on the game itself is harder. Still having honest feedback early on will help to give focus on what could be improved if there is time to iterate on it.

My bad chair and sitting position resulted in some painful joints. It was just a bad tripe filled with pain at the end of last day. I sat through the pain because I did not have to work the next day. It is not something I would recommend to do.

Thank you for reading and have a great day!

Since this was my first LD, I wanted to focus on finishing the game (making it at least playable and complete in sense of UI and flow - from intro, through at least basic options to end credits) in 48 hours, and polishing it as much as I could. I entered in Jam, since I knew I wouldn't be able to make a game completely from scratch (in Compo) that way, and I had some CC0 music and base sprites I really wanted to use in a game for quite some time now.

In a nutshell

• getting more rest beforehand and during the jam is crucial. Dozing off for an hour or two in your chair does NOT count.
• even under such stress and short deadline, writing clean code helps immensely.
• Design Document is your best freiend and always has your back.
• Don't get overly focused on small details.
• For tedious, repetitive work, like adding sprites, whip up some loud and upbeat music (not necessarily like the one I used :D -->> www.youtube.com/watch?v=C_ckNQ3f1n4 <<-- but something lively, it helps a lot.
• Gimp is not bad when it comes to pixel animation, but you need to work out how to streamline your work
• SFXR / BFXR should get an oscar. Or at least a cookie.
• LD is absolutely great for testing your skills and learning new things.

Day 1

idea

After banging my head on the wall for a while after the theme was announced, I settled for a simple idea - Small island, last dry place on earth, single protagonist fighting off enemies (probably just figments of his imagination from malnutrition). Seemed simple enough, and I wanted to extend the mechanics a bit. After scribbling down a basic design doc and deciding on tools (Unity, Gimp and SFXR/BFXR) it was 5 AM here, so I dozed off in my chair for a few hours, and at 8 AM the work began.

basic mechanics

Since then, up until 10PM, with occasional breaks to scream into a thick pillow, I worked on basic mechanics and game structure. I'm not very experienced yet, and I quickly discovered where I was lacking knowledge. Fortunately, by midnight I had a working proto-proto-prototype with placeholder sprites, but the mechanics and basic flow were there - from blue intro with music player and skip button, through menu (working with options) to level with camera follow, playable mechanic, pause menu and quit/death screens.

Day 2

extended mechanics

Then the scoring system, health, damage detection and all that jazz went quite smoothly, and before 8 am the prototype was ready and even playable - flow was complete, UI was wired and responding.

SFX, Sprites

Short nap in chair, and I began the most tedious part - generating SFX, cutting sprites, making animation frames and animating in Unity (working slowly- I was tired, and a stiff drink did not work as expected) Few hours of making prefabs, another hour dozing off, and suddenly it was noon (15 hours left to deadline). Playtesting revealed that the hitboxes, fire rate and general feel were utter bollocks, so the fine-tuning ensued.

Thank you, Game Design Document

And then it hit me - I forgot to implement the overheating, pickups and bosses. I managed to implement pickups quickly, but struggled to signal the affordance - fortunately just a simple animation sufficed. Boss mechanics and overheat were tougher, but all in all, around 6 PM, with 9 hours to go, that part was also complete. As a reward, I took a nap for an hour (best. nap. ever.).

Intro

Intro text was a breeze - not as witty as I wanted, but sufficed. With 7 hours to go, I polished UI and flow, and concentrated on fine-tuning the play itself. I still felt it was bollocks, but much better than before.

Ran out of fuel

Around midnight, I felt I couldn't work anymore. Too tired, that was it. I hit the hay, and slept for 15 hours straight, woke up, and published the game on itch and my personal homepage (It was made in under 48 hours, but deadline for jam was longer, so I took the liberty).

https://www.youtube.com/watch?v=fuCQwZIAZMQ * ITCH.IO: https://takusan.itch.io/slightly-angry-max * DIRECT DOWNLOAD (WIN 32/64) http://takusan.pl/angrymax.zip

Future

There will be a post-jam update, maybe even before the voting ends (though I must concentrate on other things for now). More weapons/firing options, screen shake, maybe lighting effects, more pickups, exploding red barrels (yes, those that exist were supposed to explode, couldn't manage that properly) and - most importantly - with better pacing/balance and optimally an option to choose the game speed and difficulty. I would like to introduce more content and work on replayability, even as simple as a global scoreboard.

Thank you!

If you made it to this point, thanks for reading. This is a first-time experience for me, and an important one :)

Thanks in advance.

I should admit, I decided to cheat a little bit right here. In our game we don’t have any explanation of game mechanics (except for first levels), so I wrote this post about basic mechanics and types of buildings.

The game takes place on a tile-based map. To win you simply need to occupy all tiles on the map. To occupy a tile you have to create a building on top of it. Spend your time, money, and population on it. The glowing circle on this gif highlights number of tiles occupied by you and tiles total.

One of the main game mechanics is the population control. With decreasing population of building you have to carefully replenish it while also not spend all of your population reserves. But beware, if there’s no pop left in any slot of a building that building will be destroyed (and will damage pops in neighbouring buildings).

Periodically spawns one pop straight to reserve. Even if there’s only one pop in the housing.

Generates gold. Does not spend your gold on maintenance.

Converts pops to science points. In the name of progress. Pro-tip: You don’t need to build too much Campuses because we had time only to create 10 techs. (sad)

Altar’s so powerful it could influence population in neighbouring tiles to create new pops. Ironic. It could save other buildings from destruction, but not itself.

That's the end of my shameless cheating (and promotion).

I think here must be yet another link to the game, so here it is: Memory:Leak.

EDIT The stream is over but the VOD is here: https://www.twitch.tv/videos/138433485 We may start a new stream tonigth or not, but I will definitivly make more during this weekend. I had a LOT of fun testing all your game.

Thanks to everyone that participated!

Original post

I will be starting to stream on Twich and test your LD38 games in 5 min, come join me and add your game to my queue

https://www.twitch.tv/togislp

To add a game: just type

!addgame yourGameUrl

in chat

for instance:

!addgame https://ldjam.com/events/ludum-dare/38/rise-of-the-termites

First came the idea of a small world enclosed in a cardboard. I drew a box... I threw the ball there, but there was lonely and sad. I taught the ball of dreamy, it's always fun... The box quickly filled to capacity. But there was colors and no purpose. I began to ruthlessly destroy them. It was fun but pointless.

Then The Music came on.

Music changed everything. Flowing with the juicy beat, balls could not resist, they start dancing like there is no tomorrow. The box came alive and the world was filled with colors, endlessly dancing together. This is their little world. Enjoy The VIXA!

Entry: https://ldjam.com/events/ludum-dare/38/vixa

This was my first game jam ever, and it was an extraordinary experience. Thank you, and see you on ‘39 :)

Hey space cowboy, get on your horsemet, take out your lariat gun and go catch some cowmets! Yay!

Links

• LD Submission: https://ldjam.com/events/ludum-dare/38/cowmets

• GameJolt: http://gamejolt.com/games/Cowmets/252115

https://www.youtube.com/watch?v=ubu6SADvWTc&feature=youtu.be

Had to fix a gamebreaking bug in our game, here is the full changelog:

Version 1.1

*Fixed a bug causing text on lamp object not to show.

*Fixed a gamebreaking bug where zooming out of the safe or vent after opening them prevented the object inside to be collected.

*Resized rug to be viewable in certain resolutions.

*Changed text of the last sentence in book, to make more sense.

I am unable to update Gamejolt WebGL version at the moment due to unity issues, so it is still Version 1.0 there. The download is updated however.

Check it out at https://ldjam.com/events/ludum-dare/38/the-room

Hey! Last time around I wrote a bunch of posts about shader stuff in our LD37 entry, LOCK AND RELOAD, which can be found on the old website:

• Part 1
• Part 2
• Part 3

This time around, I thought I'd do something similar for our LD38 game, Blomst 🌻, which also featured some procedural generation in it—something I've rarely done—so there's a lot of new concepts this time! c:

Go here if you want to play Blomst 🌻!

Procedural planets

The main mechanic of the game is to sow seeds to let different kinds of plants spring up and build up an atmosphere to terraform the planet. 🌱

We wanted to associate different kinds of plant with different "biomes", so that some could only be placed on the green greens, others only in the sandy deserts and the rest in watery puddles. So I had to make all of these areas show up on the planet!

Generating the sphere

First things first. There are different ways to go about producing a round 3D object. We could use an icosphere/polyhedron (left) or we could use a UV sphere (right).

There are pros and cons to both depending on the application. Without really considering the other option at the time, I just went ahead and generated a UV sphere, but in retrospect an icosphere would probably have been better for the tiled nature of the planets, to keep each tile about the same size, either as hexagons by joining five triangles, or as quads by joining two. UV spheres have a problem of pinching at the poles, with faces getting increasingly smaller the closer to the poles they are.

As a nice touch, to make the planets not look so perfectly round, I also displaced random vertices a bit to give a rougher, more potato-like shape to it! 🍠

Dealing with pinched poles

Well, I didn't, really! To cheat around the problematic poles, I ended up just covering them entirely in ice, much like the poles on Earth, and made it so that nothing could grow on those areas. One of them later became the designated spawn point for the main character, and the other one the designated spot for the shop, so it worked out in the end! c;

But of course if this kind of cheating doesn't work for your application, just do the smart thing, unlike me, and use an icosphere! I should have also probably used fewer slices horizontally than vertically to give the tiles more of a square size.

Generating the biomes

So the next thing to do was to figure out how to create the different areas on the planet. I wanted it to be procedural and randomised each time. I ended up generating a very low-resolution texture (if the planet had 20x20 slices, I made the texture 20x20 pixels, so as to assign each pixel on the texture to a tile on the sphere) by use of a seamless simplex noise algorithm so that it would loop nicely around the planet, and assigned different colours to the pixels depending on the noise values, while also hardcoding in the icy poles.

I only needed four types of terrain (greens, sand, water and ice), so I decided to encode each as a full RGBA value in one of the four channels of each pixel, leaving the other channels zeroed. So for example the sand would have an RGBA colour value of (1, 0, 0, 0) (or (255, 0, 0, 0)), i.e. fully transparent red. This way I would only have to read one value for each type in the shader.

A resulting texture looks something like this, with the alpha values filled in again and poles represented by white; in reality of course most pixels were fully transparent:

And on the planet, with the usual interpolation of textures, it would look less pixellated and more rounded (note that this was before I added poles):

Rendering higher-resolution terrain

So now both I and my shader code could see where the different biomes were on the planet, but of course I wanted it to look nicer than a bunch of smudged pixels. Instead of actually displaying the terrain texture on the sphere, I used it to determine which high-res texture to use in a particular spot on it. Again the interpolation would make sure that it didn't look blocky.

Essentially I would read the colour of the terrain texture at the current fragment, something like so:

fixed4 terrain = tex2D(texTerrain, UV);

Then I would read each high-res texture, like so:

fixed3 colSand = tex2D(texSand, UV).rgb; fixed3 colGreen = tex2D(texGreen, UV).rgb; fixed3 colWater = tex2D(texWater, UV).rgb; fixed3 colIce = tex2D(texIce, UV).rgb;

I could then separate the terrain values into one intensity for each biome at the current fragment:

fixed valSand = terrain.r; fixed valGreen = terrain.g; fixed valWater = terrain.b; fixed valIce = terrain.a;

As you can see, which colour channel I chose to use for which type of terrain was somewhat symbolic. Then it was just a matter of multiplication, multiplying intensities by colours to get at the final result!

Optimising and enabling palettes

Four different RGB images really weren't necessary to get the desired results, however, so I decided to optimise things a bit. Instead I turned each of the three first textures (excluding ice) into grayscale images, and encoded each as a single channel into one RGB image, so that the red channel represented the sand pattern, the green the grassy pattern and the blue the watery pattern. I didn't read the ice from a texture at all in the end, but just used pure white, which I didn't need an image for.

Of course, as you can see, the water texture ended up being completely unnecessary since it was just one colour too, but at the time I had planned to actually put some kind of pattern in there as well and reserved the space for it. In the end I actually alpha blended the grass pattern on top in a parallax manner instead, to give the water a little sense of depth as well as reflection.

Now the sampling could be simplified to just one:

fixed3 patterns = tex2D(texPatterns, UV).rgb; fixed intSand = patterns.r; fixed intGreen = patterns.g; fixed intWater = patterns.b;

So now I could read the intensities of each channel, rather than the colours of the whole texture, for each type of terrain, to get its pattern. That would make everything turn black and white, though. To get colours back in, I created a palette texture where the UV position read would correspond to the intensity of the pattern on the horizontal axis and the channel on the vertical one, and so the correct pixel colour would be red.

Here's what a palette looks like:

The left side corresponds to pixels with no intensity ("black") in the pattern texture, "white" on the right, and "greys" in the middle. For a smoother transition between colours I could've used a gradient instead.

In the end we didn't actually end up using different palettes for different planets, like we had initially planned on, however.

Moving on

There's more shader stuff to look at, like the parallax water, the atmosphere around the planet, or how the planet turns from sepia to full colour as the atmosphere grows! But I don't want this one post to get too lengthy, so I'll save it for the next one! Until then! 🎮

also….I’m bad at screenshots! because that’s totally gonna make you want to play the game to say that haha 😀

View post on imgur.com

Wigglefish

First time I took part in Ludum Dare was LD32, this was my second time. I only considered joining LD38 the night before the event started. I messaged my friend asking if he was interested in participating with me - and luckily - he had also considered joining. Funnily, last time he took part in LD the theme was a tiny world. He lives in :flagfi: and I am based in :flagmy: so we had to deal with a 6 hour time difference. The night before the event, I prepared an empty unity project with Bitbucket + Git setup, so we could jump straight into development.

Eventually, we joined the jam 6 hours late and started brainstorming for an idea for a small world. We came up with this idea of having the player stand in the center of an area of 5x5 or 10x10 tiles and having an algorithm procedurally generate the world in the direction the player is moving, based on the neighboring tiles.

This would mean the player has extremely limited visibility of the world (a small world :upside_down:), but it would allow us to do some interesting visual trickery, like making the world materialize out of nothing. We considered doing something like Proteus, where the gameplay would be based on wonder of exploration.

After prototyping the system for a while, we felt a bit lost about which direction we wanted to take the game. It was probably because we didn't really have any interesting gameplay elements that we could develop the game around. We then decided to turn the idea to something more simple. After some coffee and more brainstorming, we decided to turn the game into a shmup.

We kept the core idea of generating a world on the fly as player moves around, but we turned the world into a health system - also changing the shape of the world from rectangular to circular shape.

Everytime the player takes damage, the world canvas shrinks.

When player heals or destroys enemies, the world canvas expands.

The health system proved to be very interesting;

• The player will be safe if he just stays still, since enemies appear only when world is being generated
• Staying still reduces the chance of survival, since the world keeps shrinking in size
• The smaller the world canvas, the faster it shrinks
• World canvas can be enlarged by killing enemies and also by collecting the health packs dropped by them

This system enforces player to be active and engage in combat with enemies. One inspiration for us was the combat system of DOOM (2016), where the player gets rewarded with extra health drops by taking risks and engaging with enemies in close combat.

https://www.youtube.com/watch?v=eXk3MMRXbjA

If you are interested in checking how the health system works in action, you can play our entry here: https://ldjam.com/events/ludum-dare/38/quantum-catburetor/

Or just grab the game from itch.io https://jushiip.itch.io/quantum-catburetor (Windows, Mac & Linux Available)

Thanks for reading! :grin:

Hey,

I wanna share my LD38 story. I participated on my own this time, I like the challenge of the compo. The time constraint and having to come up with something and finish something entirely on your own. I actually didn't manage to finish in 48 hours and had to switch to jam, and here is why:

Game Idea

My original game idea was a puzzle game set on a small flying world that you have to strategically destroy using bombs. In the end you had to reach a certain area to win. The more of the world you destroy, the harder it gets to maneuver around the world.

Later the destroy everything idea turned into destroy crystals. Level design was way easier when you only had to destroy a certain part of the map.

Day 1

I quickly realized that the map should be on a grid so I wanted to make a tile map tool that allowed me to iterate on levels quickly. My original idea was to just write an ASCII parser and then turn that into 3D tiles, but writing an ASCII parser actually takes time. I realized that Tiled, a tile-map tool that I used a few times, supports .json as export format and Unreal Engine 4 ships with a Json-parser that made writing the importer actually quite simple. A few hours later I had the importer done, it is still called TimeMapASCII because that is what I called the thing originally :D

I am really happy with it, since it automatically attaches gameplay stuff to the tiles, it's not just art. I can import tiles and the game rules automatically work and it builds a playable levels with win conditions and all that.

Here some .gifs of the tools:

Tiled Export and Import

Tiled Edit and Reimport

Day 2

With those tools in place, I though I could spend all of day 2 making the game. Little did I know.

Unreal doesn't have any support for grid movement - unconstraint movement just didn't work for it so I pretty much spend the entire second day making the movement and the game rules work. It implemented a grid movement thing with LERP'd animations that came with all sorts of bugs that even bothered me all into late of the third day... I also went ahead and changed the game idea at this time. I realized that the destroy the whole world thing wasn't fun at all.

I had to switch to jam, I pretty much didn't have anything at the end of day 2.

Day3

I already hinted that my custom movement component actually was the biggest issue of my weekend. I had to cut a lot of planned features that included movement of tiles, the player or bombs.

Cut features included:

• Teleporters
• moving platforms that could carry the player or bombs
• pressure plates and switched
• moving obstacles

Sadly, those cut features really hurt the game, I think. I planned with those features for solid game design.

So I spent a few solid hours making the actual game. I implemeted the full core loop around midway through the day, implemented sounds and some effects.

I didn't have time for any art, all the things in the game are basic shapes, I didn't have time for particles or fancy effects.

I even had to cut making levels short. I basically rushed five of the seven levels in the last 30 minutes before packaging the game up.

What went wrong

I basically covered everything that went wrong in the day 1-3 writeup - I made tools! Don't ever make tools unless you know you can finish them in time and they actually increase productivity so much that it is worth the time.

It wasn't for me.

I didn't have enough time to make good levels and polish because of the tools.

What went right

• I finished the game!
• I think the game has potential and is actually kinda fun
• I didn't have time for art but I think it looks decent, considering the fact that I made ZERO art stuff
• the few levels the game has are actually decent and some are fun.
• Switching to 72 hours jam instead of quitting. It allowed me to finish the game and also the sounds I used from freesound.org add a lot to the game.

Thats it! Thanks for reading!

Links

Download - Windows, itch.io

LD38 page

Twitter

I finally had time to investigate why buildings sometimes weren't spawning. I think I got it fixed, fix is included in the version: Humanity Simulator (Bug fix pack 1). Original version is still available in the same place (link in the game's page).

Game's LD Page

RabbitTortoise

So if you want to play the game I made for the LD Jam - awesome!

Here you go:

https://ldjam.com/events/ludum-dare/38/what-a-small-world

View post on imgur.com

This is my entry to LDJam 38! Your keyboard is a small world, and these small but energetic puppers love it! Can you keep up with them?

https://ldjam.com/events/ludum-dare/38/$15179

We now have a Linux build and have migrated Murder Mitosis to itch.io. We're also still looking for more feedback. So give it a try :hugging:

itch.io: https://hastilyassembled.itch.io/murder-mitosis

Project Page: https://ldjam.com/events/ludum-dare/38/murder-mitosis

Hey guys, I created a timelapse of my work on Blocknauts and finally got it up on Youtube. Blocknauts is an open-world space exploration game based around a jetpack and spherical gravity. I had a lot of fun working on the game, and I think it turned out pretty good. Take a look!

https://www.youtube.com/watch?v=ColDkzeX7fM

https://ldjam.com/events/ludum-dare/38/blocknauts

Shrinking Space is a Action RPG about helping your friends get everything they need to escape a forever shrinking planet!

PS - Controls are arrow keys to move, press down to interact/pickup, space to shoot

Play The Game: https://itch.io/embed-upload/457535?color=333333

I've posted the first Post-jam release of Strangeness to my entry page (you can still find the Jam version linked as well, of course). This version fixes two bugs with pushable objects getting pushed places they don't belong, and makes the enemies all move at once rather than one-at-a-time, making it much less tedious to move around when there are a lot of enemies on the screen at once.

Next update will bring additional levels, including a new puzzle element!

I didn't have the time to program a tutorial and as I expected: people had some trouble with the controls of Icarus Isolation ( https://ldjam.com/events/ludum-dare/38/icarus-isolation ). So here is the not-in-game-totally-not-so-proper-tutorial for Icarus Isolation!

https://www.youtube.com/watch?v=lL0_NyYSrrg&feature=youtu.be

https://www.youtube.com/watch?v=P3nGcfVUsso

The Quest to showcase some of those sweet Ludum Dare 38 games continues! Featuring an Endless Loop of one young mans life, Mouth Cleaning Simulator, and an down to earth (Literally) adventure in insect town.

Game Links

If you would like to submit your game to Larry to make sure he sees it and prolly does a video you can use this handy web form! https://bit.ly/LarryDoesLudum or you can message me pretty much anywhere. I see it all. Im like one of those floating eyeball monsters from D&D.

Umm…

When I try to join jam time was it.

Rushed to draw gameart after saw end time , there are 18 sprites . I searched gameboy colors then watched gimp indexed color tutorial . The game idea come while itching 😀 . I used my old object pooling script. Coding was easy because of game isnt complex and the font isnt mine

Softwares

• bfxr = for sfx
• Unity3d
• GIMP
• LMMS for terrible music

What went right

• Game art was easy ,it was 2-bit
• I’m late , Even so timing was good
• I had fun while don’t sleep for 48 hours

What went wrong

• Making music was  terrible I spent 2 hours for 4 seconds loop
•  BUG:When pressed X all npcs go out from house
• Can’t added breeding and parent-child
• Hand drewn wrongly  ====> 
• I forgot simple unity codes (-.-) watched few tutorial for those
• UI isnt pixel perfect
• Idiot charging cable disconnected therefore record didnt encode , I had to use this tool for broken record
• COULDN’T  BUILD TO WEB  

And the links:

GAME

TIMELAPSE

The official post-jam version of Restless in a small world, is now public! :)

http://the.codeartistic.ninja/did/restless/

Planet Spin is a small arcade game, where you have to defend your planet against meteorites while managing the needs of the humans and trees living on the planet! If you play the game, please comment with your best score! Link: https://ldjam.com/events/ludum-dare/38/planet-spin

About to start streaming games again for people who want to showcase their wonderful work. To have your game played type !addgame followed by a link to your game (preferably the version of the link without the $).

The queue size has been reduced to 5 as last time the queue got too big for both me and viewers who couldn't stick around long enough for their game to be played. If the queue is full stick around a while and a slot will open up!

I encourage (but do not require) anyone who watches my stream (especially if you request for me to play your game) take at least a little time and play some of the other games I end up playing and leaving some feedback on their game's page! Everyone who participated spent the same long sleepless 72 hours working on their project and I want everyone to at least have that work played!

https://www.twitch.tv/drazil100

Hi fellow gamedevs,

I'm part of Banana4Life, a team consisting of @rahtainka, @faithcaio, @jqnas and me. We made the small horror-ish game "Where Is Mommy?":

One thing we noticed during the development of the game (or more precisely nearing the end of the jam): We produced a lot more and higher quality content in a shorter time span compared to our previous Ludum Dare appearances. During the last Jam we had three additional team members working on the game, yet we barely managed to publish the game in time. This time we easily finished several hours before the submission hours and had an overall better game.

This made us think about what went wrong last time, because our process stayed largely the same. In my opionon, there are two possible reasons, why this might have happened:

1. Management overhead: Intuitively more developers would mean more work can be done and in theory that is probably true. However the larger the team gets, the more difficult it becomes to keep everyone on track with the project. Everyone needs to have a common vision of the game and everyone needs to be roughly aware of what others are doing. Communicating the vision and work will consume more time as the team size increases. Failing to communicate will most likely result in slowdowns due to duplicate work, merge conflicts and will lead to a distorted end result.

2. Experience gap: Our core team (the previously mentioned people) work pretty well together and we have already participated in four previous Ludum Dare jams together (more in other constellations). Our mode was always the same: One artist working on visual assets, one artist working on acoustic assets, two programmers working on the logic and game/level design shared across all four (we generally make all our assets from scratch). The three new guys were unexperienced in game jams as well as with the technical platform (Unity3d). This lead understandably to a lot of questions which in turn took a lot of time away from the more experienced members. Additionally a lot of communication, which normally happens implicitly in the small team, did not happen across the entire team which lead to more confusion and slow downs.

For us, four people actively working on the game seems to be the sweet spot with maybe one additional member for some dedicated task (e.g. UI).

I'd like to hear your opinions and experiences on the topic: Do you work in teams? How big is your team?

And of course opinions on the game are just as welcome.

While programmers make post-jam version I can make some gifs =)

Come on, Barbarian

Cookie Knight has to get back, back to the quest!

I tried to make this really cool but the Upload button is broken again or something so here is the link to what SHOULD be here. http://imgur.com/a/S4WXb

https://ldjam.com/events/ludum-dare/38/the-cookie-knight

https://ldjam.com/events/ludum-dare/38/smant-world-1

Friday

And there were the four of us, standing near a cactilli familly and sitting on a wooden pallet drinking a beer, trying to figure out what we were going to do. We picked a random theme from the list as it is not untill 03:00 am that the theme is revealed in Spain.

I suggested a quick brainstorming in which we would say one word each, and then with the 4 words we would make a game.

The words were "Ant" "Tree" "Wood" and "Boob" (yep...) So then we made a pitch for a game about "Ants", that were on an expedition on a "Tree", and of course that tree was made out of "Wood", and well about the last one, we play as the "Mother of the Ants: the Queen". So here you have a little incremental game about Ants building a small society and feeding on a tree!

The concept was:

"High Concept: Incremental game + “Open World” (2.5D ). "Look and feel: Unravel Meets Starcraft with Ants".

These was the visual experience we wanted to aim for:

We started early on Friday here in Spain so there wasn't much more room for us to work if we wanted to get some sleep, and ayway the theme hand't even been announced so it might have totally changed and with it, our small ant world idea would have flew away too.

Saturday

How lucky could we get? We got the right theme!

At first we tried to go full 360º navmesh around the branches and an orbital camera. So we spend the first morning figuring the navigation without physics and trying to flesh out a cool camera that would allow us to do so. Neither worked.

We had spent 25% of our time and we had nothing. Well, Pablo was advancing with the tree graybox so we had one static trunk with a wooden ring around it.

We felt like...

So we made a little stop to launch and discuss our options. One Churrasco after, Cafar managed to put up a basic orbital system for the camera that would ultimatellty diverge into the two cameras we have now, the 1st person camera and the tree-orbit-but-not-ant-orbit camera.

I started made a draft of the numbers for the incremental progression, and a first iteration of the vendors UI.

By this time Pablo had already started modelling the Worker ant, and by the time we finished placing small spheres as food on the wooden ring, Pablo had already started animating the worker Ant.

At the end of the day we had a working floor for a walking cube and some unused logic, so it was a little more than one day to go and

what should have looked like this

Looked like this.

Sunday Last hours! Pablo somehow managed to put together the Army Ant and the Drone and meanwhile Cafar and me wrapped the level design with the incremental logic. It was a bit primitive, but it worked. The problem was that the hired ants weren't moving, so we integrated a navmesh and it worked wonders! Almost wonders, I mean, the ants can actually fall from the tree but hey, this can happen. Right? ^^' Ok we included a reset position button just in case.

I made an Ant Bridge using a bit of here and there.

Pablo worked on improvements for the colliders and started working on the leaves to make the atmosphere feel more like a tree, and once Cafar integrated everything together along with the music suddenly the magic happened.

It worked! and we still had a couple hours to splat bugs (not ants tho) and polish polish polish.

:)

Here os a link for the game: https://ldjam.com/events/ludum-dare/38/smant-world-1

The cool think is that although it seemed impossible, we managed to stay positive and with teamwork (and surprisingly not too much sleep deprivation) we made it together!

Thanks a lot to all of you Cafar: Code and integration Pablo Diaz Decerio: Art and animation Fran Romguer: Original Soundtrack Manu Scythe (me): Game Design and TrelloCheerleader-Producer

Thanks for your ANTENTION! ;P

If anyone else is having troubles with the Mac files become broken after the upload on itch.io, here's an easy solution:

:whitecheckmark: Archive the .app file before the upload.

Just found out that itch.io's auto-archiving system is somehow broken and Mac files crush after being downloaded and unarchived. So you should archive the files by yourself to avoid the troubles and crushes.

If you have the Mac version of your game and hosting it on itch.io, please, download it and check wether it works or not, be safe from the long minutes of panic and frustration.

:video_game:

Good luck.

Did a timelapse of my compo entry. https://youtu.be/g8wwtHbby4g

The game: https://ldjam.com/events/ludum-dare/38/worldwiper

Four friends that never programmed a game before, jumped into this pool fearlessly: Qwer City was born. A simple game with its flaws but fo(u)r us it was like climbing a mountain. We hope that, on your own way you enjoy it! We did it in two days (and a couple of hours Monday night) due to work on Monday and so many things we wanted to add will be forgotten. We are eager to learn about others opinion, just to understand how to build a game from scrach and pulish ourselves.

Here is the link to the game: https://ldjam.com/events/ludum-dare/38/qwer-city

PS: Excuse my english, we are from Spain.

EDIT The stream is over but the VOD is here: https://www.twitch.tv/videos/138512496 We may start a new streams during this friday and weekend. I had a LOT of fun testing all your game. So be sure to follow me on twitch or https://twitter.com/TogisLp if you want me to test your games so you can be the first to enter the game queue!

Thanks to everyone that participated!

Original post

I will be starting to stream on Twich and test your LD38 games for the second time of the day in 5 min, come join me and add your game to my queue

twitch.tv/togislp

To add a game: just type

!addgame yourGameUrl in chat

for instance:

Not so much time left until Judging Friday, hope you have all your bugs fixed.

Ludum Dare compo is not a place where you can spend some spare hours on additional features like Easter Eggs in your game, especially when this feature brings nothing to a gameplay. While Jam teams could afford this more often, in my oppinion.

Thus we have John Conway's Game of Life in our game. So you can play a game while you play an actual game :smile:

Green blocks are in-game resources, so player can use a knowledge of Game of Life mechanics to produce more. Which means this Easter Egg actually relates with a gameplay. But at the same time it's totally optional.

So I hope your game also have Easter Eggs, it is always fun to find some.

Hello fellow devs and jammers! :smile:

My name is Nathan Hicks (Programmer) with Apostate Games - Jason Varnell (Artist) and I did the game Plutus as our #ldjam38 submission. Please check out the game here: https://ldjam.com/events/ludum-dare/38/plutus

Seeing as this was our first jam as a team (I've been in 1 previous ldjam and 2 other jams) we wanted to focus on getting the game done in time with all planned features so we stayed away from doing a devlog throughout the weekend (as well worrying about screenshots/video) so over the next few days we will be posting day by day recaps from start to finish of all the progress, decisions made, and even problems we ran into or things we had to cut from the final entry. We simply want to document the process for future reference and help us figure out what we did right and wrong through the whole thing and seek other peoples feedback on their methods as well - with that said we will probably also do a post-jam-mortem blog post once voting is over. So hopefully these dev blogs will help other jammers from making our mistakes or allow them to utilize our successful tactics and allow us to improve in the process too. If you have any questions please post them in the comments! :smile:

Week Before LDJam38

Before I get started let's also recap the week prior the jam. We (Jason and I) made sure to get involved heavily in the voting process. Once we got down to the final 2 rounds of voting we started coming up with quick base game ideas for EACH category and tried to come up with some that would fit multiple themes. Unfortunately, the final theme that got picked was the one we prepped for the least as we didn't think it would win so First Lesson Learned: Never underestimate a theme in the voting process. First thing we decided we wanted to implement was custom control key-mapping which I started getting to work on ahead of time as a template to provide as a tutorial but it ended up breaking every time we tried it the first night so had to can that idea and is an idea we will still revisit later. But we were at least able to include X-box controller support still. Also would like to note before we went into this we decided on using the Clickteam Fusion 2.5 engine as it is one I know very well already and could easily pump out what we needed - we decided this long before the jam started)

First Day - Friday Night

Theme announced: A Small World - As I said this was what we were least prepared for so we spent the majority of the first night brainstorming. Came up with our idea for "Plutus" 2 hours into the jam which had planned to be kind of like a space Katamari. Then spent the rest of the night creating 2 asset and features lists. One we knew we could achieve in time - the other if we had extra time. We also wanted to make sure to include a short fun story so we started typing a few paragraphs we edited a few times over the course of the weekend.

Starting Asset List - Player Planet (w/ thruster animations) - 8 Planets - The Sun - 8-10 space debris objects of varying size - Shield power up - Power up Icons - Explosion - Hud/UI (size bar, power up icons and pause screen - originally we did not plan on the planet tracker and arrow guide) - Stars Background - Stars Middle Ground (for parallax movement) - Title Screen - Icon - Original Various SFX and Music

Starting Features List - ~~Customize-able Controls~~ (quickly canned this idea) - Player grows larger while all else in the solar system gets smaller respectively to create illusion of growth - Collecting debris smaller than you until bigger than other planets - Death by Sun - Death by hitting too many larger objects (explode and break apart) - Power ups (Shield and Warp Drive - Also originally planned alien threats and missile power-ups) - Notifications of when bigger than certain planets and when items acquired - Rotation of planets around the sun - Gravitational pull of the planets

...With all that done and prepped for we had some other ideas if we had time to make them like black holes, various easter egg nerd references (like star trek, doctor who, etc). If we go on to make this a nactual product we will be including most of those as well.

After the night of brainstorming got some sleep fairly early and got down to work the next day!

Day 2 Recap will be posted tomorrow :smile:

In the meantime while waiting for voting please check out our other game we currently have on steam greenlight and tell us what you think!

http://steamcommunity.com/sharedfiles/filedetails/?id=872678368

Also follow us on social media and our website for future games and updates: - http://www.apostategames.com/ - https://www.facebook.com/apostategames/ - https://twitter.com/apostate_games

Cookie Knight, nothing except jumping. Maybe a message at the end? Perhaps a story not told in words?

The Cookie Knight

My entry 's had a Linux port as of 2 o-clock last night :smile:

Like I said on the page, same game, same bugs, different O.S.! :penguin:

Finally got custom css enabled on my account :grin: , works well and happy to say there's no restrictions with what you can do!

*Check it out! *

For those interested in how to get access in their account, go here

https://www.youtube.com/watch?v=QcY1PwB6_Yw

TIMELAPSE https://www.youtube.com/watch?v=Da3xAL9Xz0o

DEMO https://www.youtube.com/watch?v=-X_mZQa6t1I

Say something

Hi guys, I've put together a concise timelapse of my game for you! Please take a look if you have a couple free minutes, thank you (first time I've used music from the game itself too)!

https://www.youtube.com/watch?v=xNvqXLZVTE0

Gaia is quite a simple platformer that helped me learn a lot about 2D art and design. You can play it here

Hello friends!

Just wanted to post some closing thoughts on my first ever LD competition experience. I was originally starting to type out a full brain dump of the weekend, but it just sounded so long winded that I was boring even myself... Instead I give you the distilled down highlights!

https://ldjam.com/events/ludum-dare/38/not-on-my-pizza

What went well: * Was able to have a completed (although very simple, and not that creative) game on time. * The initial design seemed to be a good fit for the time frame. * The light-hearted theme felt perfect for a jam game. I was able to bring a smile to anyones face who I describe the game to in person. * Worked on my first ever multi-player game. Might have only been local shared screen multi-player, but still a valuable experience. * Got a lot of experience working with game mechanics that are quite common in games, that I've had no previous experience with.

What didn't go so great: * It wasn't until half way though the event that I decided that it was going to be a multi-player game. Originally I wanted to have AI opponents instead, but by the time I had all the basic world mechanics down, there was no way I could write an intelligible opponent. * Since the game was multi-player only, I wasn't able to get much gameplay feedback until too late in the event. * Even though I'm a fairly experience programmer by this time in my life, I'm still very unexperienced as a game developer and artist. I'm afraid that the final gameplay was a little short of the mark, and the sprite art needed to be stronger. * No sound or music. Haven't worked enough with the tools involved in this area to have felt comfortable preparing these materials in the time of the event.

All and all I had a lot of fun making this game. After such a positive experience, I'd definitely like to make this a regular thing from here on out. Thank you everyone for making my first time so memorable!

Can't wait to see how the judging goes!

Mygame

https://ldjam.com/events/ludum-dare/38/giant-1

Here's some video of the gameplay of my entry, ORBIT.

Gotta say my favorite part of making this jam game was creating the code for procedural solar system generation and building in the gravity physics. Also I loved what my teammate ended up doing with the music and 3D audio.

Great job everyone, so many good entries!

https://ldjam.com/events/ludum-dare/38/orbit

https://www.youtube.com/watch?v=RpLoI59iQWc

Try now: "The NedLudd Club"

https://ldjam.com/events/ludum-dare/38/the-nedludd-club

It's an investigation game where you must find the truth! Old school rulez :)

IMAGES

Link:

• Mac & Windows Versions: A Small World After All

Hey y'all, just pushed up a new update that fixes a few of our bugs to our game.

Bugs:

• Timer text actually changes now. It was hidden before.
• Menu now starts with the title screen
• Animations now work for all our characters, not just the ones chasing you

Thanks for hanging with us during our first Jam!

Try now: “The NedLudd Club”

https://ldjam.com/events/ludum-dare/38/the-nedludd-club

It’s an investigation game where you must find the truth! Old school rulez

IMAGES

We made a trailer for our game, µP-8: Microprocessor!

https://www.youtube.com/watch?v=xN2kKu5hdAE

This is my third Ludum Dare that I have participated in and I think I created better game than the other two this time. I am happy with the game and hopefully other people can enjoy the game.

If you're interested download Galaxy Vendetta on Itch.io

• I feel like I created what I wanted to make from the very beginning. A simple competitive game that anyone could pick up and play without huge learning curve. I also didn't want it to be super competitive but a relaxed competitive.

• I was able to create a ~~simple~~ random AI that you can play against with friends or by yourself, since it's a multiplayer game. The AI was also very difficult, which could be a flaw since they are hard to play against.

• Finally I liked the art that I created for the game, while it was simple pixel art with the time and my skills on art I was satisfied.

• The main thing that I didn't like was the lack of indicators that I had through the game play. I only gave players a sound for when another spaceship was destroyed and I would have liked a visual indicator like an explosion or particles.

• Another indicator that I would have like would have been a round indicator. While serving no purpose other then just aesthetics it would have been nice to know how many rounds that game has lasted.

• The music and the sound, while I am glad I was able to create some I was not proud of how they sounded and that I implemented them. The music doesn't fit the theme at all, and the spaceship destruction sound doesn't make any sense to what a spaceship would sound like. I felt like I needed to add some sound because it makes a game better, but if the sound isn't good to begin with, does it add to the game? In my opinion no, it does not.

• Finally the AI, while I was happy I created it there was one small detail that I didn't like. When all the players where killed and only AI where left in the round it would be anywhere from a couple of seconds for the round to end or a couple of minutes. I wish I would have sped up the game or did something to make the AI playing by themselves shorter so that the players could play the game and not watch.

I am proud of what I was able to create, I just wish I had more time to make my creation better