Making of Soleil Timelapse
Just an extremely fast timelapse of the process of bringing this game into reality, and highlighting my inefficiency at the same time.
https://www.youtube.com/watch?v=9LCONZedxq8&feature=youtu.be
Just an extremely fast timelapse of the process of bringing this game into reality, and highlighting my inefficiency at the same time.
https://www.youtube.com/watch?v=9LCONZedxq8&feature=youtu.be
STACK is a game about stealing your neighbor's furniture so you can build a tower!


Link to the submission: https://ldjam.com/events/ludum-dare/38/stack
This was my first Compo, and first Ludum Dare for that matter, and I decided to take a somewhat different approach than most games. With some inspiration drawn from former Ludum Dare winners (looking at you, "The Rock, the Paper, and the Scissors"), I decided to make a relatively simple game and put a much greater emphasis on the aesthetics and style than on the gameplay itself.

It turns out that frame-by-frame animation takes a whole lot of time. I've done a lot of digital art and cartoons in the past, but animation is another monster. I originally wanted to make eleven animation sequences for my game's character: idle, right and left jumping, and attacking in each cardinal direction and on the diagonals. After finishing the idle and one attack animations, I quickly realized this was infeasible in 48 hours along with finishing the game's code and writing the music.
Instead, I decided to use one attacking animation for all directions and simply reverse the jump-right animation when jumping left (ninja cat backflips, anyone?). While I could have (maybe) gotten all of the material created, I felt that it was a time and work commitment greater than is reasonable for how much it would improve the playing experience.
Overall, how do the quality/breadth of animations affect your gameplay experiences? Would you rather play a game that is very polished visually at the expense of the number of levels/smoothness of gameplay? Do you have a preference for computer-generated particle effects or for frame-by-frame animation for Ludum Dare games? Does your opinion change between Compo and Jam submissions?

You can download Seven Pillars here: https://drive.google.com/file/d/0B4O5d69PTcqrdFpYNkFtOEdoSkE/view?usp=sharing
LunarFuture has participated on this big event: Ludum Dare 38 game contest!


Available on Linux, Mac and Windows. You are free to download, play, comment and vote for this game project here: https://ldjam.com/events/ludum-dare/38/ld38-platformer-2-1
I uploaded a new version of my game (https://ldjam.com/events/ludum-dare/38/warpys-world) with some gamebreaking bug fixes. The new upload is the one named with post jam. However still some collision detection problems remain and I could't find time to fix those.
List of bugs fixed:
•Some collision detection code.
•Fixed the behaviour of the clone cat.
•Added some camera shake in the new version.

https://ldjam.com/events/ludum-dare/38/buteratos
thumbs up, guys!

Look it's a video! We played the first 10 levels of our game to show how 'easy' it is - try it, you'll be great!
https://ldjam.com/events/ludum-dare/38/cosmic-cleaner
https://www.youtube.com/watch?v=hvAAiHG0tE0
It seems we also have a bad habit of moving the mouse cursor around in anticipation - maybe this is going to get re-recorded.
http://gamejolt.com/games/srviv/253003
made this last weekend, did not finish. thought id post it here anyways
Woo! Finally got the time lapse thrown together
As usual, here's the timelapse for the development of Intergalactic Gold Rush.
https://www.youtube.com/watch?v=Hf4JxUD5p0Y
Also check out our playlist of other timelapses from previous game jams.
Tools & Tech
A Social Network was written in Phaser, a javascript game development framework. I used MAMP to host the game locally during development. I wrote all of my code using github’s Atom. Art assets were designed and turned into sprite sheets using Pyxel Edit, picked up for cheap in a humble bundle. The rather pitiful SFX I scrounged up were generated using BFXR. LICEcap was the real MVP for incredibly easy gif capture and recording to share on twitter.
Game Design
The theme for Ludum Dare 38 was “A Small World”. The first place my mind went (and many others’ if you look at the game results) was to create a small planet. The other angle that I felt was common was the social implications of the theme. I had a brief image of a social media creeping game, but settled on modeling the connections of a growing social network amongst people. The appeal of a creating a small planet with a nice starscape lived on as a decoration element.
What Went Well?
Sharing progress a lot in Slack, Twitter, Discord helped me stay motivated. Sharing my progress along the way got me some small tips and thoughts about the project. Seeing other people interested in my game the game helped me keep up the motivation to finish the weekend with a product. Being able to record gigs easily was a big boon. Sharing is so much easier when it's so intuitive and painless! The people at Itch.io wrote an article about other easy gif creation tools.
I made it a point to have something super minimal running by first night (stayed up too late though). In addition, I had chosen an artstyle and had a mockup to work off.
Since this was my first solo game jam, I wanted to keep my scope incredibly small. Thanks to this, I managed to finish my MVP by the afternoon on Saturday. This gave plenty of time to polish the game. (You'll see I didn't use this time very well... I talk about that in the next section!)
Concept Art!
Very basic MVP
Waking up early on Saturday and getting it of the apartment to hang out at a coffee shop was great. It really helped to not just sit at home in front of my monitor for the entire jam. Getting outside and working in a different place helped me out with imagination and creativity! Especially since my theme was social, being out with other people around worked out nicely.
What Went Wrong?
I did not come up with a good solid game mechanic. My theme interpretations were not anything special and didn't have a central mechanic to revolve around. In the past when I've done jams with other people, it was easier for us to collectively arrive at fun ideas. It was much harder without being able to lean on others. Creativity is a skill that I need to practice more. Raph Koster has some interesting points on the subject: https://www.youtube.com/watch?v=zyVTxGpEO30
Creating SFX and music is hard for me. VERY hard. I knew this and left the second half of Sunday to work on the subject. But this was nowhere near enough time to actually learn how to create decent audio assets. I ended up hitting randomize a hundred thousand times on BFXR and ditching the thought of having a sound track. This continues the recurring theme of completing a solo game jam requiring you to have knowledge of skills outside of your forte.
The core idea of my game sounded interesting, but didn’t pan out very well. I did not have a clear goal for gameplay in mind which made it suffer. On top of this. my implementation ended up being a bit buggy and annoying to play with. I ended up adding some sandbox features like skipping between levels and adding endless amounts of people to try and make it a little interesting.
I left myself plenty of time to sleep this time around, but I ended up not sleeping at hours similar to how I normally do. This had me waking up too early in the morning after staying up late. It's not just getting enough sleep that matters, you’ve got to consider your normal sleep schedule too!
Conclusion
Working alone is harder than working on a team. You really find out what your personal weak points are. I didn’t have much appreciation for developing skills outside of my wheelhouse. Its very easy to discard other skills when you’re working with talented people who can handle those departments, but a solo jam is a whole different animal. To succeed at a solo game jam like Ludum Dare you really need to practice all facets of game dev! You can play the "finished" product in your browser here https://law5guy.itch.io/a-social-network.
First, let's start with a screenshot of the v1.0 compo version.

I started brain-storming around 6 hours after the theme reveal, basically from the moment I woke up. After half an hour of pondering I figured the pun with "chem trails", burst in laughter, and booted up Unity to create a bi-plane model using only the Unity primitives. In 2.5 hours I had the first prototype showing the core activity, flying (GIF). The buildings were just for reference, and I noticed already how the skybox cannot show any detail, or the player would get motion-sick, and ended up making it a solid color in the end.
Next, I realised I wanted mountains and other objects that the plane would automatically climb over, and obviously some stuff to smash into. I didn't have a clear idea of what other things the player would interact with yet, but I had an idea of "painting" the ground, probably by flying over some objects that then change color. I also played around with camera smoothing and made the plane bank to the sides when the player turns (GIF). Here I also added the first "toy" into the game, by making the plane smash into pieces (it's just made of a bunch of cubes and other primitives!)
For the planet itself, I decided to do a quick-and-dirty algorithm that I remember reading about like 6 years ago. Basically, you take a sphere and cut it in half along the center at any angle. You raise up one side marginally and lower the other side. Repeat (1500 times in my case). This gives the planet in CHEM TRIALS its shape. I then had some problems getting the visuals right - I took the lowest and highest points on the surface, and wrote vertex colors into the mesh based on the height (lowest would be a dark blue water, and highest a de-saturated gray mountain). The problem was, that I coudln't force the GPU to NOT interpolate vertex colors along the triangles of the mesh, so I ended up splitting each vertex such that no vertices are shared between triangles. This means my vert count is 3x my tricount, but 15k tris is pretty much nothing these days. I didn't have to touch the surface shader, because this trick already gives a flat shading effect.
I ended Saturday by creating an attack helicopter model (GIF) (again with primitives). Here I started getting an idea on what the gameplay would be like: the player would run from these choppers and try to cover the whole planet. I realized I had a dilemma with teh whole "chem trails" thing and had to think of a story where the government would send attack helicopters after you.
On Sunday morning I immediately hopped onto making the choppers fly, first with rudimentary AI (GIF). They basically check on which side the player is, and bank towards that side. If the player is close enough in the front, fire a missile. I intentionally left the missiles "dumb", and they'd end up on infinite orbits until an unfortunate player, helicopter or another missile hits them. I thought this would easily add some chaos and unpredictability, but also wittiness and would possibly promote good reflexes (and provide positive feedback if the player manages to evade). Later on I improved the AI, so the choppers would try to get behind the player, evade each other, and evade buildings
I then added the actual game goals, collecting the yellow markers by flying over farm buildings. The modular platforms (GIF) that can be any of the three different "buildings" get generated at the start of the level. But for the final, infinite level, I made it so they re-generate themselves when the player is on the opposite side of the planet. This was because I didn't want them to pop into view, and the final level would also seem like an endless scroller.
Unfortunately I was quite tired when I started working on the sounds and it's one of the only things I don't like about the game. I had problems with looping the sound effects (made with BFXR), and in the end the WebGL player had some cracking and popping, so I had to fix that after the compo. The PC version uses a low pass filter to remove the popping, but the WebGL version doesn't. Luckily I had made 3 different plane engine loops until I realised I could just use one and adjust the pitch in Unity for braking/boosting, and another engine loop worked better in WebGL.

Small Mart is a game inspired by the awkward encounters we all have when seeing an old friend we may not want to see. The game is made to simulate the dextrous challenge of shopping while trying to ignore people you know. Our game is a comedic stealth 2D RPG which tried to embody the phrase “It’s a small world.”
Our initial goals were to develop basic movement and detection mechanics. We also aimed to create a dialog system and to procedurally generate levels and implement a 2-player mode. Of these initial goals, we were able to create a dialog system by modifying an existing dialogue system we created for a previous game. By the end of the first day, we had the detection, movement, and dialogue systems all working, we then moved on to assets and left the goals of multiplayer and procedurally generated maps as stretch goals. We all spent the following day creating assets and story. We found many of the assets from a studio called Kenney (kenney.nl) as well as opengameart.org. We used Tiled to create the maps and import them to Unity. We used autotracker (http://ludumdare.com/compo/tag/autotracker-py/) to generate the music for our game and we used aseprite to create player animations. The asset creation took much longer than anticipated as we learned how to use Tiled while we were creating the maps. Our game actually didn’t break at the last minute (take that murphy’s law!).
As for future work, over the next two weeks for our Interactive Game Development Class we plan to fix some small bugs that we noticed during our play testing. The first thing we want to fix is some missing colliders and correct some sprites. We had messed up some visuals in the game, such as an old man in the gas station being the sprite of an old lady. The second thing we want to fix is adding a sound when you’re detected along with reordering the instructions. We found that people couldn’t tell what was going on most of the time and it was because we misplaced the instructions and didn’t give the player enough feedback while playing the game. We hope the sound and reordering the instructions will fix that. A third revision would be a sprint mechanic which allows the player to have a faster-pace experience. The last thing we want to fix is that we want to add a proper ending to our game. We were missing an epilogue because we didn’t have enough time to write and code one up before the deadline came. Overall, we had a fun experience and are proud of the game we produced. We hope you enjoy it too!
I created a HTML5 version for my game, as well as an additional Linux executable. "Our little island" is about two brothers trying to build a new home, a new garden on a tiny island.
You can play it here: "Our Little Island"
https://ldjam.com/events/ludum-dare/38/naziverse-1
Juste a little post to tell you that : i have already made a Ludum Dare "Playlist" on Twitch to find my livestreams about this Jam. I made some better montage for Youtube but this is take a long time and i don't know if i will have the energy to make all this videos, but the livestream will be always saved online :)

Twitch : https://www.twitch.tv/skywilly/videos/all
And don't forget to encourage the first video on Youtube (before the next one :P)
Youtube : https://www.youtube.com/user/GameSideStory
See you soon :)
Here's a timelapse of my LD38 game, A Relatively Small World.
And, since I learned how to export animated GIFs in Premiere, here's a peek at some art that I'm doing for a side project.

Having never worked in color before, I think it's pretty good.
Hey guys, Matt here. I've been getting some wonderful feedback for Blocknauts, and some players have had difficulty in tracking down all of the scattered rocket components.
Never fear, I've managed a remote scan of the system! It took some effort, but I've retrieved enough data via the downlink to identify the general locations of all 16 missing rocket components. Hopefully this will help retrieve all the parts and reassemble the rocket so our brave Blocknaut can return home.

I can't follow any new people any more. Is this part of some work PoV is doing to the site?
Say something
It's a game.
It looks like this:
You can play it here: https://ldjam.com/events/ludum-dare/38/invaders-of-yekithar
Many games in ludum dare are made with an engine such as unity or unreal. This is fine and has many advantages, but it can be more of a challenge using a self made game engine and porting it to other platforms with your own skill. Bonus points if it is a 3D game. Extreme props to you if you use bare OpenGL/SDL(or similar framework).
* Leave your custom game engine games in the comments. Especially the 3D ones! :grin: *
I have done just this in my custom made 3D game: https://ldjam.com/events/ludum-dare/38/ids-journey

[picture uploads don't seem to be working at the time of writing. I will add photos of the game in development when that feature comes back online]
https://ldjam.com/events/ludum-dare/38/horizons
We thought that a planet-platformer game would be a fun way to implement this year's theme. The key points of our game design were: - Multiple gravity sources (tiny planets) - Levels that had aspects of platform games. Jumping from planet to planet. Must reach a "goal planet" to get to the next level. etc. - We wanted the levels to have some puzzle aspects to them. For example, pressing a button causes a black hole to appear and destroy enemies that would otherwise be difficult to kill.
Our initial goal was to implement and polish the mechanics of the game. We wanted to make sure the game would play well before putting any effort into the design of the levels. We also wanted some kind of simple but interesting combat system. We decided that the player should have a weapon that can shoot missiles that follow a straight path as well as launch bombs that follow a gravitational trajectory. This would allow the player to decide which weapon is best for any given situation and hopefully add some depth to the game. In addition to this, we added a sort of trajectory estimator that the player could activate by pressing 'E'. This ended up not working very well, as it was a last minute addition to the game and we couldn't get the gravity simulation to accurately reflect what the bomb would do after being launched.
After we felt the player controls and the overall feel of the game were up to our expectations we began designing and implementing levels. We were able to create a surprising number of interesting mechanics using the basic building blocks of our game. (gravity, bombs/missiles, planets, black holes, flying and grounded enemies)
Since we were participating in the Jam, rather than the Compo, and we wanted to focus most of our effort on the mechanics of the game, we got most of the assets from sites like opengameart.org. We used the following tools to develop the assets that we weren't able to find online. - Bfxr was used for all sound effects - Pixen was used to create the background
We spent an inordinate amount of time getting the player rotation to lerp correctly when transitioning across gravitational fields. We had lots of last minute issues with Unity collab. Buttons would lose their referenced Unity action for no clear reason. This means we would have to test every button before deployment just to make sure they didn’t arbitrarily stop working. Also a ton of the items would also lose prefabs when pulling from Unity Collab, which wasted a lot of time. The bomb trajectory feature was reasonably accurate on our machines, but didn’t come close to working on the web build.
Over the next week we intend to do the following - Add more levels/refine existing levels - add a game intro to make the narrative a little clearer - add a final "you won" scene
https://ldjam.com/events/ludum-dare/38/small-infection-a-cellular-shoot-em-up
In designing our game Small Infection we wanted to create a unique and interesting bullet-hell-style game that captured the theme Small World. We decided to have the game take place in the small world of a human bloodstream and have players switch to and from their viral form to zoom in and out of an even smaller world. Our initial goals for the weekend, which we set on Saturday morning, were working GUIs and three functioning bosses with fair and functional mechanics. By the end of the jam period our GUIs were complete and we completed two of the three bosses. However we thought that the way our mechanics were tuned at the end of the weekend might be unfairly difficult for players, especially players new to bullet hells. There were also some outstanding bugs to fix. Over the weekend we spent unexpected amounts of time on the design and implementation of the bullet mechanics and bug fixing, and the way our code was laid out caused some very annoying inconsistencies with Unity Collab which we spent a lot of time mending between our systems. And at the last minute we were surprised by some bugs and inconsistencies we’d missed earlier. We've worked hard to fix these bugs and tuning issues for the jam version of our game.
For the final version of Small Infection we'll:
Design, draw, and implement the third and final boss, the Natural Killer Cell
Fix all bugs, inconsistencies, and exploits
Fully adjust Normal and Hard modes to be fun and fair for all players
Add new sounds and music to all parts of the game
Also some asset tools we used were Bfxr, Autotracker C, Piskel Sprite Editor, and Chronolapse for timelapsing. Anyway, thanks for checking us out and enjoy some development shots!



Hello everyone!
I am currently in the middle of finalizing my thoughts / editing my post mortem; so that will be soon! I wanted to put this tidbit beforehand though, as I needed to do a Mac build for a friend; it seems to work fine with no issues for him, but I am unable to do my own testing.
I had initially planned on getting my post-mortem up prior to the initial voting began(guess I still have time now), however I had to do some serious winding down from the weekend; as it had taken its toll on me. During the event I must be hopped up on excitement because things would flow and I had no issues; but come Monday, oh man did I need to just relax.
Anyways, onwards! On the gamepage you should now be able to see links to both the google drive mac zip, as well as a link to the game up on itch.io. There are some things I don't like about the itch.io release, mainly in that the game starts with no input from that player so you are kind of thrown in that; but it is what it is.
Link to ludum dare page: https://ldjam.com/events/ludum-dare/38/mind-the-gap
Hope you guys get a chance to take a look, and I look forward to your comments!
Take care, Izunah.
Okay, so a lot of us (including me!) want to get feedback about our game right away. So here's what we do. Comment your game pages below and I'll check them all out. (I have a Windows desktop and Android mobile)
You can check my game, Conquery, as well as the other games in the comments. This way, we all get valuable feeback!
Ready? Let's go!
Try my game, Island Guard. Post your game in comments, I will try it! :smiley:

https://ldjam.com/events/ludum-dare/38/chunk-world
Hi! Wanted to tell others about the web GL version that is up on the itch.io site, the Windows and Mac downloads are still there. not much different besides tweaking shaders for it to work on Web play. Before I only built a windows exe so hopefully more can enjoy our ld38 entry now!


thanks for taking the time to read~
So, we did gather everyone from @la-mecanique-du-plastique and @kilosaurus and pile up in a room.
That went right.

As the theme was revealed at 3 A.M. here in Paris and as we wanted to be sure to have a good time, we choose some time ago to do the jam quietly, by installing everything on friday, beginning saturday morning and having long nights of sleep every day after. So once everything powered up and sweets and cakes purchased, we took a few hours on friday evening to discuss about technical and aesthetics envies.
That's when we started to take every one of the 17 themes in competition, in order, and brainstormed on them. Some themes were less inspiring than others, some were subject to debates, but we also defined some gameplays or narrative ideas we were already happy with. But as energy was running out, and confronted to a theme which we didn't liked at all, we decided to stop and go to bed, leaving this last one only blank.
"There's only 1/17 chances of this one being chosen anyway !"
Plot twist : on next morning, theme number 17 is all over the news.
Really not inspired, refusing to do something too literal (that would have been a great path though, we just weren't inspired), we took a tremendous amount of time to find a concept we wanted to explore. We felt all along the way that we were having difficulties to find and construct gameplays. After a while, our best proposal was to focus on the relationship between a solitary human and a giant finger. The player controlling the finger. Mise en abîme, contrast of dimensions and meaningful love-fear relation between the two in order to escape the world boundaries of one or the other. We did explore, slowly, the gameplay possibilities and the LD, but we had a harsh time resolving that, and started to accumulate conceptual issues on inputs, characters movements...
|
|
|
|--|--|
||
The knockout was to discover that a game featuring a giant finger interacting in a small world was totally the pitch of Antbassador in LD30. It was already saturday on the afternoon and we still weren't sure to be able to overcome some interrogations so we decided, with difficulty, to simplify by getting rid of some of the atypical aspects of the idea.
The finger became a bit more classical character, the non-verbal relationship became secondary (we even didn't succeeded to go there in the end), we focused on the playable character being too big for its environment, the question about crushing or not the tiny humans... and we throw ourselves into production.
That's what went wrong and resulted in a game opening without so much gameplay. We could have produced a meaningful experience with more time or an experienced workflow, but we didn't have either. We learned a lot instead.
A part of the crew had the experience of making animated films in some weeks. That was crazy. But a game in some days, that was wonderfully insane.
- Den : https://ldjam.com/events/ludum-dare/38/den
- Postmortem :
- #2 : environment and ambiance
- #3 : pixel art animations
- #4 : the beast, the music and the sound effects
- #5 : Development
So, a week passed, I got some feedback and I think it would be useful to do a post mortem on my game. It's my third game jam and my second ludum dare, but it's my first post mortem and the first time I'm really satisfied with my work.
So first of all
THE THEME I remember seeing it, not sure if I downvoted it or just kept it at zero. Not the best theme there, but not the worst and it turned out to have some interesting interpretation. I spent one hour and a half more or less on the theme. I discarded a lot of ideas, mostly about taking a genre and reducing the size of the world. I don't think it would have been too bad, but it was definetely too risky. I'm still intrigued by the possibilities of making a mini roguelike with tiny floor, but I don't think it would really have turned too good. Maybe with a lot of thinking and time, which I didn't have. Another idea I came up with was a tiny tower, with floor of 2 or 3 cells squares, but if you exclude "avoid something" I didn't really find a nice gameplay for that. Then I came up with an idea. What's little? A baby. A baby world. So my original design was more like a "planet tamagochi". Originally I was trying to really avoid the "tiny planet thing" but I liked that idea and I didn't want to spend too much time thinking about what to do. So when I started it was intended as a planet tamagochi with some simulation/management features to spice it up a bit. But it never goes as intended, so the simulation/management took completely over so it became more of a "build your planet and manage it" but the "it must survive" objective was still there.


WHAT WENT GOOD Well this time I really managed to do a lot of things right. I picked game maker, so it was a lot faster(My first jam was with SDL 2) and I managed to stay on schedule basically every time. The mouse only/no animation was really a right choice and the pixel effect of GIMP really saved everything. It turned out that some vague lines pixelated look really good. Far better then expected. And I managed to develop all the features I wanted on the beginning. I guess that the soundtrack isn't that bad too.

WHAT WENT WRONG The only mouse/no animation choice was good. The simulation/management genre was really really bad. I didn't realize until the end that was practically impossibile to do even the slightest amount of balance. I didn't even have the time to actually play it. It's probably really broken in some parts, I'm pretty sure that is not impossible to win, but I'm sure that with some analysis it becomes really trivial. So this forced me to focus on comedy and dialogue lines. And this is not a bad thing, but every time I try to do a jam I have to rely on that, it's the third time in a row and I really want to do something different next time. Also, I may have developed every feature, but for sure not every content I wanted to make. Mostly on the differences between planets, right now there is just one small difference unique to the population. And the losing/winning system is not nearly as complex as I wanted it to be. The soundtrack turned out to be not as bad as I thought, but if you are not very good at doing something it will be even harder if you try to do that 2 hours before the end and way after midnight. I was barely understanding what I was doing. Even the "turn music down" button it's basically a "please save me button". It doesn't bring the music back if you click it again.
if someone wants to try it the link is here. https://ldjam.com/events/ludum-dare/38/my-little-planet
If someone already tried it and is wondering why are there roasted chickens...I don't really know why that sounded like a good idea and why now it still appears to have some sort of sense in my mind. The spaghetti one was way worse, but I changed because it was too much and luckily I liked the new idea even more.
I wanted to enter the compo this Ludum Dare, but my computer had mysterious issues with its RAM, which disrupted my workflow. I had to stop many times because of my RAM filling up and even had to leave it overnight for a cleanup. I also took my laptop to a birthday to keep working on my game ( https://ldjam.com/events/ludum-dare/38/icarus-isolation ) but was obligated to stop at one point. I also got somewhat forced to watch a movie (I watched IT which is three hours long). That's how my compo game eventually became a game jam game.
Did you guys have any disturbances in your workflow? Have any of you maybe also moved from the compo to the jam?
You need to go check out A World In A Jar made by Zeknir (@zeknir) and Traincraft (@traincraft).
We really enjoyed this cute little game!
Play it here: A World In A Jar

Derived from AngryTools' Online Gradient Editor.
In other news, I am trying to implement moons for Caelium Alpha (they don't exist in the LD version). Hopefully I can finish that today and release a post-LD version for people to play (the LD version is too buggy and little features).
Hello guys,
Small update here, mostly balancing and optimizing stuff. You can check out the game Here
Updated my game Newton's Cannon with some minor bug fixes. You can find the original and the new version here > https://ldjam.com/events/ludum-dare/38/newtons-cannon-xykvy-itch-ionewtons-cannon
Well, because everybody do this, might as well do a quick recap of my experience with my First Ludum Dare ever.

It's a story of stress, lazyness and bad decisions. I should have been in a team, I was alone. I wanted to do a long game with a lot of narrative, I made a short and weird game that can be completed in 10 minutes.
I was kind of disappointed with my game. I mean I did exactly what I had in mind, the game engine worked properly and the theme allowed me to experiment with a nightmarish world that loop on itself. But it didn't resulted in a fun game, at least fun in the way I imagined it. But the feedback had been really nice so far ! I was really happy to see the nice comments I had on the site, Twitter and various website. I wish the game had more content, or better puzzle and mechanism, but it's a good first game !
What worked - The game engine : I didn't experimented my javascript engine with a real game, and aside from problem of optimisation, it worked great. At least it didn't failed me. - Game mechanism : I know this is more an interactive adventure than a game, but I like the few game mechanism I put. I tought it will be unclear for players, or too simple, but it turned out great.
What didn't - Graphisms : I'll never do hand drawings for a game, never. Drawing, take the picture with my phone, edit and resize, 70 times. We can see some pictures was more lazy than other... - Time management and global planification : When the theme was revealed, I kinda rushed the design step, I wanted to start the drawings as soon as possible. I didn't took the time to design better puzzles or funnier text.
For a first Ludum Dare, I really appreciated the experience and i'm stoked for the next one ! I don't have much else to say, soooooo.... Take a look at my game here : https://ldjam.com/events/ludum-dare/38/recursive-nightmare It's short, weird and funny (kinda) !
The theme of a small planet fitted an old idea I had about an alternativ interaction to zoom in and click at objects using just 1 button/touch. Long mouse press or long touch on your touch device zooms in. After a short while the game will zoom out again unless you sIngle mouse click or tap your touch device.
The idea is to do exploration and find things you need to kill. Zooming in increases your precision and reveals details but makes you loose overview.
You can try to save the our small planets from UFOs and plaugues.
It's an HTML game made in phaser.io and works directly in your desktop or mobile browser:
https://ldjam.com/events/ludum-dare/38/world-tapper

https://ldjam.com/events/ludum-dare/38/small-planet-ganymede
After some time and testing, we are happy to announce that Keeplanet now available on Linux! ENJOY!

Did you know that? BTW play SPACE HUMMUS. It's in the browser so you don't have to download anything. GIF for those who suffer "text-only-blindness"

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


Brainstorming-
The method I used for generating ideas was very bare-bones. Once the final 10 themes we're announced, I listed them in a word processing document and started jotting down any game ideas came to mind. However, only one of those ideas truly stuck out to me: "A game where you try to reach the “Magic world in the sky” by stacking objects and climbing them." Although this idea belonged to the theme "A World in the Skies", I loved it so much that I had to find a way to make it work with the actual theme, "A Small World". As soon as the actual theme was released, I took a shower to think about how I could implement this game to fit the theme. In the end, I went with simply making the world a small sphere (I know! Creative right?).
Coding-
The coding was probably the easiest part of this project. I already had previous experience working on two of the problems I needed to solve: small world gravity and inventory systems. The only system that I had no experience working on was placing items in the world, which I was able to get working fairly quickly.
Art-
This was the most time-consuming part of this project, as I am a rather novice blender user. At first, I wanted to simply go with a "childish" aesthetic because the mechanics of the game seemed childish to me. After finding a font and trying a few colors for it, I thought "Why not just go with a stereotypical 'girly child' look?". And that is the aesthetic that stuck for most of the world. Once I made that decision, all that was left was making a list of "stackable" and "non-stackable" objects I wanted to make and (slowly) working them off the list.
Music-
I made this between the hours of 3am and 4am... Don't do that...
But seriously, the music was heavily inspired by the old "Kiwi!" animation. This kind of music really fit the "child-like determination" feel I was going for. I opened LMMS, found two good open-source samples for the background riff and melody, imitated the background riff from "Kiwi!", and composed my own melody through trial, error, and a little bit of music theory.
Problems-
One problem I had with the first person controller was clamping the vertical look range (you can actually do a full 360 front-flip right now). I had solved this problem before, but the quaternion math with the small world gravity threw me off. I never fixed this problem in STACK, but no one's called me out on it sooooo...
Another problem I had pertained to the optimization for the webGL build. All the objects that the player could pick up were using Unity physics, which caused an abysmal frame-rate. Now, almost all objects do not have unity physics enabled, allowing for a much smoother web browser experience.
Also... I forgot to go to bed one night... DON'T DO THAT!
Thanks for reading. :)
Submission link: https://ldjam.com/events/ludum-dare/38/stack
While my little knight isn't an unkindled ash, he does have some challenges ahead. Help him reach his goal, and Praise the Cookie!
Using Blender Game Engine.
https://www.youtube.com/watch?v=fwgiEO37N-U&
(Video in portuguese, sorry about this. But you can also watch the Timelapse and play the game (in English). Starts as 1:28).
Check my game here: https://ldjam.com/events/ludum-dare/38/the-space-explorer
![]()
Water every small cubic planet until it revives.
We will add more levels in later versions!
Entry: https://ldjam.com/events/ludum-dare/38/waterever
Have fun!
Tags: LD #38
This was a strange (but awesome) Ludum Dare. I chose to participate alone because I really wanted to develop my own idea. I wanted to make a "cute" game based on long dialogues and scenes with just one image, but I ended up doing a very dark and environmental game.
That shows me once again that I have to learn how to stick to my initial ideas and don't iterate too much.
A proof of what I am saying are the concepts I made. Clearly there is almost no direction:

As you can see, I went from "dragon ball" like characters to something more similar to what I ended doing. But was a long road and a lot of time wasted.
After finishing my game I felt a bit sad because I didn't include everything I wanted. The idea was destroy the island, get out in a boat and arrive to another island where you could interact with other entities.
But a good thing is that I managed to make a decent amount of gameplay to extend the duration of the game 8-10 minutes.
The overall reception in general have been really good! (better than I expected) It feels so good read nice feedback or comments from people who really understood what you wanted to say. That thing for me is the best part of Ludum Dare.
I spent the whole first night (about 3-4 hours) composing music. I wanted to make it an important part of the game because the environment for me is essential. It seems like for now it worked well because I've only received good comments about it.
Mood:People who have played my game said that it is really "moody", so in the end I managed to make the game feel the way I wanted it to.
Graphics:Even if they are very simple I am quite happy with the graphics. I really like the 1-bit style and since the beginning I knew I was going to do something completely black and white.
Before today the game controls were really bad. Path finding was broken and the interactions were too slow. I received lots of comments about it and I did fix some issues. I hope that after this update the game feels better.
Content:As I said, I wanted to include a lot more content, but I spent too much time working on code that in the end was not even used. Lesson learned for future Ludum Dares.
And that's it!
Thanks for playing it!I want to upload a timelapse soon (I have to guess how to export stuff with chronnolapse), so if you are interested, visit my page one of these days!
For now, here are some concepts I made: (recorded with procreate app).


https://ldjam.com/events/ludum-dare/38/daydreaming-island :milky_way:
Buteratos - crazy game about Raul Buteratos, who must save the world, where fictional superheroes run BIG Robots. The main badguy is a hot-dog man) Relax and have much - much fun!!!
https://ldjam.com/events/ludum-dare/38/buteratos


It's mostly in Unity... hope you enjoy it :grin: https://www.youtube.com/watch?v=xNvqXLZVTE0
Also, my game (called Gaia) is here, maybe bookmark it for judging later. Thanks for watching!
It's not quite Space Invaders... get it? Play Small World Attackers! here

Anyway, what started out as a 3D-with-a-twist version of a Space Invaders clone (the twist being distinct first-person and third-person views) turned out in a more fun arcade game than I imagined. While working on adding the "occasional space ship" fly-by, I found the challenge of locating and shooting it more fun than the regular aliens. So, I made that the primary gameplay and moved the invaders to a "classic mode" option.
The interesting mechanic is really about the use of the swapping between views (TAB key).

So where in past Ludum Dares I went for more complex mechanics, I went for a simple clone type of game - but with more time to play test I found some interesting hidden gameplay. Overall I'm pretty pleased with the entry, mostly I just took a different route than usual and it worked fairly well I think. As usual some tweaking of point system and how fast things speed up and get more difficult could help. But if you play for a few minutes you should see the ramping up of difficulty fairly fast.
Enjoy and please leave a comment!
https://ldjam.com/events/ludum-dare/38/small-world-attackers

https://ldjam.com/events/ludum-dare/38/the-adventure-of-malvin
Full gameplay of the game: https://www.youtube.com/watch?v=3CB9Sq3X-As
My idea was to do a game in the style of PS1 games with 2D backgrounds working in a 3D enviroment with 3D characters. I've been working in learning the techniques of the old masters of the pre-rendered backgrounds era so I told myself, why not try and use it in the next Ludum Dare?


And here it is, the product of the hard work of an amazing team I'm really proud to have work with.
You can find the game here : https://ldjam.com/events/ludum-dare/38/little-remains
I played a couple of games so far and thought it would be nice to share some favorites.
Really beautiful game about growing in an underwater world :ocean:
* Play Flovala *
Sweet little toy about making your own terrarium:
* Play Tiny Worlds in Flasks*
Discover new plants by changing soil & seeds!
* Play A World in a Jar *
You can also check out my game if you want & leave a comment:
*Play Our Little Island *
This is my game called Too Small For Us. Feel free to try it! LINK: https://ldjam.com/events/ludum-dare/38/too-small-for-us-1

Though this Ludum Dare went even less smoothly than I'd prepared for, but I managed to create a core experience I enjoyed. Regrettably though it was lacking in enough meaningful content and balance for me to have confidence in it as a submission people might share/discuss.
https://ldjam.com/events/ludum-dare/38/my-precious-orbit
https://www.youtube.com/watch?v=o-o83pJd788
Still I wanted to be able to round it out into a completed project as I enjoyed the base I had built for it, so for anyone else who were also engaged by the submission I entered,
its post-LD release can be found here - https://swiftillusion.itch.io/my-precious-orbit -
which I'm absolutely happy to have as a small completed game.
Below is a summary of my experience/followup plan if you'd like to see/read more
SATURDAY
Ludum Dare started for me on Saturday at 11am, so I was awake with lunch eaten and ready to jump in.
It got off to a good start with my favorite part (game design/conceptualization).
Below is the initial document where you can see how my thoughts trailed along.
Then I cleaned up and separeted the games core elements in-case I needed to adapt it to an even smaller scope
With all that done in the initial 3 hours I was happy and ready to get working on the gameplay.
My first priority was the characters movement as that had to feel just right.
The prototype character was just a quick dummy so I could test the initial spatial movement.
http://i.imgur.com/QDUMjzJ.gifv
That was ready around 5 hours in.
The camera was next though, while tweaking the player movement/rotation alongside it. It was a nightmarish mess of quaternion math trying to get the camera to smoothly/dynamically follow the players position/rotation.
After experimenting searching and guessing for what felt like forever I stumbled upon one amazing person who'd shared the simplest equation ever that worked!
So this day ended around 3-4 am.
SUNDAY/MONDAY
These 2 days were so horrible with the little I accomplished I can't entirely recall the order of events/what happened separately across both days.
~~~The Sun/Planet models
I wanted to have a colorful array of planets/suns, so keeping performance in mind knowing I'd want a lot of solar systems visible together I wanted them to share the same texture/material and just offset it randomly for each. However somehow as obvious as this at least seemed to me, Unity had no way to accomplish this. Each material 'instance' actually costing individual drawcalls instead of like my previous experience with this in Unreal Engine 4 where instances were used to cut drawcalls.
This led to a mess of trying to find solutions, eventually stumbling across and combining/guessing my way through a solution to offset each meshes indivisual uv's which ended up working absolutely great.
(Because I'm unable to program/I use a visual programming tool -flowcanvas- finding even working code doesn't mean instant success as I have to try and workout how to translate it into that tool).
~~~Character revision
I wanted to work on revising the character with a roughly skinned character to test its gameplay functionality.
This started off well enough, however the process I've been using to import character into Unity since I can remember randomly decided to stop working. The root bone of the character wouldn't export/import into Unity, even attempting previously functional characters caused the same result.
Not having the slightest idea how this could have started I had to guess my way into a roundabout solution that involved extra work. However, once I tested this the original root bone, no longer attached even remotely to any part of the character and not selected for export decided to show up in Unity. I was beside myself trying to comprehend this. Eventually I had to just cross my fingers with the roundabout solution and hope nothing more would break.
This resulted in having to re-animate the character from scratch multiple times and a mess of other time wasting processes in combination with the ragdoll tools to get it ready.
~~~Character physics
This I know was the last event of Sunday/Monday, as it was 9 hours of headaches and squinting at the screen with intense concentration to spot whether or not the character was snapping between frames or the ragdoll was lagging behind. It was just a mess. I rebuilt the ragdoll/physics for it countless times, compared demo scenes, shut options on/off thinking it did/didn't work but then discover the camera jolting around and having to tweak that, only to find the issue was with the character. A serious nightmare.
After the 9 straight hours of this I just had to settle with not being able to have continued slow motion (the character would visibly shake/snap) and have the camera move only on the fixed time update alongside the characters physics.
At this point there was only 9 hours left until the submission deadline, so I had to skip sleep and brainstorm what kind of gameplay I could achieve with essentially only character movement working and planets blindly following the player.
TUESDAY
After madly brainstorming/calculating what I thought I could accomplish/what had the least risk of going wrong to move forward with, I roughly put together a mental concept/schedule of what I needed to accomplish.
Player defeat/loss condition, Element of progression/impact, Enemy Interaction, sound.
I hoped for about an hour each with an hour safety net for bugs/tweaks/balancing and time left to write up the project and upload/submit it.
~~~Player defeat/loss condition
I added a new element of the characters concept, the gems around the head/globe and thankfully quickly managed a solution to track them and remove 1 each time a sun collided with you, making sure the first ones to disappear were those facing you to make it more visually evident. This also helped in that I didn't need to start adding/working on 2d elements and it complimented the 'scenic' space view during play.
I Also wanted to make sure the defeat was impactful so I stopped the camera following the player upon death.
~~~Enemy Interaction
This was relatively simple, destroying enemies when they were hit with your swing. However at this point I worked on additional tweaking of the players collision/punch collision to try and get it feeling smooth.
~~~Element of progression/impact
I then split up the destruction of suns by having them lose their planets, starting with the furthest one out.
I also tweaked how their planets did so to make it more apparent (with an additional explosion effect for them-they also expand outwards from the sun before doing so).
~~~Sound
Thankfully this was mostly taken care of as I made the above additions though I didn't have time to find/add music, I barely managed to get the title menu and credits added very roughly onto a plane in front of the camera. I also made the title smoothly move off the screen instead of disappearing to feel less rough.
CONCLUSION
Somehow I still had something I was at least comfortable submitting even if I knew it was lacking thanks to the core experience I made sure to keep refining even throughout the lost time from the various bugs/issues.
If I had just pushed forward without doing so, I would likely not even be writing this as I wouldn't have been comfortable submitting something that was both incomplete and without a core experience/layer of polish and consideration that I hope comes across in this submission.
NEXT? (after playing and giving feedback to other entries)
While I had been working on a RPG Maker MV project I'm currently recovering from an eye operation, so working with pixel art isn't something I can manage when I still have to zoom in most webpages to read comfortably.
So the current plan is to enter the '1 game a month' game jam via Unity in 3D from the start of next/this month, and hopefully have a smoother experience with that than this Ludum Dare ^^;.
Well, it's not exactly located in space, but there are lots of balls involved.
It focuses on one simple task- getting a photon from a monitor to the eye of an observer. There are atoms of oxygen in the way, so you have to dodge them.
Yes, lots of physics laws are somewhat bend here, but lots are kept, and it's a chill and relaxing game.
So, without further ado, PLAY the game itself! And don't forget to rate, when it'll be available.

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:

This is my second game jam, my second game at all !!!. My goal was the same as in the last Ludum Dare, learn, have at the end of the weekend something that I can call MY GAME! and of course, get feedback and comments on my game, and improve thanks to it! I had worked alone in this game, made with Unity and visual Studio for scripts, all "3D Models" are made with Unity basic geometry and sound effects recorded with my phone with no edit (i had help from my girlfriend making noises on the phone).
- What went right?As always I did a "Making of" video, check it out! :)
https://www.youtube.com/watch?v=XldCg9sQYx0
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 Since we wanted to focus on getting the game done in time with all planned features we stayed away from doing a devlog throughout the weekend 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. If you have any questions please post them in the comments! :smile: Also, apologies that this one was a day late. Got busy.
Day 1: https://ldjam.com/events/ludum-dare/38/plutus/plutus-dev-blog-ldjam-recap-day-1
Day 2: https://ldjam.com/events/ludum-dare/38/plutus/plutus-dev-blog-ldjam-recap-day-2
Jason was quickly finishing all the space debris, player planet, and backgrounds and were implemented fairly early in the day. I spent most of the day doing math...lots and lots of math to make sure the scaling made sense and you actually collect things smaller then you when you reach X size. This still is a slight problem starting out with smaller objects but is something we may fix later if we take it to full production
I quickly got to work on the gravitational pulls of the planets and got those in fairly quick. Then went on to do the notifications of when you were bigger then the other planets. And after that the death by hitting larger objects and cracking apart as well as randomly spawned objects off screen to populate the map with debris. By early evening most of this was all implemented and a lot of testing began. There was still no GAME OVER or victory events just yet. The rest of the night was tweaking and adjusting values, sizes, speeds, gravity etc. Half way through the evening though we decided it was too hard to find the planets since they move (which we liked and wanted to keep) so we came up with the idea for a planet distance tracker and a quest arrow since I have never done a mini map and don't know where to start making one (something I will be doing very soon now).
With ALL of the features in place a majority of the art assets also being finished it was time for Jason to move onto the planets and sun.
I had already started working on a musical composition in LMMS, a free music software I was not used to, to use in the game but of course we ran into lots of bugs that took priority. The bugs included: Scaling not working consistently as well as debris shrinking down to being invisible. Hit boxes not working properly. Gravity causing too much lag while remaining inactive when not on screen and dragging LOADS of space debris. The rest were mostly graphical issues like positions of thruster and shield overlays. The Arrow was also not pointing to the nearest planet or one you could destroy. Also making the objects pause and resume was even an issue.
With all that in mind I decided to not sleep at all till the bugs were fixed and canned the idea of making my own original music and SFX (at least for the jam). So with that said Day 3 merged with Day 4 (for me at least - Jason made sure to get some sleep). Lack of sleep also later became a bit of an issue in terms of remembering important fixes and taking all other code into consideration so more bugs kept arising so it was a good thing I canned the original audio idea. The lack of sleep also made for a few last minute mistakes that weren't tested properly but we will review that on Day 4
Day 4 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

Greetings, fellow humans. We are - like you - Genuine Earthmen. :alien: First I would like to introduce the members of the band: - @daanvanyperen on the coding - @meatmachine on the music and sound - @troop on the writing and voice-over - @flaterectomy on the graphics
Our game is Little Fortune Planet: a global physics emulating card game in which you can unlock achievements that allow you to edit the game world sandbox-style.



We adapted the A Small World theme in a pretty direct way: a cross section of a tiny planet including the core, lava tubes, bodies of water, and the planet’s surface with its inhabitants. After we brainstormed for a while, @daanvanyperen showed us a video of a tech demo he once made of a circular world with physics emulation. We figured we could have some cool emergent situations arise in that environment. Then we had to figure out how the player interacts with the world, and pretty quickly a card game came to mind.
First and foremost, our goal was to make a game with the four of us. In previous Ludum Dares, either @daanvanyperen worked alone or he and I teamed up. We had never been more than a duo, so just grouping up with the four of us and making a game was a goal in itself.
@meatmachine started venturing into making digital music about 6 months ago, and he was excited to be our audio man. @troop wanted to write and voice-over our introduction monologue.
Having practiced on (walking) animations some more after our LD37 entry (I Clean Toilet), I originally had the goal of making a game with improved animations. When our concept didn’t really allow for that, my graphical goals pretty quickly focused on the card game element. I am not really a card game player, but I do like the card designs of games like Magic: The Gathering or Hearthstone. We did not end up having a clear points system, so instead the cards differ in their illustrations and very brief descriptions (which were fun to write!).

Of course, directly after our brainstorm, our idea was too big. This is nearly always the case, and not a true problem in itself - there’s always a serration process where a large pool of ideas has to be simplified. Originally we wanted to have various tribes living on the planet, and have the cards affect the world in a way so that they could interact (i.e. go to war) with each other. The faction that survives or advances their technology enough to escape the planet in a spaceship would win, and start over on a new planet.
Another issue was that we had an ethereal concept, and we didn’t know exactly where it would lead us. This also meant that @meatmachine spent the first day making music and sound effects speculatively, not knowing exactly what we’d need.
Somewhere in the middle of the jam, we realized we had a physics emulation without a game. How are we going to make this fun to play? By introducing the achievements and adding some wacky cards (everyone turns into a dolphin!) the game grew a purpose and that turn-around was pretty cathartic.
@meatmachine’s sounds and music worked well, and add a lot of character to the game, as did @troop’s opening monologue - it made me nostalgic for classic god games.
While Little Fortune Planet turned into a quirky little game that I personally am pretty happy with, it may fall a little short on polish and explaining itself to the player. A line that we repeated a few times among ourselves was: “next time we make a platformer.” A more traditional game format might not be much of an innovation, but a familiar concept with tried-and-tested controls would mean we get to put our effort into a more finished game.
Looking back, Little Fortune Planet is kind of the child of our LD36 entry Dynasty. You are presented with some options of affecting the game world, and your choice will lead you to victory or great shame. We didn’t realize this until later on in the jam. I’m not sure if we’ll revisit this mechanic any time soon, but I suppose we did encounter a concept we enjoy.
The new site design doesn't seem to work well with lot's of text, so I'm gonna keep things brief!
I used Stencyl.com, which I used for most my 2D LDjam games so far. The scripting/coding is really easy & it allows to export the game to different platforms.
I experimented with this concept before.
It's a style not done so much recently and can be great to add something magical to a daily scene.
I spent almost all of the first day on the concept.
Here is one of my original concept artworks:
In this phase, I was able to use creative techniques I learned recently, such as the Clustering-method.
This was probably the LDjam I spent the fewest hours on, next to my 4.8 hours entry one time.
I was surprised I still got a lot done, despite losing a lot of time to conception, resting and traveling.
All the resting helped me to have more energy and focus to tackle things.
I had a pretty bad cold while I was working. This took away a lot of time and energy.
I lost ~5 hours traveling to team members recording music & sound. Maybe next time jamming in the same room is quicker.
Seeds and branches spawn at a random time with random chance. This makes the game really hard to balance & player experience seems to differ a lot.
All in all I really enjoyed this Ludum Dare! The two monsters I created during the weekend grew very close to my heart and I can imagine doing something with them again. If you haven't yet, you can click this link to play the game: https://ldjam.com/events/ludum-dare/38/our-little-island

Hey fellows,
we just want to say thank you for this awesome event! :grin: It was our first attempt and our minds are blown away from all the nice feedback you wrote us. We learned so much within this week like we did almost never before. This will definitely help us for our future projects. Before this Ludum Dare we never had any sort of feedback and to see that you enjoy our entry so much took a load off our mind.
So just thank you all for being so awesome!
After some of our comments brought us to the idea, we announce you the

The first person who mails us a screenshot with a score over 10 Cereals Per Second (CPS) in our first mini game wins a free box of cereals! This is just a small thank-you gift for all your kind and useful feedback. Because you know, breakfast is healthy. :smile:
Please mail us your screenshot at team@samurai-spark.com.

This is my second game jam, my second game at all !!!. My goal was the same as in the last Ludum Dare, learn, have at the end of the weekend something that I can call MY GAME! and of course, get feedback and comments on my game, and improve thanks to it! I had worked alone in this game, made with Unity and visual Studio for scripts, all “3D Models” are made with Unity basic geometry and sound effects recorded with my phone with no edit (i had help from my girlfriend making noises on the phone).
– Finish another game
– I managed to complete the levels and the amount of powers that i planned from the beginning
– Not much more
– Learn some 3D modeling and Animating (just spheres and squares deformed aren’t that good looking )
– Particles Systems (was my first time working with it)
– General control feeling (Jump Force / Gravity / Speed / Camera Rotation)
– Camera Collision (this was on my “to do” list since friday night )
– Add background sound/music
– Tutorial or In-Game Hints (Some people cant pass some levels / Read Spoiler Section if you get stuck)
– Maybe “Unity terrains” is not the best for platformers
– Planning more time to polish and make game look better (like add more stuff in the scene)
– what more? let me know on Twitter
Hugely Unpopular President Simulator was not one of my better Ludum Dare entries. I didn't decide on the idea until ~16 hours after the theme was announced, and it was only because I absolutely could not think of anything better. (Thought 1: I would have done well to surrender when I realized I wasn't going to get anything finished with as uninspiring a theme as this one.)
I spent most of the first day procrastinating and playing other games because I had no further game ideas beyond the vague "you're a giant Trump stomping around and wrecking the city for points ah-la Goat Simulator" and thusly just wanted to sit and think. At the end of the day, I went through a burst of coding and got the most basic of gameplay elements added. (Thought 2: I would have done well to surrender when I realized that I wasn't going to have any ideas beyond the vague starting one.)
The second day was more of the same. I added the vague outline for abilities, and a patriotic-looking health bar (the background texture is red-white-and-blue, if you haven't seen it yet) to top it off, and then...nothing. (Thought 3: I would have definitely done well to temporarily block Steam from working so I couldn't play more GMod, forcing me to actually think long and hard about how to make a game out of this stupid idea.)
The final day was just adding the basic protesters, packaging the game up, and plopping it on the LD site. (Thought 4: I should've come up with some funny sign ideas beforehand, so I wouldn't have to spend an hour sitting in front of GIMP with the text tool up, staring blankly at the screen waiting for witty ideas to come to me.)
All in all...This was a Ludum Dare I should've probably quit, instead of forcing myself through to the end. The theme was painful, the game idea is probably controversial, and I felt pretty terrible by the end despite having barely spent any time working on things. What I learned from this? Know when to surrender. I really should have.
I didn't use any background noise while making my game, but recently I've discovered rainymood.com, which just plays rain sounds while you work. I find it incredibly relaxing. I've heard of other people using white noise, music, and other things to help them concentrate, and I'd like to know: what do you use?
https://www.youtube.com/watch?v=jcwzRh8ZIVE

Water every small cubic planet until it revives.
We will add more levels in later versions!
Entry: https://ldjam.com/events/ludum-dare/38/waterever
Have fun!
Since voting is upon us, I thought I'd share with you the progression of how my entry came to be...
The theme this time around was Small World, so I (like a lot of devs) made a game either around a small game world or a tiny planet. I went with the latter and drew up a run ‘n gun shooter on a little planet.

Sadly I had plans with my friends on Saturday so I didn’t start work on the game until around 8PM GMT, so development felt more rushed than a full games jam but I managed to make what I set out to design: littleBLASTplanet

Similar to my past Ludum Dare projects, I used HaxeFlixel. It’s straightforward to use, multiplatform (Flash, HTML, Windows and Android maybe…) and it’s still being maintained so there have been several improvements. I’ve provided the game’s source code on Github so feel free to have a look to see how the game works.
The first problem I had to solve to make this game work is how to make a sprite orbit a planet. HaxeFlixel has a FlxVector object for vector math, so using that with a sprite’s acceleration meant having the sprite fall towards the centre of a circular planet was pretty easy, but how do you get the sprite to stop on the planet’s surface?
HaxeFlixel has no circular collision, only rectangtle collision. When I wrote my own C++ framework for a game on Steam called Gemstone Keeper, a framework which took inspirations from HaxeFlixel, I included Circular collision by giving each object a Radius property and writing my own circle overlap and separation functions. This would have been too much work for the time I had, so I wrote a hack method for a derived sprite class that always checked and updated the distance between a sprite’s centre and the planet’s centre, and if the distance was less than both the planet’s radius and sprite’s radius combined, then the game pushes the sprite up to the edge of the planet. This circle collision method is only applied between a sprite and the planet, and since rectangles don’t rotate then all sprites had to be perfect squares.
Bullets were one of the only sprites that weren’t built to orbit the planet, instead simply moving in an angle that combines the firing direction with the player’s current angle. I’ve had some feedback that said that the bullets should also be affected by gravity. I decided against it because it would make enemies on the planet easier to hit, while enemies in the sky would be harder to aim, not to mention the game loses a strategy element because of where bullets travel.

I went with three base enemy types: Rockets, Spikes and Robots.
Robots functions no differently from the player, except that it moves in a fix direction and smaller ones bounce by constantly jumping. Spikes has the same orbiting system, but it’s planet radius is much smaller to allow it to go into the planet. I use FlxTween and the FlxTimer to allow the spikes to move in sequence. Rockets simply spawn outside the screen at an angle and move towards the centre of the planet. If a rocket touches the planet then it would be destroyed, resulting in an instant game over.

I also added an escape object, which changes the planets side and makes the level a little bit more harder. This was for variety, so you wouldn’t have to stay on the same planet. If I had a bit more time I would have included more animations on the planet itself.
Speaking of the planet, that was one of the first objects I applied polished graphics to. To give it a more detailed pattern, I used the built in Cellular Automata function, and applied the pixels to the circle. Since it uses a random seed, the pattern is different on each playthrough.

The planet’s destruction is a particle effect that uses the planet sprite’s texture, a technique I used a lot in Gemstone Keeper. However one gripe was that I had to make a derived FlxEmitter class that could allow me to set how many frames I wanted based on the particle’s frame size.

Along with proper sprites, smoke was added to the spikes so that the game can provide a one second warning before spikes hit. I also added a distance check to avoid some unfair spike deaths. Finally I added a second camera mode incase the first one wasn’t interesting enough. The follow camera simply rotates with the player so they can stay in one spot while all the other objects rotated around. It did mean having to create a new Camera for UI elements, since objects can only be parallax scrolled by position.

The last elements I added were the title screen and audio. Sound effects were produced with BFXR and music with Abundent-Music’s Procedural Music Generator. Audio is one of my weakest skills so these procedural tools made that quick and simple, although I probably wouldn’t enter myself into the audio category for them.
I figured I add a smaller version of the planet in the title screen and have the player sprite on a bigger world to give a vague sense of a setting, with emphasis that the player is fighting on tiny planets and not just a giant on a regular sized planet.
And that’s basically how I made littleBLASTplanet. If I had more time I probably would have created more enemies and made proper transitions between planets. Aside from that I’m pretty happy with the results, particularly hacking the physics to getting jumping and moving around a 2D planet to be possible.
Voting for the game begins tonight, so if you took part in Ludum Dare, please check it out!
My approach to making games has always been focused on solving problems I consider interesting. In that same vein, this post is focused on those aspects of my entry P L A N E T O R U S that I found interesting and enjoyed solving. As a disclaimer, a lot of the code in this post can no doubt be optimized or in some cases replaced with analytic solutions; but that's how game jams go.
Before reading on, I suggest you take a chance to play my entry so this post has context.
https://ldjam.com/events/ludum-dare/38/planetorus
The surface of a torus can be represented as a 2D surface which wraps around at the seams. Towards this end we can define a rectangular map with an arbitrary MAP_WIDTH and MAP_HEIGHT. These lead to a MAJOR_RADIUS and MINOR_RADIUS for the torus as calculated below.
MAJOR_RADIUS = MAP_WIDTH * Mathf.PI * 2
MINOR_RADIUS = MAP_HEIGHT * Mathf.PI * 2
A 2D location on this map can be converted to a location in 3D on the surface of the torus with the following procedure.
``` public static Vector3 get3DLocationFor2DLocation (Vector2 mapLocation) {
float vertAsRad = (mapLocation.y / MAP_HEIGHT) * (2 * Mathf.PI);
Vector2 minorCircle = new Vector2 (Mathf.Cos(vertAsRad), Mathf.Sin(vertAsRad));
minorCircle *= MINOR_RADIUS;
float horzAsRad = (mapLocation.x / MAP_WIDTH) * (2 * Mathf.PI);
Vector2 majorCircle = new Vector2 (Mathf.Cos (horzAsRad), Mathf.Sin (horzAsRad));
majorCircle *= MAJOR_RADIUS;
Vector3 result = new Vector3
( majorCircle.x + (Mathf.Cos(horzAsRad) * minorCircle.x),
minorCircle.y,
majorCircle.y + (Mathf.Sin(horzAsRad) * minorCircle.x)
);
return result;
} ```
Essentially, we find the x,y map location as a ratio of the map width and height; which are then converted to radians, horzAsRad and vertAsRad. These two ratios can then be turned into separate 2D locations on the major circle and minor circle respectively. These two 2D circle locations are then added together. The major circle is treated as laying flat in the x⨯y plane. Note that the x component of the minor circle is transformed before addition, as the position along the major circle determines its orientation in 3D space.

To correctly orient objects along the surface of the torus we also need to know the normal vector for a given location on the torus map. This was achieved by normalizing the offset from the 3D location retrieved from the function above and a 3D location on the major circle; though in retrospect there are more efficient methods by which to calculate the surface normal.
Moving objects along the surface of the was achieved using a simple 2D RK4 integrator; the details of which I won’t include here, but see the link below for more details.
http://gafferongames.com/game-physics/integration-basics/
This however lead to an issue: moving horizontally on the torus map would give different 3D velocities depending on the vertical component of the 2D location. Mapping from the 2D rectangle to the 3D torus introduced distortion which affected the horizontal components of distances; luckily this distortion could be represented and corrected in the evaluation step of the RK4 integrator by scaling the x component of the entity’s torus map velocity by a factor given by the following function:
``` public static float getHorizontalMapDistortion (float verticalPosition) { float vertAsRad = (verticalPosition / MAP_HEIGHT) * (2 * Mathf.PI); float offset = Mathf.Cos(vertAsRad);
return 1 - (offset * (MINOR_RADIUS / MAJOR_RADIUS));
} ```
In effect, this function returns the ratio between the radius of the major circle and the radius of the circle created by a horizontal line placed at the given vertical position on the torus map.
With these functions available it became easy to orient entities on the torus surface along their direction of travel. This was handled by the inbuilt Unity function Transform.LookAt(Transform target, Vector3 worldUp), which rotates the operand transform so its forward vector aims at the target transform and then rotates the operand transform so its up vector aims in the direction given by the worldUp parameter. The target transform was an empty object whose position was set by the get3DLocationFor2DLocation function; the parameter to which was the entity's 2D position plus its normalized velocity. The value of the worldUp parameter is the surface normal for the entity's position on the torus surface.
Positioning the camera above the player object was done by directly setting the camera’s position to be some distance along the normal vector from the player’s current position. The camera’s orientation was set by the Transform.LookAt() function; though the camera’s own up vector, transformed into world space, was used as the worldUp parameter. This allows the camera to smoothly follow the player around the surface without any jarring discontinuities in orientation or position.
One problem which gave me considerable trouble was that of relating camera local directions to directions on the torus surface. After a few dead ends, the procedure that is present in the final game is as follows: find a local 3D basis for the torus surface in world space, take a camera local direction and transform it into world space, and find the projection of this camera local direction onto the local 3D basis for the torus surface.
This local 3D basis for the torus surface is constructed for a given location on the torus map and is comprised of the surface normal at the given location, and two 3D offsets found by adding to the horizontal and vertical components of the given torus map location. This set of vectors is then orthonormalized with the inbuilt Vector3.Orthonormalize() function. In effect, this set is used to describe the 3D directions which correspond to the up and right directions on the torus map.
There is a useful assumption that can be made; the camera is positioned along the surface normal and is oriented so that its forward vector is parallel with the surface normal. Due to this assumption, we can ignore the z direction of the camera and the vector in the local 3D torus surface basis which corresponds to the surface normal. This means that our directional input is constrained to the camera local x⨯y plane. We use the inbuilt Transform.TransformDirection() function, which maps the input direction from camera local space to world space. From here we can project this direction onto the two remaining vectors in the local 3D torus surface basis by taking the dot products of this world space vector against the right and up vectors respectively.
``` Vector3 torusHorz = ToroidMap.getTorusMapRightDirection (this.torusMapPos); Vector3 torusVert = ToroidMap.getTorusMapUpDirection (this.torusMapPos); Vector3 torusNorm = ToroidMap.getNormalVectorForMapLocation (this.torusMapPos);
Vector3.OrthoNormalize (ref torusNorm, ref torusVert, ref torusHorz);
Vector2 torusMapDirection = new Vector2
( Vector3.Dot (worldSpaceDirection, torusHorz),
Vector3.Dot (worldSpaceDirection, torusVert));
```
This procedure allows the player to indicate directions for movement and weapons fire in 2D intuitively. In retrospect, there is an analytic solution to finding the local 3D surface basis.
I very much enjoyed LD 38, and I was pleased with the end result of my entry. As with any game jam, there are always things I would have approached differently if I were to create this again. I hope this post has answered any questions about the implementation of this game you may have had.
Even before starting on creating Den, from the first day of brainstorming, we choose to step away from our 3D habits and go for pixel art. By lack of a game workflow routine, after a quick moodboard we jumped straight ahead into drawing a complete single illustration of the whole game, without much thinking about props and reusable assets for building the LD.
|
|
|
|:--:|:--:|
||
When came the time of integrating in Unity, we realized that this method would be pretty risky. Mainly because it meant that the level design wasn't flexible and wouldn't be tested before long. So we stepped back and switched to a LD made in Unity by using spritesheets of rocks with different scales and shapes, used as material to create the paths for the tunnels. It allowed us to allocate tasks more easily to multiple people on the team (that's obvious, but someone could change all the rocks in once by working on the spritesheets while others would work on integrating).
|
|
|
|:--:|:--:|
||
So something went wrong here, as we were a bit lost on how to manage the balance between fully controlled illustrations and flexible integration, and we lost some time in the process of figuring it out (we still didn't had a practicable LD on the beginning of the last day). It led us in the end to a lack of time to take a second look to the LD, that would have revealed an issue with the clarity of the last puzzle.
But despite this difficulty we were all along able to produce graphic assets without so much trouble and in the end creating the visual atmosphere went pretty right.
Hi,
tomorrow I would like to play some games and maybe stream it. If you want me to play your game and give you some feedback just comment a link!
Of course it would be nice if you play my game and leave some feedback :wink: https://ldjam.com/events/ludum-dare/38/where-is-mommy
A sci-fi game with rave party colors.
https://ldjam.com/events/ludum-dare/38/ld38nameofgame
It has a little story, if you want to read, it's on the itch.io page: https://elvismd.itch.io/ld38
Judging goes live, hopefully, in a bit. Check out The Cookie Knight I try to make it so any that play my game usually get a play of theirs.
That said, if you want to leave a comment of your game I may add it to my list of games to play. My goal is to play a minimum of 100.
P.S. Don't forget to go back and rate the games you played before ratings went live!!! I have a list for mine!
I wrote a long post describing how Rogue Basement works, how I made it, why I made various decisions, and how those decisions impact the player's experience.
I was going to post it here, but the text field has an 8,000 character limit! So:
My second-favorite part of Ludum Dare starts soon. Last time I participated I played something like 200 games, and had so much fun trading game design comments with all the incredibly talented developers. You learn so much by having to rush from concept to release in 3 days and you learn even more by finding out what other people liked/disliked about it. I look forward to judging and getting judged!
Shameless plug for my team's entry: https://ldjam.com/events/ludum-dare/38/eine-kleine-insektmusik

This is my first Ludum Dare so I wanna try as many games as possible! Send em' my way in the comment section!
And please try my game as well! https://ldjam.com/events/ludum-dare/38/secluded
I can't wait to officially play your games :D It's such a rich experience everytime, see what we can accomplish in a weekend !
I finally was able to post my game for this LD, I went all in with the idea of a procedural universe and exploring a world in 2d and 3d. I hope you will like it !

When the Theme was announced it was 4am here, but I stayed up to find out. I started brainstorming and got a few ideas - one of them was about how the Earth looks like a small world to the Moon, and how if the Moon would roll on the Earth the player would have very little time to see things coming from the other hemisphere. Just before falling a sleep the idea to give everything a beat struck me. Luckily, I wrote it down...

But keeping the game in sync with the music turned out to be very hard and any difference between the gameplay and the music just makes it all unplayable. I had to use several tricks, hope you can learn from them: * Adding delta time until >= beat time and then operate * Save the reminder instead of just putting zero on the counter * Occasionally sync with system time to adjust for mistakes * Save the background track with multiple loops built in to remove looping delay * Synchronize the start of the game with the start of the music by firing an event when the music starts in it's thread rather than just when I tell it to start * adjust for clock changes between said event and game loop

You can check out the game here:
https://ldjam.com/events/ludum-dare/38/one-giant-leap
Hi everyone!
We are really excited that the judging time has begun and we can't wait to get your feedbacks :slight_smile:. This gamejam was our first entry as Mineo Games (indie studio from France) and 5th altogother!
In this 3D game, you will play as a Dung Beetle who want to bring food at home. But sometimes the world does not go easy on small creatures :scream:.
Here is a "nospoil" gif to show what the game looks like!

Overall, we are very happy with the result. Of course we could have improved the game a little bit more if we had more time. We are very satisfied of what we built, it was what we thought it would be!
Have a good fun playing our game!
https://ldjam.com/events/ludum-dare/38/dung-beetle
Mineo Games.
https://twitter.com/mikekasprzak/status/858852885874003968
FYI :)
From Mike's twitter:

Whoo boy, I had just barely finished on time before submission hour(s)! And by finished, I mean it's basically art-less and probably extremely buggy. I would have loved to do more with the game, as it is quite short and not exactly great-looking. However, since this is my first Ludum Dare game as an inexperienced game developer, I'll take what I've been able to crank out. All in all, this was a great experience to help give me the push to finally finish my first "full" and relatively finished game! Can't wait to play other submissions!
So that being said, check out my game, Glop Plots! It's a bit of a mashup between an idle and a building/puzzle game, where you only have a "small world" of spaces to be able to build things on to gather your resources.
Take a look here: https://ldjam.com/events/ludum-dare/38/glop-plots
Seeing as we're nearing the start of the judging period, I tought I'd just adverstise my game a little bit. It's called 420 Planets.
Me and my partner @nightedge3141 teamed up to make this over the LD weekend and it was quite fun. When we first started brainstorming, we managed to get a pretty basic concept inspired by Mario Galaxy. And then for some reason we decided our character was gonna be high :rofl:
Seeing how my teammate doesn't have a lot of knowledge or experience in coding or graphics, he gave the ideas for the game and I made the rest. It was still a lot of work and to add to that, I was working at my part-time job all day Saturday and I had school on Monday, so I was very limited in the amount of time I had. We still managed to make mostly everything we had originally planned and I finished at the very last minute.
The game itself isn't much, but I'd say it's pretty good for a self-taught programmer, pixel artist and sound designer. I suggest you go play it here.

This post is a bit late, but here's our little advert and our brief post-mortem of making the game.

Build ships, and watch them go! Your success in-game will (mostly) depend on how well you build your ships and how well you consider the funds you have each round.
So give it a spin, let us know what you think!
https://ldjam.com/events/ludum-dare/38/angery-ships-only
And now, on to the post-mortem!
This was our first project as a team, and the first game we ever made in Unity. It was clear that we wouldn't have enough time to finish a lengthy, polished game (since high school students never have enough time to do anything) so we tried to make the game simple but fun.
When the theme was released, ideas were tough to come by. Some of us came in thinking we'd make an adventure game, others had an RTS idea in mind. Genres floated around and we had to make compromises. In the end, we floated around the idea of a sandbox-esque strategy game where you build ships and they fight enemies.

The idea was fresh and clear.
Then we started getting stuff down in code and everything kind of collapsed for a moment.
None of us were really on the same page as to how the code should be structured and how the game itself should be structured. Implementing our "simple" idea turned out to not be so simple. We had trouble keeping everyone together behind one idea, and this was one of our biggest challenges during the Jam.
We almost pulled an all-nighter to make a rudimentary simulation of ships flying towards enemies.
Saturday morning, our first priority was cleaning everything up and making our code cleaner. Although our code still ended up being jankier than a car held together with duct tape, this helped make it possible to add more features and improve the game.
From then on everything went by more smoothly: We figured out how to get clear ideas across and manage our time. By the end of Saturday, our ships were modular and they attacked enemies.
Sunday went by really quickly, and we ended up fixing issues that seemingly came out of nowhere.
Monday was a blur. We finished implementing the ship editor and we had lots of balancing to do in attempts to make the game possible but also not painfully easy.

We got ahead of ourselves and we thought we'd make it smoothly in time for the deadline. We were mistaken.
While we did finish our game, our submission was only ready around 10 minutes before the submission deadline (we weren't aware that there would be an extension!)
And it turns out our game was actually incomplete!
After building the game for any platform, the game became unplayable after the first level. This was caused by an uncaught exception, which never appeared during the development of our game. This was fixed the next day but it certainly put a big dent in our morale.
Needless to say, this has been incredibly valuable for us. We hope to improve on our mistakes and hopefully get more sleep next jam.
Until next time!
https://ldjam.com/events/ludum-dare/38/cardboard-cats-online
I've had the server up all week with no problem, max of 20 players.

Looking forward to judging, seeing some more folk online! If I don't respond, I'm asleep or at work, but the server should be up for the next couple weeks (at least) I'll announce if the server goes down or if there is a big enough bug that stops people from playing for me to fix and have people download a new version!
Thanks for stopping by, come on in, say Hi, leave a rating or comment! <3
https://ldjam.com/events/ludum-dare/38/planet-bash-1
Ready for the judgering! Kind of anxious aswell. I'm quite proud of how it ended up before I submitted it, but I am already working on a better and more enjoyable version for when the judging ends. All the entries have simply blown my mind, so much creativity around here!

We just finished up the cover art for our game µP-8: Microprocessor!

This is my first Ludum Dare and I'm excited to get some feedback on my game. Thanks in advance and you can find it here.

Now that judging has started, I wanted to release my postmortem. Here goes. This postmortem is based on the same categories Ludum Dare itself uses for judging.
But first, the basics! LD38 was the first game jam I've participated in, and resulted in the first game I've ever released: Booster's Day Out. * ### Visit the itch.io page to play Booster's Day Out in glorious WebGL!
After years of making excuses, I finally participated in a Ludum Dare! Better yet, I finished a working game with a win condition by myself in almost exactly 48 hours; my final commit was 92 seconds before the 6PM Sunday deadline! I had an absolute blast, and can't wait for the next one.
I'm pretty happy with the game, even given all its missing bits and rough edges, and plan to expand it in the future. I'd call that a pretty big success, no matter what happens in judging.

I've always been obsessed with physics-based games. To me, this version of BDO feels a bit like a miniature, extremely simplified Kerbal Space Program, which is something I find quite enjoyable. It's pretty dang tough, too; I still have trouble beating it sometimes! On the other side of the coin, it definitely needs more content. Right now, there's only one powerup (fuel), one type of obstacle (planets), and one level.

There's not exactly a ton of innovation here. Lots of people have made physics games before me, and lots will after. ¯\(ツ)/¯
BDO is a bit more "small worlds" than "a small world", since the whole thing is based on traveling from planet to planet. A bit on the nose, but gameplay over theme is best in my book! I arrived at the current gameplay by starting off with what I thought I wanted to do, and then going with whatever felt most fun as I built things out. Originally, my idea was a Super Mario Galaxy-esque 3D platformer! It took about six hours from the start of the competition for me to arrive at "rocket game".
I'm very pleased with the rocket itself, especially the engine particles (and the crash explosion, of course). The worlds are too bland, simply because I didn't have time to flesh each one of them out. In the planned full release of the game, there will be significantly more planet diversity, both in terms of shape, as well as items on the planets (plant life, landing pads, structures, etc). Overall, I'm happy with what I was able to achieve in such a small amount of time.

I like the 2D/3D environment, it seems like a good base and future direction for improving things. One specific thing I'd really like to play with on that front is subtly rotating the camera around the rocket a bit as it approaches and leaves planets.
Audio ended up super rushed (committed ~100 minutes before the deadline). I was only able to add a sound for the rocket engine and for crashing. Some sounds I'll be adding: fuel pickup, win condition, and possibly ambient "gravity"/"atmosphere" noises.
I also didn't get a chance to create any music, which is a bit of a bummer, as I was looking forward to trying my hand with that. Ah well, next time! For the full release of Booster's Day Out, I'm planning to feature some music from my good pal Kevin, who's also doing the soundtrack for my VR game, Microcosm.
I highly recommend checking out this sneak peek of Kevin's work during a second playthrough of Booster's Day Out. 👌 👌 👌
I didn't focus a ton on humor, but tried to make sure there were nice little touches of "soul" in the game. Specifically, this was done though floating text, which also serves as a tutorial. Also, you get little messages of encouragement when you die, which seems nice.

This is a spot where music would have really helped. I like the current mood, but the ideal Booster's Day Out in my head feels a bit more lonely. I think fixing those dang walls will also help with the mood a lot.
Let's talk about those dang walls for a second. I added the walls very shortly before the deadline to prevent three things:
To solve the current issues with the walls, they are going to be made much more transparent (maybe entirely), and moved quite a bit further out. To prevent level and "moon" skipping, I'll be using "asteroid fields" and other obstacles.
One of the things that really struck me about LD is how much it flexes every creative muscle you've got. Of course there's the code part, but not having a team or the ability to use existing design assets means everything falls on your plate. Code, design, modeling (in Blender and MagicaVoxel), "marketing" copy and images, sound, music (which I didn't get to), and probably more. It's really an incredible creative workout, and a great way to pick up new skills, or hone skills that need work.

Judging has started, so please check out and rate our game!
https://ldjam.com/events/ludum-dare/38/no-minor-task-party-of-a-lifetime

(btw, key controls: ENTER to fast forward cutscene, ESC to skip any scene, SHIFT to sprint. main level is also skippable by pressing 'P' if you can't beat it and want to see the ending)
This was my first game jam, my first complete Unity game, and our team was formed through Reddit(!), so I'm very proud of what we accomplished! :smile:
PiP. A multi-layered puzzle game.
https://ldjam.com/events/ludum-dare/38/$19665


A little TimeLapse video for our game murder38
https://www.youtube.com/watch?v=o6BWqGQrn_g
Its a click to move, obstacle course. If you ever played the "Bound" games on StarCraft 1, you will love this. There is 5 Difficulty levels to try.
Can play in on your browser or Download.
https://ldjam.com/events/ludum-dare/38/bound
