About the Game

​

  ‘Gepeto Plays’ is a tower defense game played from a fixed camera perspective where you control an AI Robot Toy that participates in ‘battles’ inside a child’s playground. The kid itself just cares about having fun so, for it, it does not matter which side wins. That said, the kid ‘aids’ both sides by doing actions such as ‘spawning’ enemies on the lanes to attack the base, deploying towers and using typical ‘destructive skills’ to even the odds.

 

Your role as a robot is to defend your base against an evil troop of enemy toys by…

• Collecting scrap dropped from defeated enemies

• Repairing Tower Bases and Broken Towers by using scrap

• Requesting broken towers upon repaired tower bases

• Draining enemies for scrap. This weakens enemies health and can be lethal

 

To construct each tower first you need to repair it’s base and then call for deployment, where you can choose one of these towers:

• Sticky Dart Tower: Fires a fast projectile that deals damage to a single target and sticks to it.

• Magnifying Glass Tower: Deals instant damage to a single target though focused sunlight.

• Playdough Tower: Slows enemy movement by constantly leaking playdough around area of effect.

 

After a tower is requested, the kid’s hand brings a broken version of the tower to the base it was requested from, and the Robot needs some repair it in order for it to have full effectiveness. After the tower has been repaired you can add and upgrade attachments to it, making it more powerful:

• Range: Increases the area reached by the tower’s 

• Fire Rate: Decreases the time between shots

• Damage: (Exclusive to towers that deals damage to enemies)

• Effect: (Exclusive to towers that applies one or more effects upon enemies)

 

Also, the player has at its disposal 2 power ups that can be used by spending scrap and have cooldowns:

• Teleport: the player chooses an object and a location, then the kid’s hand picks up the object and puts it on the targeted location. This power up has some restrictions based on the type of the object that was chosen to be teleported.

  • Towers: Can only be teleported to another empty, repaired base

  • Enemies: Can only be placed in any point of any lane

  • Player Robot: Can be placed anywhere

• Air Strike: The kid adds a finger puppet with the shape of a missile to its index finger and hits the targeted area with it repeatedly, dealing massive damage to nearby enemies.

 

What went RIGHT

​

1. Defining our goals early:

   • Work every single aspect of the game as a brand new implementation to test our limits within the event deadline, without resorting to previously developed projects, code snippets, macros and libraries.

2. Acknowledging our limitations:

   • We knew right from the start that art was going to be a problem since we didn’t have an artist in our team, but we thought that if we focused on designing/developing some entertaining gameplay mechanics would be enough to keep players engaged in our game.

3. All planned within initial brainstorm:

   • Starting development only when we had thought out all ideas and planned the basis of the technical side of our project allowed for a coordinated effort toward our goals.

4. Working with an Engine that we have intimacy:

   • We spent the last three years of our career working with Unreal Engine and this was almost part of our DNA, we felt at home.

5. Writing the Post Mortem:

   • Learning from our mistakes, knowing what make us strong and keep going is key to have a successful project.

6. Talk about failures is what guides us on the right path:

   • Know we feel great and proud of what was accomplished we recognize the work and effort each other puts to pursue a game developer life.

7. Having support from loved ones:

   • Anything in life is more important when you have the support and admiration from the ones you care the most.​

8. Leaving the site:

   • Having great fellowship and leaving all that game talk behind and giving your mind a break is needed. Seeing the outdoors and breathing fresh air can be energizing.

9. Making a tutorial:

   • When you try to teach someone how to play your game, it's a mind shifting from game developer to user. All developers should know that even though when the game is so defined in your head, you still need to explain that game’s mechanics very well because the player doesn’t knows it as well as you do.This helped us find UX problems right off the bat, with the game scope being already closed we had all we needed to make the tutorial level happen with almost no effort to design it.

 

What went WRONG

1. Dual input modes:

   • We shouldn't divide our focus on two target input devices (Gamepad vs Mouse + Keyboard).Unreal Engine make it easy to have multiple input for the same Action but it changed our focus for some UI/UX decisions.

2. Ignoring some of our base goals:

   • Without pre-developed snippets and macros we had to code some things that we had already done before, and this took us a lot of time despite our initial predictions.. by the time the event was reaching its deadline, we felt forced to resort to some dirty coding to finish the project.. That way, one of our main goals just flew straight out of the nearest window...

3. Try to reach for some artist on site:

   • We were open to the people we know at the event but with so many others potential friends and teams that could enhance each other, we didn't took this opportunity.

4. Technical problems

   • After the initial 24 hours, one of our notebooks had a sudden drop in processing power and never recovered from it (until this very day). So Unreal was barely working on it, and every task (even some such as importing static meshes) had become a chore to do, as it had a great impact at our efficiency.

5. 48h with 6h sleep:

   • Working nonstop and to exhaustion was limiting our production and sometimes we found ourselves looking at the code and waiting it to take some action for us.Negative thoughts don’t and that feeling that we won’t make in time as crushing from inside.

6. Succumbing to Pressure:

   • We deliberately chose to sideline the artistic part of the project until we wrapped up the game’s mechanics. We were already late on a few minor milestones and were very tired.. Also,most projects being developed by our neighbours had astonishing art so this had a heavy impact at our psyche. Our game still looked like a half-baked prototype nearing the end of the event. So one of us stopped programming and rushed to make some models that were wildly based in our established context, but it still took some time to look out for references and develop the assets.. time that could be better spent finishing up and event polishing some player mechanics, UI, etc..

7. Art Direction is so important:

   • With some art definitions we wouldn't bother so much with how our game was looking and focus more on what we are good at.

8. Trying to work as a Studio:

   • We didn't judge very well what needed to be expandable. The amount of time designing and developing fully modular, DataTable-driven systems were a huge overkill for a project that had such a short a deadline to be delivered. Game Jams focus on speed… and speed, scope and quality of code sometimes don't walk together.

9. Finishing gameplay loop:

   • With so little time to put together all systems a main feature was missing how to win the game and what’s the next level.

​

Conclusion

Game Jams put everything you know about development to the test. With every passing hour your stamina decreases and, with that, your mind can start playing some tricks on you so take a break from time to time.

Lets define Time as Money don't mind spending time on planning because it will save you more on the long run. Listening to everyone on the team definitely results in better morale and, therefore, more willpower to see that the game makes it through the end of the deadline. Share ideas with the team. Know when to cut things up and when to take the next step, have milestones pretty well defined it can guide your team and lead to the best path to take.

Get to know people on the site,they might help or even team up with you.. you never know.

Overall the energy consuming 48h developing a game is like a real-life mihaly curve, leading us through tough decisions, adventuring on unknown areas of development, meeting new fellow developers. Sometimes leaving the site to eat or take a 2-hour nap was like being plugged on a supercharging station, bringing our energy and soul back to its (current) full potential.

Game Jam is not about the game is about the connection.