About Syldarion

Entries

 
Ludum Dare 35

Syldarion's Trophies

Syldarion's Archive

The Core — Post-Mortem

Posted by
Tuesday, April 19th, 2016 5:53 pm

THECORETITLE

The Core can be found here. The following is a collection of my thoughts on the process of making this game in 48 hours, though as I write it, it feels like it is becoming more of a description of my game.

 

This was my very first Ludum Dare, and so, I was incredibly excited in the weeks leading up to it. Now that we have made it through, I would like to reflect on the 48 hours I spent pulling my hair out.

FINAL THEME VOTING

During the voting for the final theme, ideas were flying through my head, but the one that really stuck in my head was Companion. No matter how much I thought of for the other themes, my brainstorming continued to go back to that single theme. Once the voting closed, I stopped thinking about ideas. I decided to just cool down and wait for the results. When PoV revealed to us that the theme was going to be Shapeshift, I was slightly upset, but I wasn’t going to let that stop me. After all, the theme is only one voting category. So I decided to go through with making a game following the Companion theme.

BRAINSTORMING

Everyone knows that when you start to brainstorm, you get so many ideas, I mean, that’s the point after all. For this, though, it was a bit harder, because I couldn’t use every idea. If I tried, there’s no way I could have finished all of them. So it became a process of elimination. I really wanted this to be some sort of procedural dungeon crawler, with a 2.5D tileset. I shut myself down though, thinking that there was no way I could write a system I was happy with in a short enough time. So I decided to completely change the level format, making it a procedural platforming game, which makes it really hard to get across that it is supposed to be a dungeon crawler.

Moving on from that, I knew from my time thinking during the voting period that I wanted the player to have a robot companion, so I spent some time expanding on that. I wanted everything in the game to revolve around this companion. I knew that the only way the player should be able to improve their character is to improve their robot companion. I spent some time coming up with different attachments that your robot could have, and eventually decided that a reasonable goal would be to make three attachment types, each of which have three unique attachments you can build.

DEVELOPMENT BEGINS

First things first, I needed levels. So I started to write a system for creating procedural platforming levels. The first build allowed me to specify level width, level height, a platform size range, a platform distance range, and how many platforms I wanted. So now I had a sprawling empty level. After some time spent tweaking to make sure I could actually make it through various generated levels, I added in the ability to move past the first level. This was when I got my first “it’s not a bug, it’s a feature” moment. When I made it to the end of the level, it correctly spawned me back at the beginning with a new layout, but I immediately noticed that there were way too many platforms. As I moved along, it became obvious that I had forgotten to clear out the platforms from the previous level. From that, I decided a good addition to the platform generator would be the ability to specify how many paths I wanted in the level. After an hour or so of tweaking, it was done. I did some more level generation testing, until I found numbers that I was happy with for the levels being created. The final steps for platform generation was to add platform movement, which was as simple as specifying a random movement range and speed, and then bouncing the platform back and forth. With that, it was time to move on.

ATTACHMENTS

Attachments are, in my mind, the core aspect of gameplay. Everything I made this weekend tied into building these and attaching them to your robot, so you could get some sort of boost to your character. During the brainstorming, I came up with nine unique attachments, separated into three attachment classes: Attack, Defense, and Utility.

Attack Attachments

All three of the attack attachments (gun, sword, AOE) did the same thing in slightly different ways. The gun would do a moderate amount of damage to a single enemy within a moderate range. The sword did a lot of damage to a single enemy within a short range. The AOE did a small amount of damage to multiple enemies within a large range.

Defense Attachments:

The defense attachments (heal, shield, thorns) had a bit more variety to them. The heal would restore some amount of health every second. The shield blocks all shots coming from behind the player. The thorns would deal a small amount of damage to any enemy that damaged the player.

Utility Attachments:

The utility attachments (jump jet, booster, gatherer) were the most fun to write. Jump jet just enabled double jump. Booster allows you to sprint. Gatherer gives enemies a chance to drop double parts.

On top of all of the effects of attaching the attachments, I made it so you are able to level up or disassemble attachments. In the build that I finished for the comp, most of the leveling was really poorly done. I wanted disassembling the attachment to give the player a permanent stat boost, so that the player would have to decide between keeping the really nice active ability, or gaining permanent bonuses.

POWERUPS

I wanted there to be some sort of trade-off in the game, so that the player wasn’t just left stacking their stats and collecting more attachments. So I thought of a system where, once your robot companion had three attachments of the same class, you have the option to deconstruct your entire robot for a really overpowered temporary boost, at the cost of losing all of the attachments that were on your robot. I never got around to creating functionality for this, and so, once you equip a third attachment of the same class, it just does it automatically.

WHERE’S THE CHALLENGE?

So now I had a lot of mechanics for the player to mess around with, but there wasn’t much of a challenge to the game. This is because there weren’t any enemies. The only thing is your way was your skill with maneuvering platforms. So I really needed something for the player to fight against, so I dropped some red blocks while generating the level that would shoot at the enemy if they were in range. And that was that. Some sort of challenge.

DAWN OF THE FINAL DAY: 12 HOURS REMAIN

It’s safe to say that, by this point, my brain was mush. Luckily the game was also mostly to where I wanted it to be for LD. I spent my remaining time cleaning up code and making a main menu, writing a rather lengthy How-To, which made me realize my game just wasn’t intuitive enough if I needed to write something that long. I knew many players wouldn’t read it, but it was there. Honestly, my final hours felt a little wasted. I drew a few sprites, but that was it. I just couldn’t think straight by this point. I didn’t even manage to get a player sprite drawn. I tried, but I couldn’t make something that I would be happy with as the main focus point of the game. So once the submission hour hit, I put my game up, and that was it. I was happy with my progress. I was tired as hell. But I had finished a game in 48 hours.

LESSON LEARNED

Most of this is likely common sense, but seeing as it was my first ever Ludum Dare, and also my first ever seriously time-constrained project, I learned a few things from it.

  1. SLEEP. Looking back on this weekend, I know that I probably wasted more time being mindlessly sleep-deprived than I would have getting 8 hours of sleep a night. Sure, 16 hours is a large chunk of your development time, but I was feeling like death as the comp came to a close, and I continued to feel like death through the next day. Seriously, I’ll be sleeping normally during the next game jam.
  2. Energy drinks are a no-no. Sure, they were helpful this time around considering that I wasn’t sleeping, but that crash you get is awful. It hurts your development a lot. Just drink water. Or tea. Or something, just stay away from the energy drinks. Avoid the crash.
  3. Try to get rid of all distractions. I was so very tempted to just open up movies or something on one of my monitors, and sometimes I did, but when I did, I started to slow down with my code, because I kept getting distracted by what was going on. Tying into this, don’t let your roommates throw big parties the first night of the comp. Drunk people wandering through your space definitely doesn’t help.
  4. Decide on one fantastic core concept, and stick with that. Seriously, if you have a really awesome, unique core mechanic, people will notice. I tried to make too many features in my game, and because of that, many of them weren’t fleshed out all that well.

WHAT COMES NEXT?

I’ve received a decent enough amount of positive feedback for my game, and because of that, I have decided to continue developing it. So there will be a lot coming, maybe soon, maybe later, I’m not sure, but I know it is coming. Some planned features for the future:

  • Making the switch to the 2.5D tileset system that I initially wanted
  • Implementing standard RPG progression
  • More attachments!
  • Multiplayer
  • Boss battles
  • Some sort of actual tutorial. Or just introducing mechanics naturally
  • Better artwork, of course
  • And more!

Of course, the build here at LD will stay as it is, but over on the Itch.IO page, expect many updates! And please, if you feel there is anything the game needs, let me know, and I will jot it down, and you will likely see it in a future build. I can’t wait to see where this goes, and I hope you will join me for the ride.

Thank you for taking the time to read this post-mortem, and have a lovely day

— Syldarion, excited game developer

Who Needs A Theme?

Posted by
Monday, April 18th, 2016 12:58 am

Cap1

For Ludum Dare 35, I made a game that doesn’t even follow the theme, because I was wildly obsessed with the companion theme. So I created The Core. There is a rather long description on that page, so I won’t talk too much here. I just finished going through the first round of bug fixes and balance changes, so I feel it is okay enough to put on the front page. If you have any suggestions for number changes, or find a certain bug, leave me a comment so I can put the game through the ringer again when I wake up. Thank you for your time.

Progress!

Posted by
Saturday, April 16th, 2016 5:24 pm

ProcLevelGen    layoutdesign

I’m feeling pretty good about my progress so far. I’ve been doing way too much on the back-end, so there isn’t too much to show yet, but I have some procedural platformer level generation and a general UI layout for attaching modifications , or “shapeshifting” in a way. You can drag mods back and forth between the inventory on the right and the mod slots on the left. The bottom left shows information about the currently selected mod. I’m having so much fun. Can’t wait to see everything that comes from this.

I’m In!

Posted by
Thursday, April 14th, 2016 6:09 pm

Well, this is going to be my very first LD, and I’m so excited. I can’t wait to see all of the wonderful games this community creates, and to see mine in there with them.

Engine: Unity

Music: BFXR; Various instruments

Art: Paint.NET

Models: Blender

[cache: storing page]