On Friday night when the theme was announced I just sat there and thought while scribbling some ideas on paper.  I wanted to do something with physics and attaching enemies or weapons to yourself.  At first I was thinking of doing a round planet with humanoid figures using telekinesis.  I started to set this up in code but wasn’t really feeling the idea so I just went to sleep.

Saturday morning I took a quick look at games with a similar concept for inspiration, specifically TUMIKI Fighter and Captian Forever.  My design is based on simple abstract shapes so they are easy to recognize on form alone allowing for the color to represent health.  I also planned on having random weapons with random colors and lots of trails all over the place.  For color values I have it set up so I can randomize over HSV space to get away from the RGB kind of look.

Building off the clean project in my game engine I set up an object oriented structure where there’s a base class shared by the player and enemies, a base class shared by all part types, and everything derives from a GameObject which is part of the engine.  By about 3 PM Saturday I had the player moving around with the ability to pick up parts and attach them though it was sloppy and the only part was always the same default weapon.  I took at least 2 hours to put some polish on the system of grabbing and attaching parts.

Around this time I did a little art pass: tweaking colors, particle systems and other visual aspects.  I threw in an enemy that just randomly tried to pull parts to it and shoot.  By the end of Saturday night I wanted to have all of the core functionality in game so I could take the next day to add better AI, polish, balance and tweak.  Trudging along I added the other 3 part types in a very rough state.  Around midnight Saturday night I posted a screen shot to demonstrate the core functionality.

Sunday I started out by just tweaking lots of little things.  There needed to be some background for movement reference so I just threw in a simple particle system of large gray squares.  I worked on the AI a bit and improved their tractor beam use.  I made them move around pretty much randomly near the player.  I tried having them turn to aim but that isn’t very reliable because of their poor ability to configure their ship so they just cheat and rotate their weapons directly.  There just really wasn’t enough time to make any kind of real AI.  Up until now I just had the player start next to some parts and an enemy that I placed in the editor so I added logic to randomly spawn in enemies and parts out of view of the camera.

This felt good enough so I wanted to spend some time adding random weapons to add both visual flair and gameplay depth.  As a simple balance measure all weapons have the same DPS with different firing rate, bullet damage, and bullet count.  Other aspects like speed, spread, and color are just randomized.  It seemed like a big part of this game was reading where damage was coming from and going to so I had an idea to make bullet size proportional to their damage to facilitate a quick visual read.

As the deadline loomed I started to freak out a little becuase there were only a few hours left and I harly spent any time actually playing my game.  So I took a while to just play and polish random gameplay issues.  I experimented with several different control schemes but decided to go with the simplest which seemed like a good enough choice given limited time.  I threw in some random large solid black boxes to both add an interesting element to game play and visuals while also making the world feel more solid to the player.

With about an hour to go I focused on sound by adding more firing sounds and a tractor attach sound.  I scaled fire sound frequency by bullet damage so weaker weapons sound higher pitched to make it sound a little more dynamic.  In the last half hour I just tried to play my game only tweaking a few minor things.  I had a score display of how many enemies were killed with high score tracking but decided to remove it a the last minute.  Adding a scoring system can add a lot to a game but it can also detract if done incorrectly.  I like the idea of just providing a pure experience without the need for imposed goals. The implicit goal of growing your ship is as motivating a factor as any.

It’s was hard to come up with a name for my game in such a short period of time.  I went with Protractor because it sounds sort of abstract and mathematical while also containing the word tractor for tractor beam.  I’m happy with the way my entry turned out and after playing it for a bit since then it still seems to hold up pretty well.  Next time I’d like to try to get some testers lined up, people offered but I was so focused on working that I didn’t take the time to contact anyone.  Also I’d like to plan my time a little better so at the end I have more time to just play and tweak.

It’s impressive how well put together the Ludum Dare competition is.  The judging phase is currently in progress and it’s great fun playing everyone’s game and doing my best to judge.  It’s sort of like playing Wario Ware on a grand scale.  Thanks to everyone who put it together and congrats to those who successfully delivered a game.

Competition Entry

• Official entry page at Ludum Dare

Updates

• Download newest version: http://www.frankforce.com/downloads/protractor.zip
• I fixed some bugs and made some tweaks.  If you aren’t playing for review purposes I recommend the newest version.
• You WILL need latest DirectX! Update DirectX at Microsoft’s website.

Video

Instructions

• Kill enemies and collect their parts to build.
• Use left mouse to pull parts to you to attach them.
• Colors indicate health level.  Purple is super high health, red is about to die.
• Weapons are randomized but also normalized to all have the same DPS.  So on average they will cause the same amount of damage over time. Larger bullets represent more damage.
• Try to keep your ship balanced or it will become difficult to control.
• Triangle – Weapon (random but normalized to the same DPS)
• Square – Healer (auto repairs ship and attached parts)
• Pentagon – Speed Booster (increases speed and turn rate)
• Circle – Extender (allows for expansion)

Controls

• Left Mouse – Tractor beam
• Spacebar or Right Mouse – Shoot
• Mouse Wheel – Zoom
• WASD – Move your ship
• Alt+Enter – Go fullscreen (recommended)

Screenshots

Saturday Night Progress Report

Core functionality is in.  Enemies are composed of parts.  Enemies drop parts when they die and player can attach them.  Part types are: shooter, engine, healer, and extend.  Tomorrow: weapon randomization, better AI, tweaking and game flow.

Sunday Afternoon Progress Report

I finished first playable.  All the basics are in.  5 hours left for tweaking and adding more weapons.

Final Report

The name of my entry is “Protractor”.  I’m happy with how it turned out.   Visually I hit exactly the mark I was going for.  I didn’t get much time to play when I was actually working on it but after playing it a bit now I can safely say that it’s pretty fun.

Everything necessary to create a fully featured game is included: physics (box2d), rendering (directx), level editor, particle system, sound, music (ogg vorbis), joystick input, GUI, and debug console.  The code is fairly well documented and includes a simple demo game plus a clean slate to build on.  The project is all set up on SourceForge. You can sync to the SVN repository or download a package of the current release.  In order to use Frank Engine there are only a few requirements that can be downloaded for free: Microsoft Visual C++ 2010 Express and the latest DirectX SDK.

There will be many improvements and changes coming soon.  If anyone is interested in working on the source or using it to develop a game, contact me I’d be happy to help get you started.  For some examples that I’ve created with this engine check out A Stitch In Time or Pill Bug.

Here’s the current feature list:

• Focus on simplicity, flexibility, and ease of use
• C++ using object oriented architecture
• Very large streamable worlds
• Integrated level editor
• 2d sprites, terrain and particle system
• Sub frame interpolation using fixed time step
• Integrated physics with Box2d
• Stereo sound effects with Direct Sound
• Music with Ogg Vorbis
• Keyboard, mouse, joystick, and Xbox 360 or PS3 controller input
• Integrated with The DirectX Utility Library (GUI, sound, etc)
• All assets can be compiled into the exe (besides music)
• In game debug console
• Dev environment is Microsoft Visual C++ 2010 Express Edition
• Graphics SDK is Microsoft DirectX 9

Download Pill Bug – Latest Version *

Controls

• WASD or D-Pad – Movement
• Space – Jump (Hold to auto-jump)
• Left mouse – Rapid fire forward mounted machine with overheating
• Right mouse – Unlimited slow motion
• Alt-Enter – Toggle Fullscreen (recommended)

* Updates:
6/1 – I was having some physics jitters (perpetual oscillation) caused a high gravity setting. To fix it I had to implement physics sub stepping.
6/24 – I finally added sound loops to my game engine and make use of them for player movement sound. Still needs level design work but I need to refine the gameplay and add more object types before investing any real time in level design.
7/4 – Joystick Support! Works with any dual stick gamepad like the Xbox 360 or PS3 controller.  If you use a PS3 controller with Motion Joy, set it to 360 controller emulation mode.

The terrain textures are from Spiral Graphics free texture packs
Sound effects were generated with SFXR

Like most games it stared as a copy of another game, in this case Spaghetti Planet. In about an hour the guts were commented out so I had a clean slate to slap in the player’s ship, weapons and controls from another game I had laying around. The core hook for this game is time travel so I focused on getting that working first. Basically it runs on a fixed time step of 60 fps and stores the player’s position and input for each frame. Then some code feeds the frame data back into a player object to make the ghost replay. Initially the details about how the time travel would work were a bit fuzzy. I knew that I wanted the player’s ghost to become a hazard if played poorly but a necessary ally if planned well. After playing Chronotron I really liked the concept of needing to return to the time machine to facilitate the kinds of puzzles that I had in mind. For most of the week I was using the working title “Time Ghosts”.

The enemy behaviors are pretty simple archetypes chosen because they were easy to implement and wouldn’t need any randomness which could cause problems with time travel. There are bouncers, shooters, seekers and seeker spawners. For the seekers there was initially a problem with clumping where they eventually cluster together in a ball so I just added a single additional force that pushes away from the nearest enemy which works amazingly well at pushing them all apart. I wanted to do a boss battle with multiple ghosts fighting the same enemy but had to cut it due to lack of time.

Door switches took a little bit of work and some changes to the editor, I kept it really simple though. Every object in this engine has unique identifier including doors that is visible in the level editor. When a switch is placed there’s an attributes box to enter the id that belongs to it’s door. The power lines are only there to create a visual line between a power line and a door and don’t have any real logic. As a variation on doors a little time was devoted to experimenting with a physical switch where something gets knocked down and falls blocking the path.

Up until the very last day there was still no real level design, only a tiny test layout and bunch of ideas scribbled on paper. Throughout the week I had been brainstorming and came up with a few key ideas to explore the core game mechanic: racing against time, order of operations, needing to kill a ghost, and forcing multiple ghosts into small areas. At first the task of building the entire level in under 6 hours seemed daunting but it progressed rapidly. Starting with a central hub style layout I tried to just make broad strokes, branching out in different directions to get the main ideas represented. There was less then an hour left for testing by the time level design was wrapped up. Thankfully my brother Ben was around to help me test it bit before I posted it to the EGP forum.

Normally I would just prefer that people download the latest version of my games, but for those interested here is a link to the 7 day version of A Stitch In Time that I submitted to EGP. You can check out the level edit mode by pressing F4.

Download A Stitch In Time – 7 day version

You are trapped in a 1 minute long time loop and need to collect all the 30 time shards to save the universe. Return to the worm hole to time travel. Coordinate your efforts to beat the puzzles but if you touch any of your time ghosts not only will you instantly die but the ghost will also be erased from existence. I think it is pretty challenging yet winnable if you are crafty enough. You may need to update DirectX in order to play it (if you receive a missing dll message click here).

Download A Stitch In Time (latest version)

Controls

• Left mouse – Rapid fire forward mounted machine with overheating
• Right mouse – Omnidirectional tap to fire or hold to charge blaster
• Middle mouse or Space – Speed Up Time
• WASD or D-Pad – Movement
• Ctrl – Self Destruct
• Alt-Enter – Toggle Fullscreen (recommended)

* Update – I put up a new enhanced version with auto save, improved frame rate, and many gameplay improvements.