Home | Rules and Guide | Sign In/Create Account | Write a Post | Reddit | #LD48 | #ludumdare on irc.afternet.org (Info)

Ludum Dare 30 — August 22nd-25th 2014 — Theme: ??? (Suggest a Theme)
  • Ludum Dare 30 Begins: in 22 days, 3 hours, 19 minutes, 22 seconds
  • [ Real World Gatherings | Ludum Deals | MiniLD #53 ]


    ReTurtle post-mortem

    Posted by
    September 3rd, 2013 7:29 am

    I had a run at a few LDs before, but every time something came up that didn’t leave me the space to flesh out my concepts (which also happened to be quite ambitious most of the time). Between the last LD and this one I gave in and picked up Unity. For a while the proprietary/closed nature of it and the scene/gui-centric design scared me (as did the reporting of information about my machine during installation). Unity itself clicked with me quite quickly after I started doing things with it, and it is just what I needed for prototyping. I start (way too) many small experiments, so I want something that allows me to easily setup lightweight projects. In regards to that I only wish Unity would let me setup an empty project with metafiles and text-based assets from command line.

    Also “error CS1061: Type `int’ does not contain a definition for `f’ and no extension method `f’ of type `int’ could be found (are you missing a using directive or an assembly reference?)” some day will make me break something.

    Visionary

    I designed ReTurtle) as some kind of puzzle-shooter. You would have 10 seconds to beat a boss, so you need to find out how to do enough damage to him in the time. To make things interesting you would record 10 8 6 5 characters, one after another, where the coordination would give the game some depth.

    At first I was worried that coordination would be trivial. To fix this, friendly fire would make the player have to actually adapt the path for each incarnation to keep them out of each other’s aim. That doesn’t necessarily make for non-trivial coordination. Every character could still have his own small space he would stay in and just move a little now or then to avoid attacks. So it became the enemy’s job to make them move. I designed a set of attacks to get this done:

    • Motion: He would move everywhere once, and cover some space with bullets, so the whole group would be pushed around the stage, having to avoid bumping into each other.
    • The Grid: Having attacks that separate the playfield into cells would force the player to pick different safe spots for his individual characters if he wants to keep shooting at the boss.
    • Grenade: The grenade aims for the current position of every player. This way you have to consider where your previous incarnations will move to, while picking your path, which adds another aspect to the puzzle. The second use of it is that it avoids any completely safe spots.

    Now having an idea of the base concept, I wanted to add a bit of depth, so I added two mechanics.
    pm_tutorial

    • Gun Charge: Friendly fire is already there to keep the player’s finger off the trigger, but I didn’t want to make him feel bad about it, so I added a small challenge. While not firing, the gun charges for one second. Firing once the gun has fully charged does quite a bit more damage but getting the most damage out of it requires focus. This creates space to improve.
    • Shield: You would have a shield that reflects attacks (by either player or enemy), making them more powerful in the process. To make things more interesting the shield is not able to reflect projectiles right back (which would leave some space for abuse). A frontal deflect would just destroy the projectile, while bouncing it around at 90° would maximize damage.

    The numbers were designed so you can do 25% damage with one character through rapid fire. This means you need four of your five incarnations to beat the boss that way. Using all perfectly timed charged shots lets you raise that to 34%, which is just enough to win with three characters, but requires to not waste time between the shots (and of course every shot to hit). An optimal reflect doubles the projectile’s power, so reflecting a charged shot adds the equivalent of another on top of it (without needing charge). This way the first character can replace the third, if all shots are perfectly reflected by the second. So every mechanic was designed to cut one character by perfect use (note: due to projectile flight-time it probably doesn’t, but gets close).

    Back to earth

    For the first day I planned to make all core mechanics work and do all the visuals. That’s quite risky, since I couldn’t tell whether the parts would work together at all. So after day one I had incarnations being able to get recorded, shoot and reflect shots. The boss just sat there and fired a shot straight down now and then. Modeling the boss took me longer than it should have and he didn’t look much like my sketch (I suck at blender). To make up the time the player built from a few 2D-Layers without any animation. The stage suffered the same fate. Planned were multiple layers of tech-y plates and a stripe in the center with numbers running through it to show you the remaining time. But to close out day one, I made what is in the game now instead.

    Schedule for day two was boss-actions, menu and intuitivation (that’s a word now), sound was pushed to what would be left. After attaching a hitbox to the boss and making him move through the stage, I could finally test some of the feel. To my surprise coordinating characters already was more interesting than I expected at that point. One of the challenges I didn’t think of is that under pressure one tends to react to an attack the same way every time. This makes the act of creating different paths for all characters challenging by itself, since any time you have to rely on reactions you end up in the line of fire for another incarnation.

    Fireballs were already there from day one, so I only had to implement lasers and grenades, which went smooth. Unfortunately not everything went this well. With most gameplay in place, shield just didn’t work out. I boosted its value by making the scaling multiply. That doesn’t help if you can’t set it up though. It’s still too powerful due to a bug, but quite useless for proper gameplay.

    pm_easy

    What threw my schedule off was the upgrade for player-visuals that got pushed over from day one. I wanted only the ‘head’ to move and the game also needed something to point at the currently controlled character. Some information on the charge-state and something to show the number of an incarnation was critical too. With all of this done I was already closing in on the deadline.

    I still had to add a menu, and link everything together. So I threw together the atrocity that is the main menu, added some hit-detection for clicking, and moved handling of the game-progress to the new scene. That left me just enough time to set up a dropbox-account until the submission-hour started. What fell off was sound and any kind of ingame-instructions, including any hints on what you have to do on the main menu.

    Conclusion

    I’m mostly ok with how the game turned out, I got to play with a few mechanics and they didn’t rip each other apart. It is desperately in need of instructions, some tuning for the core and an overhaul in regards to presentation. I gave myself a week to tweak everything, before I let the game go and focus on other prototypes. The time is up and I’ve added the post-compo-version you might want to try after playing the compo-version. You could also try to beat these informal challenge-times in the post-compo-version: under 6 seconds as a ‘silver’-mark and under 5.5 seconds as ‘gold’-mark. I’ll follow up with an overview of the changes soon, this post is long enough already.

    Tags: , ,

    Leave a Reply

    You must be logged in to post a comment.


    All posts, images, and comments are owned by their creators.

    [cache: storing page]