Posts Tagged ‘ld34 Postmortem’

The Cube of Zanigriv (LD 34) Postmortem

Monday, January 4th, 2016 3:48 pm

I told myself I’d be more involved after submitting this time, but I let the Holidays get the better of me. I guess I still have a little bit of time to get a postmortem in. As always, I’m blown away at the creativity and ingenuity of everyone’s submissions. There are always more to play then I ever find time to get around to.

So this was my second Ludum Dare and I am, for the most part, pleased with how I’ve progressed since last time. We will start with the…

PROS:

  • Was happy to experiment with music this time. I didn’t get to practice as much as I had hoped between Ludums, but I made a push before the compo started to learn the basics of MilyTracker and was able to produce a loop that I hope wasn’t too annoying.
  • Made a time table this time and did pretty well sticking to it. Taking time up front to plan out and schedule makes a huge difference.
  • Liked the look of my art (much more than last time). I think I made some simple choices that allowed me to get a look that I liked in a short amount of time.
  • Actually finished in time to enter the Compo!

CON – I’m only going with one, because I was happy with everything else:

  • My game mechanic/loop.

I tried to stay away from “snake/nibble” games as I figured they would be in abundance. When I started on Friday, I created a prototype for a procedural side-scrolling runner that involved using one button to grow the player and another to grow the world (shrinking the player). The problem was the procedural world was either too difficult or didn’t work well in the puzzle aspect I wanted. Once I realized I was designing levels, I didn’t want to fall into the same trap as last time. So I went to bed, that idea scrapped and no new idea.

When I awoke I had an idea for a much simpler mechanic of a guy that that could either a) turn a crank to charge a battery/light or b) shine the light. The light would in turn keep the monsters surrounding our player at bay. The goal was to see if you could manage the two tasks and see how long you could survive as the resolve of the monsters would increase. I proceeded to code the prototype for this idea.

While designing visuals for the prototype, I somehow let the idea become warped and started messing around with the mechanic. I never really took the time to evaluate the whole picture/project as I kept making tweaks and changes. This was my ultimate mistake. In the end, the final game mechanic feels very muddied and confusing.

I look forward to April and entering my third LudumDare, where I hope to expand on what I’ve learned through these past two weekends. Thanks to everyone that has already tried and commented and Happy New Year.

If you haven’t had a chance, you can try out ‘The Cube of Zanigriv’ here.

screencap4

HeXor – Postmortem

Posted by
Saturday, January 2nd, 2016 6:31 am

First of all, if you haven’t tried the game, take a look at it!

The idea of making a team first appeared on the discord gamedev group. We all got hyped and a gigantic team was assembled. Of course, on the day before LD a lot of the members left.

The final team was composed of soso (the LD account we used), mahham (meee), odyssey and muddmaker. Yoohooyuzu (the artist) had some internet connection problems so we had to go with programmer art.

So it begins…

A few hours in we had the idea of making an RTS in which you, the immune system, fight a virus which wants to grow. The hex grid was in our minds all along. I (mahham) chose to make the hex grid work, since i fell in love with them a few years ago after reading this beautifully written article. I think i made it work in about an hour.

In the meantime, the others were working on entities. That code was horrible and we scratched it.

We later decided to refactor the hex code. After refactoring around 1/2 of the code, muddmaker left.

Soso and I worked on a hexagonal map and buildings. When muddmaker came online after a few hours, he got mad at us for not making a tower defense game. Wait a second… tower defense? We were making an RTS, right? Yeah, he misunderstood it. He left the team. So now we’re only 3 out of the original 8.

I’m not sure when, but around this time we changed the game from immune system vs biological virus to antivirus vs computer virus.

A very, very early demo of the troop AI

After that we finished the building base code (still no textures) and some basic troop AI:

Now we only needed more buildings, the virus AI and A LOT of tweaking. The buildings were slowly but steadily made.

I chose to make the virus AI. The first AI draft looked like this:

After a few hours of trying to make it work I realised it’s too hard, so I went for another AI idea, in which the virus will place buildings in order to get to a certain predefined configuration (always the same). That worked out pretty well, but it needed some tweaking. While I was working on the AI, soso made the shop work.

At the beginning of the third day, we had the basic game almost finished and I had to fake a disease in order to not go to school. After I finished the AI, soso said that we have no time for our own music so we instead went with using NCS music. He started working on the main menu and a popup that showed when a song started playing while I searched for some fitting music. I did a horrible job. The music was way too distracting for anyone to concentrate on the game, but I didn’t realise that until the jam was over.

 

Another problem that occured at the beginning was git. We weren’t familiar with it and the conflicts were hell, breaking the code EVERY SINGLE DAMN TIME.

 

And that’s all. Hope you liked the game 😉

Learning to Dance — PostMortem

Posted by (twitter: @wetdesertrock)
Wednesday, December 23rd, 2015 5:10 pm

Banner

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.

(more…)

Post-Mortem Documentary of “Pressure Run”

Posted by (twitter: @PixelProphecy)
Monday, December 21st, 2015 2:26 pm

Because I thought making a game in 48 hrs wasn’t hard enough, I also decided to shoot some footage for a little documentary about me making the game. Now the editing and all is finished and here for your enjoyment:

Mount FuJ Post Mortem – LD34

Posted by (twitter: @roaringcatgames)
Sunday, December 20th, 2015 6:31 pm

 

The Game

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

Mount FuJ is a take on tower defense, or defend the castle style games. You play as an active volcano trying to protect the village that has popped up just below at your base. The village is under siege from an unknown enemy that is sending wave after wave of pikemen and horsemen units. The village will fight back, but it is no match for the army. You must use your volcanic ways to rain down lava balls on the enemy before all of the buildings are destroyed.

[Features that didn’t make it: If you are successful, the village will flourish and grow. However, as the village grows, it begins to spread into the range of your lava, so you have to be very careful to do more protecting than damaging.]

mountfj

Background

Zoe Blackwell – Music and SFX
Loi LeMix – Art
Barry Rowe – Programming

The Team

Left to Right: Loi, Barry, Zoe

This was Zoe’s first game jam, and first game related project. Loi and Myself have been working together since Ludum Dare 30, and have formed Roaring Cat Games under which we publish our work. Our team formed as we were brainstorming at the live Ludum Dare meetup with GameDevLou. This was the first time that Loi and I have worked with a dedicated musician and sound designer (which was awesome).

Tooling

Zoe used Logic Pro to record, mix, and compose music. She user her Casio Privia PX-160 keyboard as a midi controller to write the segments needed for composition.

Loi used his usual package of Adobe products but heavily worked in Photoshop to generate the art assets. However, this jam, he added a new tool into the mix with Spriter2D. Spriter really let him focus on the art and fluidity of the animations when during previous jams he was having to worry more about manually framing animation sizes and pivot points.

I chose to go with libGDX for this game jam as it is the framework I have the most experience with for games. While I’ve been doing some 3D work and learning unity since Ludum Dare 33, we knew we wanted to go with a 2D game for this jam, and I wanted to eliminate engine knowledge as a possible roadblock. We always like to challenge ourselves in some way with our projects though, so I did decide to throw Ashley ECS into the mix. I had used it for LD33, but only sort of embraced the ECS approach. For tooling I used: IntelliJ as an IDE, GIMP for placeholder art, and Git for version control.

Location

We worked the entire Jam at the Game Dev Lou “real-world gathering” working alongside at least 8 other teams. (See all of the GameDevLou games here: http://gamedevlou.org/our-ludum-dare-34-games/)

real-world-meetup

We presented a less finished version of the game as the real-world Jam wound down on Sunday about 7PM:

Brainstorming

Our brainstorm session was a bit longer than usual this time around. The existence of two possible themes really seemed to throw a wrench in our creative process. We kept falling into the trap of trying to force both themes into the game rather than focusing on one theme and discarding the other. Loi and I had also discussed trying our best to find a hack’n’slash to fit the theme, so I think that had us always coming back to “is this better than just building a hack’n’slash?” In no particular order, and with no further explanation, here is a list of some of our ideas:

  • Auto-run with Attack, Duck, and Jump all in two buttons
  • Snake/Centipede style game
  • Save the iceberg
  • Ninja absorbing souls into an ever-growing sword
  • Volcano Game
  • One-punch man training simulator (w/ boss fight)
  • Planet Building
  • Tree vs. Lumberjacks Survival game
  • Avoid the expanding Objects
  • Dark Maze Puzzler
  • Grow and Shrink objects to get out Puzzler
  • TRex growing up
  • Lion hunt and roar

When we got to the end, our top 3 ideas were between a Growing Sword hack’n’slash, One-Punch Main Training Sim, and a combo of Volcano and Protect the Iceberg.

brainstorming-sketch

As a whole we were most interested in the One-Punch Man game, as it had the opportunity for lots of humor, and working with a story/world we all enjoyed. However, as we started designing out how the game would play, we realized that the mini-games were fun as a concept, but boring in actual gameplay. We came to the conclusion that we couldn’t make the game fun enough to move forward on.

Next in line was the Hack’n’Slash with a growing sword. We discussed it, and the game play was going to be pretty simple and fun, and the environment had a lot of potential for interesting visuals and sound. Unfortunately, once we started looking at some of the features that would need to be implemented and the number of animations and art assets required to match our vision, we realized that the scope was just a bit too much. I personally had some major concerns that I wouldn’t be able to figure out how to implement the sword mechanics we wanted in code. I kind of regret giving into that fear looking back, but it was probably the right call. Loi can blame me for dashing his Hack’n’Slash dreams until the next jam.

As we began finalizing our third choice, the volcano game, we all kind of realized it might fit our strengths really well. Zoe seemed confident that she could produce the tense, dramatic soundscape we were designing toward. Loi found the concept might lend itself to a painted style he’d been wanting to try out. I felt there were some interesting challenges in the code, especially with only my second project using Ashley ECS, but was all doable in a Jam time-frame. On top of this, once we all got on board, we began expanding some of the possible mechanics, and the game was sounding pretty fun.

Process

Our process for building out the game was straightforward.

  1. Work up a list of all the known assets (art and sound) we would need
  2. Work up a list of all the programming features we need
  3. Task out the features in order
  4. Build each feature to implementation
  5. Repeat 3 and 4 until the Jam ends

Check out this timelapse of the programming effort over 3 days:

While there was no intention this jam of keeping Loi and Zoe from playing the game until the end of the jam…it still happened. Due to the development tools, having the game up and running where we can all play it isn’t as simple as I’d like it to be. This means that unless everyone on the team sets up their machine for development, the only way to play is to jump on my machine.

I think we should have done more small 5 to 15 minute breaks where we all get together to test a mechanic, listen to a piece of music, or analyze an animation or set of art assets as a group. This is something that was missing from our process this Jam, and I think it did limit what we accomplished.

What Went Well

The art and music for the game turned out fantastic. Zoe and Loi nailed it, and I love the feel of the game with them in combination. The soundtrack is nice and tense, with a subtle yet still noticeable buildup of urgency. Combined with the SFX and the lava animations, it makes for a very cacophonous battlefield scene. Yet, somehow with all the explosions and battlefield tension, there is a soothing calm to the experience as well. About halfway through the jam I could see that the music and art were going to need to take the main focus of the game.

The collaboration between the team went smoothly. We were each able to spend the majority of our time in our own tasks but were able to stop and discuss next steps/changes as needed without any issues. I think being in the same location really helped with that, and I can’t recommend enough that you try to join a real-world meetup if possible.

Coming together on Monday after our day jobs, we were able to pull off a lot of work right at the end. Sunday at the end of our day, we barely had a game. The wave system didn’t work, there were no sound effects, there was no balance to the enemies, and worst of all the game didn’t do anything to highlight the great soundtrack. On Monday we were able to take a step back, prioritize the features to make it a game, and knock them out with just a few minutes to spare for submission. This final crunch period went really well, and it was very satisfying to see how quickly we could get things accomplished under pressure.

What Didn’t Go Well

Coming up with a damn name for the game… This is the first jam I feel like we never had a clue what to call the game. If anyone has any great ideas for what this game should be called leave it in the comments below. We were just drawing blanks the whole time.

I feel like I was the weak link in this jam. I’m not sure what happened, but between saturday about lunch all the way through sunday about 10am, I just couldn’t get anything going. I was writing code, but it was all non-essential background placement or environment building code that I could have (and should have) knocked out towards the last few hours. I think I was dealing with a rough combination of:

  • Exhaustion (I had not been sleeping enough all week prior to the Jam)
  • Doubting my abilities to implement features
  • Lack of clarity on how some of the mechanics needed to work
  • Worry that I may have talked the team into a game that just isn’t fun

I definitely should have started working on having the lava destroy enemies much sooner as that is the key mechanic of the game. I had the lava-firing and charging really quick, and it then just didn’t do anything with it for almost 24 hours. I made the mistake of not building the basic mechanic up front so we have time to tweak and make it fun. On the plus side, I’ve learned that lesson (for at least the second time now! :)) and will be able to remember this instance to hopefully keep it in my mind going forward.

What’s Next

In the end, we feel our game has a pretty fun mechanic hidden inside of it. We’d like to tweak some of the known issues (spamming lava is an auto-win, no visual indicator to know how charged up your lava is) and add touch controls. This would allow us to release the game out for mobile devices as a little time sink. We’ll definitely need a scoring system, and a way to indicate that fun you’ve lost. The win sequence needs some work as well.

Team Thoughts

Barry:

“I was very excited for this Jam and challenging myself with Ashley ECS. While I’m disappointed in my output for the Jam, I was able to build out some pretty generic Systems and Components that will be useful for games in the future, and I plan to clean them up so I can open source them as an additional library for other libGDX developers. I’m very proud of the work our team produced, and I hope the shift in focus on Art and Sound comes across for those playing our game. It was an exhausting, humbling, stressful jam for me, but as always I’ve learned a ton and am even more ready to jump into our next projects.”

Loi:

“So, the whole week leading up to Ludum Dare 34, I was filled with excitement! Excited to create something new! Excited to take a break from RCG’s personal 3D project and get back into designing 2D characters and environments again. In the days leading up to the Jam, I started playing around in Spriter 2D (an animation creation and management program that I had been wanting to learn since the last Ludum Dare), because I was looking forward to making a hack and slash. Spriter 2D would have been perfect for animating action frames, as one of its unique features is bone-rigging and attaching them body parts and objects. Spriter 2D was very productive; it saved me a lot of time with image file management, ease of exporting animated frames, and having a simpler, yet more extensive, animating options that were non-existent in Photoshop. It allowed me to focus more on content creation rather than spending a lot of time on filename and manual frames export, which can be tedious and time-consuming when you trying to create a smooth animation sequence.

As always, I wanted to challenge myself to a new art style every Jam. This time, it was watercoloring in Photoshop. I haven’t used watercolor paint since I was a wee-lad, and picking it back up again felt a bit strange, especially now that I am doing it digitally and my paint brush is my tablet pen. The hardest part in the beginning for me was getting the brush settings just right to give it that wet outer-edge water-effect look. Below is my custom brush settings that I used throughout the Jam (works best with a drawing tablet, as it emulates brush pressure and strokes). It was nice to use watercolor inside of photoshop without the mess to clean up afterwards”.

BrushSettings

 

Thanks for reading, Thanks for playing,

–Barry, Roaring Cat Games

 

The Star War post-mortem

Posted by (twitter: @Eerongal)
Wednesday, December 16th, 2015 7:57 pm

Play it here

 

The deadly star

Introduction

 

Hello all! I figured it was about time for me to do a post mortem for my game! After the hectic ludum dare weekend, It’s always nice to circle back around and put my thoughts to paper about how the weekend went after a bit of reflection.

 

A little bit about me:

This is my 5th Ludum dare I’ve participated in, and I usually participate once a year or so as a holiday tradition. My day job is a software engineer working on financial software (boring stuff), so I have a background in programming in the first place.

 

I am not, however, anywhere near competent in the graphics or audio department. This was a pretty big deciding factor in the aesthetics of my game. I figured I may as well go purposefully bad for comedic sake rather than try to do something and come out as unintentional poor quality.

 

So from the outset, I was planning on doing something space/star wars related due to the upcoming release of the new movie. Just figured it would be a fun tie-in. I was planning this well before the theme was announced.

 

I had some tentative plans to work with maybe a couple different people, however that ended up not amounting to anything, so about 3-4 days before beginning I was for sure going to be on my own. Without someone more competent to put together my audio and visual needs, I went with an idea I had sort of brewing in the back of mind, using construction paper/crayons to come up with my graphics!

 

In addition, I decided I would record all of my sound effects myself, with the thoughts of using a kazoo for music. Like i said above, going full on intentionally bad was my goal here.

 

The First Day, part I

By Friday evening, I had a pretty good idea of what I was planning on doing. I watched the theme voting with interest, but was hoping the theme would end up aligning with my plans. Earlier in the day, I ran out to the store to grab some craft supplies/kazoos (i still have a pretty large bag of ’em, apparently I can’t just buy ONE kazoo…) and of course a supply of caffeine.

 

Lucky for me, the theme ended up aligning perfectly with my idea, or at least half of  it did. Grow fit perfectly into my plan, but two button controls didn’t really fit all that well. Fortunately, we were able to do one or the other if we wanted, not necessarily both.

 

So with theme determined, supplies in hand, and ideas fresh in my mind, I set off from the announcement of the theme working on my game. Theme announcement for me, locally, happens around 8 PM, so I had a good few hours in the evening to work. I set about getting the basics of player movement down, as well as adding some interaction mechanics between the player and enemies. At some point in there, I was able to get to adding in my background.

 

So i ended up wrapping up the first portion of the day around 1-2 AM my time, and decide to wrap it up for the evening and try to get some sleep. I was pretty pleased with my progress so far, because the first portion of this event for me is usually coming up with a plan and ideas. This time, I actually had some tangible progress on an idea, which was going to make things easier for me down the line.

 

The First Day, part II: Electric Boogaloo

 

So I begin the next day (but still LD day 1) around 8 AM, and before jumping straight into working, I decide to fix myself a nice breakfast to prepare myself for the coming work.

 

Once all that was squared away, I set about immediately working on the bulk of my game. Overall, it was clear, steady progress down the line as I worked on mechanics and took breaks from coding to get down to the serious business of construction paper and crayons, or to record some more sounds, and the occasional snack/sanity break. I took some time out of my day to acquaint myself with some new features of unity 5 while i was at it.

 

At some point during the day, I decided I needed some cut scenes to really tie the whole package together. Luckily, these were pretty easy to implement. In case you couldn’t tell, the dialogue was mostly ad-libbed (hard to tell, right?). I recorded a handful of variations that all hit right about the same points on each and took the ones I felt were the best. It was about this time I was beginning to realize I had a masterpiece coming together in my hands.

 

The day chunked by steadily, and I ran into no major road blocks. By the end of the night, I was feeling pretty good and had a mostly completed game on my hands. At roughly midnight, i decided it was about time to turn in for the night

 

The Second Day: The day-ening

 

So on the final day (Sunday) i decided I earned a bit of rest, so I slept in a bit. Got up around 10 AM or so. I was pretty confident I would be done on time, and I spent most of the day tightening up some mechanics, and eventually I decided that the boss needed some retooling.

 

In previous versions, I toyed around with the bosses movement mostly, and I couldn’t find a really workable solution. Either he moved too fast and was basically impossible, or he moved too slow, and was a joke. Eventually, I decided that I needed a new mechanic to make a boss fight work, because it was either a simple slog through a massive HP pool, or an insta-gib for the player. That’s when i decided to add in the bullet hell/shooter mechanics to the game (player firing shots, boss with giant beams), and these features came together pretty quickly and worked out pretty well. I finally had a final boss I was happy with.

 

After getting the game into its completed state, I decided to try getting a working build put together. This proved to be (oddly) the biggest roadblock I had come to so far. I was determined to use Unity’s new WebGL build, but to my surprise, the build kept clocking in at insanely huge (for the scope of my game) sizes. I’m talking the first build hitting about 250 MB. And actually playing it would take ages to load, in excess of 20-30 minutes.

 

This was, of course, a BIG problem. However, this being ludum dare, it didn’t surprise me in the slightest that SOMETHING went wrong. Up until now, it had been way too smooth, and I was quite suspicious.

 

So, with nothing left to do, I buckled up my big boy pants, and began researching my issue, trying to figure out what could be the problem. The total raw game assets came to about 100 MB (high DPI PNG scans and high quality OGG vorbis sounds), still pretty big, but nothing like the final build. So the obvious thing to start with was to start scaling down my assets to something more manageable in size.

 

Cue a few hours of tinkering with all of the images and sounds until I reduce my asset size down to around 30 MB.

 

After i get everything to a quality i’m happy with and a more manageable size, my builds were still clocking in around 150 MB, so I only ended up shaving off about 100 MB. At this point, I’m completely puzzled at what could possibly be causing my build size to be so large. So i take to google searching for all the information i can concerning unity 5 and large WebGL builds.

 

Many hours of googling later, I eventually come upon a post in the unity forums recommending someone to turn down the material quality to lower their build size for a 2D pixel art game. Little did I know, I had struck on gold here that pointed me in the right direction.

 

Turned out, all of my image assets were being imported into unity with a default texture max size of 2048, which was significantly more than needed for the assets i was using. A bit more tinkering later, I figured out I could very easily turn this setting down to 512 with almost no discernible quality loss. And most importantly, the builds were clocking in around 20 MB afterwards, which was far more reasonable. Along with the smaller size, the load times were reduced greatly (to a minute or so).

 

With all this completed, and a final, working build, I still had about 45 minutes until the end of the competition. So with my head held I high, and my kazoo rendition of the star wars theme still stuck in my head, i proceeded to play my game one last time to snag a few screenshots, and ultimately submit my game about 30 minutes early.

 

It was a long weekend, but well worth it. I felt good about the product I had made, and hoped it would go over well, and currently that does seem to be the case, which makes me all the more proud of it!

 

The Good

Over the weekend, I was able to play around with some new features of Unity I hadn’t ever really used in the past, and was able to bring my game to fruition pretty exactly as I have originally envisioned. It’s not often in a Ludum Dare that one gets to say this, so I was particularly proud.

 

The Bad

At the end of the day, had I previously familiarized myself with some of the newer aspects of unity (and WebGL builds specifically) I could have saved myself a lot of headache and stress right up at the end there. Fortunately, things worked out for the best.

 

The Ugly

The game itself brings nothing new to the table, and relies solely on its parody value. However, I’ve learned in the past that setting out to break new ground during a Ludum Dare is a very risky proposition, so I feel justified in my decision to play it safe in terms of mechanics and game play.

 

Thanks for reading, everyone! Hope you enjoy mine and many other of these fine games that are part of Ludum Dare 34!

Dungeon crawler making of

Wednesday, December 16th, 2015 7:08 pm

13139-shot0-1450170155

Hi all!

Here’s a post-mortem for Lands of TSR Lore , my tiny dungeon crawler made from scratch!

This was my 10th Ludum Dare and I thought I’d treat myself.

Early on I realized I will have no fun if I follow the theme, my ideas weren’t exceptional. What I thought was a fun idea about growth was, in fact, just an idea about leveling up in an rpg. Nothing better was coming, and since my internet connection chose that time to abandon me for 6 hours (yes, thank you internet gods), I felt less and less inspired.

Instead of despairing and spoiling all the fun for myself, like I usually do, I decided I’d just make a tiny rpg thingy. An old-school 2D (2.5D?) dungeon crawler, like Eye of the Beholder, Lands of Lore, Wizardry, Etrian Odyssey, the sort of games that felt magical to me, because the potential was there for a 3D world made of carefully pixeled pixelart. The closest pixelart can get to being immersive, without actual 3D transformations like wolfenstein (which kind of spoils it for me).

So, what went well?
First of all, a TON of code. I spent a ton more time coding than any other LD. I also spent a ton more time coding than I did content creation, which is refreshing because I’m always self-conscious that my art is better than my code is. Here’s all my “event groups” (it’s how Construct 2 allows you to organize code).

code1

Each of those groups contains 3-4 dozen events. And not just if/then statements and quick solutions, I had to think hard about the algorithm that renders this:
this

 

into *this*:this2
Here’s the code by the way:
code2

After a lot of headscratching, trigonometry saved the day: I made code that can read a bunch of 2d tile positions in the 4 cardinal directions at once, instead of having to input each separately. This code reduction is important, because tiles, monsters and objects (and later on, decorations) are going to be using the same function. Making changes is certainly easier the less code I have.
The basic idea was: the sine and cosine of 0,90,180 and 270 degrees have this useful property of having values of -1,0,1. So why not incorporate the code for checking for North/South and East/West in the same line, but multiply each half with either sin() or cos(), half the line is multiplied by 0, and the other half remains.

field-of-visionThe inventory: I started this on a whim near the end, so you could pick up those shields.

Naturally I fumbled with the visualization code for the inventory and didn’t want to waste more time on it. Therefore all the shields you pick up just crumble to dust. I’m sorry ^-^’ The crumbly ancient shield graphic is from Eye of the Beholder by the way, I thought it was funny, since it’s a 24 year old game. I certainly feel old for having played it when it came out 😀

I made a wall set by using a 1-point perspective set of lines, and decided I wanted some extra bits sticking out in corners, for the thing to look more 3-dimensional (ergo the pillars in the front row)

full wallset template
I also thought how cool it would be to have the dungeon sort of smoothly transition from one tile to another, like Land of Lore first did. I probably used the same trick as they did, I used r0j0hound’s html5 canvas plugin for Construct, which allows me to take a screenshot and then manipulate it (scale it up) over the course of 3 frames, while also repositioning it to keep the horizon line level. This,  along with mirroring the floor and wall graphics with each step (still a little buggy) gives a very solid illusion of moving forward, comparable to even recent AAA titles (Etrian Odyssey).

The whole game window is 192×108 pixels, smaller than SNES resolution, the height is smaller than even gameboy resolution. It’s the only way to get away with pixelart that looks good and polished.

inventory
dagger

Tiny screen size means it’s not overkill to have 11 frames of attack animation. It’s basically a 50×50 sprite, quite reasonable for platformers and such, and absolutely screen-filling at this size 😀
slime slime

I like the dungeon music I wrote, inspired by Wizardry and Westwood studios’ brilliant Adlib music, using a Yamaha chip emulator called JuceOPLVSTi

Dungeon Music

More things that went right:

  • I enjoyed  myself! I’m going through a very rough personal time, with more stress than I’ve ever had, and yet on Saturday morning I was singing MISTER I’LL MAKE A MAN OUT OF YOUUUUUU from Mulan at the top of my lungs with a smile on my face.
  • I felt alternately worthless and god-like while coming up with solutions to  math problems
  • a lot of code (under the hood) makes this a lot more complex and a lot more expandable than it looks. For example weapon slots are properly coded and will be fully functional once I make a proper inventory. Weapons have d20 stats, chance to hit is calculated based on Armor Class, strength bonuses apply, etc. It’s all rather pleasing for my geeky side.
  • editing levels is a dream come true for me! Make a top-down tile-based map, as big or complex as I like, and it instantly gets shown in 3D. Through a 3D engine that *I* made, and completely understand. That’s magic for a person like me who lacks a lot of math knowledge that makes 3D representation feasible.
  • the fact that our tools have come so far from 1991, that a single person can in 3 days replicate technology that was state of the art in AAA games back then, makes me SO happy to be indie
  • I had one person say they *love* the game. That’s all you can hope for, that’s all you need, one person.

What went wrong:

  • I didn’t match any of the themes. I don’t mind, but people do
  • no gameplay apart from killing a few slimes and getting to the exit.

I know people make genius experiences for LD that last hours or have that wow factor and innovation. I admire and respect them, and hope I’ll have that spark of creativity myself some day. Until then, I’m happy to just chip away at little problems, learning to think like a coder, making game spaces I can explore. Thanks for being here for the ride and reading about it.

I love LD!

SupRunner summary

Posted by (twitter: @agilejoshua)
Tuesday, December 15th, 2015 3:01 pm

I kind of succeeded with something but not really with the game side. Had little inspiration and in the end not enough to actually do anything with the few good ideas I had. Spent most of my available time getting the SuperPowers collaborative engine and IDE running on a hosted Azure website, which in itself was pretty cool and taught me a lot about hosting multi-platform applications in Azure…

In the end my son and I were talking about what cool ideas others had implemented for the two button control theme. We joked about it would be fun if you used ALT-F4 as the control keys – so he quickly made a simple sprite animation and I threw together an even simpler game in my hosted SuperPowers IDE. Quite happy with the results considering we only spent about 3-4 hours doing the game and we used a hosted IDE to program it.

Screen Shot 2015-12-15 at 02.13.16

LUDUM DARE 34 POSTMORTEM | COMBAT HELL

Posted by (twitter: @antonuklein)
Tuesday, December 15th, 2015 12:58 pm

Well, that was fun. I did my first Ludum Dare and now I’m slowly playing through a bunch of entries and sometimes just voting on them in batches. But let’s go over my game, Combat Hell, and let’s see what I did right and wrong.


Combat Hell followed the theme of ‘Two Button Controls’ and it an immediate decision that that would be the best way of playing it. The actual idea of it being a topdown dogfight was made actually about a day before the jam started, when I was thinking of good potential themes that I’d like to do. Other ones included ‘One Massive Enemy’, ‘Generations’, ‘Death is not the end’, ‘Death is useful’, ‘Strength in numbers’, and ‘Isolation’; most of these would work with my current concept, but some would have worked better than others. Actually, I think stuff like ‘Death is Useful’ might have made for a better game in the end.

The game idea was simple: You’re a hired mercenary by a dick, and your job is to fly around and kill enemies. That’s it, and I took the idea of gameplay from Combat’s jet sections, where you and another player would duke it out across the solid sky; now I wish I took its controls too.

[STATISTICS]

The game was released initially as a Windows standalone game, and it was later ported to Newgrounds. The game has 26 votes, the standalone version has 35 downloads, and Newgrounds has 294 plays (although most of them are likely from Newgrounds). A bit lower than I expected, but at the same time, people have already noticed my little game, so I’m pleased.

[WHAT WENT RIGHT]

Even though my execution was, uh, slightly shite, the idea of using the mouse as a directional pad and as a means of attack led to a risk-reward situation, where you could either be running away or fighting. On top of that, I had some basic different ways of attacking, although the balance absolutely broke in your favour as soon as you got even a single extra shot, especially with weapons such as the RNG shot (the ? ‘powerup’ that made you spread bullets everywhere). Honestly, I think that added to the life of the game, and I gave similar powerups to the enemies as well. Overall, that was a good choice.

Also, I’m pleasantly surprised as to how well the shop came along considering I coded its entire functionality in about 3 hours at the literal end of the jam, while also balancing the game to be a bit less random (didn’t help much though), and I had tons of issues getting the buttons and text working. If I were ever to go back to this, I’d have a 48×48 spritesheet (each of the 9 corners and middle fill), and stretch that to be the text box. That’s have worked better than the quick textbox I drew, as well as having another font instead of HaxeFlixel’s default.

Armour restores. Armour is taken away constantly and while it slowly recharges, there’s a powerup that gives you 60% of your armour back; that was such a last minute addition, I literally changed the code to throw out a -1 in the powerups, since any other value would mean you’d have to take the time and fix it, while I had about 20 minutes left.

The postrelease Flash port worked amazingly, I’m actually surprised that it ran almost as well as the standalone version, although the lack of fullscreen led to players clicking outside of the box. I wanted it to be HTML5, but I couldn’t figure out how to get rid of the right-click menu, so Flash it was.

[WHAT WENT WRONG]

This should totally have been a topdown plane Borderlands. Forget the powerup system (well except for the purple ones, those are nice), enemies should have dropped weapons with some random stat modifiers and you should have been able to select which weapon to use when flying out; if you don’t like a certain weapon, you could have scrapped it and forged either a reroll to your current one (so you could have some better modifiers, or even just changing the numerical values), or you could have made a brand new one. Persistent XP would have helped with this. If I ever get the chance to expand it, I could have a weapon slot, a hull slot, and an armour slot (since you need all three), and make the game be faster pace as a result.

The code became a mess over the last hour, trying to get it to work okay. Here’s a useful hint, don’t read it. It’s a mess, especially since the indentations broke and in the end, I’m not sure what I was coding. I mean, it worked, but still.

The movement controls, while neat, are horrible when trying to get to a corner or even going in a straight line, as the way I coded it in made the plane just fly around like it’s Pluto. Boo.

Music is just grating, I just transcoded it in an hour to a tracker file and then threw the resulting ogg into the game. At least I added in a mute button. Everything’s wrong with it, sometimes I think it shouldn’t have even been in the game. I wanted to have a military-like drumming with a strong lead, but… yeah.

I also ran this on a Llano AMD laptop processor with a clock speed of a whole… 1.4GHz. I had slowdown; now I’m not sure whether it was my code that was unoptimized or my computer was struggling to run HaxeFlixel, but it ran bad when it had over 100 entities on screen, counting the bullets. Probably my enemy plane code was unnecessarily complex, I never profiled it. Hilariously enough, I couldn’t do any work for the first few hours since both of my copies of Photoshop died, so I had to quickly get a copy of CS2 running, and FlashDevelop wouldn’t do autofill at all, so I reinstalled it and HaxeFlixel and Haxe and OpenFL so many times… it was a mess.

The shopkeep is too much of a dick because you need $1000 to unlock the sadist mode (please don’t play it), but that’s my fault. I could have fixed it really easily, but I was limited on time and energy at this point.

[CONCLUSION]

Overall, it’s a solid little game that could have used way more polish and a few extra days to clean up the whole thing. This took me 28 hours to code, counting the time I tried even getting anything on screen because my IDE wasn’t as fully tested as I’d’ve liked, and it was a great learning experience.

This was coded at Winnipeg’s Ludum Dare game jam, where I saw a bunch of awesome folk. Huge thanks to Dylan, Graeme and everyone at Owlchemy, ACI, and New Media Manitoba for hosting this event, this jam was awesome.

Space Amoebas (Not Agar.io!)

Posted by
Tuesday, December 15th, 2015 4:46 am

Space Amoebas!  http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=7542

pictured: not Agar.io

 

<NICEFILTER>
This game was incredibly challenging for me to finish within the deadline. I can’t describe the feeling of joy I am getting watching players connect and pilot their goofy little amoebas around trying to eat each other.

Separating the servers from the game was a mistake though, which is obvious to me now. It is confusing to have to keep a separate server window open and confusion keeps the player count low, which is death for a multiplayer game. I was terrified of latency since I am in Europe so I wanted to make sure everyone could connect to a local server. I should have just made one server and dealt with the lag.
</NICEFILTER>

<RANTFILTER>
Most of my reviews are saying my game is just a copy of Agar.io. For some reason this is getting under my skin so I have to rant about it before I snap and yell at my dog.

First Rant: Do you go around to every one of the 100s of platform games and leave reviews saying they are “Basically just copying Mario Brothers”? Space Amoebas is about using planets gravity to propel yourself around in space to eat small enemies or hide from big ones. Yes, in my game you eat dots too. So did Pacman. What is your point?

Second Rant: Have you ever tried to make “Just a copy of Agar.io” in 48 hours before? It was really freakin hard. I wish there was a category for Technical Achievement which I think I would do well in since I don’t think anyone has made a WebRTC game with synchronized physics for LD before. The best I can hope for is Innovation, which I will do terrible in because my game is “just a copy of Agar.io”.

Do I look like Agar to you? Well, do I punk?!

Third Rant: This rant is aimed at myself. I swore I would never make another multiplayer game for a compo. It is so disheartening to see players have connected, bopped around for a few seconds without seeing another player, and leaving again. The whole, complicated system is working (miraculously) but there are no players to interact with so the game is boring. I really planned to write some AI but I ran out of time.

Fourth Rant: One side effect of writing a server for the compo is that I can see exacly how long each player has connected before leaving again. I can see you people. All but a few of the users who have left reviews spent less than one minute in the game. Some about 15 seconds!! Is that how much time you are spending on all of the games you review!? Are you just padding your coolness score? Why not just look at the screenshots and base your review on them?

Grumpy old man out. *drops mike*
</RANTFILTER>

Seriously though, thanks everyone who has tried my game and left feedback so far. Feedback is like gold.

Ludum Dare 34 – The Postmortem

Posted by (twitter: @@moongateuk)
Tuesday, December 15th, 2015 4:38 am

So it’s been a mixed weekend for for me especially with the 34th LDJam. I’m sad to say that I couldn’t get anything up this time as once again I think I over done everything on the actual project itself. In the end I had a playable game which would loop through and randomly generated dungeons.

The gameplay itself was a click to move kind of game with basic path finding (thanks to Quill18’s tutorials on youtube.) where you had to go through different dungeons collecting scrolls before reaching the final level and destroying the boss. The controls were already set out for using a mouse with right click and left click only.

What went good?

Well in terms of the ldjam itself most of the stuff went really good:

  • I stuck to one idea and evolved it to suit all of the final themes.
  • Had an outline and todo list of items that had to be done and kept to it.
  • Learnt something new. In regards to 2D path finding (Which I could find no basic ones on the unity asset store.)
  • I now have a character that I want to develop on for a series of projects next year.
  • Focusing on my work rather than getting side tracked by social media.
  • Knowing when to stop and wind down.

What went bad?

So not a lot of different things actually went bad to be honest:

  • Having a few game breaking bugs that I obsessed over. One bug took almost 2 -3 hours to track down and fix.
  • Not keeping the design of the game simple.
  • Getting distracted by other people and being in areas of distraction.

What have I gained from all this?

So all in all it was a pretty good run even though I didn’t manage to get anything pushed out again. But I did manage to learn a fair bit about path finding and that having a “World” and randomly generated “levels” actually works really well. I gained a character design that I plan to use in a few of my small projects next year.

So if you want to keep up to date with what I do follow me on twitter @moongateuk, Like the Moongate Games UK page or keep an eye on moongate-uk.co.uk.

Keep up the gamedev everyone.

[cache: storing page]