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!
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
3) Make sure you're in "Paint Mode" and open the console by hitting "control-shift-c"
4) In the console type: colladaexport
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
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.
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.
10) Revel in the fact that the creature is now playing on your turf.
Happy Hunting!
- ecanaan's blog
- Login or register to post comments
-
I'm the Map!
It's been a long time, but we're happy to say that we'll be releasing a playable demo of the first sets of levels next week!
Until then, we'd like to share a screenshot of our map system. It not only shows how it will function, but also reveals a bit about the first sector of your adventure.
Within this 3D view of the sector, there's a series of nodes that continue to grow as you expand throughout it. These nodes represent levels that are either goal-based or function as passage to other levels. Yellow nodes represent the nodes you've explored, and the white nodes are new, unexplored, ones. Rather than having the whole map available from the start, only mission destination nodes are shown, and the player must uncover the network of nodes that lead to that location. Level names are also provided for the node you're presently at along with the actions you can make at it.
In the upper left hand corner, you can see info about the system you're in and what your current mission is. In the upper left is a read-out of total number of resource you've collected. This can be used to tell if you have enough resources to synthesize something at the lab or if there's a certain kind of element you should try harder to retrieve.
The system we're in now (and where most of the first levels take place) is called Faris, and its 2 main planets are named Pons and Arbus. Pons, a gaseous planet and the larger of the two, has been in orbit of its sun for millions of years. Arbus, the smaller of the two, is a relatively new planet (only a few centuries) believed to originally be a massive meteor plummeting through space only to be locked into orbit by the pull of Pons. Before this phenomenon occurred, Pons was consistently growing and destroying any matter within its path and becoming dangerously close to reaching critical mass and causing the sector to implode. However, due to its close vicinity to Arbus, this energy was actually absorbed and safely dispersed among the alien resources beneath this smaller planet's crust. This relationship has caused Arbus to thrive with new and exotic resources (ripe for the harvesting for a certain rocketboy!) and prevents Pons from erasing part of the universe (but making it non-the-less dangerous to explore).
- ecanaan's blog
- Login or register to post comments
-
Action Scene!!!
While the Shrimpers are a sizable and powerful organization, they lack the technological and production abilities of many of their counterparts. Relying on salvaged ships and other resources to fuel their endeavors, they are often forced to explore more unconventional methods for combat. Their inability to sustain a sizeable force of their own Rocket Troops has proved troublesome when encountering rivals, particularly the RBC.
But necessity is the mother of invention, and the Shrimpers have taken to outfitting some of their more expendable members with jumper harnesses. These soldiers, known as “Leapers”, are attached to the end of a retractable cable which is generally retrofitted to one of the Shrimpers smaller attack crafts. Working in tandem, the pilot and Leaper are often an effective duo in combat, and have become the recent bane of the RBC’s expansion units. While this has proved a successful tactic, the in-combat life expectancy for Leapers is expectedly low (approximately 12 seconds) which makes finding “volunteers” for this duty difficult.
- ecanaan's blog
- Login or register to post comments
-
The Rocketboy Corps -- First Look!
Here's a scene we put together to show off some of the newest assets and animations. This is our main character with a basic idle animation and some particle effects for the rocketpack. Right now, he's practicing his 'tredding space' move until the real adventure begins.
- ecanaan's blog
- Login or register to post comments
-
The Rocketboy Corps: Enemy Faction - The Shrimpers
One of the first adversaries you'll encounter in the game are The Shrimpers. They are one of the larger, yet most unorganized, corporations looking to strike it rich. While a few higher ranking members fill out 'the board,' the majority of their forces are comprised of freelancers, mercenaries, failed pioneers, and psychopaths. They keep their costs low and usually resort to theft, assault, or murder to obtain other faction's hard-earned resources and territory. 
They received their nickname from the large nets they use from above the gravity-pull to claim and steal resources since they lack the advanced tech required for refined surface harvesting. They resemble pirates more than anything. 
However, what makes them most dangerous is their complete absence of concern for their own personal safety in order to obtain their goals - and because of their lack of modern equipment, this is the only way they can succeed. Whether they are desperate, crazy, or just plain stupid, they will go as far as to jump off their ships in flight with only a rope tethered to their back. 
- ecanaan's blog
- Login or register to post comments
-
Joints
One of the newest features of platform is the inclusion of joints. This basically gives users the ability to link objects together in a scene and then function as one multipart object. The flexibility at the connection points can be set to provide any number of reactions. The default physics also work to the advantage of joints – pendulums swing, wheels turn, and ragdolls ragdoll.
In the following video, we show 2 examples: Several objects linked together to form a chain that can launch penguins across the scene and a car body with the wheels attached through joints so they react naturally across the terrain.
These are only 2 of the ways in which you can use joints – the possibilities are almost limitless. Moveable doors and barriers, complex machinery, or even a hinged character. If a developer is creative enough, they could potentially make something the world has never seen before!
- ecanaan's blog
- Login or register to post comments
-
Normal Maps among other things
This past week, we gained the ability to incorporate a couple different advanced shaders in our work – mainly Specular and Normal Maps. Along with our dynamic lighting, these go HUGE lengths to strengthen our visual quality. While we don’t know their limitations and these won’t be available publicly until a later release, we had the opportunity to play around with them in our internal build, and the results were very exciting.
Normal Maps are essentially an extension of bump maps. They both apply a detailed height map to a set of geometry to give the appearance of a much more complex surface. However, while a bump map only reapplies the existing normals of the geometry to the new heightmap, a Normal Map also contains another layer of information that defines unique normals for the new details causing it to react to light much more realistically. The following diagram shows the basics of this concept with arrows representing the normals of the different maps (it also doubles as a pretty good drawing of a happy cat.)
So by applying a normal map to an old model (simple cube with a color map) from one of our demos, this:
Becomes this:
By adding a Specular Map, a surface can take on even more detail. A Specular Map basically defines the color and opacity of a highlight that is produced when it’s affected by lighting - this allows for a range of shiny gloss to complete matte within the same material.
So adding a Specular Map:
The addition of these new shaders also opens the door for many others – these were just the ones we’ve had time to make. Once these are publicly available, the ability for a developer to create their own custom shaders to do any number of things will also be accessible. Combined with our emphasis placed on usability, these advanced visual features have the potentiality to create some pretty amazing content.
- ecanaan's blog
- Login or register to post comments
-
Microtransactions
Microtransactions
Last week our focus was on figuring out how to complement and expand upon our base games’ experiences. More often than not, our discussion went towards microtransactions as a way to engage both developers and the community. At the core of our platform’s design, we incorporated microtransactions that will allow users to extend or customize their game experiences and gives developers incentive to produce more compelling content.
From the start, we wanted to avoid making ANY additional content that is required to continue or complete the game. When free games do this they just end up feeling like glorified demos with a fuzzy checkpoint where you have to pay to proceed. We’re also going to avoid transactions that simply improve abilities because that would only lead to a class system based on wealth. We ended up feeling the type of content we wanted to share would be extra level sets and rewards, expansions, or additional convenience.
Extra Level Sets
Always coming in a group of logically similar stages, these extra ‘universes’ would provide modified or all new art, and/or variations in standard gameplay. During the exploration of these stages, existing or new resources will be harvestable, along with a brand new upgrade object at the end. These upgrade objects would not only be visually impressive when they are attached to your base or rocketboys, but also potentially grant the player improved abilities or passage to additional content.
Expansions
These would be groups of level sets that are released together and tailored to be a more complete experience. This can be accomplished by making a common theme, story elements, or level dependencies (you need this before you can go there). Like the level sets, these would also give upgrades and improvements.
Additional Convenience
These would be features that don’t make the game any easier, but remove a lot of backtracking and extra footwork required to progress in the game. Instant travel between outposts instead of flying the entire path is the most obvious. Other time-savers would be removing the limit on the number of active mini-bases or rocket boys that can be active at once. These could either be obtained through a transaction, or as upgrades at the end of extra level sets or expansions.
A player will most likely gain these additions entirely within the context of the game. There would be no external downloads or file management. Basically a player would own the ‘rights’ to content – much like owning a song on iTunes – and it would be associated with individual accounts, not machines. Also, like other products that use this system, content creation wouldn’t be limited to just developers and could extend to players and brands.
Our main intention of planning out expandable content now is that anything we add in the future will feel like part of the actual experience and not something simply tacked on.
- ecanaan's blog
- Login or register to post comments
-
Designer Diary Four
As we proceed with development on our internal game projects, the amount of work placed on our limited number of programmers continues to grow. Also, until a lot of this initial work is done, our artists are stuck at the other end of the bottleneck waiting for their work to get implemented. Based on previous experiences, this is usually the time to start production on some internal Artist and Level Design Tools. The main purpose of these tools is to allow a non-programmer to create content that is usually only available to team members that can code. While these take time to create and may almost feel like a waste of limited programmer resources, in the end, the time gained from the other team members more than makes up for it.
For Rocketboy (new name coming soon!), we determined that a visual level editor would get the most out of our artists in the least amount of time from our programmers. Since every level is generated from a library of asset-types based on a player’s progress in the game, they can all be broken down to a list of numbers and models. Ideally, an artist will be able to upload any model they create for an asset (such as “small block,” “enemy,” “shield boost,” etc…), and it will automatically have the properties and effects of its asset-type for the current level. An artist will also be able to tweak generation rates and properties to make the best possible experience. Finally, they can test the level at anytime with preset conditions (rocketboy shield and fuel amount, base defenses, etc…). It also doesn’t hurt to be sure that a visual person is designing a visual aspect. Most importantly, ALL of this can be done without bothering the programmers and fewer hands are tied. Even though these levels will eventually need something with a bit more control for full game implementation, the actual content will be ready to go whenever the tech team is ready for them.
![](/"sites/default/files/images/rocketboy_concept.jpg")
Another benefit of the Level Design Tool is its release to the community. This could potentially provide an infinite amount of content for players to explore in the global game universe. Since many of our users have limited technical ability, this tool would be an opportunity for them to create their own levels by changing object properties and replacing current art with their own or with different combinations of existing art. It may not have the same power level of our internal tool (wouldn’t want people to accidently break something big), but it will allow people to easily customize, upload, and share their experiences as part of the main game with other players – all piggy-backed on something our own designers used.
- ecanaan's blog
- Login or register to post comments
-
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 |
Hazards |
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) |
Power Ups (1 per 7 screen lengths) |
|
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) |
Power Ups (1 per 7 screen lengths) |
|
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) |
Power Ups (1 per 6 screen lengths) |
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:
- ecanaan's blog
- Login or register to post comments
-