Blog

Top Bloggers

Who's online

There are currently 0 users and 3 guests online.

Spore Creature in Wild Pockets!

Today we're going to expand on one of the previous blog entries about the Wild Pockets Model Viewer by TAKING IT TO THE NEXT LEVEL!


Click Thumbnail to View Pocket

Let's say you're playing the hit game Spore and have a creature that you reeaaaallllly like and wish you could put it on your website - sorta like that time I took a picture of my tv screen of that guy with a chainsaw arm and taped it to my bedroom door right under the Eddie Ave sign. Still with me? Good, because things are about to get crazy. WildPockets gives you the power to take a creature out of Spore and put it in the Model Viewer just like any other model - fully rigged and textured!
If you're using an up-to-date retail version of Spore, you have the ability to export any creature to a 3D Collada File and then into WildPockets. Here's the steps!
1) Find or make a creature you like in Spore
2) Open it in the Creature Editor in the game
Spore

3) Make sure you're in "Paint Mode" and open the console by hitting "control-shift-c"
4) In the console type: colladaexport
Spore Image

5) This will create a collada file (.dae) and texture set in My documents/My Spore Creations/Creatures/
6) Using either Maya or Max, import the collada file. A good collada importer for either can be found here: http://www.opencollada.org/download.html
Spore

7) The creature should be fully rigged and UVed.  Some of the textures may need to be reapplied, but feel free to pose or even animate your creation for WildPockets.
8) Using the appropriate WildPockets exporter, export it from Maya or Max to your WildPocket's account library.
Spore

9) Once in your library, you can either view it in the builder or, following the tutorial we linked to, insert it in the Model Viewer for a selfcontained, embeddable, pocket.
Spore

10) Revel in the fact that the creature is now playing on your turf.
Happy Hunting!

Numbers Count

As we continue with our preproduction designs, a lot of times it can be easy to make assumptions of how a gameplay system will work or how the game will flow. “Oh, some enemies and powerups will fly by during that stage,” won’t really cut it once the game begins actual production. Sometimes, the person coding the experience will want nothing to do with any sort of design choice, and even worse, make a poor choice because they either misunderstood a high level design point or just lazily threw in the first thing that came to mind.

Continuing with some of the themes we’d mentioned in Rocketboy, we were quick to find out that some of systems we’d assumed would be relatively easy to implement ended up being some really complex numbers once we got into them – mainly enemy, powerup, and obstacle generation and frequency.

To give a quick explanation of the rocket gameplay - as the Rocketboy travels forward, block obstacles, enemies and powers up generate and travel towards the character and must be either avoided or collected.

This concept worked fine on a high level, and we’d seen games do a very similar style of game, so we felt confident that this would be one of the easier designs. However, once we started working on object generation rates, we found this to be MUCH more complicated than we thought.

List of Objects

Rewards

Money + 5

Money + 10

Money + 20

Money + 50

Money + 100

Fuel + 5

Fuel +10

Fuel Fill Up

Shield + 1

PowerUps

Slow Rocket

Shrink Rocketboy

Metal Suit

Auto Canon

Shield + 1

Hazards

Contextual Block Small

Contextual Block Big

Contextual Block Long

Stationary Enemy

Moving Enemy

Seeking Enemy

Projectile Enemy

Large Enemy

Our first thought was to have a percent chance for an obstacles or power up to appear or not appear during a set length of the screen depending on the level. This would have worked fine for a game with only one level and no ramp in difficulty, but after seeing the shear number of objects divided up amongst a chance to appear out of 100, most players wouldn’t have the opportunity to get the better objects to last long enough to see the later levels – or worse, get a string of really strong enemies on level 1 because the numbers didn’t happen to work in their favor.

We then decided to break down hazard and reward objects by stage – basically levels with harder enemies and obstacles will provide better rewards and powerups.

Milestones(per hazard generation)

Stage 1 1-20

Stage 2 21-50

Stage 3 51-100

Stage 4 101-200

Stage 5 201-300

Stage 6 301-500

Stage 7 501-800

Stage 8 801+

Stage 1 – 20 Hazards



Hazards (1 per 2 screen lengths)

Block Small (55%)

Block Big (35%)

No Hazard (10%)

Rewards (1 per 1 screen lengths)

Money + 5 (50%)

Money + 10 (5%)

Fuel + 5 (30%)

Fuel + 10 (5%)

No Reward (10%)

Power Ups (1 per 7 screen lengths)

Auto Canon (50%)

Infinite Fuel (10%)

No Power Up (40%)

Stage 2 – 30 Hazards



Hazards (1 per 2 screen lengths)

Block Small (45%)

Block Big (45%)

Stationary Enemy (10%)

Rewards (1 per 1 screen lengths)

Money + 5 (40%)

Money + 10 (10%)

Money + 50 (5%)

Fuel + 5 (25%)

Fuel + 10 (10%)

No Reward (10%)

Power Ups (1 per 7 screen lengths)

Auto Canon (30%)

Slow Rocket (30%)

Infinite Fuel (10%)

No Power Up (30%)

Stage 3 – 50 Hazards

Hazards (1 per 1 screen lengths)

Block Small (40%)

Block Big (25%)

Block Long (15%)

Stationary Enemy (10%)

Moving Enemy (10%)

Rewards (2 per 1 screen lengths)

Money + 5 (30%)

Money + 10 (15%)

Money + 50 (10%)

Fuel + 5 (20%)

Fuel + 10 (15%)

No Reward (10%)

Power Ups (1 per 6 screen lengths)

Shield +1 (20%)

Auto Canon (25%)

Slow Rocket (25%)

Infinite Fuel (10%)

No Power Up (30%)

On paper, this seemed to work out much better. Which brings up another important point – while these are still all guesses until we try them out in the actual game, they are at least educated guesses based on a system and a designer’s ability to imagine it live. Even though these numbers will be tweaked, changed, and maybe even thrown out all together during iterations, there’s at least a place to start. One of the last things we’d want during development is for production to come to a standstill when a programmer asks, “How much is ‘a bunch’ of enemies and ‘some’ money, exactly?”

Thumbnail Image: 

Entry Two

We’re back again with another Wild Pockets designer diary. In case this is your first time joining us, this is place where we plan to share our current work, ideas, and processes and hopefully help out some of our users with their own ideas.

In our previous entry, we’d talked about our original batch of potential game ideas to make in Wild Pockets. These ideas would not only present Wild Pockets as a platform for the next generation of games on the web, but also showcase the strengths specific to it. We’ve now taken a few of the stronger ideas and began to go more in depth with their designs. To do this, for each of the games we established and identified a few different categories:

Goal: What is my ultimate purpose while playing this?
Gameplay: What are ALL the different types of gameplay going on in my game? Until you start listing these out and describing them, you’ll never get a complete sense of scope or cohesion. This will also help you identify trouble spots or underdeveloped ideas that you can either spend more time thinking about or attempt to cut long before you begin actual development. If you’re complete enough, you’ll also be surprised by how much is actually going on in your game.

Win/Lose Condition: How will I be judged on success or failure. Surprisingly, this can very easily become an afterthought or taken for granted. Unless you begin to consider the details of these conditions, you’ll never realize the complexity that comes along with something as simple sounding as “save the princess” or “die.” Also, having these plainly stated outside of the regular Gameplay section will help to emphasize them since many times these will be a combination of several different gameplay systems.

Controls: Just what it sounds like. How will I control my game and with what input devices? If this starts to get too long, you’ll know its waaay too complicated. Some of the best online games have only one button and movement controls.

Interface: This is another aspect of your game that could be easily overlooked. Start by listing out every possible interface element you’ll need – this includes the HUD, any gameplay menus, and even the main menu. Then, begin describing each of these elements to figure out what they convey, how they’ll work, and also how they will interact with the other parts of my game.

Main Assets: This is where I would list out all the major objects that will be in my game – actors, props, locations, etc. The important ones will be obvious, but the purpose of this list is to identify the ones that are required, but not necessarily on my mind when I imagine the game.

If you complete a similar set of information for one of your game ideas, you’ll have the beginnings of a pretty simple, but solid, Design Document.

Any of these sections can be developed further (especially anything under the Gameplay section), and any effort spent doing design is rarely time wasted.

This will end up being an irreplaceable tool that helps you organize your thoughts, set a plan, and if you are working with a team of people, provide a strong, common, vision for everyone to follow.

This last example is one of the MOST important reasons to create a thorough and comprehensive design document or you may end up with 4 people on a team making the 4 different games they are imagining in their head.
Here’s one of the initial games we gave this treatment too:

Rocketboy Advanced

Overview: The flying character automatically moves forward and pressing the left mouse button applies a force up and then automatically glides back down. Try to travel as far as you can without crashing and keep your base alive as long as possible. Distance traveled rewards points that can be spent on things to make traveling longer distances easier such as defenses and fuel boosts.

Goal: Travel the longest distance possible without running out of money and before your base is potentially destroyed

Gameplay:
Rocketboy Death
When a rocketboy collides with an obstacle or hazard, the rocketboy will crash and die. If the player has purchase defensive upgrades from the base, the rocketboy may be able to sustain multiple collisions depending on the upgrade. The dead rocketboy will remain at the location where the crash occurred. If the corpse is contacted by subsequent rocketboy, it will be collected along with a resource boost. Once death occurs, the player is returned to the base and allowed to launch another rocketboy, if available.

Navigation/Exploration
Fly a rocketboy through the scene avoiding obstacles. The further a rocketboy travels, the more resources are awarded back at the base. Using the jet pack to gain altitude will use fuel with the possibility to slowly regenerate based on current upgrades. At certain distance milestones, the environment will transition to a new location with its own rewards and hazards. Each section will also contain a resource node.

Rewards
Money
Fuel
Slow Speed

Base Defense
The further a player travels in the scene, the higher the threat against the base becomes. Enemies slowly travel towards the base and reduce its shields and finally its health. Once its health is 0, the base is destroyed and the player loses. The base starts with default shields and automated defenses, but can and must be upgraded to defend against later threats. The rocketboy may also aid in defending the base by defeating incoming enemies with their shields, automated defenses, or kamikaze. However, base defense is mainly a passive activity meant to gauge resource management.

Collection/Resource Nodes
While traveling through the scene, the rocketboy may collect various objects that can reward resources to be used back at the base, shield bonuses, or speed changes. A rocketboy may also claim resource nodes by contacting them in flight. This will ground the rocketboy, reward additional resources per distance traveled on all subsequent flights, return the player to the base, and add an extra jetman (to replace the one used to claim the node). A node can be captured only once.

Rocketboy Upgrade
The player has the ability to use resources at the base between rocketboy launches to purchase upgrades for all future rocketboy. They are (but not limited to) more fuel, faster fuel recovery, additional shields, faster shield regeneration, and active defenses.

Upgrades
Fuel
Fuel Recovery
Shields
Shield Regeneration
Active defenses

Base Upgrade
The player has the ability to use resources at the base between rocketboy launches to purchase upgrades for the base. They are (but not limited to) repairs, shield increase, shield recovery speed, passive defensives, and additional rocketboys for flight.

Upgrades
Repair
Shield
Shield Regeneration
Defenses
Power
Recruit Rocketboy

Win: Endless, highscore/mastery of upgrade and resource managment

Lose: Base Destroyed. This will happen because its health reaches zero. Running out of money and being unable to buy rocketmen and upgrades will accelerate this process.

Controls:
Mouse and left click – navigate menus and base options
In flight-
Left click – fire jet pack

Actors:
Rocketboy
Complex Model. Humanoid figure with engine attached to his back. Allow for additional geometry w/ upgrades. Rocketboy will also have a limited number of animations – fly, launch, fire engine. Include joints in model so it can ‘ragdoll’ during a crash.

Base
Complex Model. Home base and launch pad. As the base is upgraded, additional geometry will be added with its own animations (defense systems, new launch pad, etc..)

Resource Node
Single Model with 2 animations – unclaimed and claimed.

Hazards
Simple Models. These will be barriers, floating obstacles, and basic enemies. They will be themed to each of the locations in the field.

Locations:
Base
Field

Interface:
HUD
Distance traveled
Fuel Remaining
Rocketboys left
Rocketboy shield level
Base Health
Resources
Crash Alert
Launch Alert

Base
Upgrade Rocketboy
Upgrade Base
Launch Rocketboy

StartTitle

Main Menu
New
Save/Load

Thumbnail Image: 

Welcome to the Wild Pockets Designer Diary

Welcome to the first ever WildPockets Designer Diary! We're doing some really exciting stuff, and we look forward to sharing a lot of it. In the upcoming weeks, we'll be giving you an inside look at the team's day-to-day work, our ideas, features, and the 100 other things involved in game development. We also hope it helps some of you in the community think about projects of your own.
Since this is our premier entry, I'd like to spend some time going through the process we used to come up with our first round of potential game ideas to pull off in Wild Pockets. This list not only helped us get started on a path to making one final, polished, demo, but also to establish what games and features would showcase the strengths of our Wild Pockets engine.

To get started, we went through almost every most-played Flash game on all the major sites such as Addictinggames.com and Kongregate.com (Ed. Note: harder work than you'd think!) and documented them to see if any common trends could be recognized. The main ones we discovered were: Simple Controls, Replayability, Incentive, Ease of Agency, and Polish. These trends were then taken and used as a standard in our own development. While game design is subjective, it's much easier to predict success if you're able ask yourself, "Does my game have enough _______?" A lot of these trends are also interconnected, so it may not be easy to establish any single reason for a game's success since many of them work together to improve the effectiveness of the others. Once these trends were identified, we decided which existing games exemplify them best and would benefit the most from the resources Wild Pockets has to offer. This list greatly influenced the 10 game ideas we came up with over the next week. (Screenshots of games that mirror these ideas have also been included.)


Tennis
3D Tennis. Simple Controls to volley a ball back and forth to your opponent. Players will be given the option of a quick-play mode or advance through a tournament and upgrade their player.

Pros: Simple interactions, Simple gameplay, Potential multiplayer, Single or extended play, Simple development
Cons: Low Complexity, May not show off WP


Wild Pocket Edge: Many current versions of tennis in Flash suffer from simple animations and unresponsive controls. With Wild Pockets, we would be able to take this very contained experience and provide a level of polish and control only seen on gaming consoles and arcade cabinets.

Baseball
3D Baseball. Not the entire experience of a baseball game, but instead batting and catching against a computer opponent. By switching between 2 cameras in the 3D stadium provided by our engine, the player will take turns trying to score points at bat and then preventing the opponent from scoring runs by fielding.

Pros: Simple interactions, Simple gameplay, Potential multiplayer, Experience can be extended with additional baseball features
Cons: Done before, May not show off WP

Wild Pocket Edge: Much like Tennis, current baseball games on the internet are hindered by 3rd generation graphics and controls unacceptable by today's standards. WP corrects these. WP

would also be able to give a stronger sense of 'location' by providing a full 3D environment from an unlimited number of angles rather than 2D backgrounds meant to give the illusion of a full space.


WP Tower Defense
Defend your goal from armies of monsters by building attack towers that operate on their own. Tower Defense games were originally made to reproduce a slimmed down version of 3D Real Time Strategy games, such as Warcraft, in a web browser. Using the technology provided by our engine, we have the capabilities to not only bring the experience back to what is was inspired by, but also keep the casually addictive gameplay that made it a hit.

Pros: Proven addictive gameplay, Strong visual showcase, Simple controls with high agency
Cons: Potentially long development, May push current tech limits too far

Wild Pocket Edge: This could be a very impressive visual showcase. It would show off the visual limits of the engine in a game rather than just a tech demo. It would also be able to demonstrate advanced behaviors that allow the monsters and towers to operate autonomously.

Army Attack
The player sends troops out to fight the enemy's troops. They will meet in a battlefield and

slowly advance towards the opponent's base with each individual victory. Different troops will have different strengths and weaknesses to create a fast paced rock-paper-scissors style game.

Pros: Very simple gameplay with complex results, Easy to implement, Strong visual showcase
Cons: Tech limitations for onscreen visuals, potentially long visual and design development.

Wild Pocket Edge: This would be a good chance to show strong visuals and complex gameplay that are easy to implement.


MotoCourse

MotoCourse is like the current "balance the motorcycle" games, but in 3D and leveraging WP's built in physics. While navigating a course with ramps and hills, the player will have to apply the correct amount of force so they don't flip forward or backward

Pros: Simple Gameplay, Physics Showcase 
Cons: Motorbike/Rider Physics combination could be difficult, May require a lot of art assets to not seem repetitive.

Wild Pocket Edge: One of Wild Pockets strengths is it's built in physics system, and the goal of this game is to keep the motorcycle from flipping. This would be a great opportunity to show how physics can be used in a complex game beyond building or destroying.

SnowRacer
3D snowmobile racing. The emphasis of this game would be racing other computer controlled opponents across snow-covered courses. If the player wins races, they are awarded with money to upgrade their snowmobile and unlock additional courses.
Pros: Simple controls, established genre, snowmobiles would avoid complex physics by 'sliding'

across the course

Cons: Opponent AI could be difficult, multiple courses to design and create, physics may
make the game too difficult, number of opponents balance – too many could slow the engine, too few could seem empty
Wild Pocket Edge: Much like MotoCourse, this game would be a great place to show the power of Wild Pockets physics. However, this game would feature tweaked physics to facilitate a more traditional gaming experience.

Fish
The player controls a fish that moves into a 3D underwater scene. Forward motion is constant, so the player only needs to control the fish's position on screen. There are hazards and enemies to avoid and rewards to collect.

Pros: Simple gameplay, basic environment, short development
Cons: Game may be too simple, 3d camera may be difficult to navigate, nothing very new or fresh

Wild Pocket Edge: A simple experience that would be 90% polish. This would be a visual showcase from the effects and animations to the physics and environmental reactions.


Jetman Advanced

This is a 3D twist on the traiditonal Jetman game - a player flies forward in a side scrolling scene and pressing a button to elevate the character to avoid hazards and automatically floats back down. In WP, we'd make this a full 3D scene and animated characters. It would also include a slightly dynamic camera to take advantage of the depth. Progressive elements such as money and upgrades from games like Tower Defense could also be included to expand the experience.

Pros: Simple controls, Gameplay and camera constraints will allow for very developed visuals, Physics can handle collisions.
Cons: Extended version will require additional design and balance, potentially too 2D

Wild Pocket Edge: Jetman Advanced would show a very complex experience not possible in other online platforms and only requires simple interactions to implement.

Thumbnail Image: