Well, this was the last thing I was expecting, honestly…
In the space of about one week, I’ve made a game, polished it, added features to it, polished it again, made a trailer, setup a store page, and put it up for sale.
One week.
This is why Ludum Dare is amazing.
Introductions:
Hi everyone, I am Luc, I am an artist and game designer from the southern tip of Africa. This was my first time game jamming alone, my goal was to create a game for the compo, but alas, it was not ready in time. Below are the details of exactly what I feel went right in my first solo game jam, and what went wrong.
A brief Caveat to my game concept was that Eskort Mission was not on theme, I had a game idea before hand that I wanted to explore in the jam.
What Went Wrong:
AI: this represents the first time I was tackling AI, and its spotty at best. My games enemies path-finding is mostly dodgy, the solutions to the collisions, even more so. I need to explore the Gamemaker grid system in more depth to fully fix the problem, but for now enemies are a bit too effective at running at the player, therefore are too hard for uninitiated players, and are not fun. Furthermore their path-finding can often drag them through vehicles and building unopposed. My tired minds solution was to have objects slowly move enemies out of their collision boxes… which makes for some weird bugs and sticky movement.
Tutorials and Communication: From feedback I have realized that players feel a bit lost. The procedurally generated maps become labyrinthine and finding cats was difficult for most player. The cats AI also stops following the player at a certain distance. Interactions with the cats therefore feels sometimes arbitrary and at worst frustrating because finding them and making them follow the player is difficult. To mitigate this I find I need to add communicative devices to let players now how my systems are working.
There was also feedback regarding finding the way back to the chopper. I tried to provide an arrow with an “E” to make it easy to find ones way back, but given how many players got lost, this is evidently not effective enough at communicating. I need to explore other options, perhaps a mini-map, or a arrows in the heads up display.
Players also remarked on how the games goals were not explained. The lack of an appropriately explication of the games goals detracts from the overall experience.
bugs: There are some occasional graphical and drawing issues which cause some strobing between tiles.
What Went Right:
learning to code: I set out with a few challenges to meet in this jam, the most predominant of these was my resistances to coding (what I do is not so much coding as scripting and will be referred to as such from here on). While I have scripted before, in both Unity and Game maker I was an artists and used them mostly as tools for getting my art on display. Forcing myself to create a complete game play loop within the 72 hours really taught me a lot about successfully creating a game.
the first thing I learned is that it is important to get a game play loop in as fast as possible. Too often I find myself stressing over the feeling of the shooting, The random generation of tiles looking good, or the specific timing of the enemy firing rate, and leave the games loop to the last few minutes of the jam, making my games feel like galleries of activities rather than games. Focusing on finishing the game play loop timeously allowed me to better assess the problems with the game play at an earlier stage of the game jam. This left me time to fix things things (though there are still many bugs and issues, make no mistake :D).
Making Lists: Completing my scripting tasks timeously would’ve been impossible without setting out lists of what I wanted to complete and at what times I wanted to do things. This both gave me a feeling like I was approaching completion, as well as keeping me on track for completion and ensuring I didn’t get distracted.
Planning: I had a plan of what I wanted to do before the jam, while this meant I strayed from the theme, ultimately this helped me be determined in creating the kind of game I had envisioned. However I was also flexible with this plan, compromising on frivolous details and many of the features of my original concept (which was about guiding reckless soldiers who resemble lemmings away from danger and to the Evac helicoptor).
Art: I did all the art in the Sunday of the jam, I was rather chuffed with how quickly I managed to get it all out. Though the tile sets were not quite what I wanted, and the solution to auto tiling was not very robust, meaning the layout of tiles was hap-hazard rather than planned.
List of excuses:
Ignoring the theme: In the end I acknowledge that this will count against me, and In future I may find that sticking to the theme will provide a enjoyable and stimulating challenge.
Not sleeping enough: This seems silly, but going to bed late in the morning really affected my productivity. On good sleep I was able to fix problems quickly that in my tired mind I was unable to work around.
Travelling and sickness: A spot of Gastro and having to catch a flight on the last day of the compo ate into time I would’ve liked to spend fixing bugs.
Conclusion:
For the first time doing a jam by myself I was proud to have made my thing, broken as it is. While jamming alone is a great learning experience, I did miss the company and camaraderie that comes from a group game jam.
I really hope you guys enjoy my little game about saving cats.
regards Luc
It’s all about that forest magic and a bit of finger dancing today. Just don’t get caught with your Mushroom Hat off!
Check out Dizzy Dazzle by Tselmek & Ted Wennerstrom
Play around with Enliven by Patacorow & lonebot crew
It’s not too late to submit your game or a game your pals have made. You can send it to Larry in this fancy form thingy -> over here.
Tags: Dizzy Dazzle, Enliven, Larry Chupacabra, Larry Does Ludum, ld34, Youtube Showcase
Still far from complete, but I liked where I reached, hope you like it too! o/
You can play it here http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=11311
This was probably the first Ludum Dare in which I was actually almost completely happy with the end product. What I amount that happiness to is the personal goals I set for myself. Instead of having my goal be about making a complete game at the end, I made it about having a game full of music and art that I was happy with. Another goal I had was to try to make another story-based game. I wanted a cohesive experience that used art, and music to help the story telling. My last goal was to not get bogged down by programming. I didn’t want something difficult, I wanted something simple that I could whip out. I knew that programming was the one aspect of LD that (at least in recent times) has bogged me down and de-motivated me to the point where I was not happy with my product. Don’t get me wrong, I love programming, but gamedev programming has been hard for me recently and I wanted to continue my break from it. I also had a bonus goal, which was this: Live record my music. Instead of using all of the software instruments to create my music, I wanted to record it myself. At least a little bit. I succeeded.
With these goals in mind, I knew there was a high likely hood that my success hinged on the theme. So I decided that if a theme was chosen that I didn’t like, I would go with my own theme (I choose the theme “Isolation” for this). A lot of people wouldn’t agree with this, however this time around I didn’t want the theme to be the challenging factor, I wanted it to be a guiding factor. Sometimes if I make a game based off of a a theme I don’t like, I’ll produce a loveless game. Luckily there were two themes for me, which worked out super well. I think that the dual theme was a great point about this LD, many games were produced that were fantastic, as well as a good variety of games.
What follows is a day by day account of my process.
So I started out by going to the store and buying my game jam food. If you want a list it goes a bit like this:
You may notice a big lack of classic junk food, which is amazing for me and Ludum Dare. If anything, doing the “healthy” snack of dinky oranges (all gone by the end of the jam) and bananas worked out well. Also, this is the only time I really buy myself a pack of soda, so it was a nice treat.
Usually I use the walk to and from the store as a chance to brainstorm, but I didn’t really get very far with that. The most critical part of LD is the brainstorming. Thats bolded for the people who just skim the text and look at the pictures. So I went to place that would be perfect for brainstorming. “The Cube” is a room at my school used for orchestra rehearsals and various performances. At night, its vacant, with a piano, 8 speakers, and a whiteboard. I had a lot of pacing space, and would listen to music and just think. I think the hour or two I spent doing this was by far the most productive of my whole LD. I got an idea I loved, as well as an idea for my music, my art style, and a vague idea of the themes and lessons I wanted to use in my story.
At the end of this brainstorming session, I knew I wanted dancers, I knew how to get that dancing, I knew what music I wanted, I knew the art I wanted, I knew the themes and lessons I wanted to use. What I didn’t know was how it would all go together, and what sort of gameplay it would have. I knew I wanted to you to be able to “control” your dancer, but I didn’t know what sort of goals and penalties there would be. At this point I was still trying to make a full on game.
I then set out on my music creation. I wanted three movements, the first upbeat, ignorant, and happy. The second was isolated, dark, and pensive. Third was to be a waltz which would be happy (but not overly), but also matured. I worked mostly on the first movement and got it out of the way, I then moved to the third and got the basic waltz and melody figured out. Never doing a waltz before it was hard, and so I had to draw inspiration (and the basic um-chuck-chuck) from another song. Its all part of the learning process after all. That would be the end of the first day (it was around 3am).
I had to focus on art. I knew exactly what style I wanted to use. It was a style I saw in a print Kusaka Kenji at a museum that gave the perfect sense of movement. Because it was a jam, and I didn’t want to waste time on something I am the worst at in art (I’ll improve later), I actually took my palette from a print of his. Part way through I realized I wasn’t getting what I wanted, and decided to scrap it and start over. I had decided that I didn’t think out the form well enough and it lacked a cohesive feel. However, after I got a snack and a step back, I realized that what I had wasn’t bad, but I still needed form. To do this I layered on top my “isolated” motif, which was an orthagonal overlay that stood separate from the backdrop. In the end, I got a background I really liked (and still do). I started programming at this point, and throughout the rest of my daylight hours (only till 4:30pm!) I would intersperse my programming with the rest of my art creation. In the evening I transitioned into more music creation. I was going to record my (improvised) second movement at around 10:00pm. That time came and I set up my microphones (2 on the piano, two on the room, and one below the piano), headphone mixes, and had my drop in engineer take a couple pictures while I finished the routing.
Here is a picture of my recording set up (not seen are two room mics behind and to the right the camera):
Brief postmortem on that session goes as such:
Pros:
Cons:
One important thing to think about is that the piano is great for a number of reasons. It sounds great when you play it, but it also sounds great when you tap it, hold sustain pedal, brush the keys, scream into it, and do all manners of things.
My goal for the end of the day (night?) was to have all of my music done and mixed. I finished my recording at around 1:00 am and then moved to work on my waltz some more. Throughout the night I would hop around my three pieces of music, and got closer to the goal. At one point I realized I wanted some background noise to my second movement that you probably never even noticed. So for a few minutes I went outside and played around with various ways to record rain. The sound I went with was the sound of water hitting the leaves of a shrub. I finished my music and finally got to bed at 6am. Much later than I wanted.
At this point I was slowly realizing my goal of entering into the competition was going to be a bust. I knew I had to make more art (I hadn’t made the “branch” sprite yet), needed to write a story, figure out gameplay, and compile it all together. Because I only had around three hours of sleep I’m not fully sure how this day went. The biggest part was the creation of the story. At this point I wasn’t sure what story I wanted, or how I wanted to tell it. After talking on IRC I realized I wanted something like a one sided conversation in letter form. Although for some reason I totally forgot about it until midway through writing, its somewhat like the lyrics to the Juliet Letters (lyrics start at ~0:50):
Parts of the text were inspired by this album as well as the Les Misérable soundtrack. My line of text “I saw the world reborn, you saw it move on.” was a direct reference to this song (which has the most emotional impact on me of the whole musical):
I got the text all written, went to refine. I choose themes and emphasized them, I created reoccurring motives. My goal throughout all of this was to make it feel as if you were peering into this fellas private notebook, which was somewhat a stream of consciousness, going straight from his brain through the ball on the point of the pen and finally bleeding into the paper. This is how I rationalized using silly out of place phrases such as “Am I a fungus?“. That specific line was more or less an inside joke with myself that I was dying to put in, and was relishing the reaction people would have when it came at the time it did. Hopefully people realized how it related to the line “Our failure taught me that I can grow. This death just feeds my growth.” Throughout my text writing process I was brainstorming names for the game. It was only when I ordered my text in its appearance in the game did I realize I wanted the last line to be “I finally learned how to dance.” Which is a bit surprising as dancing is the core of my whole game. Funny how that happens.
After writing the text I had to decide how to put it in the game. I realized I wanted a kind of collage that would transform throughout the game. To do this I used photoshop to create my text in .png form as well as place them to my liking. Although this meant a lot of dull and repetitive work, I think it was a good choice.
By the end the night I had my story written, made the text placements in photoshop, semi-exported manually into the format my game could read, and had the timings done. I had also improved my dancers dancing and created the branch sprite. I had a mostly complete game at this point. I had more I wanted to do though. I wanted to add shaders to improve the mood and feeling, I wanted to fix my mixes (turns out doing final mixes late at night isn’t a good idea), as well as add refinements to the dancing. I went to bed at around 2:00am
Nothing new really transpired through the day. I added in shaders, improved the timing of the text elements, finished up the dancers, finalized the song’s mixes, title screen, and added in the ability to go fullscreen. The only hitch was fullscreen. It seems like the window resizes when going fullscreen, which would mess up just about everything in my game. The art was made to order, it is the exact same size as the intended resolution. While this is bad practice in general, it was a necessary one for LD. Also a good practice for my computer, as photoshop tends to slow it down, especially with large images. I eventually hacked in fullscreen support (overwriting framework calls such as love.graphics.getWidth()) to not destroy random aspects of my game but also have it centered on the screen. This along with one other minor thing (making all of the text white in the second movement) was my only real hacky programming I did throughout the whole of this LD. I packaged and submitted 30 minutes early. Although in reality it takes me about 1 hour to package and release so I was only done 30 minutes into submission hour. Only at 6:30pm did I finally get a chance to breathe, and say hello to my programmer pet, Monty.
If (and when?) I do a post-compo release I have a few things I would fix for sure. First of all is the music. While I like the feel and how it turned out, I need to refine the melody and give it a bit more form (in all songs). I also need to re-instrument it to be more unified throughout the entire game. I also need to redo the art, make a palette that fits the game more, as well as give the colorful part of my backdrop more of a formal idea (so it can stand by itself). I would also separate the art more so instead of it all fading in at once, I have bits an pieces fade in, as well as for the orthogonal layer I would separate it into lines and have each line move in independently. I would also redo bits and pieces of the text to make the times at which they appear more often as well as remove all of those spots where nothing was happening. Also dancing, I have ideas on how to improve the dancing.
Some links:
Tags: ld34, ld34 Postmortem, love2d, post-mortem, postmortem
Have received a lot of positive comments and decided to continue work.
So I’ve already done some after compo in the game.
Changelist:
Some of ideas I received from comments.
And I will be happy if you play Evilator and leave some feedback.
Know issue:
Lag after few seconds of playing in WebGL. Will find it soon.
TODO:
Just updated the Kongregate version of my Ludum Dare 34 games which can be played:
Note this is not a compo version so don’t use it for rating, if you want to rate play:
I have really enjoyed making this update and realizing just how bad (and wrong) some of the original code was. This means that some of the main features of this new build are bug fixes, but I have also updated spawning script to make the start of games more varied and fair and I have changed the UI to make it easier to understand along with some balancing and optimizations.
I will most definitely continue to update this game but for now only on Kongregate so as to not get the compo version muddled up on itch.io. However when the voting has finished this will also be updated to the latest version.
And as always, thank you very much for playing my game.
If you want to see what the changes to this version, here are is the Change Log:
V1.02v0
Features:
+ Added tile type display, building name will be green if it is the optimum type for the terrain type
+ Added some useful messages to give the user more information about what is happening
(e.g. that a building is already at the maximum level so can’t be upgraded any more)
= Changed fog to use curved edges similar to how the kingdom border is done
= Changed scenes to be loaded additively
= Changed resource display poll resources to be more correct
= Changed resource cost display to show current resources/net and cost resource/net change separately to be more clear
= Changed cost resource display colours to show effect of building/upgrade/attack where the cost will be red if possible
and the net will be dependant on the final net (i.e green if the effect will end up being positive, red if negative)
= Changed team spawning to be randomly generated to give more variety and be fairer at start (will mostly start with positive net for all resource types)
Balancing:
= Reduced amount of gold produced by towns
= Changed attack cost when attacking a different team to include the base cost of the tile dependant on the terrain type
= Increased starting resources to 100 for each type (from 20)
Bug Fixes:
= Fixed bug where lines would end up between tiles at certain zoom levels, now uses a default material with “Pixel snap” turned on
= Fixed bug where display tiles would not be destroyed when new instance of the game is loaded
= Fixed bug where upgrade cost was inconsistent/wrong
= Fixed bug where the cost for building/upgrading buildings was applied incorrectly
= Fixed bug where resource display was incorrect
= Fixed bug where team start locations where stored in a static variable making them not be reset on starting a new game causing
an infinite loop when trying to find a new start location
= Fixed bug where buildings could be downgraded to negative levels
= Fixed bug where you can attack tiles if you click on a development button when you can’t build upgrade
= Change internal method of accessing upgrade data to make it more difficult for me to make mistakes and made it work properly
= Other optimisations and bug fixes
Started working on the post-jam version yesterday. Wrapped up the first task today, have a look.
I won’t be releasing anything before I’ve finished the gameplay improvements as well.
Tags: godot engine, xmas
“Networking programming is hard,” I’ve heard, “don’t do it.” It’s been a common consensus among us programmers that online multiplayer is simply not a beginner-friendly material, let alone a game jam material. At the time, having bits of experience programming networked software in college, I agreed with this consensus. This left a strange hole in my large library of games: I have no online games listed. Perhaps it was the Ludum Dare 34 keynote that motivated me to kick this bad habit. Either that, or the Shia LaBeouf’s video mentioned in the keynote.
Either way, hack.source.net is the first attempt I’ve ever made at an online multiplayer game, and an open-source one to boot. Despite being a bug-laden, lag-filled, unoptimized experience, I’m proud of what I was able to make in the short time given throughout Ludum Dare.
hack.source.net is a 2-player online first-person shooter that allows one to hack and disable up to two buttons from the opposing player’s controls at any point in the game. Born out of this Ludum Dare’s theme, “two button controls,” hack.source.net forces both players to improvise as their best abilities are taken away from them. The game is played on the keyboard and mouse, providing each player with the following abilities:
Combining hacks allows for a variety of strategies to emerge. For example, one could leave the opposing player in the dark by disabling the forward key and the radar. Another may disable the back key and the shield to discourage the other player from playing defensively. Yet another could take the upper ground by preventing their opponent from running and jumping. It plays like the video below, which has an older build that does allow hacking two directional keys:
Historically, I’ve used #OneGameAMonth to learn new features in Unity 5, such as path-finding and the recent UGUI framework. This is for multiple reasons: for starts, even if my game turned out to be bunk, I still took something new and important away from it. Learning just one aspect of a game engine also helps me creatively, developing games that mechanically revolves around one focused feature. As of late, I’ve been focusing on creating Not a Clone mobile remake for so long, I haven’t had an opportunity to learn new things about my game-engine-of-choice. As such, I took the risk to learn and practice the latest UNET framework, using the hacking mechanic to justify the mandatory online connection. Even though the game is very rough on the edges, it’s still lauded for an interesting premise.
From experience, I knew that the majority of my time during this jam was going to be spent learning network programming. As such, I had to come up with how the game was going to be played as quickly as possible. In this case, I chose to use the first-person controller that comes with the Unity Standard Assets rather than the third-person controller. It comes with the game engine, after all, and it reduces the number of problems I would have to deal with such as camera placement. The rest of the design decisions came naturally from this first choice:
Seeing as menus are a common thing that needs to be implemented in every game, I created a simple GUI manager in my Template Unity Project before the jam. Originally, the GUI manager, along with various example menus for the most common functionalities, was made for a single-player experience. To my surprise, the same code proved to be a time-saving feature for this game as well, allowing me to create a large number of menus in a short amount of time. The hack menu, for example, was simply a re-purposed pause menu that doesn’t stop time, and includes an extra hierarchy of menus that lists all the buttons available for hacking.
Perhaps due to my exposure to Agile development, I always develop with an hourly milestones in mind. In practice, this meant that the first few hours were focused on following tutorials to sync the position of two players, and testing to make sure this worked. The next few hour is focused on syncing the rotation of both players, and testing to make sure this new feature behaved properly. Next hour was on shooting, and so forth. Even the most basic feature was put into its own milestone, followed by thorough testing. To help this, I used tools such as version control (Mercurial + BitBucket) and continuous integration (Unity Cloud) so I can stay focused on coding and testing.
This strategy proved vital for this project since I was just learning network programming, and thus, prone to making errors and mistakes. By testing often, especially after a new feature has been implemented, it helps reduce the time spent on technical problems by keeping the scope of changes small.
I have a bad habit of focusing on graphics too early in development, which leads to a beautiful game that needs gameplay polishes. This time around, however, I worked on graphics last, which provided me more time to work out technical problems. Unfortunately, technical problems defined my entire development process of hack.source.net, so this isn’t saying much.
As it turns out, I was planning to work with barcode on MaskGarden on the first day of the jam. They overslept, however, and arrived at our real-world meeting place at around 5:00 PM. In a bit of a pickle, I’ve decided to start on my own project at around 1:00 PM. Those doing the math and correctly assuming we live in the Eastern timezone will realize I lost 16 hours. Yikes!
Network programming is hard. This bears repeating: network programming is really, really hard. A huge annoyance I needed to deal with while testing was the actual setup itself. For a single player game, testing a feature is as easy as clicking the play button on Unity. For networked game, I needed to build the game (a long process on its own), play it, then press play on Unity and connect the build to Unity. I would have to test both the game running on Unity and on the build to make sure when either sends a message to the server, the other receives that information. And this is before I notice something goes wrong! If something goes wrong on the build side but not on Unity, I then have to stop both, host from the build, then connect Unity to the build to check for any errors that may appear on the console. And if I make a fix, I need to go through all this process again to verify it’s gone.
Needless to say, testing and debugging a networked game is a time-consuming process. Since I was just learning how to code with networking, technical issues would occur often, and the grand majority of time developing was taken from debugging and the many attempts at fixing bugs. This experience sure gave me a whole new respect for network programmers.
One major feature I never got around learning, let alone implementing, is the latency prediction in most online games. This is pretty huge: I knew that I needed to keep the data sent to the server to a minimum, so I could have drastically improved the user experience by making predictions to player movement and bullets. Sadly, the debugging process alone was enough to punt this feature out of the scope of the jam, leading to a very laggy game. As someone who prioritizes the user experience above all else, this is very shameful.
Sadly, I was never able to find the time to have the game play-tested by other players. Consumed both by the debugging process and hosting the real-world meeting event at the same time, there simply wasn’t enough time to ask others to play, let alone setup. Given this nightmare situation, I simply went with the fastest, minimal plan. Naturally, this resulted with an unstable, laggy, difficult-to-setup game.
The current game requires setting up your computer’s firewall properly, and knowing how to obtain your own IP address to send to your friend to connect to your computer. Due to the minimalist peer-to-peer network setup, a lot of Ludum Dare judges could not actually play the game. This obviously breaks down the most important feature in Ludum Dare: the online feedback of other developers, letting you know what you can improve on next time. It would have helped if I knew how to make the process of connecting 2 players easily, such as creating a lobby server everyone can connect to and find others online to compete with. Obviously, this is well beyond the game jam scope, but it would have been nice to have.
At the same time I was developing hack.source.net, I was also organizing our real-world meeting. Fortunately, the meeting has gone very smoothly, with our participants creating 8 new games, including become a game developer in 60 seconds. That said, the weirdest experience I had throughout this event was when we were visited by a certain tourist. To clarify, we reserved a quiet community room in a makerspace building, so while the makerspace receives a lot of tourists, the room itself remained a quiet and productive place. We did have, though, one persistent visitor who was curious enough about game development to ask if they can see what I was doing. I agreed to this, but immediately regretted it when they sat next to me, staring silently while I try to figure out what I was doing before. This experience only lasted for about 20 minutes, but it was the most awkward moment I had in a jam. I can only say I’m glad I was the only one who suffered from this.
Chanced are very high the next game jam game I’ll work on will not involve with networking again. The time spent on testing and debugging alone is enough to make the task unfeasible in a short amount of time. That said, for any longer-term projects (such as #OneGameAMonth), I think it’s worth learning how to create latency prediction and lobby servers to create a more streamlined experience. Improving hack.source.net, especially down-grading the power of hacking, will need a lot of brainstorming and efforts that won’t be easy to do alone. Efforts on that game will probably remain stagnant for a while as I finish developing Not a Clone.
Also, to avoid the same strange visitor incident from happening again, I’ll need to let the building organizers know that we don’t accept tourists into our area.
Tags: hack.source.net, postmortem
So, over the 30-some-odd games I’ve rated, I’ve actually seen quite a few cool games, and so today, I would LOVE to show you guys some games from us little guys who aren’t complete geniuses, yet.
First up is All Ways Down, which while it’s not very fancy, there is DEFINITELY some cool potential for this one.
Here it is!
Next up here’s the Rap Game, a fun, oddly strategic, fighting game, where you actually don’t hit anyone.
Here it is!
The Serpent’s Shadow is by far the most innovative game I’ve seen. It’s use of shadows, bunny eating, and the classic Snake mechanics is genius. Check it out here!
These are my favorites so far, so check out my game maybe, leave a comment, and I’ll see yours too!
Hero Feed Co.
Looking for a holiday game jam to participate in? Look no further than the SUPER MLG CHRISTMAS GAME JAM! It’s a Christmas themed jam on GameJolt that runs until the 27th of December. The winners will be featured on my YouTube channel. This jam should be loads of fun and I hope to see some of you folks there!
~Keep it indie~
Have you ever wished you were a cat locked in a food factory with a voracious appetite? Now you can be!
If you haven’t voted for Fat Cat yet, head on over and check us out! Thanks!
Hi people!
We are “Team Glitch Happens” and we made the game “La Mano Loca (Sticky Hand)”.
If you’re interested, check it out here: http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=66113
These are sketches of the level design of the game (Sorry, but it’s only in Spanish)
Thanks for all and Merry Christmas!
With the Christmas break starting, we finally got the time to write proper post-mortem and finish the post-LD version with improved graphics for our LD34 game “The Tournament”. You can check it out here. We also uploaded the source code if you are interested to take a look.
The game was designed to be an arena manager simulator, where you manage team of robots to get as many victories as possible. You don’t have the direct impact on the fights (as you are just the coach – not the gladiator), but you can choose the fate of the defeated opponents, suggest tactics to your fighters and choose who shall face each opponent.
What went good:
What went wrong:
Overall though, the Jam experience was a blast for the whole team. We learned a lot and had a great deal of fun 
Can’t wait for the next LD 😀
PS. Our music artist uploaded the Full OST to the soundcloud. It’s pretty sweet:
Tags: post-mortem
Just wanted to highlight these awesome games. Check them out.
Frank & Stein by vegapomme27
Frank & Stein is just a really well made compo game. Graphics, sound, are all top notch and work together really well.
Rude Bear Recreation by Alex Rose
Rude Bear has the most fun gameplay of all games I played here. Mechanics are really simple but feel awesome to use. And the game has a lot of checkpoints, so it is not frustrating.
Hey there, folks!
This Ludum Dare has been very meaningful to me, beginning with the fact that I started working as a freelance programmer to make other people’s games while trying to live, it was about time (after missing 3 Ludum Dares), for me to make a game of my own.
To be honest I started this journey because I wanted to experiment with Unity’s WebGL and the WebSockets implementation, which turned out not being as hard as I expected. In the middle of the weekend I began to work on Tama Battle which ended up being my entry for this edition.
Combining a bit of RPG, a bit of Multiplayer and a bit of RANDOMNESS I created this little game, that is already turning into something bigger. Yeah, because fuck it, I want to make this a brilliant and beautiful game, something people can enjoy everywhere (Mobile & Browser based), because that’s why I “signed” into being an independent game developer. Not to make someone else’s games.
And that’s why I’m happy to announce the following new features coming by the start of next year (start of January):
There will also be a website for the game ready sometime before this month ends (http://tama.devmidgard.com/), be sure to check it out!
And that’s it for the moment, you can go and enjoy some christmas season fights while there’s snow on the game!
View & play the game here: http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=11046
Cheers,
Midgard.
Oh, I almost forgot, there’s a hilarious gameplay video someone made (really appreciate it!):
Time for another post-mortem! If you haven’t yet, you can play Earth Invader here!
For this Ludum Dare I didn’t actually learn anything new… I was very focused with my own project that I didn’t learn anything particularly new. I actually started developing a new engine which would support 3D, but it’s way too far from being complete, so I decided that I would use Unity, since in my new project I’m going to use it anyway, so might as well begin practicing!
What went right:
This was my first time using Unity to release a game, and it went pretty well! I’ve tested before with some tutorials so I already knew that it was fairly easy to make something. The work flow was really smooth and wasn’t so difficult. Although I did want to make this game with my engine, it was good learning and worked well.
At first I was going for pixel art with GIMP, but then I thought, well, I always wanted to use Krita and try another graphic style. And so I did, and I’m pretty satisfied with the result! Krita is a great tool, even though I don’t have a tablet to draw I was able to use it well! It was difficult in the beginning to adopt a whole different style, but I guess it was worth it
As always, I used Bfxr for sound effect and Bosca Ceoil for music. It worked like the last Ludum Dare, nothing new, but the result was nice. I did have some difficulties with my composition, since I still only know the basics, but the result was something I was happy with
In this Ludum Dare I tried some of new things. Uploaded the game at itch.io, did screen recording (I wanted to make a timelapse, but didn’t work well)… It was really fun and really good learning for my future projects!
What went wrong:
This Ludum Dare was pretty harsh for me… I was really tired from work, then I spent the first 12 hours just trying to think a concept that I was happy with, then the energy went down in my house, and so on…. Yeah, not the best situation…
Although I’m happy with the style I adopted later, I already had some assets done so I had to remake them (I didn’t really, just made some touches to adapt them), so it got a bit inconsistent.
I really wanted to have more playtests, but I didn’t have any… I really need to start searching for people that are willing to do that…
Conclusion
This was a really difficult Ludum dare for me. Not so much on technical part, that went pretty well, but setbacks from life. But still I managed to overcome them all and finish a game that I’m actually satisfied with! I really didn’t expect that… Even now I’m still pretty tired from the last part of the year, but I’m going to rest a lot this holiday! And let’s hope for a great year that’s coming! For the next Ludum Dare I hope I can finish my engine, get some more composition practice and make better animations! Congratulations everybody! Keep up the great work and let’s even work harder next time! Happy holidays!
PS: Sorry it’s a bit hastily, I’m a bit short in time here ^^;
