[Forum Project #1] Steam Run Design Document

Subforum dedicated to discussing group projects.

[Forum Project #1] Steam Run Design Document

Postby skydereign » Thu Dec 06, 2012 5:17 am

Introduction
Steam Run (working title) is a steampunk themed run 'n gun for gE's major target platforms (iphone/ipad, pc, mac, linux, android) that uses expansive levels and divergent play mechanics to create a fun and addictive game to show off the power of gE.

Team
AliceXIII (programmer [map editor])
skydereign (design document, programmer, concept/promo art)
Jagmaster (environment art, animation, story)
lcl (programmer [dialog])
happyjustbecause (story)
sonicforevergame (concept art)

Possible Members
GEuser (concept art, sound)
master0500 (game/concept art)
NightOfHorror (to be decided)
moonforge (concept, programmer)
kickstart (concept, programmer)
schnellboot (tester)
osopeligroso (art/animation, story)

Document Structure
We are currently using the forum for the document, though it may be shifted to the wiki at some point. This is the head of the document, and subsections may be branched off to other forum posts (handling art, sound, aspects of programming, and similar).

This is a living document, so if you have suggestions, complaints, or requests, feel free to post them in response. I'll update it often enough. Also, we want most communication to be public to support the sense of progress.

Table of Contents
...


Project Goals
  • Create a stronger sense of forum spirit and community, and finish a successful forum project.
  • Create a commercially viable and impressive game with gE.
  • Prove and document the process of releasing games for various platforms, as a way of paving the path for other users.
  • Show off gE's power and key features.
  • Document the code in a way that users can learn new and better techniques.
  • Motivate people on the forum to finish their own projects.
  • Resume building for everyone involved.

Background
Steampunk is a sub-genre of science fiction revolving around steam machinery similar to times of the industrial revolution. A large component of steampunk's appeal is atmosphere and gadgetry.

Run 'n gun games are platformer based featuring a well armed player character, usually using an assortment of projectile weapons. Unlike a lot of run 'n guns, Steam Run will use free movement like typical platformers.


Brief Description
Steampunk run 'n gun, where the player is able to build and customize different gadgets and weapons. The tools and strategy used in each level impact certain bonuses and stat changes. End level ranking may influence the next level in the story, allowing for different stories per playthrough. Enemies drop parts and gears/screws/bolts that act as currency in the game. Gadgets can alter the movement of the player, and allow you to enter new locations.

Key Elements
Machinery
The creation and purchase of new gadgets is a core element to the game. The player will be able to build many different weapons, with varying stats and bonus effects. Weapon abilities may combine together, allowing double weapons (flamethrower machine-gun). Parts are collected within the level, and as pickups for beating enemies and bosses. Players can also be awarded parts for completing the levels.

Creating new gadgets and buying gadgets can yield the same effect, but by synthesizing your own gadgets you can add extra bonuses. Through this there can be hundreds of customizations.

Different gadget combinations may work together to create boosted effects, similar to equipping all gear of a certain type. This further adds to the customization possible for the player.



Weapons
As a run 'n gun, weapons play a large role in the game. And as mentioned in machinery, the player will be able to create new weapons as well as customize old ones. In game, the player will be able to switch between all weapons they have. The player will have mostly projectile weapons, though perhaps a few melee weapons.

List of Projectile Weapons
  • Pistol
  • Rifle
  • Multi shot
  • Machinegun
  • Shotgun
  • Sniper
  • Flamethrower
  • Railgun
  • Acid blaster
  • Corrosive mist gun
  • Bombs
  • Lightning net shotgun
  • Magnet gear things, throw two at max, they come back (like wrench in ratchet and clank)

List of Melee Weapons
  • Lightning beat sticks
  • Chainsaw Great Sword




Exploration
The levels will be large enough that one could play through the level in several ways. They shouldn't be so large though that the level is too large to complete by an individual character.

There should be some form of collectible that does not respawn within the level, which acts as an indicator of how much of the level has been explored (similar to gems from Spyro Year of the Dragon). This makes the desire to explore the level tangible.

We can also add achievements for both ranking and certain aspects of the level.


Enemies
Most enemies are relatively easy to kill. Since the game is a run 'n gun, the player will have a lot of ammo, and is able to often overkill enemies. In terms of stats, enemies can have large hp or defense stats, as well as elemental weakness. Enemies are very diverse, some attack with melee while others also use projectile weapons.

Enemies are in some ways similar to rpg monsters as they have common and rare drops. There should be many different enemy types, if ambitious enough could be created through different autonomous parts. This would allow for the creation of many different enemy types while reusing graphics.

Most if not all enemies are robotic in nature, and when defeated fall into pieces. This crumbling effect emphasizes the mechanical nature of the game as well as creates a satisfying and dynamic particle effect for destroying the enemy. This also supports multipart enemies, in which you can destroy individual parts of the enemy before destroying it as a whole (blowing up the arm cannon).

Depending on how level creation is handled, enemies may respawn after moving far enough away from the spawn point. This promotes some degree of mastery and knowledge in the levels.


Bosses
Not every level will have a boss at the end. Bosses normally will be very large, allowing for easy targeting. Like enemies, a boss will have many different pieces that must be destroyed. Boss fights can initiate unique controls to the game (always flying/moving) adding a bit of diversity to the movement scheme.

Player Description
Concept art for the player.
Image
Still in the works, so input wanted. Should be connectable to the story.

Different player actions and movements
Stand
Run (forward and backward)
Dash
Duck
Slide
Hit
Shoot (independent of other actions)

With Gadgets
Climb
Glide
Hover
Fly

Story http://game-editor.com/forum/viewtopic.php?f=35&t=12464
The game would benefit from a convincing and interesting story. Suggestions wanted.



Art
Since we are using 1.4, we'll need to rotate the images ourselves. Art reusability is important, but not at the point of reducing quality. Since we are targeting multiple platforms, we want to keep our source files larger than the actual images. This way we can scale them down to fit different screen sizes, without having to scale things up. This also makes animation easier.

Other things to note are certain limitations for image sizes. iOS images can be no wider or taller than 1024 pixels. Straying away from overly large images is good practice anyways.

Standards
To be decided. Current suggestions:
  • Final images and animations should be png.
  • Use vertical strips for animations (this allows reflecting images).
  • Keep a larger copy of every source file (preferably twice the size of the final image)
  • In terms of quality assurance, the final product should have similarly styled images, but this isn't as big a concern during prototyping.


Style
Still to be decided. Everything will be steampunk themed though.


Concept/Promo Art
Anyone and everyone is recommended to contribute concept art. If you have an idea of a cool looking weapon, enemy, or level, post it. Major categories for concept art are gadgets, weapons, enemies, levels, but can extend to anything within the game.

As we start centering on ideas, promo art will be included here as well.


Menu Art
To be added.

Player Art
The player will most likely be broken up into at least two sets of animations, top body and lower body. Top body animations consist of holding the weapons at different angles. We will need different holding animations for different types of weapons. Lower body animations can remain the same for all weapons.

The player can also be equipped with various gadgets, such as a steam jetpack, glider, or copter pack. These will be managed through code for smaller file size.

The player should be able to fire in all directions, facing backwards as well. Need to specify number of animation angles we will support.


Weapon Art
We can take two approaches with weapons. Either have pre-drawn models that are diverse enough to fit customizations the player has, or handle the weapons through multiple parts/actors.

Either way, the weapons will need to be rotated in the same angles the player can shoot in.

Along with the weapon designs themselves, the actual projectiles, weapon effects go here.


Level/Environment Art
Need to decide on how we are structuring levels. Since we are using a map editor, we don't need to have tiles, but it is a lot easier to make complex maps if we use a generic tile structure.

Environments
Factory
Outside Streets

Tiles
There will be a lot of different tiles, should fit all of the environment themes we pick. Base tile types should be listed.

Parallax Backgrounds
The game should have a few levels of background, as well as one foreground. For instance steam/fog/smog layers.

Interactive Elements
Can be composed of tile pieces, but usually more unique. Examples including moving platforms, conveyor belts, gears to jump on, and similar.

Props
These are things the player doesn't interact with, but add to the atmosphere and overall level design. Some examples being large gears in the background or foreground, piles of scrap metal the player can walk by. Helps to add depth to the game.



Audio
Sound and music are rather important for the atmosphere...

Sound Effects
A general list of sounds for the game.
Metal clanging
Gears meshing
Steam bursts
Gun noises
Electric hum
Player sounds
And similar

Music
The only steampunk game fitting music I've heard is the Steam Punk Opera Overture. http://mochalab.bandcamp.com/track/the-steampunk-opera-overture

Presumably we would want something along those lines. There should be eerie environmental music, as well as more actiony boss music. We could create a level of dynamic music changing.



Programming
Since gE can only merge full geds together, we should build separate ged files to test different features and parts of the game. When a piece is agreed upon it can be merged or recreated within the master ged. A formal version of the source won't be created for a while, since we are still in early concept stages. This modular style will help create reusable pieces, and keep the code base clean.


Standard Discussion
We should decide on some coding standards. Easiest would be to follow gE's default spacing, and bracket alignment. It is important for blocks of code and brackets to be well defined, so we should try to avoid one line if statements without brackets. Though if and logic fit on one line, that is probably okay as well.
Code: Select all
if(condition)
{
    if(condition2)
    {
        // code
    }
}
else if(condition3)
{
    if(condition4) { x+=5; }
}
else
{
    //
}

This is just a recommendation, but we do need to come to some agreement.

Code should be commented to some extent, though not to the point of explaining everything. Functions at the least should have a comment explaining what they do.

Standard In Progress
...


Core Programming Pieces
To prevent duplicate work, you should post if you begin working on one of the core pieces.


Licensing and Similar
Since this is a project to show off gE's capabilities, we may want to release this completely for free. Though some people have mentioned potential revenue going to the gameEditor development team.

There are some advantages to commercializing it as well. So another possibility is to release a free and for pay version.

Depending on the length of this project we may also be able to do ads and in app purchases, assuming those can be worked out. For now though we can't rely on those being supported. The other option is to create a kickstarter for this game. The main pitch is help support gE, and we'll release this game for their contributions. We'd be able to give various nice awards, and it is a two in one type deal.
player_concept.png
player_concept.png (37.25 KiB) Viewed 15682 times
User avatar
skydereign
 
Posts: 3510
Joined: Mon Jul 28, 2008 8:29 am
Score: 589 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby AliceXIII » Thu Dec 06, 2012 11:35 pm

well im alright with everything the standard is the only thing i feel the need to discuss.

im fine with any style of coding we just also need to take into consideration the naming of data types i usually go about it like this:

Tile-> create actor-> script editor
Code: Select all
//simple array math just to show my data type naming style
int tempXY[2];

tempXY[0]=x;
tempXY[1]=y;

x+=tempXY[0]*32;
y+=tempXY[1]*32;
"Taking a breath of fresh air."
User avatar
AliceXIII
 
Posts: 325
Joined: Fri Sep 17, 2010 2:36 am
Location: victoria, texas
Score: 37 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby skydereign » Thu Dec 06, 2012 11:51 pm

AliceXIII wrote:consideration the naming of data types i usually go about it like this:

I allocate certain name spaces for functions and variables. By the looks of it, you do to. The most important things I think are, we should be able to tell what a function does by its name, and where it will be in global code by its name space. Something along these lines.
Code: Select all
typedef struct map_s
{
    //
}map_t;

// save map file to filename
void
map_save (char* filename, map_t* map)
{
    //
}

// load map from filename
void
map_load (char* filename,  map_t* map)
{
    //
}

I personally stopped using camel case, though I don't mind switching back. We could differentiate style between variables and function names if people think that will make it easier. Also what is your view on using global variables within functions?
User avatar
skydereign
 
Posts: 3510
Joined: Mon Jul 28, 2008 8:29 am
Score: 589 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby AliceXIII » Fri Dec 07, 2012 1:24 am

im not in a specific boat when it comes to the standard i just wanted to cover all the angles of the standard so we would have a clean cut idea of what were going for personally we could both probably easily switch between any style if need be.

Also what is your view on using global variables within functions?

actually i use global variables for every variable that lasts the entire game so alot of my functions use global variables.

if we go the route of global variables we should just make a root script for them just a script named variables to store all of them on!
"Taking a breath of fresh air."
User avatar
AliceXIII
 
Posts: 325
Joined: Fri Sep 17, 2010 2:36 am
Location: victoria, texas
Score: 37 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby Jagmaster » Fri Dec 07, 2012 1:56 am

I was thinking about storyline and the actual written concepts for characters/environments/etc for a minute here. I've found a useful template for building a character's background/personality in this book. I've roughly jotted it down to a text file here. Anyone who wants to can feel free to make use of it, It really gets the creative juices flowing! The book has more sheets regarding level design, setting, mood, and overall storyline. I'd really recommend reading the book instead of me posting more bits of it. It's a pretty good one.

I'm open to contributing some writing on that note. I certainly don't want to bear the whole burden of course, but I'd like to add some setting/background story.
Might be tricky as I'm a slow writer. :P

I've got a few steampunk characters from my pithman reboot that I designed last month. I'd be honored if they at least had a cameo appearance or some other role in this game haha. :) They might be a bit simple (these were meant to be modelling sheets) but that can be remedied if they are to have a role.

ImageFull Res
Falco - The psychotic inventor/mastermind
ImageFull Res
Rodge - The master-mechanic boy genius.

Just another passing thought, that it might be neat to have pre-rendered 3D graphics for environments or even characters (like DK Country for snes). That would make some neat results.

Heh, any form of vector based animation workflow I'm open to, be it 2D or 3D. Whilst traditional frame by frame animation has a certain legacy about it, vector based animations (and graphics in general) have the flexibility to change frame rate and resolution at will which is nice for multi-platform. I've had good success with cutout animations using tools such as Synfig.
But if it boils down to frame-by-frame I'd take anything over pixel art. :lol:

That kind of stuff is sorta irrelevant during the prototyping stages. Thought I'd throw that thought out there anyway.
User avatar
Jagmaster
 
Posts: 875
Joined: Sun May 08, 2011 4:14 pm
Location: Not where you think.
Score: 82 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby skydereign » Fri Dec 07, 2012 2:19 am

AliceXIII wrote:im not in a specific boat when it comes to the standard i just wanted to cover all the angles of the standard so we would have a clean cut idea of what were going for personally we could both probably easily switch between any style if need be.

Also what is your view on using global variables within functions?

actually i use global variables for every variable that lasts the entire game so alot of my functions use global variables.

if we go the route of global variables we should just make a root script for them just a script named variables to store all of them on!

I usually use a global variables script as well, but that makes the individual elements linked. I would say we should go with the natural compromise for this. If certain global variables are exclusive to the system they belong in, they shouldn't be in the global variables section (and should be treated as private by other people). Public variables that will need to be accessed by multiple systems would go into the global variables script. One concern with this though is we don't want to setup any dual dependencies, as gE can really dislike that.

Jagmaster wrote:I was thinking about storyline and the actual written concepts for characters/environments/etc for a minute here. I've found a useful template for building a character's background/personality in this book. I've roughly jotted it down to a text file here. Anyone who wants to can feel free to make use of it, It really gets the creative juices flowing! The book has more sheets regarding level design, setting, mood, and overall storyline. I'd really recommend reading the book instead of me posting more bits of it. It's a pretty good one.

I second that recommendation.

Jagmaster wrote:I'm open to contributing some writing on that note. I certainly don't want to bear the whole burden of course, but I'd like to add some setting/background story.
Might be tricky as I'm a slow writer. :P

Cool, I'll add you to writing as well. At this point we just need to get some ideas down, and start mulling it over. My brother will probably help with story as well.

Jagmaster wrote:Heh, any form of vector based animation workflow I'm open to, be it 2D or 3D. Whilst traditional frame by frame animation has a certain legacy about it, vector based animations (and graphics in general) have the flexibility to change frame rate and resolution at will which is nice for multi-platform. I've had good success with cutout animations using tools such as Synfig.
But if it boils down to frame-by-frame I'd take anything over pixel art. :lol:

That kind of stuff is sorta irrelevant during the prototyping stages. Thought I'd throw that thought out there anyway.

Any discussion is good. And the sooner we start converging on an art style the sooner the art gets done. I'd stray away from typical vector graphics though, as it is usually too bright and shiny, and less industrial. Though I'm thinking of animating in a similar way as vector graphics.
User avatar
skydereign
 
Posts: 3510
Joined: Mon Jul 28, 2008 8:29 am
Score: 589 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby AliceXIII » Fri Dec 07, 2012 3:11 am

we'll just keep an eye on the variables!

also thoughts on pointers? i personally use them whenever i can, but i know some people are touchy on pointers because of the sensitive nature of them..

also on a side note what type of mapping engine do we want a tiling one? or other?
will we use array maps or structure maps?

as it stands i have a generic template from back when i was developing the rpg engine that loads maps with a tiling map editor to build and save maps for the template it uses array maps right now but could be changed for structures if needed.
"Taking a breath of fresh air."
User avatar
AliceXIII
 
Posts: 325
Joined: Fri Sep 17, 2010 2:36 am
Location: victoria, texas
Score: 37 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby Jagmaster » Fri Dec 07, 2012 5:37 am

skydereign wrote:Cool, I'll add you to writing as well. At this point we just need to get some ideas down, and start mulling it over. My brother will probably help with story as well.

Awesome

skydereign wrote:Any discussion is good. And the sooner we start converging on an art style the sooner the art gets done. I'd stray away from typical vector graphics though, as it is usually too bright and shiny, and less industrial.

I'll keep that in mind. And I agree about typical vector art in general (wasn't really suggesting it, but yes I agree definitely).
skydereign wrote:...Though I'm thinking of animating in a similar way as vector graphics.

What I was suggesting was yes, using a vector method to animate the probably raster pieces of the "puppet". Versus frame by frame.
I've seen some pretty neat 2D bone setups in Blender, that would give a lot more flexibility a lot more easily with less effort than a regular "cutout" method.
What was your opinion on pre-rendered 3D stuff? Just wondering 'cause I know it's a whole different ballpark, but I'm pretty ambitious right now lol.
User avatar
Jagmaster
 
Posts: 875
Joined: Sun May 08, 2011 4:14 pm
Location: Not where you think.
Score: 82 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby skydereign » Fri Dec 07, 2012 7:40 am

Jagmaster wrote:
skydereign wrote:...Though I'm thinking of animating in a similar way as vector graphics.

What I was suggesting was yes, using a vector method to animate the probably raster pieces of the "puppet". Versus frame by frame.
I've seen some pretty neat 2D bone setups in Blender, that would give a lot more flexibility a lot more easily with less effort than a regular "cutout" method.
What was your opinion on pre-rendered 3D stuff? Just wondering 'cause I know it's a whole different ballpark, but I'm pretty ambitious right now lol.

Ah okay. I'm all for 3d pre-rendered stuff, as long as it fits. With the right textures, it would definitely add to the environment and make things like gears easier to handle. Can you post some examples?

AliceXIII wrote:also thoughts on pointers? i personally use them whenever i can, but i know some people are touchy on pointers because of the sensitive nature of them..

I use pointers. For anything really dynamic they are a must. As long as we are good and clean about it, it shouldn't be a problem. We could also have our functions check their pointers before using them (I've had this habit drilled into me for some time). Another thing, what are your thoughts on debugging? It'd be good to have a uniform way of printing out trace information.
User avatar
skydereign
 
Posts: 3510
Joined: Mon Jul 28, 2008 8:29 am
Score: 589 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby AliceXIII » Fri Dec 07, 2012 9:19 pm

I use pointers. For anything really dynamic they are a must. As long as we are good and clean about it, it shouldn't be a problem. We could also have our functions check their pointers before using them (I've had this habit drilled into me for some time). Another thing, what are your thoughts on debugging? It'd be good to have a uniform way of printing out trace information.


for a project like this it would be beneficial to debug it i dont do debugging all that much except for like text actor debugging but thats because im typically only building small little features not full games so i usually can handle it but this will be a bit larger so im thinking it will be a smart choice to debug it..
"Taking a breath of fresh air."
User avatar
AliceXIII
 
Posts: 325
Joined: Fri Sep 17, 2010 2:36 am
Location: victoria, texas
Score: 37 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby Jagmaster » Fri Dec 07, 2012 9:49 pm

skydereign wrote:
Jagmaster wrote:
skydereign wrote:...Though I'm thinking of animating in a similar way as vector graphics.

What I was suggesting was yes, using a vector method to animate the probably raster pieces of the "puppet". Versus frame by frame.
I've seen some pretty neat 2D bone setups in Blender, that would give a lot more flexibility a lot more easily with less effort than a regular "cutout" method.
What was your opinion on pre-rendered 3D stuff? Just wondering 'cause I know it's a whole different ballpark, but I'm pretty ambitious right now lol.

Ah okay. I'm all for 3d pre-rendered stuff, as long as it fits. With the right textures, it would definitely add to the environment and make things like gears easier to handle. Can you post some examples?


Alright sounds good!

I'm on my phone right now, but I'll mockup some stuff over the weekend.
User avatar
Jagmaster
 
Posts: 875
Joined: Sun May 08, 2011 4:14 pm
Location: Not where you think.
Score: 82 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby AliceXIII » Fri Dec 07, 2012 11:09 pm

i like that we have the art and programming getting off the ground already!

on another note im trying to decide what i want to start programming on hmmm..
"Taking a breath of fresh air."
User avatar
AliceXIII
 
Posts: 325
Joined: Fri Sep 17, 2010 2:36 am
Location: victoria, texas
Score: 37 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby happyjustbecause » Sat Dec 08, 2012 2:23 am

Great job on the organization of the document, lots of room for adding game related stuff. I do think I want to be involved in this, maybe as a tester and writer because I'm not so great at art or programming, but I do think I could come up with ideas for the game. I'm already picturing how this game could look and it seems very awesome.

I'm kind of picturing rough graphics kind of like metal slug, but I picture this game to have more smoothed out and cleaner textures, but that same general rawness and roughness:

Image

I may be wrong to think in that direction for the graphics, but that's kind of what I'm imagining.
For small creatures such as we the vastness is bearable only through love.
-Carl Sagan

Night Knight Development Thread
User avatar
happyjustbecause
 
Posts: 267
Joined: Tue Jul 26, 2011 3:10 pm
Location: Frazier Park, Ca
Score: 15 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby skydereign » Sat Dec 08, 2012 9:42 am

AliceXIII wrote:
I use pointers. For anything really dynamic they are a must. As long as we are good and clean about it, it shouldn't be a problem. We could also have our functions check their pointers before using them (I've had this habit drilled into me for some time). Another thing, what are your thoughts on debugging? It'd be good to have a uniform way of printing out trace information.


for a project like this it would be beneficial to debug it i dont do debugging all that much except for like text actor debugging but thats because im typically only building small little features not full games so i usually can handle it but this will be a bit larger so im thinking it will be a smart choice to debug it..

Ok, so I'll probably post something tomorrow for this. I have something I usually use, but I have never gotten around to completely cleaning it up.

AliceXIII wrote:i like that we have the art and programming getting off the ground already!

on another note im trying to decide what i want to start programming on hmmm..

Well the most important thing is the map editor right now. But, we really need to have a good idea of how we are doing levels before really setting that up. Though, that could be said about almost all of this. Can you post your current map editor?


happyjustbecause wrote:Great job on the organization of the document, lots of room for adding game related stuff. I do think I want to be involved in this, maybe as a tester and writer because I'm not so great at art or programming, but I do think I could come up with ideas for the game.

Okay, I'll put you down for story.

happyjustbecause wrote:I'm already picturing how this game could look and it seems very awesome.

I'm kind of picturing rough graphics kind of like metal slug, but I picture this game to have more smoothed out and cleaner textures, but that same general rawness and roughness:

Yeah, that's more or less what I was picturing. We'll see though, as it ultimately depends on what art we can do.
User avatar
skydereign
 
Posts: 3510
Joined: Mon Jul 28, 2008 8:29 am
Score: 589 Give a positive score

Re: [Forum Project #1] Steam Run Design Document

Postby master0500 » Sat Dec 08, 2012 12:50 pm

i updated the character
Image
gave him a darker colour scheme and shrunk his head
master0500
 
Posts: 409
Joined: Sun Jun 26, 2011 9:42 pm
Score: 27 Give a positive score

Next

Return to Forum Projects

Who is online

Users browsing this forum: No registered users and 1 guest

cron