Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualthade

Posted 28 January 2013 - 03:02 PM

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.


#4thade

Posted 28 January 2013 - 11:37 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 has 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.


#3thade

Posted 28 January 2013 - 11:37 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 has 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.


#2thade

Posted 28 January 2013 - 11:36 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 has 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.


#1thade

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 has 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.


PARTNERS