Plan for Paul Dana
by Paul Dana · 09/23/2005 (10:15 pm) · 13 comments
Long Strange Trip, Part 3: Boys Go Wild
This is part 3 in a series of blogs that documents the wonderous journey of Jason Sharp, Paul Dana, and Kirk Alberts as we learned the hard way how not to make games. Part One is here
We last left you, dear reader, at the end of Part Two. I had finished a prototype of my game and had Joe Maruschak play it and gave me feedback. Also at this time Jason Sharp and Kirk Alberts were inspired by my Droids prototype to join me. Plastic Games was born!
Our Logo
We had Joe's feedback, which was:
1. Instant Death is nerve racking and somewhat hard to understand experience...why did I just die?...might want to add health.
2. 5 degree of freedom flight model is very difficult. Consder abandoning it. At the very least the flight model should be your focus until you get it right.
3. Landing the ship feels awkward...how about just flying by to grab Droids?
4. Write a mission statement...Identify your target audience and make decisions on what is right for your game by always going back to that mission statement. He cited his mission statement for Think Tanks: A cartoony tank game for former fraggers who don't have very much time in their life anymore but who would enjoy a simple online fighting game where it's quick to get into the game and quick to finish a map.
Jason would do modeling and animation, Kirk would gui/hud/concept/texture/terrains, and I would do coding. Jason and Kirk already knew how to get art into the Torque Game Engine. We were all set! We were ready to continue our prototyping. One month later we had a new version. You can
download this 8-May-2003 prototype of Droids right now and try it yourself.
By this point we had decided that this remake of Oids would happen inside a computer. Instead of "robots" you would be saving "Bits" (they would still look like robots)...the more you save the less data loss, right? Get it? We called the ship the S. S. Scandisc and we envisioned saving Bits being like saving data inside a computer. When we told Joe of this theme he suggested the name Bit Shifter.
Our First Brilliant Move
A Spiffy new ship model and a "chip" model for Bit Prison
Our first priority should have been addressing the flight model...so instead we made the ship look much cooler. How could we resist? I had this fugly flying UFO donut. We needed a ship that looked like it could fly the way the UFO dounut could fly.
Well...no we really didn't. What we really needed was to work on the flight model and improve it, possibly abandon it altogether. After that was done we could make a ship to match the flight model. Sure...but...but isn't that ship much cooler?
While we were making new models heck we would make a new model for the Bit prisons. Computer chips are found inside computers...let's use that!
Our Second Brilliant Move
A Giant Magnet that pulled you to your death!
Instead of address basic issues we instead had an orgy of putting content into the game. We were "cloning" Oids, a 2D arcade game, and so I suppose we figured that if we just put in enough content the game would be fun. Instead of playing the game we had and fixing and adressing the game we had...we constantly thought instead about the game we were about to build. We continued with the plan that the gameplay is already decided...it's Oids in 3D. Therefore we simply needed to translate the elements of the 2D game into our game and, presto! Fun! Right?
Not so much.
We reasoned: The original game had Grav Pods that pulled you in and Repulsors that pushed you away. We translated that to our in-a-computer theme and said, OK: Our game will have Magnets to pull you and Case Fans to push you.
A Giant Case fan that tracked you and pushed you
Now this was cool!
The Brilliant Moves Just Keep Coming
Only one month elapsed from when Jason and Kirk joined me to the version of the prototyp you can d/l and play yourself and that produced the screenshots your looking at. We had never worked as a team before and none of us had all that
much experience with the Torque art pipeline. And yet we were able to get all the game elements into the game that you see here in that time. And this is not just static models. Each of these models has animations and sounds:
The case fan would track you and push you away
This was quite an accomplishment. I had already created the Turret Resource that I am generally known for and there were AI Turrets in the game when Jason and Kirk joined me. That took an entire new C++ class to make work, but this Fan is animated in script only! I made a few small changes to the script animation functions, mostly just exposing to script animation thread code normally only callable from C++. Beyond that the rest was done in script.
And the turn around time was insane! In this same month not only did we make the new ship model, the chip prison, the magnet and the fan. The original game Oids also had "fuel pods". You would land next to them. A little "gas hose" sort of deal stuck out and refuled your ship. Kirk made an awesome piece of concept art that lead to this game model:
The Zapper that refueled you
How f***ing cool is that?
Again this is a fully animated model that works in game, also done almost entirely in script. Notice the cool lightning effect across those electro rods. Once you land on the pad needing fuel, the arm comes down and your ship gets hit with lighting. As the lightning fires your ships fuel goes up. The needle indicators on the zapper slowly drain. Once your ship is full the arm retracts. If the zapper has been drained of its energy then the cool lightning effect across the rods would stop and of course the needles would read zero.
The Zapper had some bitchin detail
We Were Gods
We were drunk with power by this point. We were astounded by our own brilliance; and it was quite a technical achievement. We were so astounded, in fact, that it blinded us to the reality that we were not actually making progress. It sure felt like progress. After all...look at the number of features that we got into the game in such a short time! But...consider this: The Magnet, the Bit Prisons, The Fan, and the Zapper do not appear in the current version of the game!
And we were not even done putting stuff into the game! Just like Oids, we added a Missle Dome that would crack open when you got near and emit a Seeking Missle that would come and getcha!
Watch out for the seeking missle!
Conclusion
We added a lot of contant. We went wild. We assumed adding content would magically make the game fun. It didn't. It just muddied the waters more and more. As time went by I started to realize that fighting the muddy waters is a major challenge when designing games.
Deciding what to put in the game is hard. Deciding what to take out is hard. Dealing with a muddy game design that already has too much in there is even harder still.
This is one of the main reasons whey there is a certain order to do things in: start with the control scheme of the "main character", in our case a space ship. Build only enough of the game to test the control scheme. Make sure it is tight.
Next move onto the camera...as many things about the camera heavily influence the players perception of the "main character" being controlled.
You continue with this process, iteratively improving the game in such away that it muddies the waters less and less, rather than more and more.
These are lessons I learned the hard way.
Well...that is all for now. Be sure to tune in next time for Part 4 in the series: Burnt Down, Fell Over, And Then Sank In The Swamp.
This is part 3 in a series of blogs that documents the wonderous journey of Jason Sharp, Paul Dana, and Kirk Alberts as we learned the hard way how not to make games. Part One is here
We last left you, dear reader, at the end of Part Two. I had finished a prototype of my game and had Joe Maruschak play it and gave me feedback. Also at this time Jason Sharp and Kirk Alberts were inspired by my Droids prototype to join me. Plastic Games was born!
Our LogoWe had Joe's feedback, which was:
1. Instant Death is nerve racking and somewhat hard to understand experience...why did I just die?...might want to add health.
2. 5 degree of freedom flight model is very difficult. Consder abandoning it. At the very least the flight model should be your focus until you get it right.
3. Landing the ship feels awkward...how about just flying by to grab Droids?
4. Write a mission statement...Identify your target audience and make decisions on what is right for your game by always going back to that mission statement. He cited his mission statement for Think Tanks: A cartoony tank game for former fraggers who don't have very much time in their life anymore but who would enjoy a simple online fighting game where it's quick to get into the game and quick to finish a map.
Jason would do modeling and animation, Kirk would gui/hud/concept/texture/terrains, and I would do coding. Jason and Kirk already knew how to get art into the Torque Game Engine. We were all set! We were ready to continue our prototyping. One month later we had a new version. You can
download this 8-May-2003 prototype of Droids right now and try it yourself.
By this point we had decided that this remake of Oids would happen inside a computer. Instead of "robots" you would be saving "Bits" (they would still look like robots)...the more you save the less data loss, right? Get it? We called the ship the S. S. Scandisc and we envisioned saving Bits being like saving data inside a computer. When we told Joe of this theme he suggested the name Bit Shifter.
Our First Brilliant Move
A Spiffy new ship model and a "chip" model for Bit PrisonOur first priority should have been addressing the flight model...so instead we made the ship look much cooler. How could we resist? I had this fugly flying UFO donut. We needed a ship that looked like it could fly the way the UFO dounut could fly.
Well...no we really didn't. What we really needed was to work on the flight model and improve it, possibly abandon it altogether. After that was done we could make a ship to match the flight model. Sure...but...but isn't that ship much cooler?
While we were making new models heck we would make a new model for the Bit prisons. Computer chips are found inside computers...let's use that!
Our Second Brilliant Move
A Giant Magnet that pulled you to your death!Instead of address basic issues we instead had an orgy of putting content into the game. We were "cloning" Oids, a 2D arcade game, and so I suppose we figured that if we just put in enough content the game would be fun. Instead of playing the game we had and fixing and adressing the game we had...we constantly thought instead about the game we were about to build. We continued with the plan that the gameplay is already decided...it's Oids in 3D. Therefore we simply needed to translate the elements of the 2D game into our game and, presto! Fun! Right?
Not so much.
We reasoned: The original game had Grav Pods that pulled you in and Repulsors that pushed you away. We translated that to our in-a-computer theme and said, OK: Our game will have Magnets to pull you and Case Fans to push you.
A Giant Case fan that tracked you and pushed youNow this was cool!
The Brilliant Moves Just Keep Coming
Only one month elapsed from when Jason and Kirk joined me to the version of the prototyp you can d/l and play yourself and that produced the screenshots your looking at. We had never worked as a team before and none of us had all that
much experience with the Torque art pipeline. And yet we were able to get all the game elements into the game that you see here in that time. And this is not just static models. Each of these models has animations and sounds:
The case fan would track you and push you awayThis was quite an accomplishment. I had already created the Turret Resource that I am generally known for and there were AI Turrets in the game when Jason and Kirk joined me. That took an entire new C++ class to make work, but this Fan is animated in script only! I made a few small changes to the script animation functions, mostly just exposing to script animation thread code normally only callable from C++. Beyond that the rest was done in script.
And the turn around time was insane! In this same month not only did we make the new ship model, the chip prison, the magnet and the fan. The original game Oids also had "fuel pods". You would land next to them. A little "gas hose" sort of deal stuck out and refuled your ship. Kirk made an awesome piece of concept art that lead to this game model:
The Zapper that refueled youHow f***ing cool is that?
Again this is a fully animated model that works in game, also done almost entirely in script. Notice the cool lightning effect across those electro rods. Once you land on the pad needing fuel, the arm comes down and your ship gets hit with lighting. As the lightning fires your ships fuel goes up. The needle indicators on the zapper slowly drain. Once your ship is full the arm retracts. If the zapper has been drained of its energy then the cool lightning effect across the rods would stop and of course the needles would read zero.
The Zapper had some bitchin detail We Were Gods
We were drunk with power by this point. We were astounded by our own brilliance; and it was quite a technical achievement. We were so astounded, in fact, that it blinded us to the reality that we were not actually making progress. It sure felt like progress. After all...look at the number of features that we got into the game in such a short time! But...consider this: The Magnet, the Bit Prisons, The Fan, and the Zapper do not appear in the current version of the game!
And we were not even done putting stuff into the game! Just like Oids, we added a Missle Dome that would crack open when you got near and emit a Seeking Missle that would come and getcha!
Watch out for the seeking missle!Conclusion
We added a lot of contant. We went wild. We assumed adding content would magically make the game fun. It didn't. It just muddied the waters more and more. As time went by I started to realize that fighting the muddy waters is a major challenge when designing games.
Deciding what to put in the game is hard. Deciding what to take out is hard. Dealing with a muddy game design that already has too much in there is even harder still.
This is one of the main reasons whey there is a certain order to do things in: start with the control scheme of the "main character", in our case a space ship. Build only enough of the game to test the control scheme. Make sure it is tight.
Next move onto the camera...as many things about the camera heavily influence the players perception of the "main character" being controlled.
You continue with this process, iteratively improving the game in such away that it muddies the waters less and less, rather than more and more.
These are lessons I learned the hard way.
Well...that is all for now. Be sure to tune in next time for Part 4 in the series: Burnt Down, Fell Over, And Then Sank In The Swamp.
#2
09/23/2005 (10:38 pm)
Awesome post Paul, there's some crap in there that I never knew it used to exist in FB :)
#3
Good work :)
09/23/2005 (10:40 pm)
Paul, your .plans are always a pleasure to read, and it keeps me extremely interested and wanting more!!Good work :)
#4
At any rate, as we start to approach the end of this journey I don't necessarily regret the things we did wrong. I would regret a whole lot more if we didn't atleast share our mistakes to try to help others through this process.
Thanks for taking the time to put this .plan series together. Looking forward to the next one...
09/23/2005 (10:41 pm)
You are taking me waaaaay back with this stuff, Paul. What a great (yet kinda embarrassing) read. It sounds so elementary when you look back this way but we really honestly felt we were doing the right things (or we were perhaps so lost we didn't think to look around and care if we were doing the right things). At any rate, as we start to approach the end of this journey I don't necessarily regret the things we did wrong. I would regret a whole lot more if we didn't atleast share our mistakes to try to help others through this process.
Thanks for taking the time to put this .plan series together. Looking forward to the next one...
#5
and I don't pretend to conclusively know it, but man I am learning it just like you. with my ballet game I did somewhat of the same thing, got some bad ass details on the models, kept designing more features and ordering up fresh concept art pages. meanwhile I struggled with the main character control scheme and just figured if I kept at it that it would eventually just work itself out. DUUUUH. oops.
I made the same mistake with shelled though not as huge. I learned my lesson but not fully. I mean, I only just now got tanks fully functional in the game. meanwhile I have hundreds of lines of NPC dialogue and 1500 NPC character names and all kinds of other finer details, but I only now got the tanks working! (and when I say "I", I mean the programmer I'm working with)
so yeah, this is awesome stuff to be sharing with the community, and this was such an entertaining read ("drunk on our own power... we were gods"). hopefully people take heed and iterate their games properly. GID style demos should really be the basic starting block, start small, polish that hook, and then worry about everything else. somehow it's all coming together though, but not as elegantly as it could have... but then, that's part of the whole point of why I wanted to make a game, TO LEARN HOW TO DO IT! you don't learn as much by sitting on the sidelines, that's for sure.
09/24/2005 (12:54 am)
but here's the thing paul. when you learn from personal, first hand, hard won experience, you KNOW what you're talking about. you have knowledge that is in a form more valuable than what others can just read about. what you're talking about - iterating a game properly, from the foundation up - is common game design knowledge, but you really can't know it until you experience it yourself.and I don't pretend to conclusively know it, but man I am learning it just like you. with my ballet game I did somewhat of the same thing, got some bad ass details on the models, kept designing more features and ordering up fresh concept art pages. meanwhile I struggled with the main character control scheme and just figured if I kept at it that it would eventually just work itself out. DUUUUH. oops.
I made the same mistake with shelled though not as huge. I learned my lesson but not fully. I mean, I only just now got tanks fully functional in the game. meanwhile I have hundreds of lines of NPC dialogue and 1500 NPC character names and all kinds of other finer details, but I only now got the tanks working! (and when I say "I", I mean the programmer I'm working with)
so yeah, this is awesome stuff to be sharing with the community, and this was such an entertaining read ("drunk on our own power... we were gods"). hopefully people take heed and iterate their games properly. GID style demos should really be the basic starting block, start small, polish that hook, and then worry about everything else. somehow it's all coming together though, but not as elegantly as it could have... but then, that's part of the whole point of why I wanted to make a game, TO LEARN HOW TO DO IT! you don't learn as much by sitting on the sidelines, that's for sure.
#6
Dont think this is an isolated incident either, many many big games companies do exactly this...
Great plan though Paul, I remember seeing the prototypes, but I wonder now about the final game! :) it must be so different!!
Look forward to playing it at IGC!
09/24/2005 (2:37 am)
Oh man, so many mistakes I can identify with... its painful, but its also necassary to go through it...Dont think this is an isolated incident either, many many big games companies do exactly this...
Great plan though Paul, I remember seeing the prototypes, but I wonder now about the final game! :) it must be so different!!
Look forward to playing it at IGC!
#7
This is actually an advantage if your project methodology can adapt and utilize the lessons you learn along the way, and most importantly refactor the information back into your design and your implementations. I call it the iterative approach, and in my personal project we work with it...implement aspects of the game (art, systems, control system, etc.) to a prototype stage, and then most probably turn right around and work on something else. We then come back in a controlled manner to implementations and designs that were "tier 1", and refactor all that we have learned (fun factor, usabilty, implementation strategy, etc.) into the original tier 1 implementation, and push it to tier 2 if appropriate. Rinse and repeat.
While this does make you feel that you haven't "progressed"--you actually have: during this phase when you were doing all of the "wrong things", you have explored areas that you think the game should go, and this in turn is going to fuel both design and implementation once you "get back on track" and work on the things that you still need to do.
And especially as an Indie team with all the restrictions, issues, and real life concerns, as long as you are learning and most importantly using what you learned, you are doing well!
09/24/2005 (9:54 am)
As an Indie Developer, one thing to keep in mind is that sometimes you don't have a choice but to do "the wrong thing" in various phases of your project. For example, you may really need to be working on your movement model, but your primary programmer is in Fiji for a month, and all you have are artists and a project manager--so you need to be very flexible in where and how you progress in your project.This is actually an advantage if your project methodology can adapt and utilize the lessons you learn along the way, and most importantly refactor the information back into your design and your implementations. I call it the iterative approach, and in my personal project we work with it...implement aspects of the game (art, systems, control system, etc.) to a prototype stage, and then most probably turn right around and work on something else. We then come back in a controlled manner to implementations and designs that were "tier 1", and refactor all that we have learned (fun factor, usabilty, implementation strategy, etc.) into the original tier 1 implementation, and push it to tier 2 if appropriate. Rinse and repeat.
While this does make you feel that you haven't "progressed"--you actually have: during this phase when you were doing all of the "wrong things", you have explored areas that you think the game should go, and this in turn is going to fuel both design and implementation once you "get back on track" and work on the things that you still need to do.
And especially as an Indie team with all the restrictions, issues, and real life concerns, as long as you are learning and most importantly using what you learned, you are doing well!
#8
09/24/2005 (10:38 am)
Great read Paul. This is one of the great things about these .plans. You get to see that you aren't the only one who is struggling and learning the hard way. I agree with Joshua. Learning by doing is the best. Being both an art as well as a science I think that it takes learning by doing to really know. Because it's not like you are following instructions or something. You have to figure out how to make your game. That's cool. That's what is the most cool about game development to me. And when I feel like maybe all of my mistakes and struggles mean that I may not be cut out for this kind of work... I think of the fact that Thomas Edison made (I think) almost a thousand light bulbs before he got it right. And he had a huge team of inventors. And then I read .plans like this and realise that I am doing great and that I am in great company.
#9
One of the main problems I see with many games is that the scope is too large and the development is often 'backward'. For me, I like to prototype everything.. and I like to do this while expending as little resource on development of assets as I can get away with. A certain amount of art assets are required to prototype the look, but even with those, I like to use a very deliberate system to work slowly toward a final project.
The development of the look and theme should ideally begin as early as possible, and ideally this can be done in paralell with the development of the play mechanic. The easiet way to do this is to prototype the game and let the theme 'fall out' of the good things in the game and minimize the bad. This requires a slow and deliberate approach to theme development where the creation of the theme is responsive to the developing 'fun' of the game and works to maximize the fun and add depth to the product. The danger is doing too much too soon and having the theme creature the requirments for a feature that does not turn out to be very engaging.. if a feature is just not working, it needs to be discarded.. and having it be central to a thematic device can lead to lots of work trying to make something work that does not add (and potentially detracts) from the game.
I much prefer a 'light' backstory or theme that is flexible to the evolving game that can bend in response to it. I also prefer not to 'nail down' art assets until the core play mechanic is more or less final. Sometimes this is unavoidable, as one cannot do zero art in order to test the look and feel, but it can be approached in such a way that you don't overspend your resources on throwaway items.
The main advice I can offer to anyone making a game is to focus on making the game fun first. Make the primary play mechanic enjoyable. If it is not 'right', as you add functionality, you can just make the process harder. If a game is fun, and additions to it make it less fun, there is a clear indication that the changes have altered the project and need to be addressed. If you add too much too quick, and then you have something that is not that engaging.. trying to figure out why is very difficult.
With experience, you can learn to identify what is good and bad, and what things may be affecting the project in a negative way.
I have learned to be able to sit down at any project and use my imagination to fill in gaps (especially yhe graphics) and see the potential and the problems. Coming into an almost complete project is hard as changes required to make the game more compelling may require massive amounts of rework or fundamental changes to the base gameplay, leading to a cascade of changes down the line that affect everything.
Great .plan again paul..
09/24/2005 (11:29 am)
I agree that learning by doing is best, but I think that we can do more in terms of idenitfying common problems and coming up with methodologies that make sense for creation of games. One of the main problems I see with many games is that the scope is too large and the development is often 'backward'. For me, I like to prototype everything.. and I like to do this while expending as little resource on development of assets as I can get away with. A certain amount of art assets are required to prototype the look, but even with those, I like to use a very deliberate system to work slowly toward a final project.
The development of the look and theme should ideally begin as early as possible, and ideally this can be done in paralell with the development of the play mechanic. The easiet way to do this is to prototype the game and let the theme 'fall out' of the good things in the game and minimize the bad. This requires a slow and deliberate approach to theme development where the creation of the theme is responsive to the developing 'fun' of the game and works to maximize the fun and add depth to the product. The danger is doing too much too soon and having the theme creature the requirments for a feature that does not turn out to be very engaging.. if a feature is just not working, it needs to be discarded.. and having it be central to a thematic device can lead to lots of work trying to make something work that does not add (and potentially detracts) from the game.
I much prefer a 'light' backstory or theme that is flexible to the evolving game that can bend in response to it. I also prefer not to 'nail down' art assets until the core play mechanic is more or less final. Sometimes this is unavoidable, as one cannot do zero art in order to test the look and feel, but it can be approached in such a way that you don't overspend your resources on throwaway items.
The main advice I can offer to anyone making a game is to focus on making the game fun first. Make the primary play mechanic enjoyable. If it is not 'right', as you add functionality, you can just make the process harder. If a game is fun, and additions to it make it less fun, there is a clear indication that the changes have altered the project and need to be addressed. If you add too much too quick, and then you have something that is not that engaging.. trying to figure out why is very difficult.
With experience, you can learn to identify what is good and bad, and what things may be affecting the project in a negative way.
I have learned to be able to sit down at any project and use my imagination to fill in gaps (especially yhe graphics) and see the potential and the problems. Coming into an almost complete project is hard as changes required to make the game more compelling may require massive amounts of rework or fundamental changes to the base gameplay, leading to a cascade of changes down the line that affect everything.
Great .plan again paul..
#10
So, a studio like Bioware, who I hear work first on story, can do so because they are not creating gameplay but rather using the same game play they have used in previous games. I kind of wondered about that.
09/24/2005 (11:51 am)
@Joe MaruschakSo, a studio like Bioware, who I hear work first on story, can do so because they are not creating gameplay but rather using the same game play they have used in previous games. I kind of wondered about that.
#11
I am not saying that story cannot come first.. it can, but it is harder to develop gameplay from a theme than the other way around, and does not work as well if you don't have a lot of experience. In terms of the 'micro' design.. there are lots of little things that need to be addressed.. and over time you remember things that were tried, what worked, and what did not work, and why they did or did not work for that particular application.
This 'bag of tricks' give you more things to play with and a certain amount of comfort in being able to define design issues as 'ones we have dealt with before and have ten+ possible solutions to' and those that are new and the team has no f$%*ing clue how to fix it'. In partcualr with Bioware, they are not going too far afield in terms of the games they make (they are not switching to flight sims and making monkey ball or katamari damacy).. so it makes sense that the smaller design changes are treated like 'micro' issues, as the core mechainc is something they have a good handle on.
It should also be noted that most RPG games are less game and more entertainment. The genre has shaped the expected play.. going to far outside the expected is not necessarily a good thing.. this is not unique to RPGs.. the same goes for racing games, for FPS games.. and many other genres that already exist.
The difference here is in the developer. If I were making a big RPG, I don't have the experience (nor does my team).. so we cannot just jump in an expect that we will be able to get it right first time around.
For indies, most don't have experience in making games, so making a story and trying to draw on a play mechanic that they understand and having a ton of possible plans of attack for all the 'micro' design issues is just, in my opinion, not the best way too approach the problem.
The approach taken is unique to the developer and the game type.. there is no 'rule' that I think should be made, but I think there are best practices that I think will work for most people in most instances.
09/24/2005 (12:15 pm)
@Anton,I am not saying that story cannot come first.. it can, but it is harder to develop gameplay from a theme than the other way around, and does not work as well if you don't have a lot of experience. In terms of the 'micro' design.. there are lots of little things that need to be addressed.. and over time you remember things that were tried, what worked, and what did not work, and why they did or did not work for that particular application.
This 'bag of tricks' give you more things to play with and a certain amount of comfort in being able to define design issues as 'ones we have dealt with before and have ten+ possible solutions to' and those that are new and the team has no f$%*ing clue how to fix it'. In partcualr with Bioware, they are not going too far afield in terms of the games they make (they are not switching to flight sims and making monkey ball or katamari damacy).. so it makes sense that the smaller design changes are treated like 'micro' issues, as the core mechainc is something they have a good handle on.
It should also be noted that most RPG games are less game and more entertainment. The genre has shaped the expected play.. going to far outside the expected is not necessarily a good thing.. this is not unique to RPGs.. the same goes for racing games, for FPS games.. and many other genres that already exist.
The difference here is in the developer. If I were making a big RPG, I don't have the experience (nor does my team).. so we cannot just jump in an expect that we will be able to get it right first time around.
For indies, most don't have experience in making games, so making a story and trying to draw on a play mechanic that they understand and having a ton of possible plans of attack for all the 'micro' design issues is just, in my opinion, not the best way too approach the problem.
The approach taken is unique to the developer and the game type.. there is no 'rule' that I think should be made, but I think there are best practices that I think will work for most people in most instances.
#12
09/24/2005 (5:27 pm)
I can't wait for IGC and more discussions like this. This is all so very interesting. We need a frickin' video series of lectures and labs on this stuff. Unsensored directors cut versions too. Give me the 'kevin costner' director's cut of this stuff. I've learned enough to know that wisdom begins with listening to someone with experience. Now there's a good name for a game development lecture series: The Game Experience. Thanks Paul and Joe.
#13
that's the tricky thing about game design, there's never a rule that always applies.
09/24/2005 (9:28 pm)
the ONE thing I will say about developing art early on is that if you are a new studio and don't have a previous title to point to to establish credibility, then like it or not, but good game art WILL help you establish credibility more than good gameplay will in terms of attracting team members.that's the tricky thing about game design, there's never a rule that always applies.
Associate Ben Garney