Time period: All chapters

- You start off in Neutral, Imperial, Rebel, (Republic, CIS could be one of those unlocks)

- Starts off in the Home area of the faction in that timeline

- First needs training in flying the fighter,

- You can buy any Faction based ship in stock as long as you do the missions or hijack random ships (or people in spaceports).

- You can travel around the ship or stay in the bridge and command everybody from there.

- Missions/orders come from a hologram, boards, or from people (Randomly generated also).

- You can change the timeline by destroying certain ships you come in contract with and also make new ones.

- You can land at planet bases/out posts/shipyard for resupplying and exploring the base/outposts/shipyard (Can travel no farther and will be stopped by guards asking for your planet citizenship)

-You can attack any ship you would like and the game will realistically react to your actions (If Imperial they will torture you if they are policing an area, If Rebels they will punish you if you attack friendlies or even boot you out, for neutrals the sector's police/guards will harass you until you stop your ship or leave the sector.

-Customize your ship with paint jobs, interior designs on transports, and customize your character.

-If you own a ship you can buy or fire your crew

- Mod support for adding new characters, ships and planet bases and player save points in the game on a planet.

Multiplayer:

- up to 64 players can play and any side you want.

- Vast area of space bigger then Star Wars Galaxies space area.

- Can control any component (Engines, shields, bridge, troop stations) on the ship

- Can only hologram or radio chat to another player but only through there. Players will choose teamspeak or xfire but for those that rather do it the realistic way can.

- Can be revived by another player or ai medic team if near the area or in the ship.

More detailed Information

Since there was a lack of new Flight Sim games for Star Wars when EAW came out (and still to this current day of July 2nd 2007) I thought I should tell the forumers (On PFF) and Lucasarts to make a new Flight Sim for PC and consoles (join forces online) so they can enjoy flying in their favourite Star Wars vehicles. Since there is a lack of flight sims I would also suggest doing more work then just spitting just another game for the fans and actually make it worth the buy with going beyond a rehash. Players will start from their factions HQ doing training that will dictate what ship they will get and how they perform in battle. I will now break down each part of the game in more detail to give you an idea of how the game could play.

Training in Faction Base:

This mode could be a start off a new career or just a button in the menu but it must be added. If your in Career you can simply radio your squadron leader and he'll escort you to the closest space station to do training (if your close enough to any Imperial owned planet). Or you can simply save and exit to the main menu and click on Training camp from there and return to career.

This mode is very important because you need to know what you are doing and so does your character. This mode adds an RPG element to the game where you level up and add "power up" to your character which will effect how you do up in space and how other recruits like yourself with present themselves to you. Your experience effects how you and your teammates react to one another except for neutral factioned players with no faction affiliates. At times you will see your character loosing his "edge" and would recommend relearning what he has learned at the Imperial Navy Academy/Training base where the player has to keep his character in top fighting/flying ace pilot self. 

Neutral players will get training if they choose to but they will just be helping out pirate factions or betraying them. They have more of a choice to obtain training or not but it would be recommended if they do since their performance would go up greatly. It should not be forced onto the player for the neutral aligned player since the player should be able to do things more freely then in the Empire or the Rebellion. The Neutral player would rely more on money and stealing which would be more pirate and personal attempt taught. Trial and Error for the Neutrals.

For the Empire you would start off in a Imperial training camp and would be forced to do training before seeing action in space. The only time you can skip training is if your in a mission that requires you in action at all times until reaching an Imperial owned Planet/Space station. Your training will consist of keeping the ship in tip top shape such as keeping the engines running, engines tuned, shields perfectly tuned and running, radio navigating, and basically simple component training (Think Silent Hunter 3 and Battlefront 2). For every rank gained you will have to report back to training for more lessons for every ship class. For those that played Battlefront 2 space battles will remember you can repair the shields, well the players will grab the necessary tools in the ship to repair the part. The players will also learn how to fly their fighters, bombers, scouts, transports, frigates, corvettes, and to the bigger ships.

For the Rebels It will be as simple as learning how to use the droids as repair tools, flying a star ship, repairing your Y-Wings, and learning how to fly ships. They will also learn how to use their ships and how to repair them. In Missions you will also help the Rebels learn how to fly new ships that they captured or modded in by fans.

When you beat all three careers from the game you will open up the Republic and CIS Career mode where you will be able to do more training missions. These will give you new skills and character achievements that you can add to your profile (talked about next) which can be unlocked online for new gameplay. You will learn what the Imperials are learning but more for what the Republic tech has so you will learn the appropriate stuff.

Profile:

This profile is important to the player because it will keep all his achievements he has done in training, career, and online. It will show medals, awards and how many you killed. This profile also shows the ranking you have both offline and online for each game type (Mods or vanilla). This profile will also be helpful for those clans/guilds that want to recruit all those players that fit their specifications. It also will be shown as bragging rights to other players or to those needing help.

Game Store:

Each faction will have its own selection of ships the player can buy with faction points. The player will gain faction points through training camp missions, missions from their faction, Helpful patrol missions (from space stations/spaceports) or Mission generators that randomly generate missions and load player made missions for the specified faction. The amount of Faction points you gain will be decided through mission type and level difficulty. The game store will contain ships, ship components, random ship parts, weaponry for the ships, ship crew for hire (neutral, rebel), player's pilot customization (i.e uniforms, guns for raids, and ect), and any player made content.

Ships and Ranking:

You gain ranks by doing missions for your faction and any place that gives you missions. If you help out a random civilian he will recommend how you helped him to your faction with the faction rewarding you appropriately. The ships you gain are determined by the time line and the ranking you have. You will start off from a training camp learning basic lessons to a trainer Tie Fighter to Frigates and Corvettes to Capital ships (and any modded ships you added). To start gaining larger ships though you have to go back to training after every ranking you accomplish in career to actually acquire a bigger ship and crew. In Career the crew will be randomly assigned to you as will they in multilayer.

If your a multi-passenger ship owner and know how to repair ships as well as fly it then your role is greatly widened. You can repair the ship and command it at the same time giving you more efficiency in space.

Career:

Empire Side:

You fight for the Empire from the end of Episode 3 up until the very end and beyond. The only plot is that you follow what the Empire tells you to do from the movies, any series between episode 3 & 4 up until Endor. If your one of those players who skipped tutorial/Training camp then you will end up in a less skilled fleet fighting for the Empire doing patrols and escorts with more effort needed to make up for your lack of training effort. If you have completed The Training Camp missions and been told what squadron/Fleet and ship you have then you will be placed in that fleet/squadron that you have been assigned to in career every single time. If you gain ranks and choose not to go back to training camps then you will have more and more crew not respecting you over time unless your highly respected by the AI pilots (who will scan through your mission progression results).

Once you get past the story missions and survive to Endor then you will be own your own fighting for the Empire with random generated missions to rely on, random faction raids, and any events Lucasarts wants to add into the game itself. You will also find yourself fighting on land but very rarely and only in Movie based missions. You can also try to destroy every single A-Wing in the game to prevent an A-Wing crashing into the Executor if you wish with the Empire living on going into EU timeline.

Rebel Side:

You will start off as a trained recruit starting from when the Rebellion was form fighting in space and only protecting Rebel owned bases on land (only in Story missions). You will fight the Empire and assist them in every way you can including trying to destroy the Death Star. You will also be able to own larger ships and command a larger fleet with more respect and rankings gained with more to accomplish.

Neutral Side:

Neutral pilots are those gamers who rather use pirate ships or modded ships with no affiliates and fight for no cause. They can join any faction and leave them but only through faction trust at a space station of the correct faction. You have more freedom to do as you wish but less to accomplish. You have a unique mission type that other factions might harass you for if they discover you doing something they wish you not. You have access to smuggling spices from outpost to outpost. The options are more unique then for Factions being less Linear. If you are at the right place at the right time during story mode you can see certain events unfold and even can participate in them if you wish.

New Republic & CIS Factions:

These two factions are unlocked through completing both Rebellion and Imperial careers to the finish in Story mode (not counting what happens after). You fight from Episode 1 to the end of Episode three and if you survive (if you do) you can live on to the original time line. You fight from the beginning to the end even in the Clone Wars Cartoon, 3D battles.

Multiplayer:

There are three types of modes for multiplayer which are "Quick battle", Faction Sided battle (co-op), and a game-mode where one side fights the other with up to 64 players on a side.

Quick Battle:

You and a few players just choose a ship, a scenerio, and just do what it tells you to. For those that rather just hope into the game and leave quickly.

Faction Sided Co-op:

You and a couple players assist one another in an online version of Career but not containing training camps. You and a player go in the same fleet and randomly chosen squadron. You fight for the same side doing what the career does up until you reach Ace pilot ranking. Once the story parts are complete you fight in the EU side of the story and then randomly generated missions. Same as whats in offline career.

64 Player battlefield:

32 players vs 32 (normal game) where one side fights against another in a scenerio battle or career mode. Simple.

Deaths in the game:

For Career when you die you lose some of your faction points, some respect and continue on off from where you died. Your ship is also out of commission with you needed to receive another one of the same type. Your fighting over a large timeline so you have to have some kind of death penalty.

In Republic and CIS unlocks when you die you have to start over from the beginning since after all it is an unlock that required skill.

----end of Transmission----

The Major Points to be Discussed:

1. Spartan's Offer

2. The Petro Forums

3. Future of the community

4. Possibility of PFF Exclusivity for P-02's first news release... (I am going to contact Mike this week over it)

Merry X-mass

-Katarn

Well why the heck did I delete my log from before  :-\ Anywho now that I got a clean fast running computer its logging and pwnage time again  ;D

Patrol 1: Set sail to grid AN48 and patrol there for a day. My crew doesn't know me and I don't know them so we both get into fights but I did manage to slap them back into shape  ;D Well during my patrol I did manage to stalk a cargo ship and sink it. I think the tonnage was 2847 or something around there. Headed home with 2 torps left. Maybe thats where my bad luck came in.

Video - http://files.filefront.com/Silent_Hunter_3_Vid_2_Pat_2wm/;4663403;;/fileinfo.html

Patrol 2: I went on patrol to AN47 and I stalked 2 boats but failed to sink a cargo boat and let fishing boat go. A Tug boat came into view and was it ever huge. I shot a torb at it but missed because of some stupid range on it (steam torp). I surfaced to try and flak gun the mini boat but a plane came over head and it was too rough for flag gunning. I headed home and I shot the torp maker I hired a guy who got me electric torps.

Patrol 3: I checked my banking and couldn't buy the VIIB so instead I went out and went to AN44. I patrolled the area and well no kills and the fishing boat again. I then stalked a cargo for 2 seconds then a destroyer which did circles around me. I then slightly headed back home when a Cargo boat was extremely close to me. I engaged and shot 1 torp (missed), I then shot the second (Forgot to lock on), I shot the 3rd torp and it hit, and then I shot the 4th locked and on medium and well it hit but didn't go boom. I then spent 20 min flak gunning the cargo ship surfaced and well my boat somehow managed to squeeze into a crack in the cargo boat and well reversing didn't help since I got in more inside. I then dived and got free and headed home. Pissed off yet again I decided to take a vacation even tho I didn't do well. Before I left I made sure the Electric torps got loaded on. 2 more patrols to catch up on so 3 patrols  ;D 1 per day.

Lessons of War Video: http://files.filefront.com/Lessons_of_War/;4682583;;/fileinfo.html

Patrol 4: I went back out to sea with my fellow crew to the cost of Netherlands. I went to sector AN82 and while in this sector I went hunting. A fellow submarine (AI and invisible) contacted a enemy cargo ship inbound to the Netherlands so I went there and did what I did in my previous career (Wait for my prey to come to me). I went to the little island then all stop waiting for ships going in or out. I notice a ship going outbound but its a neutral so I ignore it and let it pass. I then notice a ship going inbound to Netherlands so I waited until it was close enough to recognize. It was an enemy so here it comes. Fired a torp and BOOM it went down but whats this? The water is shallow and its a ship wreck  ;D Few min later I back up far enough and get fresh air. Go back to my hunting ground and wait for a cargo boat to come. It did but was bigger  And it was the one that made a fool out of me  > I fire a torp and it hits but its a dud which makes a big splash. I fire 2 torps one after another and goes BOOM and BOOM. Whats this? Money? Money coming out of the ship ?  Oh wait my camera needs fixing. It turns into another shipwreck and i'm out of torps so I leave and head back to base. For this my morale is boosted but I could have saved the 2 torps I missfired and one to correct my mistake I could have sunken and one that was a dud all on a third boat  > No mater I got a medal for myself and a promotion for a crew member.

Patrol 5: Before I left I brough alone some newly released records I bought at the market. These records had trance and rock which is hard to get  ;D I had time so I explored the docks and saw a poster for the war then saw a guard just walking around his post. I still had time to see people waving us off. I then went to the sector I hunted the ships before (AN82) and waited. Just before I reached my waypoint a neutral ship slightly stalks me  :-\ then left. A cargo ship came by so I got ready to attack it. It came and it was in range so I fired. I waited and whats this? MY torp hit the bow but missed and didn't sink the sucker  > So I followed it firing all my torps one by one and then I was dry. I left and headed to my sector to AN73. I just stayed submerged and if I wanted to kill anything I couldn't since I fired all my torps at the damn cargo boat that got hinted I was in the area. I then headed home and got ready for my new patrol but before that I rewarded and qualified my crew to my crew (more experience).

Patrol 6: I got ready for another patrol and another fun trip to sink ships. I set out too sea with my records playing again on this trip to my patrol grid, AN41. While I go to my grid and kept on getting contact reports from other submarines I still didn't engage since there was nothing to attack. Once I reached my grid I get a contact report so I tracked its course then headed there to see if another one of those ships would go that way. Nothing and my patrol was over in 24 hours so I then went back to my previous hunting ground but on the way I get a contact report heading my way  . I plot its course and was off by about 5-10 squares. Even though that happened I was still close enough to reach my target in a proper distance. It came and unaware of me stalking it I pre-pared Torp 1 and 2 for destruction  ;D 40,39....35....30......All stop.....27....25...FIRE Tube 1.....Fire Tube 2.......KABOOM...........KABOOM........(everybody cheers its destroyed and enough for my VIIB)  ;D. Victory at last so I took pictures of it going down. Perfect so I then headed to my hunting ground but whats this? I landed myself into a storm  ??? Should have seen this coming  I try to wait for my 2 preys but they both elude me since i'm too slow in the storm. I get a contact report but its a neutral. I try to find the docks but the storm is just unbareable. I then head home and buy myself a VIIB and free upgrade  ;D During the building of my VIIB I took a vacation and my crew which seems to be from December to March  ;D .....Happy Hunting time 1940 of March 

Patrol 7: Well before I left I checked out my new poster I put up but seeing as its been ripped down again in my submarine I had no choice but to go on a patrol in my new VIIB. I got orders to go to sector AN28 so I left port and went on my way. Halfway to my sector I got contact of a Nazi ship going back home so I went to the conning tower to check him out. Apperantly that cargo ship was good luck. I went to sector AN28 waiting for contact but none came until I left it. I plotted its course and waited for it. Seems like I was off so I adjusted my course and got ready for a snack. Its a C2 Cargo ship and I waited until I could identify it with my Perascopes. I waited until it came closer and the light flashed green. I fired 2 torps 5 seconds apart and 1 hit then later second hit then instant destruction. I surfaced and let the crew take pictures. We left the bottom of sector AN49 to AN82. It was clear then two min later a storm started to form. I slightly paniced but still a great weather to kill in. A Small Merchant came towards me so I got ready as usual and learned how to properly fire torps. This one was going to teach me how to do things  . Fired torp one expecting a instant kill but whats this?  It didn't tilt one way or another but kept going at a slow speed. I wasted 2 torps on it and the other one I managed to kill the son of a beep. Let the crew take pictures and took one myself we left to hunt more C2 Cargo ships. Before we went I took a picture of the sun that looks like a UFO. Sent message of my kills to BdU and headed back to sector AN49 to hunt more ships. Got a contact report so I plotted its course and went infront of it. I waited for it and got ready for the kill. Got a sonar contact report so I plotted its course as it was coming. I sent 2 torps one after another at it also 5 seconds apart and it got instant destroyed. Watched it sink and I went through the wreckage. Crew took pictures again and so did I and well we also took videos of it going down  ;D. Same sector but more up north then the first C3 Cargo boat. I was heading to the Southeastern tip of British England but as I was I got a contact report slightly north of me since I was heading south. I turned around and ahead flank for 2 sectors until I managed to outpace it. I waited for it at evening (between 7-10 pm) in AN61 sector. This one was a stubborn one since I used one torp to try and kill this cargo boat. First one hit, other 2 missed. I surfaced and got ready the deck gun. I fired at its hull on the right side of it. I then used the flak gun to fire at its cargo. Went back to the deck gun and fired at its hull then cargo then its bow then its anchor. Its anchor is its weak spot so I fired and it blew up and sank my way. The cargo boat sank but killed my flak gunner. I was too close to it since it was steering to the right. I repaired the medium damage (yellow) and learned to aim at the anchor. I left the area at flank speed to my base but a plane came to the rescue and attacked me. I periscoped depth and left the area with 2 stern torps and enough ammo in the  deck gun to attack another ship but seeing as I had a dead crew and low on ammo I didn't want to risk it.

Returning to port a Destroyer (friendly) came clouse and mourned the loss of "Axel Reichmann". During an attack the Flak Gunner is in the worst position and I didn't know the ship would topple on me. Repaired my ship and rewared my crew 6 medals and 1 qualification. Armed my submarine with electric torps and went home to rest.

-----------------

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/P71.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/P72.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/P73.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/P75.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/P76.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/P77.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/P78.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/P79.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/P710.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/P711.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/P712.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/P713.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/P714.jpg

Well if any of you want to join me now please join me and set up a time.

Heres a few pictures if your still in doubt but if you just dont want to play then ok.

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/Sh2.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/sh10.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/sh12.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/sh25.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/sh27.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/sh38.jpg

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/Silent%20Hunter%20III/sh47.jpg

So as I said anybody going to join me in a pack to kill off ships or just rot in your little huts on the shore? Besides this game is better with more people then just attacking solo. We may get spotted inland but at least we'll have more firepower . If you hate the Germans then nothing to worry about since in this game they lose anyways which is just sad that you cant change history.

Star Wars:

- http://empireatwar.com (redirected to Lucasarts site)

- http://www.lucasarts.com/products/rebellion/gameplay_tips.htm

- http://www.galacticbattles.com/main/main.htm

- http://starwarsgalaxies.station.sony.com/ (Dont bother it sucks )

- http://www.lucasarts.com/games/swrepubliccommando/

- http://www.theforce.net/

Anime:

- http://www.gundamofficial.com

- http://www.e2046.com/product_info.php?products_id=4616

- http://www.e2046.com/product_info.php?products_id=2532

- http://www.e2046.com/product_info.php?products_id=2504

- http://www.e2046.com/product_info.php?products_id=2159

- http://www.e2046.com/product_info.php?products_id=2153

- http://www.e2046.com/product_info.php?products_id=1926

- http://www.e2046.com/product_info.php?products_id=2917

- http://www.mechag.com/

- http://www.g-seed.com/gallery/index.php

- http://members12.tsukaeru.net/peck/factory.htm#mg

- http://gundams.net

other:

- http://gendou.com/amusic/?filter=gundam+seed&match=0

- http://uboat.net/types/

- http://www.communitymanuals.com/shiii/index.php?title=Main_Page

- http://www.slovakia.org/currency.htm

Modding

- http://forums.cgsociety.org/forumdisplay.php?f=73

- http://forum.mechmod.com/index.php?showtopic=1274

Quote from Gundam Seed Destiny Episode 47 from the Chairman

"There is a feeling of anger and sorrow swirling inside me, just like it is in everyone else. Why did something like this happen? Even though I already know there's no use in asking that, my heart continues to wander,  in search for the answer. We just went through a large war a few years ago. And we where supposed to have pledged back then. That we would never let something like this happen ever again. Despite that, Junius Seven fell, and in spite of our efforts, a new war started and expanded without end, and we once again experienced the same sorrow and suffering. What does this really mean? The repetition of tragedies that once can only call foolish? One of the reasons, as I have mentioned earlier, is  undoubtly due to the presence to Logos. The ones who created enemies, fan people's tears, instigate them to fight, and feed off the battles. Those who have thrived in the shadows throughout our long history. The merchants of death. But we were finally able to destroy them. That is why I would like to say this now. That we must now fight against our other enemy. That we must defeat it and be freed. I'm sure that you all already understand...the reason why fighting has never disappeared from the history of mankind, ever since ancient times. Our enemy, which has always existed...that which we have not been able to conquer - our ignorance and ambitions!......Even now, after leaving the Earth, dahsing across the sky, and even after obtaining the secrets of the strengths and abilities of our bodies, people still do not understand Equality...no, to have more, to become wealthier...The ever-reaching hand of ambition. That is what characterizes us today. The problem and seed behind all our fighting is there. But the time has now come for us to bring an end to that. The time when we can bring and end to them.  We've obtained a way to conquer them. The answer is within all of us. With that, we will know the people, ourselves, This is the only way to stop the repetition of tragedies. As our final defense plan, with the survival of mankind on the line, I hereby declare the introduction of the Destiny Plan!"

Had some fun harassing an idiot I know  Grin Told CnC that he loves copying me. ie I get a phone and so does he, I get a Mp3 player and so does he, I get a PSP and so does he, I get GTA for PSP and so does he.

 

Now for the main event.

 

Hes an EMO or so CnC said  Grin This guy tries to talk to anybody and bug em so everybody knows him as an idiot. I tried helping him for 2 years and this is what I get  Embarrassed

 

[16:33] nightsmagic: what ever ur stupid trying to make me look stupid when u know urself that ur making u look stupid

(above from Xfire)

(Below from MSN)

C&C King | Empire-At-War.com says:

eh? is his first language arabic?

I know this isn't Star Wars but i'd rather keep this safe here or i'll lose it in my computer and forget where I put it. Also if any game designer wants to leech this to be produced do so since I can't wait for one to be made. Do not be as easy as Star Wars Battlegrounds or you'll be worse dishonorable to the gaming world. If you do credit me somehow.

Plateform: PC

type of game: RTS/Tech information/Sci-fi

players: 1-4

Single or multi: Both if possible

gamespeed: real time (if turn based it would be extremely boring)

Index

-Campaign

-Custom Battle

-Multiplayer

-Unlockables

-Point of it?

-How it might work

-AI

-Extra features

-Mobile Suit features

-Buildable stuff

Campaign

-Mobile Suit Gundam and its sequels and movie (Base game)

-Gundam Wing and the movie (Expansion pack)

-Gundam Seed with its Destiny sequel. (Expansion pack)

Well to explain this more you'll follow a linear plot (For this game you should) so you follow those orders and try your best to beat the enemy AI or save them or whatever. If theres a hero you can try and defeat it in the 1 min time limit to control a unit. Well you gain a mission and if you beat it you get rewards. If you fail then off to square 2 with less forces and a punishment.

Custom Battle

Just any faction against any how you want to do battles. Even use unlockable prototypes that seen only 1 battle then got destroyed. You can do anything as you wish since Campaign is a story teller. Here its a free willed world. Build a military unlockable building in your HQ to unlock units that are unlockable and turn the tide for your achievments in campaign.

Multiplayer

4 players max (2 vs 2 factions possibly (example from Seed: Zaft/Orb vs Earth/Logos or any other way). Build a military unlockable building in your HQ to unlock units.

Unlockables

Able to unlock prototypes that seen battle once then destroyed or from other series. You can play with these suits once your done one of your campaigns and have fun with them. You can use these also in custom and multiplayer. When the suits are destroyed successfuly by you you can unlock them by building a unlockable units the second time around in campaign or in Custom battles or multiplayer.

Point of this all

Well Gundam is popular since people like the ideas of Mechs and since anime is popular and put mechs into anime. Zoids, Gundam, Escaflowne, World After Tomorrow (i think, movie), Red Faction (game), and many others. Well we like RTS and theres already a action game, Online world, and RPG but its missing a RTS. Well to put into Star Wars terms, AT-ATS!!!!!AT-STs!!!!!!!!!!!!!!!!!!!

How it might work.

I bet if Gundam uses the EAW engine or modified for this game it would work out well. Either way it would work like this.

MAP or battle area

-Map would be a circle since no mobile suit has ever made it farther then the moon

-Space colonies would be specially placed on the map with damaged space colonies if its in the plot or background

-Earth would be in the middle of the map since some people still live on earth (if orignal gundam) or if its seed it would be half half. Its also a battleground.

-Earth battles would be a enlarged earth map which would a huge circle something like Civilization 4 has but more detailed and more earth like(More detailed then Rome Total war or Rise of Nations since there will be barely any point in playing this game since the earth would look crappy.

-Space battlegrounds would be sectors in space were enemy approaches you and you attack in that area or if you approach them you attack them in that area all in real time.

-When in space colonies there'll be a Rectangular map with 3 levels in it and you chose were you enter before going into those colonies.

-Maps for Gundam Seed http://www.gundamofficial.com/worlds/ce/background/maps.html

-Maps for Gundam Wing

(none available)

-Gundam (orgininal series, UC )

http://www.gundamofficial.com/worlds/uc/background/maps.html

Well the maps are somewhat difficult to understand for now. My bad they did go a tad bit out of the Moon ring but not that far (in UC).

Resources

To be honest I have no clue were they get all those metals and such. Lets just go with more money for more territory. Metals would come from mining astroids or moon or whereever. Well you could also use damaged or unusable mobile suits as resources since it was made from resources you used.

Battles

-Experience: Well for this game you need to gain experince or else it will be a boring mess of a battle. When your units train longer or fight longer and survive the battle they gain experience and gain better MS to attack with that you researched to battle with.

-Training/Fighting: Gain experaince to fight better and have a better chance of surviving a battle. More experience they get better units.

-Squads: Well squads were used a lot so it would be a good idea to have squads.

Research

At first you star with a basic Tank, infantry,Resource mechs, planes, battleships. and space ships. As war goes on you start to build larger and better mechs until you reach the end of that series upgraded suits. To research you go to your hq and try for upgrades which would be your new tech. Well we could use damaged mechs as resources to build new ones.

Territorys, Nations, and Space Colonies

What would be the point of battling if you cant conquer anything ? Well you start off where the series faction headquarters are. Then you control all the set cities and nations from there. Freedom of conquering also should be at your control so then you conquer that city. If your in the faction you control that area.

-Civil riots/war: People who dont like you will try and get rid of you from that area by setting up riots and breaking stuff and stealing your military units to go against you. They might even join the enemy forces to defeat you.

AI

Well for one pre-program the heroes their personalitys and their strengths, Their injurys that they had before,during,after their battles. For normal soilders they'll have their newbie combat tactics unless if they been trained they get better MS or MA (mobile suits or mobile armor) depending on their training course. Longer they train the better they are. Civilians aren't just NPCS, they're living breathing people also and what you can recruit from with. If you give them a good cause to join they will.

AI Tactics

Well the AI tactics depend on the AI's skill in combat. If its good enough it will block attacks and help its teammates out. Also it will attack when necessary. It will also use tactics more and succeed more if its experience is high enough.

Extra Features:

-Weather for space colonie and Earth, comets and astroids landing on anyone of them and also mechs falling from space (If ai).

-Reasons to join or announcements (A list of what to say to the public or other factions)

-Controllable units in cockpit view would be interesting (1 min control) you control the unit if you can, if that unit dies no biggy except you lost a unit and a human life. 1 Minute is a limit to keep RTS feel to the game. Also only once during a mission or you'll constantly use it and lose the RTS feel.

-vehicles can be stolen so you got to put your facilitys at high security. Soilders can steal units and bring it to your faction's base where you have properly trained soilders and you can then modify those suits and put them into battle.

Mobile Suit Features

-Some mobile suits can transform into flight mode or Mobile Armor mode.

Some are just meant for melee and some for long range assault and some do both. Some are just mass produced crappy suits. Some can fly for long distances and some can go both in Earth and Space. Depending on your custom battle research or multiplayer you'll fight on Earth or in space. If your in Campaign you'll gain auto reasearch when completing a mission.

Buildable Stuff

Buildings

-Civilian buildings: they'll be premade and grow if your faction is a healthy and strong one. Also random buildings will be placed for safety from fighting.

-Military: There will be tank,boats/subs, mobile suit, and air plane building factorys. For Infantry and pilots you'll recruit them and if your short on pilots you'll have a shortage of MS/MA or whatever in the battlefield.

-Pilots and Infantry can go out of MS/MA and be ordered to go into another unit but they would be have to be trained to do that or else it be a pointless battle.

units

-Mobile suits will be built at a Mobile suit factory placed in your factions HQ or wherever you built a base, vehicles can be stolen by anybody.

-Air units will be built at a airbase at a base you built. Airbases also built space ports and space ships to go into space or go down to earth.

-Pilots/Infantry you train will act like mobile suits so you can control them, they can also enter any vehicles. As I mentioned if your soilders are trained enough they'll be able to steal and pilot a mobile suit or vehicle.

-Ships are your sea supports and you can have Sea mobile suits if its in the series. Not much to do at sea except shore support and capture any damaged vehicles at sea or start a salvage operation.

-Tanks and transport vehicles are built at you base or HQ. They are support like Airplanes are.

-For other units only your HQ will build Gundams and hero units and spawn hero characters.

I'll come back and edit.

.... an interesting find

http://www.angelfire.com/wizard2/ferrari_phantom/

My other sites:

www.freewebs.com/ghostlysubstance

http://ghostlysubstanc.12.forumer.com/

www.freewebs.com/ghostlypolovnik (Maybe, should be linked to my site in downloads from angelfire.com, first link)

edit: http://eurosubstance.swgbex.com

New report projects upwardly mobile industry to have doubled in value worldwide over 2005, closing in on $2 billion mark.

Analysts may be predicting a stagnant or even shrinking traditional game industry in 2005, but it appears to have been a banner year for the mobile gaming market. In the past year, worldwide wireless gaming has doubled its revenues worldwide, according to a new report from Screen Digest.

The report says the worldwide market was worth 850 million euro ($996 million) in 2004, and is projected to swell to 1.7 billion euro ($1.99 billion) in revenues when all the 2005 numbers are tallied up. It also notes that traditionally strong mobile markets like Japan and Korea are losing some of their position in the industry as Western countries catch up. Markets in the US and Europe now account for 52 percent of the mobile gaming market, according to Screen Digest.

"As operator-voice revenues worldwide have slowed, the importance of mobile data has markedly increased, and games are delivering sizable revenues," stated the report's author and Screen Digest analyst David MacQueen. "The importance of this sector will continue to grow."

MacQueen noted in the report that JamDat and GameLoft were the biggest players in the American and European markets, respectively, and that traditional game publishers have by and large failed to duplicate their success in the emerging market. The lone exception to that was THQ, whose THQ Wireless brand has carved out a niche for itself.

http://www.gamespot.com/news/6140894.html

By Brendan Sinclair -- GameSpot

Posted Dec 7, 2005 3:02 pm PT

~ Depends on what you are understanding by “publicize modsâ€

During Halloween at certain time of day have a ghost pop up on screen with a loud bang to scare the user In EAW. Maybe have Obi-Wan be the ghost and have a big loud explosion coming from the game.

During Christmas time have the units dress up in christmas cloths and see these winter stuff in it. Have vehicles painted christmas colors (whole day)

For April 1st have a cut scene (random time) of the units you own surrender or something along that line but not actually doing that to prank the gamer.

For Valentines day have both sides liking each other for the day only thing you can do is control 2 units stuck together and explore the galaxy in a ship or vehicle like speeder and only get attacked by pirates

Canada and America day (or gamers playing the game in their country flag) have a cutscene of units holding a flag or marked with the flag

First Release units and Maps:

Maps:

Space Map: Waiting for enough information

2 Land Maps: City and Shoreline

Unit types:

- Gouf Ignited (level 3 unit, Both)

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/6GMod/GoufIgnitedlvl3.jpg

- Astray Gundam - Blue Frame (Level 1:Beam Saber[Lightsaber], Level 2: Beam Rifle, Level 3: Upgraded Beam Rifle with Missle Launcher(2 kinds))

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/6GMod/AstrayBlueframe.jpg

- Izumo Class Battleship

http://i7.photobucket.com/albums/y292/GhostlyPolovnik/6GMod/KusanagiShip.jpg

Heroes/Commanders:

- Orange Gouf Ignited (Level 4, both) - Commander

- Kusanagi (Izumo Class Battleship) - Flag Ship

- Astray Gundam - Blue Frame - Commander

After talking with MyZrael I think its best to stick with three units. I'll just end up also using borrowed tech if possible from other mods.

Tech Tree or Level list:

Coming Soon.

I'll list points you can ponder on and then say what you think.

Platform: PC, PSP, PS3

-Time period: End of Episode 3

-Plot: Still thinking of one

-You start off with a Transport ship with 4 other crew member and then move up in ship classes or stay in the ship your in and upgrade it to the max and your crew to with elite experience.

-You can buy any Imperial ship in stock.

-You can travel around the ship or stay in the bridge and command everybody from there.

-Missions/orders come from a hologram and you interact with it and click on a yes/no/later/already did type messages.

-You can change the timeline by destroying certain ships you come in contract with.

-You can land at planet bases/out posts/shipyard for resupplying and exploring the base/outposts/shipyard (Can travel no farther and will be stopped by gaurds)

-You can attack any ship you would like to attack and go neutral with the ship you have.

-You can join Imperials/Rebels/Pirates/Neutral.

-Starting vehicles: Imperial - Vehicle transport/ Rebels - Rebel Correlian Corvette/ Pirates - Unknown/ Neutral - YT-1300

-Customize your ship with paintjobs also and customize your character.

-If you own a ship you can buy or fire your crew

--Can fly in a Tie fighter/Bomber or X-Y wing but if you die your 100% gone.

-Can be revived by another player or ai medic team.

Multiplayer:

-8 player and any side you want.

-Can control any commonent on the ship

-Can only hologram or radio chat to another player.

-Can be revived by another player or ai medic team.

As I said I dont expect this to be made but to see how you people think about this. Maybe i'll get a bash from Marcus with no response. If theres a game like this for PC point me to it.

Suggestions anyone ?!

-Katarn

Better Games Through Usability Evaluation and Testing

No one wants to play games that are either frustrating or difficult for the wrong reasons. The best way to make sure that unintended problems do not hinder enjoying the game is to take usability into account in game development. This article presents how this can be done and what kind of results to expect.

Usability is an integral part of software development and has been so for the past 20 years. For one reason or another, usability has not gained similar popularity in game development. This, however, is about to change. Ease of use and optimal user experience are already important in games and will become even more so in the future.

What is Usability?

Usability is about maximizing effectiveness, efficiency and satisfaction. This definition originates from the traditional software industry, but it translates well to game development. In games, usability is about delivering a better and deeper experience with less unnecessary interruptions or challenges that have not been designed by the developers.

Why is Usability Important?

There are many reasons why usability is important in games. For one, playing games is voluntary. If the player has to struggle with problems that make playing less fun than doing something else, then there is nothing to stop the player from switching off the console. This is a serious risk as the user experience is very sensitive to usability problems. Even the smallest glitch or hiccup in the user interface may render an otherwise good game into a rather annoying experience. For example, if managing the inventory in a role playing game is not fluent enough or restarting a race in a driving game is tedious the player is not likely to enjoy playing the game.

Another reason why usability is important in games is the competition. Competition in the market is fierce. The gamers can choose which game to buy from a wide variety of titles; if the controls are not fluent in one soccer game, there are five more titles left from which to choose. Usability is one of the key factors that make the game stand out of the crowd.

The delicacy of the user experience and heavy competition actually make usability more important in games than it is in other software. There are not too many word processors to choose from, and having fun at work is not usually a top priority.

There are also other reasons why ease of use is important. One of them is that modern games are large and complex programs. In even the most focused games there are tons of menus and ways to interact within the game, not to mention games like the Grand Theft Auto series. Usability is important when making a game as easy and intuitive to play as possible. Good examples of complex games made easy are World of Warcraft and Xbox Live games. Both have succeeded in making traditionally difficult multiplayer gaming easy.

Usability is also important for the future of gaming. For gaming to continue to increase its popularity, the ease of setting up games and a fluent gaming experience are of the essence. This is because newcomers are not familiar with the conventions and common pitfalls of gaming. For them, learning the peculiarities that old gamers are already familiar with can be too much.

This Article

The focus of this article is not only to tell why usability is important in games, but also to introduce two usability methods and the kind of results they yield. The methods are expert evaluation and usability testing.

It will be presented how these were applied in the development of Frozenbyte's Shadowgrounds (www.shadowgroundsgame.com) game. Adage Corporation (www.adage-usability.com) was responsible for the usability related activities in the project. Before moving on to the methods, the game will be presented briefly.

Frozenbyte's Shadowgrounds Game

Frozenbyte Inc. is an independent games studio, based in Helsinki, Finland, founded in year 2001. Frozenbyte is currently working on a PC game called Shadowgrounds, which is to be released in the third quarter of 2005.

Shadowgrounds is an action game viewed from the top-down/3rd person perspective (see Figure 1). The main features of the game are adrenaline-pumping old-school action, realistic lighting, destructible environment and upgradeable weaponry.

Figure 1. Intense battles, lightning effects and upgradeable weapons are key elements of Shadowgrounds.

Usability Expert Evaluation

In a usability expert evaluation, usability experts review the game and search for potential usability problems. Based on both their knowledge and experience they review the game systematically and report the findings.

In a typical expert evaluation three usability experts review the game. The experts first evaluate the game independently. After that the experts have an evaluation meeting together. In this meeting, the usability problems found are discussed and rated for severity. After that a report is written where the usability problems found are listed systematically. For each problem there is a title, severity rank, and a detailed description of the problem. A solution to each problem is also suggested.

This process takes approximately a week. Preliminary results, however, can be given in a few days. After handing in the final report, a meeting between the usability experts and the game developers is arranged. In this meeting, the findings are discussed in more detail, and the usability experts can answer questions that come about from the report.

Expert evaluation is a very flexible method, and it can be done at almost any point of game development. In the case of Shadowgrounds the expert evaluation was done approximately six months before the planned deadline of the game. In the version evaluated there was one playable level and the basic gameplay mechanics were implemented. Everything was, however, not ready. For example, the destructible environment was not fully implemented yet, voice acting was missing, and many smaller bugs were still present.

It is also possible to conduct an expert evaluation even in earlier stages of game development. For example, menus and displays can already be evaluated on the basis of paper prototypes, and potential usability problems affecting gameplay can be spotted from the design document. The earlier the expert evaluation is done, the easier and more cost efficient it is to make changes.

The depth and scope of an expert evaluation are also easy to change. For example, if there is a desire for constant input from the usability experts to the development process, then conducting several smaller usability evaluations with less experts and faster reporting may be a good idea.

Results of the Expert Evaluation

In total 135 usability problems were found in the expert evaluation of Shadowgrounds. Out of these problems 2 were classified catastrophic, 30 severe and 60 intermediate. The remaining 43 problems were either minor or cosmetic. The distribution of the problems is illustrated in Figure 2.

Figure 2. Classification of the usability problems found in the expert evaluation.

The number of usability problems found may seem high, but in reality it is not exceptional by any means. Expert evaluation gives feedback to almost every area of game development. In a typical evaluation, usability problems are found in menus, in-game displays, controls, gameplay and level design. Because of this, the total number of problems found can be quite high. Here are some examples of usability problems along with the game developers' view on the problem.

Problem

One color has multiple meanings in the map display.

Rating:

Catastrophic

Description:

The light blue color in the map display has three different meanings. It marks the area visited, unknown area, and areas that cannot be accessed (e.g. mountains).

Using the same colour to symbolize three different things makes understanding the map difficult. Every time the user opens the map, s/he must stop for a second and think what the colors mean in different locations. There is also a danger that the users do not understand what the colors mean or misinterpret the map.

Solution

Use different colors for displaying visited, unknown and inaccessible areas.

Developers' comment

This problem could have been addressed earlier if the design document had covered the map screen more thoroughly. In the final game, a map legend will be displayed, and only one color (shade) will be used for one meaning.

Problem:

No feedback is given if the player cannot pick an item.

Rating:

Severe

Description:

Sometimes it happens that the player cannot pick up an item because there is no room in the inventory. If this happens, the user is not given any feedback.

This is problematic as the user may not know why s/he cannot pick up the item. It is likely that the user will figure it out eventually, but the confusion and extra effort required are likely to cause frustration.

Solution

Give the user proper feedback in every situation where the user interacts with the environment. If the item cannot be picked up, inform the user about this with a sound and/or textual feedback.

Developers' comment

This was addressed only vaguely in the design document, and was overlooked by the programmers at the time. It is likely that this feature would have been implemented in due time, and goes to show that sometimes developers leave many of the smaller usability issues to the final stretch of development.

Problem

When fixing an item, the feedback is displayed too far away from the location being fixed. Rating

Intermediate

Description

The player often fixes items in the game. Fixing an item is done by moving close to the item and holding down E. A progress bar is displayed and the item is fixed when the bar reaches the end. The progress bar is displayed too far away from the item fixed.

Presenting the feedback closer to the location at which the action takes place makes it easier to understand that the feedback and action are linked to each other. It also reduces the need for the user to move his/her attention between the feedback and the action.

Solution

Display the progress bar close to the location it refers to.

Developers' comment

This seems like a no-brainer but it went unnoticed for a long time by the development team, because it had grown so accustomed to the game and its features. The feature had only a vague description in the design document (loosely translated to "a repair bar is displayed on the screen"). Had the document been given more thought or had it been read by usability experts before implementing the feature, the feature might have been done correctly from the get-go.

Problem

It is not immediately obvious whether the upgrades presented next to the weapon are installed or not.

Rating

Intermediate

Description:

The upgrades available for the weapons look active even before purchasing them. This is because they are marked with a similar color scheme as the weapons next to them, which are active.

This is especially problematic early in the game. Because the upgrades look active, the user may not understand that this menu can be used to purchase new upgrades.

Solution

Make the upgrades that have not been purchased yet clearly inactive. This can be done for example by using a darker shade of blue to present the upgrades that have not been bought yet.

Developers' comment

The weapon upgrade feature had not been fully implemented by the time of the testing, but regardless, this particular problem had not been taken into consideration. Later user-testing showed that this was definitely a problem with gamers, especially in the beginning of the game.

Problem

Red lights in the computers are easily mixed with enemies displayed in the radar. Rating

Minor

Description

Enemies are marked with small red spots in the radar. The radar is semi-transparent: the scenery is visible through it.

In some buildings there are computers and other equipment that have small red lights. When it happens that such a light is visible through the radar it is easily thought to be an enemy.

Solution

Do not use small red lights in levels, or change the method of displaying enemies in the radar.

Developers' comment

Sometimes the developer can freely ignore the comments or suggestions made by the usability report. Here, Frozenbyte decided that this problem occurs too rarely to warrant any changes to the user interface.

After the expert evaluation some of the most central usability problems were fixed to prepare the game for the usability testing that was scheduled to start two weeks later. For example, the map problem discussed earlier and minor usability problems related to the radar were fixed.

Better Games Through Usability Evaluation and Testing

Usability Testing

Usability testing is the most fundamental usability method. In a usability test, the game is tested with players that represent the target group of the game. Just like in an expert evaluation, the goal is to pinpoint the challenges in the game that were not intended by the game developers.

The reason why testing is important is that it provides direct and objective information about how real players play the game and what are the exact usability problems that players face when playing the game. This data is irreplaceable when developing the game and making it easy to use.

In a typical usability test 3–6 players from each target group of the game are recruited to come and play the game in a usability laboratory (see Figure 3). The players come to the laboratory one at a time and play the selected parts of the game for 1–2 hours.

Figure 3. A usability laboratory consists of two rooms with a one-way mirror and a sound proof wall in-between. The user and the test instructor are in the laboratory room. The test is recorded in the observing room and the developers can follow test in the nearby meeting room.

In the laboratory, there is a test instructor together with the player. The role of the expert is to give tasks to the player and observe playing the game. The player is instructed to think aloud while playing. In practice this means that the player tells what s/he is doing while playing the game. Sometimes the usability expert may interrupt the player and ask questions about what the player was doing and why. The purpose of these questions is to get in-depth information about the problems and the reasons behind them. Game developers are also invited to come and observe the tests. The onscreen action and an overall view of the laboratory are displayed in a meeting room where the developers can follow the tests and discuss the findings with a usability expert.

After the tests, each recording is carefully analyzed to find all the usability problems and to understand the reasons behind them. Then the final report is created. In the final report, all the problems found are prioritized and solutions for the problems are provided.

Typically usability testing takes 2–3 weeks from the start to delivering the final report. Initial findings can be provided even earlier, and it is also possible to change the version tested between the players. This makes it possible to fix the problems during the testing and thus to verify the changes later on in the same test.

In the case of Shadowgrounds the usability test was conducted two weeks after the expert evaluation. The focus of the testing was broad, and all the aspects but the main menu of the game were tested. The testing was done with a version similar to the version used in the expert evaluation. Like mentioned earlier, some usability problems were fixed between the expert evaluation and the test. Next, examples of the problems found will be presented.

Results of the Usability Test

In the usability tests 97 usability problems were found. Finding less problems in usability testing than in expert evaluation is typical: players do not necessarily use every feature of the game, and some of the minor problems found in the evaluation do not necessarily show in the tests. One of the problems found was classified catastrophic, 26 severe, 28 intermediate, and 42 minor or cosmetic. This is illustrated in Figure 4.

Figure 4. Classification of the usability problems found in the expert evaluation.

Next, five examples of problems classified as severe are presented. In addition to presenting the problems and their suggested solutions there is also game developer's comments after each problem.

Problem

Picking up a new weapon went unnoticed.

Rating

Severe

Description

It happened twice in the usability tests that a user picked up a laser rifle but did not notice it before entering the weapon upgrade menu later on. As acquiring new weapons is an important reward in the game this should not go unnoticed.

Solution

Give clear feedback when the user finds or acquires a new weapon.

Developers' comment

There was feedback for picking up a new weapon - the information bar in bottom of the screen displayed a text message. In this case the feedback was not noticeable nor rewarding enough, and will be improved in the final game.

Problem

The character moves too slowly. Rating

Severe

Description

Two out of six users commented spontaneously that the character moves too slowly. The movement speed was considered especially problematic in open spaces. Inside the buildings the speed was considered to be good. See also the survey results.

Solution

Consider implementing a running option.

Developers' comment

This could be one of the biggest issues in games - the movement speed of the units/characters. In our case, the problem was mostly outdoors, which would suggest that the outdoor areas were not interesting by themselves, and the player wanted to get to the next interesting area (building). It will be interesting to see if this is the case, when the final game is tested

Problem

The users did not understand how the radar works.

Rating

Severe

Description

The radar displays only the enemies that are moving. None of the users understood this. Most of the users thought that the enemies are shown in the radar when they are close enough.

Many users also thought that the radar cannot see through walls. In reality, the radar does not care about obstacles.

Solution

Inform the users about the radar and how it works in the tutorial of the game. Consider labelling the radar as motion sensor.

Developers' comment:

The radar will be renamed to motion sensor (which it is). Apparently the aliens theme wasn't enough to make the players understand that the circular element in the top-right corner worked like a motion sensor, even if it had the familiar beeps.

Problem

Finding doors is difficult.

Rating

Severe

Description

The users had difficulties in finding doors, and it happened often that the user thought that either a window or some other structure was a door.

Solution

If the door is not hidden on purpose mark it clearly. Symbols and/or light effects should be considered. Change the shape of the windows and the buildings' support structures so that they are not mistaken as doors.

Developers' comment

This is a tough problem, and hard to predict in the design phase. Additional lights could be added, and the buildings could be remodeled, but this takes a lot of effort. In the end, this problem seemed big enough to warrant changes, and each door was scrutinized individually to make sure it worked alright.

Problem

Changing of the mission objective was not always noticed

Rating

Severe

Description

During the tests it happened a few times that the users did not notice that the mission objective had changed. This was because the users did not always pay close attention to the dialogue between the characters.

Solution

Provide the users a clear notification about a new mission objective. It is not enough to inform the users about the new objective in the in-game dialogue.

Developers' comment

Part of this problem was caused by unpolished dialogue (sometimes the texts went by too fast). English wasn't the users' mother tongue, which could have affected the outcome as well. The new mission objectives (and the target point) were presented in the map screen, but not all users had understood this very well (due to the lack of tutorial before playing the game). " Mission objectives updated" was displayed in the information bar at the bottom of the screen, and also as a icon on the right side of the screen, but the icon was not understood clearly. In the final game, all of these problems will be fixed.

Benefits of Usability Expert Evaluation and Testing

Usability expert evaluation and testing are systematic methodologies that provide information to support game development. Together they provide both the experts' view on usability and experimental data of usability problems in the game. The usefulness of the methods is illustrated by the following quotes from Joel Kinnunen, the development director of Frozenbyte:

On expert evaluation:

"Expert evaluation is a fast and effective way to check the usability of a game. In our case, the results arrived in a couple of weeks, and they helped us solve some major design issues. We were also able to fix numerous smaller usability problems, and avoid a couple of potential pitfalls in designing and implementing new features.â€

The Anatomy of a Design Document, Part 1:

Documentation Guidelines for the

Game Concept and Proposal

Contents

The Purpose of Documentation and the Benefits of Guidelines

Guidelines for the Game Concept

Guidelines for the Game Proposal: Market and Technical Analysis

More Guidelines for the Game Proposal

The purpose of design documentation is to express the vision for the game, describe the contents, and present a plan for implementation. A design document is a bible from which the producer preaches the goal, through which the designers champion their ideas, and from which the artists and programmers get their instructions and express their expertise. Unfortunately, design documents are sometimes ignored or fall short of their purpose, failing the producers, designers, artists, or programmers in one way or another. This article will help you make sure that your design document meets the needs of the project and the team. It presents guidelines for creating the various parts of a design document. These guidelines will also serve to instill procedures in your development project for ensuring the timely completion of a quality game.

The intended audience is persons charged with writing or reviewing design documentation who are not new to game development but may be writing documents for the first time or are looking to improve them.

Design documents come in stages that follow the steps in the development process. In this first of a two-part series of articles, I'll describe the purpose of documentation and the benefits of guidelines and provide documentation guidelines for the first two steps in the process - writing a concept document and submitting a game proposal. In the next part, I'll provide guidelines for the functional specification, technical specification and level designs.

The Purpose of Documentation

In broad terms, the purpose of documentation is to communicate the vision in sufficient detail to implement it. It removes the awkwardness of programmers, designers and artists coming to the producers and designers and asking what they should be doing. It keeps them from programming or animating in a box, with no knowledge of how or if their work is applicable or integrates with the work of others. Thus it reduces wasted efforts and confusion.

Documentation means different things to different members of the team. To a producer, it's a bible from which he should preach. If the producer doesn't bless the design documents or make his team read them, then they are next to worthless. To a designer they are a way of fleshing out the producer's vision and providing specific details on how the game will function. The lead designer is the principle author of all the documentation with the exception of the technical specification, which is written by the senior programmer or technical director. To a programmer and artist, they are instructions for implementation; yet also a way to express their expertise in formalizing the design and list of art and coding tasks. Design documentation should be a team effort, because almost everyone on the team plays games and can make great contributions to the design.

Documentation does not remove the need for design meetings or electronic discussions. Getting people into a room or similarly getting everyone's opinion on an idea or a plan before it's fully documented is often a faster way of reaching a consensus on what's right for the game. Design documents merely express the consensus, flesh out the ideas, and eliminate the vagueness. They themselves are discussion pieces. Though they strive to cement ideas and plans, they are not carved in stone. By commenting on them and editing them, people can exchange ideas more clearly.

The Benefits of Guidelines

Adhering to specific guidelines will strongly benefit all of your projects. They eliminate the hype, increase clarity, ensure that certain procedures are followed, and make it easier to draft schedules and test plans.

Elimination of hype. Guidelines eliminate hype by forcing the designers to define the substantial elements of the game and scale back their ethereal, far-reaching pipe dreams to something doable.

Clarity and certainty. Guidelines promote clarity and certainty in the design process. They create uniformity, making documents easier to read. They also make documents easier to write, as the writers know what's expected of them.

Guidelines ensure that certain processes or procedures are followed in the development of the documentation - processes such as market research, a technical evaluation, and a deep and thorough exploration and dissemination of the vision.

Ease of drafting schedules and test plans. Design documents that follow specific guidelines are easy to translate to tasks on a schedule. The document lists the art and sound requirements for the artists and composers. It breaks up the story into distinct levels for the level designers and lists game objects that require data entry and scripting. It identifies the distinct program areas and procedures for the programmers. Lastly, it identifies game elements, features, and functions that the quality assurance team should add to its test plan.

Varying from the guidelines. The uniqueness of your project may dictate that you abandon certain guidelines and strictly adhere to others. A porting project is often a no-brainer and may not require any documentation beyond a technical specification if no changes to the design are involved. Sequels (such as Wing Commander II, III, and so on) and other known designs (such as Monopoly or poker) may not require a thorough explanation of the game mechanics, but may instead refer the readers to the existing games or design documents. Only the specifics of the particular implementation need to be documented.

http://www.gamasutra.com/features/19991019/ryan_01.htm

Guidelines for the Game Concept

A game-concept document expresses the core idea of the game. It's a one- to two-page document that's necessarily brief and simple in order to encourage a flow of ideas. The target audience for the game concept is all those to whom you want to describe your game, but particularly those responsible for advancing the idea to the next step: a formal game proposal.

Typically, all concepts are presented to the director of product development (or executive producer) before they get outside of the product development department. The director will determine whether or not the idea has merit and will either toss it or dedicate some resources to developing the game proposal.

The director might like the concept but still request some changes. He or she may toss the concept around among the design staff and producers or open it up to the whole department or company. The concept can become considerably more compelling with the imagination and exuberance of a wide group of talented people.

A game concept should include the following features:

Introduction

Background (optional)

Description

Key features

Genre

Platform(s)

Concept art (optional)

Introduction: The introduction to your game concept contains what are probably the most important words in the document - these words will sell the document to the reader. In one sentence, try to describe the game in an excited manner. Include the title, genre, direction, setting, edge, platform, and any other meaningful bits of information that cannot wait until the next sentence. The edge is what's going to set this game apart from the other games in the genre. For example:

"Man or Machine is a first-person shooter for the PC that uses the proven Quake II engine to thrust players into the role of an android space marine caught up in the epic saga of the interstellar techno-wars of the thirty-seventh century."

Breaking the introduction up into several sentences for the sake of clarity is acceptable. Just know that the longer your introduction, the more diluted your vision will seem.

Background (optional): The background section of your game concept simply expands upon other products, projects, licenses, or other properties that may be mentioned in the introduction; so it's optional. The background section is physically separated from the introduction so that readers can skip it if they already have the information presented. But the background section is important for licensed properties and sequels and concepts with strong influences from previously released titles in the same genre. If you intend to use an existing set of code or tools or to license a game engine, then describe these items and their success stories here.

Description: In a few paragraphs or a page, describe the game to the readers as if they are the players. Use the second-person perspective -- "you." Try to make this section an exciting narrative of the player's experience. Encompass all the key elements that define the core game play by describing exactly what the player does and sees. Avoid specifics such as mouse-clicks and keystrokes, but don't be too vague. You want the readers to become the player's character. Hover your detail level right above the GUI interaction. You would say something such as, "You scan your tactical radar and pick up two more bogies coming up the rear," instead of "You click on your tactical radar button and the window pops up revealing two bogies coming up the rear." The description section should make the content and entertainment value of the game obvious and convincing.

Key features: Your game concept's key features section is a bullet point list of items that will set this game apart from others and provide goals to which the subsequent documentation and implementation should aspire. It's a summary of the features alluded to in the description. These bullet points are what would appear on the back of the game box or on a sell sheet, but include some supporting details. For example:

"Advanced Artificial Intelligence (AI): Man or Machine will recreate and advance the challenging and realistic AI that made Half-Life game of the year."

Determining how many features to list is a delicate balancing act. Listing only one or two key features is a bad idea if you're doing anything more complex than a puzzle game; listing more than a page of features implies that the project would be a Herculean task and may scare off the bean counters. Listing too few features might sell your concept short; listing too many waters down the concepts' strongest features.

Keep in mind that you need not list features that are given, such as "great graphics" and "compelling music," unless you really think such features are going to be far superior to those of the competition. Great graphics, compelling music, and the like are the understood goals of every game project. On the other hand, if the particular flavor of graphics and music provides your game with an edge in the market, then you should spell that out.

Genre: In a few words, define the game genre and flavor. Use existing games' classifications from magazines and awards as a guide. For example, you could choose one of the following: sports, real-time strategy, first-person shooter, puzzle, racing simulation, adventure, role-playing game, flight simulation, racing shooter, god simulation, strategy, action-strategy, turn-based strategy, side-scrolling shooter, edutainment, or flight shooter. Then you can refine your game's niche genre with these or other words for flavor: modern, WWII, alternate reality, post-apocalyptic, futuristic, sci-fi, fantasy, medieval, ancient, space, cyberpunk, and so on.

Platform(s): In a few words, list the target platform(s). If you think the game concept is applicable to multiple platforms, you should also indicate which platform is preferred or initial. If you intend multiplayer support on the Internet, indicate that as well.

Concept art (optional): A little bit of art helps sell the idea and puts the readers in the right frame of mind. Use art to convey unique or complex ideas. Screen mock-ups go a long way to express your vision. Art for the game concept may be beyond most employees' capabilities, so requiring it would limit the number of submissions; thus, it is optional. If a concept has merit, the art can come later from a skilled resource. Often art from previous projects or off of the Internet will jazz up a document. Just be careful with any copyrighted material.

Common Mistakes

Here are some common mistakes that developers make in creating a game concept:

The concept is totally off base or inapplicable to the company's current plans. If you don't want to waste your time writing up concepts that get tossed, find out what the company in question is looking for and keep an ear to the ground for opportunities with which your idea may be a good fit.

In terms of resources, the document asks for the moon. Try to keep your concept within the realm of possibility. Keeping the budgets down by suggesting existing tools or properties to reuse is helpful. Limit your ideas to that which can be accomplished in a timely fashion and with a reasonable budget. Limit experimental technologies to one area. Don't suggest revolutionary AI as well as a new, state-of-the-art 3D engine. If you are being solicited to produce the game concept, find out what the time frame and budget expectations are first.

The document lacks content. Simply saying, "It's Command & Conquer meets MechWarrior where you order your 'Mechs in tactical combat," is insufficient. Your description has to explain the actions that the player will perform and make them seem fun. A good description might read, for example, "You order your 'Mech to fire at point-blank range on the exposed right torso of the Clan MadCat OmniMech." This kind of descriptive content will help mitigate misinterpretations of the core game play that you envision.

The game isn't fun. A useful exercise is to break down all of the player verbs (such as shoot, command, run, purchase, build, and look) and envision how player performs each. Then, for each verb, ask yourself if it's fun. Then ask yourself if the target market would find it fun. Be objective. If the action that the player takes isn't fun, figure out another action for the player to take that is fun or drop the verb entirely.

The game-concept document employs poor language and grammar. Don't make yourself look like an ass or an idiot. Check your grammar and spelling and avoid four-letter words and sexual innuendo. You don't know who will ultimately read your document or whom you might offend with some particularly expressive words. Even the macho, politically incorrect, culturally insensitive, slang-using manager with whom you exchange dirty jokes over a beer at lunchtime can get quite sensitive with documented verbiage.

The designer gives up. Don't give up submitting ideas. You never know when one of them will take off. Persistence pays off, believe me.

http://www.gamasutra.com/features/19991019/ryan_02.htm

Guidelines for the Game Proposal

A game proposal is a formal project proposal used to secure funding and resources for a game development project. As a game proposal takes time (and therefore, money) to do correctly, it should only be developed for promising game concepts.

The proposal is an expansion upon the game concept. Writing a proposal may involve gathering feedback and information from other departments, especially the marketing department (if it exists). You may need your marketing department to perform some market research and analysis on the concept. If the game requires licensing, you may need your finance and legal departments to investigate the availability and costs involved in securing the license.

The programming staff, typically senior programmers or the technical director, should perform an initial technical evaluation of the concept. They should comment on the technical feasibility of the concept and the programming areas that may require research. They should assess the risks and major tasks in the project and suggest solutions and alternatives. They should give a rough estimate as to the required research and development time and resources.

The game proposal should include a revised version of the game concept. Technical, marketing, and finance feedback to the concept document might force you to scale back the concept. It might also suggest modifying or adding features. These changes should not take anyone by surprise, as this is the first time that the concept has been subjected to major criticism and the collaborative process. Giving copies of the feedback and analysis to the director of development (or whoever asked for the game proposal) before they are folded into the game proposal or effect changes in the concept is a good idea. This process not only provides written confirmation that the concept has been reviewed by certain people or departments, but it arms the director with the knowledge to veto, alter, or otherwise approve any proposed changes.

The game proposal includes the following features:

Revised game concept (preceding)

Market analysis

Technical analysis

Legal analysis (if applicable)

Cost and revenue projections

Art

Market analysis: The marketing department and/or a market research firm, assuming your company can afford it, should compile this information. If you are compiling this information yourself, you should try to avoid pure guesses on numbers. Look for info on the Internet (www.gamestats.com is a good source) and use existing hits in the same genre as indicators for market performance.

Target market: The target market is defined by the genre and the platform, issues that have been already addressed in the concept document. You can qualify this definition by mentioning specific titles that epitomize this market. The most successful of these titles will indicate the viability and size of the market. Also mention the typical age range, gender, and any other key characteristics. If this game involves a licensed property or is a sequel, describe the existing market.

Top performers: List the top performers in the market. Express their sales numbers in terms of units, breaking out any notable data-disk numbers and any successful sequels. Include their ship date. You can be vague -- Q1 1998 or spring 1998. This research can go way back, so present your data in chronological order.

List their platforms if they vary from the platform for the proposed game. However, because the markets change depending on the platform, you should always present some title of the same genre on the target platform, even if it didn't perform as well as the others. Such data may indicate a sluggishness for that particular genre of games on the platform. For example, turn-based strategy games may have great sales on the PC platform, but have terrible numbers on the Sony PlayStation. This list of top performers should indicate this discrepancy if you're doing a turn-based strategy game.

Feature comparison: Break down the selling features of these top performers. Compare and contrast them to the key features described in the concept document. Try to provide some specifics. For example:

Tactical Combat: In Command & Conquer, Dark Reign, and Myth, you order your units to attack specific targets and move to specific places or ranges for an advantage. Most units have a unique strength and weakness that become apparent during play, thus encouraging you to develop superior tactics. Tanktics has a wider variety of orders to allow you to apply superior tactics, such as capture, ram, and hit-and-run. Unit position and target selection become even more important due to terrain, movement, and range bonuses; firing arcs; and soft spots in rear- and side-hit locations. All of the units have distinct weaponry, armor, and speed to differentiate their strengths and weaknesses and encourage tactics. Not only do you learn to master these tactics over time, but you can also script these tactics into custom orders.

Technical analysis: The technical analysis should be written by a seasoned programmer, preferably the technical director or a lead programmer, and then edited and compiled into the proposal. Reviewers of this proposal will use this technical analysis to help them make their decisions. Be honest; it will save you a lot of grief in the end. Overall, this analysis should make the reviewers optimistic about the game's chance of succeeding.

Experimental features: Identify the features in the design that seem experimental in nature, such as untried or unproven technologies, techniques, perspectives, or other unique ideas. Do not include features that have been proven by existing games, even if they are new to the development team. For example, if the team has never developed a 3D engine, don't list it as experimental. Rather, list it in one or more of the other categories in the technical analysis section. On the other hand, if your development team is working on a 3D engine using the theoretical system of quads, then this effort should be listed as experimental. Of course, by the time you read this article, quads could be in common use.

Include an estimate of the time that it will take to bring the experimental feature to an evaluation state, as well as an overall time estimate for completing the feature. Experimental areas generally need more time in the schedule, so the more experimental features you list, the longer the schedule will be. While some companies shy away from such 18- to 24-month projects, many see these experiments as worthwhile investments in creating leading-edge titles. So tell it like it is, but don't forget to tell them what they will get out of it. Make them feel comfortable that the experiments will work out well.

Major development tasks: In a paragraph or a few bullet points, make clear the major development tasks. Use language that non-technical people can understand. Major means months of development. Give a time estimate that assumes that you have all of the resources that you'll need to accomplish the task. You could also give an estimate of the resources that you'll need. For example:

"Artificial Intelligence Script Parser: Three to four months with two programmers. The parser reads and compiles the AI scripts into lower-level logic and instructions that are executed at run-time."

Risks: List any technical risks. If you don't foresee any technical risks, by all means say so. Risks are any aspect of research and development that will cause a major set back (weeks or months) if they fail. List technologies that, though they've been proven to work by competitors, your company has never developed or with which your company has little experience. List, for example, real-time strategy if your team has never developed a real-time strategy game before; or 3D rendering if this is your first foray into 3D. List any of the major development tasks mentioned previously if you perceive any risk. All untried off-the-shelf solutions (3D engines, editors, code libraries and APIs, drivers, and so on) should be listed as risks because they may end up not fulfilling your particular needs. Any development done by an outside contractor should also be listed, as that's always a big risk. When assessing risks, you should also indicate the likely impact that fixing or replacing the technology will have on the schedule. Indicate the time in weeks or months that the ship date will slip. List the time impact on specific resources. List any new resources (people, software, hardware, and so on) that would be required to fix it. This section may seem pessimistic, but it creates a comfort level for your document's reviewers - they will come away with the impression that the game implementation is under control, especially if they can perceive these risks themselves. Plus you'll have the opportunity to say, "You can't say I didn't warn you."

Alternatives (if any): Alternatives are suggestions for working around some of these experimental or risky features and major development tasks. By presenting alternatives, you give the reviewers options and let them make the choices. List anything that might cost more money or time than desired but might have better results, or vice versa (it may cost less money and time but it may have less desirable results). Whatever you do, be sure to spell out the pros and cons.

Estimated resources: List the estimated resources: employees, contractors, software, hardware, and so on. Use generic, industry-standard titles for people outside of the company: for instance, the publisher or investor who might read your document. List their time estimates in work months or weeks. Ignore actual costs (dollars), as that comes later.

Estimated Schedule: The schedule is an overall duration of the development cycle followed by milestone estimates, starting with the earliest possible start date, then alpha, beta, and gold master.

Legal analysis (if applicable): If this game involves copyrights, trademarks, licensing agreements, or other contracts that could incur some fees, litigation costs, acknowledgments, or restrictions, then list them here. Don't bother mentioning the necessity of copyrighting the game's title or logo, as these are par for the course and likely to change anyway.

Cost and revenue projections: The cost and revenue projections can be done in conjunction with the finance and purchasing departments. This data should give the reader a rough estimate of resource costs based on the technical analysis's estimated resources.

Resource cost: Resource cost is based on the estimated resources within the technical analysis. Employee costs should be based on salaries and overhead, which the finance or payroll department should provide. You can list these as average by title or level. Any hardware or software that you purchase should be listed as well, even if it will ultimately be shared by other projects or folded into the overhead budget. Use a table or embedded spreadsheet as it is easier to read and edit. For example:

Employee Cost Per Month Work Months Total

2D Artists $4,000 35 $140,000

Lead Artist 7,000 14 98,000

Level Designers 3,000 35 105,000

Total: 343,000

Hardware/Software Price Qty. Total

Graphics Workstations

(PIII 500MHz/256MB/9GB/Voodoo2) $4,200 3 $12,600

3D Studio Max Extended Site License (5-user pack) 3,000 1 3,000

Total: 15,600

Additional costs (if any): This section is an assessment of additional costs incurred from licensing, contracting, out-source testing, and so on.

Suggested Retail Price (SRP): You should recommend a target retail price before your game goes in the bargain bin - pray that it does not. The price should be based on the price of existing games and an assessment of the overall value being built into the product and the money being spent to develop and manufacture it. Of course, your distributors will likely push for a lower sticker price or work some deals to use your game in a promotion that will cut the price even further, but that will all be ironed out later. Keep in mind that the higher the sticker price, the lower your sales, especially in a competitive genre where there's not as much demand as supply.

Revenue projection: The revenue projection should show pessimistic, expected, and optimistic sales figures using the costs that you've already outlined and the suggested retail price. Other factors, such as marketing dollars and company overhead, should be left out of the picture as these are subject to change; if a minimum marketing budget is known, however, then you should certainly factor it in. Often the revenue projection is best represented with a pie chart or a bar chart. Be sure to indicate with an additional wedge or bar the costs incurred from any of the risks described in the technical evaluation and show totals with and without the risk assessment.

Art: If your game concept did not include any art, then the game proposal certainly should. The art should be created by skilled artists. Dispose of or replace any of the art in the concept document that was not created by the artists. The art will set the tone for the game. Assume that the readers may only look at the art to evaluate the proposal, so be sure that it expresses the feel and purpose of the game. Include a number of character, unit, building, and weapon sketches, in both color and black and white. Action shots are great. Include a GUI mock-up if your game is a cockpit simulation. Be sure to have good cover art. Paste some of the art into the pages of the documents, as it helps get your points across and makes the documents look impressive.

Presentation: The whole proposal, including the revised concept document, should be printed on sturdy stock and bound in a fancy report binder along with copies of the art. This document is to be presented to business people - you know, those people who walk around your office wearing fine suits to contrast with the t-shirts and cut-offs that you normally wear. Don't forget that you're proposing a major investment, so make the proposal look good and dress well if you're going to handle the presentation. Preparing a slide show in a program such as Microsoft Persuasion is helpful for pitching your key points and art.

Common Mistakes

Some common mistakes in preparing a game proposal include:

The analysis is based on magic numbers. Try to back up your numbers by listing your sources or explaining how you came up with them. Watching a producer pull some numbers from thin air and throw them in the document is almost laughable.

The proposal is boring. This is a selling document. Don't bore the readers. Give them facts, but make these facts exciting, concise, and convincing.

The proposal fails to anticipate common-sense issues and concerns. You should find out what this proposal is up against -- other proposals, competitive products, financing concerns, cost and time expectations, game prejudices, and historical mishaps. Your proposal will stand a much better chance of being approved if it addresses these issues preemptively rather than getting besieged by them during the review process.

The proposal writer is overly sensitive to criticism. My experience might be unique, but don't be surprised if the major promoter for your game proposal decides to play devil's advocate. Make sure your proposal is solid. Believe in it and remain confident, and you'll weather the criticism and make believers out of those reviewing your proposal.

The proposal writer is inflexible to changes to the game. Often during the process of gathering research or receiving criticism from the review committee, some reasonable suggestions will arise for changing or scaling back the design. Game development is a collaborative process. Take the feedback and change the design, or the game could die right there. The key word here, as tattooed on the arm of my buddy who served in the Vietnam War, is transmute. He had to transmute to stay alive and keep going, and your game idea may have to do the same.

This concludes part one of a two-part series on the anatomy of a design document. In the next part, I'll taunt you with some more colorful metaphors interspersed with some useful guidelines for creating functional and technical specifications and level-design documents. I'll also give you an overview of the document review process and how it facilitates the game development cycle.