Jump to content

  • Log In with Google      Sign In   
  • Create Account


Design:Development Ratio - What's your orientation?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
30 replies to this topic

Poll: Design/Planning or Development/Implementation Oriented (53 member(s) have cast votes)

Do you spend more time designing a concept or trying to make it?

  1. Designing. I rather plan stuff out extensively before attempting to create and test it. (17 votes [32.08%] - View)

    Percentage of vote: 32.08%

  2. Creating it. I rather have something to work with while I think of ways to improve and develop it. (36 votes [67.92%] - View)

    Percentage of vote: 67.92%

Do you see Designing and Development as two different things?

  1. Yes, Designing isn't required when developing. (1 votes [1.79%] - View)

    Percentage of vote: 1.79%

  2. Yes, but designing is a part of developing. (45 votes [80.36%] - View)

    Percentage of vote: 80.36%

  3. No, they are both one and the same. (10 votes [17.86%] - View)

    Percentage of vote: 17.86%

What is prototyping to you?

  1. Making a playable demo of my idea, feature, or concept. (37 votes [69.81%] - View)

    Percentage of vote: 69.81%

  2. Sketching/Writing plans, notes and ideas. (2 votes [3.77%] - View)

    Percentage of vote: 3.77%

  3. All of the above and then some. (14 votes [26.42%] - View)

    Percentage of vote: 26.42%

Vote Guests cannot vote

#1 SinisterPride   Members   -  Reputation: 210

Like
2Likes
Like

Posted 28 January 2013 - 09:52 AM

To continue the discussion in my first thread (hopefully more productively this time) I'd like to get your opinions/methods for starting and following through with a project seeing as they're are plenty of ways which lead to the same outcome. Some methods have advantages over others but when given the right circumstances, all realistic and proper routes lead to the same goal. Creating a game and finishing/entirely developing it.

 

My question is: How much do YOU design/plan when you set out to develop something?

 

There comes a point where we reach the extent of what the human mind can process accurately with only theory and design. However, not everyone has the same marker/limitation for that extent. My acute spatial and detail centered memory (I've been tested, Its borderline savantism) has allowed me to reach a level of design in my mind that not all can process or comprehend unless explained in detail through diagram/prototypes and demos. 

 

I am a one man team. Being so I don't have a deadline/time constraint. Not having a deadline nor feeling the need to rush into a pure development sense has allowed me to reach that inevitable point in almost each concept, mechanic and general design where theorizing just won't cut it. If I were to become a part of a team where I am now expecting people to put in their own time, then yes I would consider time restraints and how to most effectively manage their time. 

 

When I reach that point where theorizing just wont cut it, I consider my design 75% complete. The other 25% is only attainable through means of testing and developing. I consider my design(s) (not the entire project or mechanic/feature even) to be near its end basically when I'm prepared to test and develop. At this point, I would only consider a mechanic/feature to be 15-20% complete at MOST. The design process isn't complete in my mind until the project or mechanic/feature is itself atleast 50% complete and has a working model that proves its theory and functionality/feasibility.

 



Sponsor:

#2 Got_Rhythm   Members   -  Reputation: 239

Like
4Likes
Like

Posted 28 January 2013 - 11:06 AM

I find I am most successful in creative projects when I can get a complete concept in a very short space of time (if a concept develops over a week, for me it ends up being less cohesive and more disjointed). Either mentally or on paper.

After that I design and develop at the same time. Mainly because game development is relatively new to me, so I am not aware of all the technical limitations of software and the limitations of my own skills.

So if I design a monster in my mind or on paper, and then I am unable to achieve the look I want in photoshop or other digital medium, I have to go back a step and redesign, which creates double work (which irritates me because I love efficiency). So for my skill level it makes sense to design at the same time as developing, because I am learning so much all the time which effects everything I do as I am doing it.

#3 SinisterPride   Members   -  Reputation: 210

Like
0Likes
Like

Posted 28 January 2013 - 11:10 AM

I find I am most successful in creative projects when I can get a complete concept in a very short space of time Either mentally or on paper.

game development is relatively new to me, so I am not aware if all the technical limitations of software and the limitations of my own skills.

So for my skill level it makes sense to design at the same time as developing, because I am learning so much all the time which effects everything I do as I am doing it.

 

Great/Valid points and angles/perspectives. Thank you for being the first to post smile.png 


Edited by SinisterPride, 28 January 2013 - 11:11 AM.


#4 thade   Members   -  Reputation: 1652

Like
3Likes
Like

Posted 28 January 2013 - 11:35 AM

My approach is one of a hobbyist who works in software (but not for the gaming industry). I play a lot of games, read and watch a lot of game reviews with a bent on game design (Angry Joe, Total Biscuit, Errant Signal and Spoony Experiment are especially good, the list goes on.) I do everything I can to keep up on the topic of game development because it fascinates me. I am designing a game currently. Here's my path of attack:

 

First, the dream: what kind of game do I want to make? What are the core elements of game play? What sets this game apart from others like it?

 

Next, I figure out the requirement set as completely as I can: what does the software need to do? Each requirement needs to be clearly defined. If, for instance, I want my game to feature turn-based tactical combat (e.g. XCOM, Fallout, Final Fantasy Tactics) then my game will need a system devoted to that: a map system (the "game board"), what kinds of effects the actors can have on one another (inflict damage, status effects, etc), etc. Naturally, each of these things requires a great deal more meat. For status effects to have meaning, each actor could have a suite of statistics that have real effects on game mechanics; for instance, a Speed trait that delineates how often an actor can act in a turn.

 

Next, I have a lot of reading to do. I've played a lot of games like this, but I want to have a really firm grasp on why certain decisions are made in games like this. Why, for instance, did Fallout 1 use a hex grid for the game board while the more modern game XCOM chose to use squares? Was the decision arbitrary? Technical constraints? Was it more fun? (I can see XCOM's cover/flanking mechanics being very hard to implement convincingly and teach to players on a hex grid; by contrast, very intuitive with squares.) The 'why' is very important, and helpful if the answer can be found. Sites like gamedev, Gamasutra, etc. might get me some answers. Google and Youtube help. (Fortunately I enjoy watching interviews with Jake Solomon and Sid Meier.)

 

Once I have a rough idea for mechanics that I think might be interesting, maybe I can play with the game on paper: actually throw down a mat with hexes or squares on a grid, get out some minis and some dice, and play my game. Is it fun? I'll get some friends to play it with me; we all play a lot of games like Warhammer, DnD, Warmachine, etc. So there's a lot of experience to tap there.

 

Next, I need to get a prototype up as fast as I can. This will both help me to further explore the "What's fun?" question and, equally importantly, it'll start revealing to me technical considerations I need to have in mind. Maybe "tearing huge hunks of the game board up and throwing it at enemies" would be super fun, but 1. what kind of in-game effects on balance and fun would it really have and 2. how big of a pain will it be to implement, troubleshoot, etc. I am a one man team. "Write games, not tools" is the mantra, but it can only go so far. I want my game to have an Interplay-style conversation system and the tools out there to accomplish that really don't do what I need and would take a lot of work to shoe-horn in...so at times I find myself doing lots of research and building tools to fill in the gaps. (Good thing that can be fun.) What kind of tools do I need for the job? That starts happening now.

 

All of this goes into the composition of the design document. When I finally have a design document for people to read, I'll start sharing it with friends and colleagues for feedback...and maybe see if I can generate interest in some help.

 

Pure design is only the first leg on a very long journey. Once I get into code and start really building things, I start to see what kinds of things work, what kinds of things are needed, and what kinds of things are time prohibitive, just not doable, or just not fun. There are most definitely going to be design level changes after implementation...it's so sure a thing that I don't want to tie myself up too deeply in pure design before taking it to the shop, as it were. XCOM: Enemy Unknown has a brilliant design (as it should, since it was scrapped and redone three or four times over it's dev cycle) but shipped with a tremendous number of game-breaking bugs (because they essentially had 30% of the time they planned for development to actually develop it)...and all of that was true while they were playing with prototypes and reusing code. The sooner you get an idea into a real, breathing machine, the better.


Edited by thade, 28 January 2013 - 03:02 PM.

I was previously serratemplar; a name I forfeited to share a name with an angry rank-bearing monkey.

http://thadeshammer.wordpress.com/


#5 SinisterPride   Members   -  Reputation: 210

Like
0Likes
Like

Posted 28 January 2013 - 12:06 PM

Thank you for posting such a detailed process of your approach Thade biggrin.png Vote ! I wanna get that poll as juicy as possible so I can hopefully show the opinions in peoples approaches lol



#6 SimonForsman   Crossbones+   -  Reputation: 5770

Like
1Likes
Like

Posted 28 January 2013 - 12:26 PM

I start writing code pretty much as soon as i get an idea and just document things as i go if it becomes necessary, all my serious designs are based around a single core mechanic and don't require much in terms of planning (Imo a solid core mechanic and lots of polish is all you need to make a great game, if the core mechanic requires a set of complex supporting mechanics to be fun then it will most likely be too timeconsuming/expensive to turn into a properly polished game)

That said though, i have tons of ideas for large complex games, but i don't bother fleshing them out and putting them on paper since i would have to win the lottery to be able to afford spending the time required to keep up with technology while developing the game.

Edited by SimonForsman, 28 January 2013 - 12:29 PM.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#7 SinisterPride   Members   -  Reputation: 210

Like
0Likes
Like

Posted 28 January 2013 - 12:32 PM

I like and agree with these statements/concepts:

 

all my serious designs are based around a single core mechanic

 

Imo a solid core mechanic and lots of polish is all you need to make a great game

 

I disagree with this however:

 

if the core mechanic requires a set of complex supporting mechanics to be fun then it will most likely be too timeconsuming/expensive to turn into a properly polished game

 
From whos perspective are we talking here? Yours? Lone deisgner/developer/indie crew? In general?

Edited by SinisterPride, 28 January 2013 - 12:33 PM.


#8 Waterlimon   Crossbones+   -  Reputation: 2361

Like
1Likes
Like

Posted 28 January 2013 - 12:42 PM

As i dont have much practical experience with c++ yet, i tend to:
1.Design system that is able to do everything required
2.Implement (or start to)
3.Fix design to make it simpler, cleaner and.more flexible
4.Reimplement/modify based on new fixed design

Though i dont make the details perfect (like optimization unless its relatively easy and i know exactly how to), just trying to get the overall design work.

Waterlimon (imagine this is handwritten please)


#9 SimonForsman   Crossbones+   -  Reputation: 5770

Like
0Likes
Like

Posted 28 January 2013 - 01:09 PM

SinisterPride, on 28 Jan 2013 - 19:31, said:
From whos perspective are we talking here? Yours? Lone deisgner/developer/indie crew? In general?

its from my perspective. (The OP asked for our perspectives), Basically i'm a professional programmer (not in the games industry), on the game project i work with my boss and we don't really have that much time to spend on a project that isn't guaranteed to bring in enough money to make up for the time spent (So we do it in our spare time when we're not too tired).
I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#10 thade   Members   -  Reputation: 1652

Like
1Likes
Like

Posted 28 January 2013 - 01:38 PM

I think SimonForsman's thesis is an important one to keep in mind; complex mechanics are not what makes a game fun...game play is. The mechanics that support the game play should only be as complicated as the game play requires; this is especially true if the supporting mechanics are visible to the player.

 

As it has been lately, XCOM: Enemy Unknown will serve as my example. The game's shooting mechanics are based on true line-of-sight: if a model cannot see a target due to world geometry or fog-of-war blocking that sight line, the model cannot fire on the target. (Explosives are the exception, but let's eschew that for our purpose here.) In one of the early builds of game, the player could see everybody's fire arcs (showing specifically what they could see) in different colors, and the colors would merge together when the firing arcs overlapped. You could see enemy firing arcs as well. The idea was that it would help the player in planning out unit placement; the reality was that it made the playing field incredibly cluttered and tiring to look at. Less complex design made for more solid game play.

 

Additionally, simpler design lends to being intuitive for players to learn, which is a very desirable trait for your game to have.


I was previously serratemplar; a name I forfeited to share a name with an angry rank-bearing monkey.

http://thadeshammer.wordpress.com/


#11 SinisterPride   Members   -  Reputation: 210

Like
0Likes
Like

Posted 28 January 2013 - 02:25 PM

The mechanics that support the game play should only be as complicated as the game play requires; this is especially true if the supporting mechanics are visible to the player.

Simpler design lends to being intuitive for players to learn, which is a very desirable trait for your game to have.

complex mechanics are not what makes a game fun...game play is.

 

Agreed, great example and good use of available input.


Edited by SinisterPride, 28 January 2013 - 02:40 PM.


#12 sunandshadow   Moderators   -  Reputation: 4579

Like
0Likes
Like

Posted 28 January 2013 - 02:52 PM

In novel-writer land a poll equivalent to the top question is a pretty common topic.  The responses seem to be about 40 : 60 (people who plan before writing : people who start writing and do any planning during writing or revising)


I want to help design a "sandpark" MMO. Optional interactive story with quests and deeply characterized NPCs, plus sandbox elements like player-craftable housing and lots of other crafting. If you are starting a design of this type, please PM me.

#13 WavyVirus   Members   -  Reputation: 735

Like
2Likes
Like

Posted 28 January 2013 - 05:04 PM

I feel like the poll didn't allow be to answer one of the questions accurately:

 

What is prototyping to you?


The actual nature of the prototype depends on the subject. Typically, the first prototype will be completely minimalistic - the lowest-fidelity representation of the system which still allows it to be experimented with in a way which will transfer meaningfully to the final system.

If I have an idea for a control scheme, weapon/skill, AI behavior or something of that nature, the minimal prototype may be something interactive created with a scripting language. I will no doubt be using terrible placeholder art - stick figures, stolen sprites (non-animated) or boxy models.

An idea for a graphical effect may be testable in Photoshop. I've tested ideas for shader-based effects using a scripting language like Python. The prototype may not even run in real time, but it allows me to gauge the results and play around with ideas more easily and in a more productive environment.

On the other hand, it may be possible to effectively play around with the idea using a few improvised props (bits of paper, game pieces etc). Turn-based battle system? Play with a friend on paper.

In fact some systems are very nebulous, and a typical interactive prototype may not make much sense. A skill or development system, for example, generally works in terms of abstract inputs - the player kills an enemy of level X, the player spends Y points on a stat, the player casts a spell Z times etc. To build a representative prototype of this might require you to implement shallow versions of all sorts of related systems such as combat, movement, casting and so on, simply to provide input to the system you are actually trying to experiment with. Suppose you want to estimate the rate of player growth or damage against enemies of various levels resulting from a particular character development system you have in mind - does it make sense to spend hours artificially grinding away in an interactive prototype? At this point you're probably better off using a spreadsheet! (After all, that is how the most obsessive players will be calculating their optimal builds anyway...). Of course, this is still a system you'll want to playtest, tweak and balance once the related systems (combat, casting etc) are actually implemented and you can put it in its proper context.

Finally, prototyping a game may not be the same thing as prototyping a single system or mechanic. Generally, my actual approach to beginning design / development of game is more like the following:

  • Have an idea. Make notes. Over a short period of time, I will begin to develop a broad vision of what the game will consist of. Keep a notebook and continue to make notes of new ideas in off-time throughout the following steps
  • Prototype the core mechanics. Often this consists of basic control / combat, implemented with placeholder art in Python. Play around with it. If it's engaging, consider going further with the idea. I believe that the very act of interacting with a game or controlling your character should be satisfying
  • Create a "playground" area. Usually hacked together with what I expect to be the final development language. For a side-scrolling platformer, first create a character floating in thin air. Then add basic movement. Then perhaps a floor. Then a box to climb on to. Then walls. Then maybe a simple enemy, etc, etc... Basically, populate this test area with new game entities as you create them, to provide an accessible way to play with them
  • More brainstorming of specific mechanics / abilities. As I now have my playground area, I can often prototype these ideas with minimal effort
  • Think more seriously about the world, the mood of the game, its setting, the people / factions involved, what messages I want to get across etc. I've usually had some sort of vision for this in my mind since the beginning of the process, but now begin to build it around the gameplay in a meaningful way. New factions may give me ideas for new game mechanics, and vice versa
  • Clean up the code. Some sort of save/load is usually implemented at this point, which allows the playground world to become one of several test worlds or mockups of planned scenarios

 

For example in my current game (a space shooter), I decided that I wanted some kind of robot faction. Thinking about this led me to the idea of networked swarms of ships. I knew about flocking/swarming AI, so tried that out in my playground area, using a spreadsheet to help me come up with reasonable initial parameters for the algorithm. It looked pretty cool, but then I considered the possibility of the robots spontaneously splitting/joining/reassembling with nearby teammates in flight. This turned out to be very interesting when prototyped, and actually added some more strategy to the combat. This splitting/merging mechanic was born out of a combination of thinking about the lore (how such a robotic race might work using self-assembling nano-robots) and playing with the earlier prototype of basic flocking behavior.



#14 Legendre   Members   -  Reputation: 963

Like
4Likes
Like

Posted 28 January 2013 - 05:45 PM

In my humble opinion, "design vs development" is quite a false dichotomy. The actual process is more like this...

Step 1 - Ideas Generation

This is the "fun'' part of making games. Often mistaken for "design" (Tom Sloper Lesson 14). I dream of different game ideas, stories and mechanics. I used to write a lot of details out on paper but don't do it anymore because I keep having to make major changes or drop nonviable ideas.

Step 2 - Prototype

This is one of the "hard" parts. I pick an idea from step 1 and test/prototype to see if it is viable or works like I imagined. I had to go back to step 1 several times when my idea turned out to be not viable or not what I expected (which is why I stopped wasting too much time writing extensive details in step 1 without testing). The prototypes/tests are never "playable demos". They are often not playable implementations for my own use only.

Step 3 - Develop

Step 2 tests which ideas are viable and which technologies (programming languages, engines etc) to use. Once that is done, its time to actually make the game. This is another one of the "hard" parts.

Sometimes I have to do "heavy" development. E.g. I recently had to write a node.js web server from scratch for my multiplayer game. But this is always done with the design of the game in mind. There is no "generic" web server or engine that programmers churn out from a fixed blue print. The design is deeply intertwined with the programming. After that, I switch to developing the client-side or "front-end" while at the same time, adding complementary features to the server-side or "back-end". Once again, the game's design is so deeply intertwined with this process: I have to test what works and what is doable, then edit my game's mechanics and story accordingly.

Conclusion

Each of the 3 steps both requires "design" and is influence by "design". I am not sure if it is possible to separate "design" out into a standalone activity.

Edited by Legendre, 28 January 2013 - 05:50 PM.


#15 NoAdmiral   Members   -  Reputation: 503

Like
2Likes
Like

Posted 28 January 2013 - 09:49 PM

I try to spend as little time in design-mode as possible.

 

That's not to say that I don't like design or engage in it, but I definitely focus on development, and I go through a ton of iterations of whatever game I'm making. I'd rather not spend too much time thinking about how to implement a mechanic or an idea that I ultimately can't find a good place for, and thus wind up crowbar-ing it into my design (which so rarely makes for a good gaming experience); and so I prototype almost constantly. As I figure out which mechanics work with each other and fit the overall feel of my game, I implement them.

 

I should note that I've learned not to get attached to any of my ideas--I've thus far tossed out (or put on-the-back-burner) more mechanics than I've implemented (and been satisfied with).


Inspiration from my tea:

"Never wish life were easier. Wish that you were better" -Jim Rohn

 

herwrathmustbedragons.tumblr.com


#16 SweetyS   Members   -  Reputation: 173

Like
1Likes
Like

Posted 31 January 2013 - 11:32 PM

When I think about a game concept I get vast ideas because of my study in game reviews, playing games, observing some techniques and even reading stories. But when we make a very creative  and vast concept there comes the limitation of coading.

So just thinking most crative things and idea leads to waste of time because finally you have to design your game under the limits of codes.

 

Hope designers will agree on this point.



#17 SinisterPride   Members   -  Reputation: 210

Like
0Likes
Like

Posted 02 February 2013 - 12:20 AM

@SweetyS: As I've said before, I don't consider myself a game designer or developer. These titles entail more than I find myself worthy of being called even if I may possess some (if not most) of the skills encompassed by both.
 
I too have plenty of experience and knowledge due to many sources of exposure. Thanks to these sources I have a rich understanding of the current technical limitation and capabilities of the gaming industry.  I have a strong sense of the techniques applied in both design and development. I've also been a gamer for as long as I can remember (picked up a nintendo controller and played well enough at the age of 2).
 
This means I have plenty of experience in reviewing/critiquing video games from a technical side as well as a fan/gamer.
 
In my opinion, your concept is only limited by your understanding of current technology. Knowing what's plausible is the only way of reaching, conceiving and surpassing the current "limitations".
 
As I said, I do not consider myself a designer so my opinion on the topic can be taken at face value if regarded at all.
 
As some have mentioned, the process of planning before implementing can lead to a waste of time when your vision does not pan out as expected. Even more so when your skill does not match your creativity.
 
I strongly believe in all my actions and plans having inherent plasticity. This leads back to (once again) my martial arts training.
 
During training, the ultimate defining quality in our skill level was our ability to adapt. An advanced practitioner using the same techniques as a novice was often exposed by their ability to apply those techniques fluidly and effectively to any situation presented by the novice.
 
This approach is the same I apply when it comes to design. I've seen and know what's capable in the industry so I never think in a linear format. If "mechanic A" doesn't work with "implementation plan A" then "implementation plan B" is less of a reach (and inherently less creative/innovative) and will most likely work beacause it has already been done before. My concepts would only be a plausible step within or away from what I've seen done and what I know we're capable of, given the current technology.


#18 Morphia   Banned   -  Reputation: 99

Like
-1Likes
Like

Posted 02 February 2013 - 07:15 AM

I think that every Design begins with a better video-demo ,
which will show the Idea and Vision of the Chess Field.

As of right now to think about KickStater.com :
who have Amazon account - USA and UK (I with UA)

Assassin Creed because the team of about 700 people,
so Space is better, because that requires less people in development,
but Need more Intelligence and AI for NPC too .

Twin Shadow Interface

Cancel Button of 3D Voice

Edited by Morphia, 02 February 2013 - 07:20 AM.

Game Interface Manager ^|^ Deep Space Engineering

#19 SinisterPride   Members   -  Reputation: 210

Like
0Likes
Like

Posted 03 February 2013 - 04:45 AM

@Morphia: I honestly didn't fully understand what you said but I did my best to dissect and reply to it.
 

I think that every Design begins with a better video-demo ,
which will show the Idea and Vision of the Chess Field.

 

Again, I disagree with this approach due to my fundamental approach to design/development. I know I am among the minority who believe in a design heavy/design oriented foundation.

I do NOT feel a proper design begins with a "video-demo". I begin with sketch and written prototypes which won't go post that until I feel I have enough down to get ready to develop the mechanics and features. I'm usually very thorough and detailed which works just fine fire me.
 

Idea and Vision of the Chess Field.

 

I'm assuming you're equating a design/project to chess. Meaning a video demo is a good way of showing the scope and range of your design/project. I agree, it is just not for me and doesn't work out with my way of processing things mentally or physically.

 

As of right now to think about KickStater.com :
who have Amazon account - USA and UK (I with UA)

 

I'm not entirely sure what you meant to say by this.

- You're with Ubisoft North America?
-AC3 has a "video-demo" on kickstarter?

That's great, I'd be honored/amazed to work for such a well established company. I hope the project goes well?

Cool, I've been meaning to give kickstarter a visit. I may have a reason to, now that I'm curious about the way ubisoft may have laid or their proposal.
 

Assassin Creed because the team of about 700 people,
so Space is better, because that requires less people in development,
but Need more Intelligence and AI for NPC too .

 

Space as in the larger team quantity works out best considering what they are undertaking?

 

More specifically:

 

Assassin Creed because the team of about 700 people

 

I disagree once again. There is an article on UE4 in GameInformer (Start Your Engines: Introducing Unreal Engine 4) which states my opinion on why bigger teams in the industry are a waste.

 

It leads back to my comments on efficiency:

My stand

 

because that requires less people in development,

but Need more Intelligence and AI for NPC too .

 

What requires less people in development?

I can see how a dedicated team for AI would benefit a project (if you can afford that kinda stuff, which I'm sure if anyone could, it'd be Ubisoft lol). However, I still don't think it justifies a team of such magnitude.


Edited by SinisterPride, 03 February 2013 - 06:49 AM.


#20 Morphia   Banned   -  Reputation: 99

Like
1Likes
Like

Posted 04 February 2013 - 06:00 AM

SinisterPride :

I think you are trying to gradually understand me!
Vision of Gameplay as the ChessBoard: it is soonely the word-revolver.
I know people who from UbiSoft , but I did not say that I work in UbiSoft.
That is, you did not watch the video - you, like most of the other all the same, or more then one computer bots (programs), because of your text is not true. And I said that we needed to account for AmazonPayments for Kickstater.com, well, where does UbiSoft - unless you understanding, I would say that I am Freelancer - Independent Manager (yes GameDevIndustry modern companies - just a "modern trash"). In translation: better to act. Will Write one hundred thousand Theme than those in the text and a Zero Result in the End. In EpiEnd none GameProduct and none Money : eating text or other it ?!

What was done on GameDev.net or GameDev.ru : nothing .. tell me again of Orientation of this Forums .

Edited by Morphia, 04 February 2013 - 06:05 AM.

Game Interface Manager ^|^ Deep Space Engineering




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS