People use their phone cameras to find pokemon and take pictures of them.
Choose pokemon based on facial features or body shape or both.
After the pokemon is identified, begin tracking the movement of it
When the human body turns, the pokemon also turns
Track certain parts of human to mirror skeletal movement of pokemon (arms, legs, body turn, head turning)
upload pictures to a database (in-app and website) where people can rate them for certain characteristics, awarding them with badges
Using Second Surface, one can create playgrounds for others to play in the real world. Only doodles for boundaries are needed to create levels.
walls (thick lines) that can be adjusted
boxes and circles that can be scaled
add rules to the game, perhaps just writing a doodle at the start is enough
colors, rules can define what they do: green for good, red for bad, etc.
NOTE: Works for iOS 6, not sure about 7. I’m updating everything right now!
This project is really old, but it still seems to work for me. It’s an Xcode project.
2. Open PinkiesUp.xcodeproj
– to play it on multiple devices: run the game on each device to install it, start the game on each device, on one device press host game, on the other devices press join game, press at least 2 buttons on each side to have a minimum of 2v2, press ready on each device, press start on the host device.
As Jon often describes the game to others, “it’s basically flip-cup for iPad”.
Two teams race, each team having a quirky physics based character code-named Harold. Each player is assigned one button. Each active player group must press their buttons in sequence to add force to Harold. A button pressed out of sequence causes Harold to physically collapse, stopping him for a moment. First Harold to the finish line, which is at the end of the screen of the last device, wins.
A social extensible-multiplayer iPad game with a simple interface. It’s what Jon and I had been gravitating toward for the previous few months.
We intended to maximize the use of iPad’s features: eleven touches, physics, and networking. Oh the possibilities! A single parallax scrolling background over multiple devices as Harold runs across the screen, UI color palettes and silly sounds for each device.
The game is Jon’s idea, which constitutes a large portion of the game design. We collaborated to etch out further game design. I programmed everything except the physics of Harold. Jon also handled visual design.
The greatest problem with development was the lack of consistent playtesting. Consistent playtesting is needed to see progress and priority, but also to maintain motivation. A related problem: we were working remotely. Being physically together is important.
I also underestimated the time it takes to write code for Objective-C, Cocos2d, Box2d, and Game Kit. It was at least five times slower than writing code for my previously used game engine: FlashPunk. I also felt that my networking code was poorly written. It takes time.
The lack of feedback caused motivation to wane, and the work sits on my computer, teasing me. Perhaps I just need to bring it out, playtest it to regain motivation, and finish it.
This is my entry Experimental Gameplay March 2012. The theme is economy. It is the result of developing a game without thinking about the core game mechanic first. It is a complete failure.
Player 1/Player 2 – description
A/’ – Red
S/; – Green
D/L – Blue
F/K – hold and press RGB to direct military to retreat, halt, and attack
G/J – hold and press RGB to tell workers to get a specific resource (by default it auto-gathers)
Player 1, use right hand
Player 2, use left hand
Player 2’s controls mirrors Player 1
A/’ – index finger
S/; – middle finger
D/L – ring finger
F/K – little finger
G/J – little finger
How to play:
It’s just a simple real-time strategy game, except you play with a keyboard. Blue units gather resources, green do nothing as of now [supposed to research/upgrade], red can attack.
As of now battles are sad due to lack of solid objects and pathfinding. Also, there is no win condition.
What was envisioned:
1000s of units, flocking, simple yet competitive gameplay (think Hokra), precise controls (think QWOP), color-collar workers (and a statement against classism), resource renewal (and a statement against resource consumption), map based off of image, able to upload map (MS paint is now a map editor!), large resolution to zoom in and out.
Why it didn’t work:
Decreasing the amount of player input increases the amount of AI programming. Competitive games require more balancing and tuning than non-competitive games. Multiplayer on the the same screen isn’t as fun because it lacks fog of war.
Also, I felt like crap while making this. It was forced. It just didn’t feel right.
I feel like a game could be created with these initial ideas, but I can’t bare to look at it again.