My first Ludum Dare, the majority of Saturday morning missing, a laggy computer and very little experience programming games. What could possibly go wrong?

So yeah, I’m Hunter X and this is my first Ludum Dare. I’m mostly here as an opportunity to practice my programming skills (I’ve developed a number of small programs either as personal projects or private commissions, but never anything major), as well as to see what it’s like to take part in one of these competitions. I’ll be using C# and XNA for my project (unless I miraculously learn Java in the next 3 days), with either Paint or Photoshop as my image editor depending on what I end up making.

If I actually get anything off the ground I’ll be sure to post about it, but having seen some of the entries in the past I’m doubtful I’ll get anywhere near them on my first try. Still, all experience is good experience, right?

At first glance, there doesn’t seem to be much room for interpretation with the theme Tiny World. I’ve seen a lot of people working on games that take place on small planets or maps and I’ll admit that was my first idea too. Then I had the idea, why not represent the regular world but in a tiny form? I looked at quarks, the smallest objects in existence that comprise protons, neutrons and all other particles, and had the idea to build a construction game where you start with quarks and build up to the larger forms of matter. (I suspect this game would’ve been valid if Alchemy had won, too!) An obvious inspiration is Scale of the Universe, but my game probably won’t function in exactly the same way – for starters, there’s no way I’ll be able to represent the same scale range as that.

In a few minutes I’ve got to head off to my Computing class (Saturday lessons FTL) but once I get back I’ll be getting down to work on this game. At present I’m working out in my head exactly how I’m going to structure the program, and hopefully soon after that is sorted I’ll have something to show you guys.

http://create.msdn.com/en-US/education/catalog/sample/game_state_management

Am I allowed to incorporate this code into my program and still be eligible for the Compo, or would I need to restrict my self to the Jam if I did? The code is licensed to allow free reproduction, but I’m not sure of the specific rules concerning sample code like this – do I just need to declare it as with personal code, does it full under ‘publicly available libraries’ or is it not allowed altogether?

Thanks in advance

So I’m almost through my first day, and in that time I’ve managed to port an existing code sample into my program and change the names a bit. TRULY I AM A REVOLUTIONARY PROGRAMMER.

In all seriousness, the code I imported was a screen/menu system which greatly simplifies my work from here on out – now I just need to focus on handling gameplay code instead of fussing over the skeleton of my program. Also, my game now has a name!

Hi, I’m Hunter X and I’m hoping to enter this Ludum Dare! I tried entering a couple years back but didn’t get very far, but I’ve done a lot more programming since then (and am currently at university studying Computer Science) so maybe I can do a bit better this time. That being said, I have a few other commitments throughout the weekend, so I don’t know whether or not I’ll be able to finish, but at least it’s good experience and gives me something to do in my free time

• Engine: Unity
• Coding: C# in Visual Studio 2013
• Artwork: Paint or Photoshop
• Libraries: Probably the Scaffolding View Framework, beyond that I haven’t decided.

More news if and when it happens.

So this is my third attempt at entering a Ludum Dare, with the previous two times not going well due to other commitments throughout the weekend. Thankfully this time around I’ve got less to deal with over the next day or so and over the last couple of years I have been practicing with a number of personal programming projects, so hopefully I’ll be able to come up with something vaguely presentable by the end of it. I’m currently using Unity and Visual Studio 2015 to produce my game, working in C#.

My interpretation of the theme was to produce a platforming game in which the entire game takes place on a single map; as the player progresses the camera gradually zooms out until the whole level is displayed on the screen at once:

At the early stages this concept is fine, but as the camera zooms out it gets harder and harder to see anything of importance. In order to counter this I decided to implement a ‘magnifying glass’ feature, in which holding down a specific key will overlay a second image over the first displaying a zoomed-in view of the player. However, the magnifying glass both obscures the zoomed out map and is zoomed far enough in itself that to rely on it too much will leave the player vulnerable to hazards that they will be unaware of until the last moment.

As it stands the majority of the code is in place – barring tweaking the player movement script to solve an issue in which moving towards a wall while in mid-air will cause the player to stop falling, the main things that I need to work on tomorrow are expanding the level design and updating some of the art (I might stick with the black-and-white theme, but that placeholder stickman really needs replacing). If possible I’d also like to look into ways of expanding the functionality of my game – barring the expanding and magnifying glass concept, there’s not an awful lot that separates my game from every other obstacle avoidance platformer out there.

See you in the morning!

Play now!

Dodge the obstacles and try and make it to the end, but be careful as the map expands and makes things harder to see!

My first completed entry for a Ludum Dare, in all its buggy glory. I took the concept of an entire game on one screen and decided to implement it in such a way that the camera gradually zooms out until the entire game map is visible at once. You can also make use of a ‘magnifying glass’, in which holding down a specific key will overlay a second image over the first displaying a zoomed-in view of the player. However, the magnifying glass both obscures the zoomed out map and is zoomed far enough in itself that to rely on it too much will leave the player vulnerable to hazards that they will be unaware of until the last moment.

The collision detection is a little wonky given that I had to write my player controller from scratch and some of the obstacles can be a little hit-or-miss, but it should all be beatable and overall I’m fairly satisfied with the amount of work I got done over the last two days. Maybe tomorrow I’ll see about exporting a standalone version in addition to the web player (along with fixing all the unexpected bugs that are to sure to crop up within minutes XD).

And yes, the snowman is in there somewhere 😛

Everything wants to kill you, but you have no weapon? The solution is simple: use your enemies’ weapons against them!

This is my second completed Ludum Dare entry. I decided to go with the concept of having to manipulate the NPCs in order to benefit from their weapons and abilities (such as being able to trigger otherwise un-pressable pressure plates). It’s not a huge game, but it gave me a fair bit of practice with enemy AI coding and line of sight, and overall I’m satisfied with how it turned out.

Most of today has been spent alternating between playing video games and working on my Ludum Dare entry. While it still looks extremely ugly, I believe I have the main gameplay mechanics for Patient Zero all fully functional!

In a step up from yesterday’s work, the player (and subsequent zombies) are now able to infect humans by touching them, and police officers can shoot at the zombies in order to kill them. I also reworked my code for humans running away from zombies (the first version simply had the human select a room at random to run to and head there as quickly as possible, which unfortunately quite often involved running straight past an oncoming zombie), at which point I encountered my first major hurdle – namely, that while Unity’s pathfinding is straightforward and easy to use for static levels, when attempting to maneuver past other NPCs the algorithm simply attempts to push past them rather than find an alternate route around. Several hours of searching revealed no built-in way of handling this problem in Unity’s pathfinding, so I ultimately devised a roundabout solution – when a human sees a zombie, they attempt to find a point as far away as possible with as small an angular difference to directly opposite as possible and head there, regularly updating the target until the zombie can no longer be seen (at which point they then try to use a phone or head to the police station). This resulted in a far more natural-looking effect in which the humans will actively run away from the zombie and take the side corridors if they are empty.

Out of curiosity I decided to spawn a few zombies in the center of the map and see how they fared without any player assistance. While a single zombie is quickly located and destroyed by the police officers, a small group produced some very interesting behaviours – while the humans are much faster than the zombies, on multiple occasions they would end up trapped by two individuals or groups which had targeted them from each end of a corridor. On the other hand, while a police officer can take out a single zombie before it reaches him, two or more grouped together can easily overwhelm him.

There’s still a few minor tweaks to make (such as adjusting the sprint values for the player, and possibly adding a few more selectable levels to play on), but on the whole I think the game is shaping up quite nicely! Whether it’ll actually be fun for anyone but me to play, however, is another story entirely 😛

Hi, I'm Hunter X. I participated in Ludum Dares 31, 32 and 33, but due to a combination of being busy and just forgetting I haven't participated since then. I've not done much game development work for a while now and I'd like to get back into the swing of things, and it just so happens that I have the entire weekend free, so I figured I'd give this a shot.

Unless anything changes dramatically I'll be working with Unity and C#; expect god-awful placeholder artwork (assuming I get beyond just cubes and cylinders this time :P) and a focus on learning new skills/techniques as I produce my game.

Managed to stay up long enough to see the theme reveal last night, but I ended up sleeping on it while I considered ideas. Now that a good half a day has passed, I think I've settled on a concept: a procedurally generated dungeon crawler where after each floor you can increase your remaining/total health by selecting difficulty increases for the next one - instead of spending your life to access things, you're earning it by challenging yourself, and the difficulty naturally scales as you either take damage or increase the complexity of the dungeon.

It's possibly not the most original idea in the world, but all of the gameplay elements are relatively straightforward such that I should hopefully have a shot at making this work before the end of the event.

Didn't I promise you horrendous placeholder artwork? :P

Once everything is in place I'll be able to use this to generate any number of rooms and link them together to form a floor of the dungeon. Next steps are basic enemies, health and win/lose triggers, then I can move onto the procedural elements of the game and the actual implementation of the theme itself.

It's 4am over here in the UK and I think it's time I get some rest. So far today I've managed to produce all the elements necessary for a basic gameplay loop, and things are finally starting to resemble an actual game (albeit a somewhat ugly one):

The player has to collect keys (which may be lying on the ground or held by enemies) and bring them back to the start in order to clear the floor. After each floor your remaining health will decrease by one (even if you took no damage), forcing you to increase the difficulty of the next floor in order to earn additional lives. Is it better to attempt lots of easy levels with minimal health, or go straight for the harder difficulty with as much as you can get?

The next step for this game is to implement the purchasable difficulty modifiers, as well as add new types of enemy. From there I can start looking at replacing some of the placeholder graphics with slightly less terrible placeholder graphics/animation, and possibly think about music/sound effects if I have time.

But first, sleep.

Had a scare at the last possible minute where none of my level-specific values would reset properly upon starting a new game (I'd destroyed the controller object and a new one was in the Scene with the correct values, but it seemed to still be accessing the dead controller somehow), but I managed to get that resolved and have uploaded my game!

On the whole I'm very satisfied with how this turned out, though I had to omit a couple of things (audio, animations, GameJolt high score board integration) due to time; perhaps I'll finish those up in a later version of the game.

I'll write up a proper post-mortem some time in the near future, but now that everything's sorted I think it's time for me to go get some sleep (watch as my game magically becomes unplayable the moment I turn the computer off :P).

So because I have way too much free time on my hands, I rigged up a program to pull all of the score data from every completed LD44 entry (or at least the ones that got a score in the Overall category) and dump it into a CSV file. I was then able to use this data to produce a series of histograms, so that people could see what the score distribution is like for each category and how well their game did relative to the average. Please ignore the "below 0.5" and "above 5" columns; this was the only way I could find to make Excel display the full length of the score axis instead of trimming the empty space.

Compo

(Open in new tab)

Jam

(Open in new tab)

Combined

(Open in new tab)

After dismissing a few ideas that were interesting but not easy to work into a solid gameplay loop or produce during 48 hours (the topic of submarines came up a few times), I ended up going with a side-view mining game; think Dwarf Fortress crossed with Lego Rock Raiders crossed with Motherload. You direct a team of miners to venture underground and bring precious resources back to the surface, but as you go deeper it becomes harder to work efficiently - your miners need to head back up to eat or replace tools, and carrying rocks is slower than walking normally. So as you earn money you can build supply depots and elevators to assist your team.

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

It's been a bit of a challenge to get my brain in programming mode today, but some of the functionality is coming together - the terrain automatically makes holes between open spaces, the player can set or clear tasks for the miners, and I have a basic pathfinding system in place (albeit there's still some bugs hiding in that one). First milestone on the to-do list is getting to the point that the miners can make new tunnels following the player's commands, second milestone is having those tunnels drop rocks to be carried back to the surface and sold (at which point we have a basic gameplay loop) and the third milestone is being able to purchase additional structures for the mine; we'll see which of those I manage to achieve tomorrow.

Took a bit of fiddling to get the web version running properly, but my game is now uploaded and available for people to play! I had a bit of a slow start to the project, but everything came together in the last few hours and overall I'm fairly satisfied with how it turned out - I got the opportunity to do a bit of 3D modelling for the project instead of just making a 2D game like my last entry, and I managed to hit my milestones in terms of functionality (though there's plenty of potential for further expansion in there too).

Now it's time for me to go to sleep, and await the inevitable reports of game-breaking bugs in the morning :P