a different kind of Torque project
by Jeff Highsmith · in Jobs · 09/23/2001 (12:37 pm) · 33 replies
i am looking for like-minded individuals to help me design a different kind of game. using the torque engine, this project - called URGE, for Universal Roleplaying Game Engine - will not be a specific game but a sort of engine laid on top of the Torque engine. the idea is to create a common interface that will be used to produce genre-specific games. anyone who has played champions rpg or hero system games will understand the idea: take a generic system capable of doing anything (within specific guidelines) and then add on the specific settings (wild west, fantasy, sci-fi, conspiracy theory, occult, etc) later. the ultimate goal is to enable a development team to use Torque and Urge for their game's skeleton, freeing them up to concentrate on content creation.
to put it another way, the main idea is, why reinvent the wheel constantly? for example, lockpicking is a skill that is, or should be, present in every fps/rpg game. since lockpicking (and just about every common skill) will already be coded into the game, there will be no need to code it. the developers can concentrate on making the animation for lockpicking look cool, and tweaking the specifics to their needs.
i should note that URGE will be specifically oriented towards a first and third person shooter/rpg type game, and will not be for everyone. the concept behind URGE is difficult to explain in a small space and if you are the least bit curious, you should check out my page at
http://www.angelfire.com/scifi/satur9/index.html
please note that the page is old and i have about a million things i want to add, but it gets the point across.
at the moment, URGE consists of just myself and a few loosely knit confederates, but in a few months i should have substantial funding available. the business model is up in the air at present. i just feel strongly that reinventing the wheel is folly, and i feel that the artistic end of games should be the major hurdle, not the engine. i feel that a project like this would be a great help to all the small teams out there long on artistic and design talent but short on programming and or funding.
i would greatly appreciate any feedback or criticism, and look forward to hearing from anyone with similar ideas.
jeff
to put it another way, the main idea is, why reinvent the wheel constantly? for example, lockpicking is a skill that is, or should be, present in every fps/rpg game. since lockpicking (and just about every common skill) will already be coded into the game, there will be no need to code it. the developers can concentrate on making the animation for lockpicking look cool, and tweaking the specifics to their needs.
i should note that URGE will be specifically oriented towards a first and third person shooter/rpg type game, and will not be for everyone. the concept behind URGE is difficult to explain in a small space and if you are the least bit curious, you should check out my page at
http://www.angelfire.com/scifi/satur9/index.html
please note that the page is old and i have about a million things i want to add, but it gets the point across.
at the moment, URGE consists of just myself and a few loosely knit confederates, but in a few months i should have substantial funding available. the business model is up in the air at present. i just feel strongly that reinventing the wheel is folly, and i feel that the artistic end of games should be the major hurdle, not the engine. i feel that a project like this would be a great help to all the small teams out there long on artistic and design talent but short on programming and or funding.
i would greatly appreciate any feedback or criticism, and look forward to hearing from anyone with similar ideas.
jeff
#2
regards,
jeff
09/23/2001 (2:24 pm)
was on my way to bed and checking in first. thanks for the idea, ill check that out. we should definitely be able to get the right talent eventually (as i will have cash for programmers!). right now i need someone who knows code to go into what is feasible and what isnt. ive put everything on a back burner of late because of my new job, but when my funding comes through (private investor) i intend to pursue URGE full time. thanks for the offer of consideration. the more i think about the project, the more strongly i feel that it is right up garage games' alley. sometimes i even feel like this should be an open source-type movement, but a few things kill that idea: first, unpaid labor can be and usually is synonymous with mediocre product. second, i need the project to pay for itself! i would be happy if the project made enough money to break even. then i could concentrate on making content. the bottom line is, i want to see better games made, with more content and better art, instead of everyone busting their butts reinventing the wheel. i hope i can find a programmer or two who feel likewise.regards,
jeff
#3
09/23/2001 (4:35 pm)
Regarding RPG maker..... there's a PSX version that was released in both Japan and the US (although the US version can be hard to find). And then there's Fighter Maker. Antoher PSX game, only 3D fighting game related. Once again, the US version can be hard to find.
#4
09/23/2001 (9:37 pm)
thanks, ill check them out too, fighter maker sounds cool...
#5
A friend of mine showed it to me and althought it isn't a remarkable game it does have one redeeming feature, you can actually code your own AI scripts into the game using their very simple programming language. The benefits of the scrips are that you can spend more time screwing around the game while the robots go about their AI business (and to answer the next question that anyone might have, no you don't need to know programming to play, you can also play via point & click).
Logan
09/24/2001 (5:21 am)
On the tread of games that can help teach computer skills to the end user, you should take a look at a game called "Colobot" (http://www.epsitec.ch/colobot/index.htm).A friend of mine showed it to me and althought it isn't a remarkable game it does have one redeeming feature, you can actually code your own AI scripts into the game using their very simple programming language. The benefits of the scrips are that you can spend more time screwing around the game while the robots go about their AI business (and to answer the next question that anyone might have, no you don't need to know programming to play, you can also play via point & click).
Logan
#6
09/24/2001 (6:29 am)
This might be able to help out with the game I'm trudging my way through. I definitely wouldn't mind helping out (it'll also give me an excuse to really get going with the engine). I think there should be more programs available that let people quickly prototype and experiment with games. Send me an e-mail if you want to talk more, or we can continue in this or another thread.
#7
09/24/2001 (6:54 am)
hey adam, if youre interested, youre more than welcome to help. if you want i can send you my notes for the design docs. at this point URGE is firmly in the percolation stage. i dont have the time or skill to start the real work, so i figure the best thing i can do is flesh out the docs as fully as im able. let me make it clear that anyone who helps me out at this stage will not be pressured to put in more than they want, at all. id just like some opinions that are more informed than my own. its very easy to come up with all the grandiose ideas as i have, and equally easy for a programmer to read them and say, "uhh, no way are you gonna do that." for instance, i told a level designer buddy of mine that i wanted to maybe start with a 3d version of tekken, then build the action/combat engine around it. he told me that its impossible, the amount of 3d data required would swamp even a high end system. i think thats horseshyte, but it gave me pause. thats the point, unfortunately, i dont know enough to say for sure if im right.
#8
what i came up with is actually pretty simple. for the strong hand, a four or five button mouse. for the off hand, a special kind of joystick. instead of having a ball joint connecting stick to base, this joystick will be rigid, ie stick and base are one piece. where your fingers curl around it are a series of buttons, probably 3 to a finger (probably excluding the pinkie), 2-3 buttons for the thumb, and a small analog joystick on top (like the one on the N64 pads) for player movement with the thumb. since a 3d game needs a mouse for eye/camera movement and a pad or four keys for spacial movement, the burden of myriad 'combos' falls on pure button combinations. i havent done the exact math, but i think at least four hundred or so moves can be achieved with the buttons alone, using both mouse and joystick.
yes, the learning curve would be steep, but thats only if a player wants to take full advantage of the possibilities. if hes intimidated by so many combos, he can pick the fifty or so he feels confident with and forego the rest.
anyway, done with the overlong post now, let me know what you think.
jeff
09/24/2001 (7:25 am)
mentioning the tekken thing got me thinking about the control system i alluded to on my website, but haven't elaborated on yet. the problem with existing controls is that they arent up to the tasks i have in mind for them. for URGE, players need to be able to implement any one of hundreds of different commands instantly. a keyboard can handle the complexity, but not the speed requirement (excepting maybe the ultimate power gamers out there). a joypad or joystick can handle the speed, but not the complexity (and i want a mouse for aiming - imho, and many others', nothing else comes close).what i came up with is actually pretty simple. for the strong hand, a four or five button mouse. for the off hand, a special kind of joystick. instead of having a ball joint connecting stick to base, this joystick will be rigid, ie stick and base are one piece. where your fingers curl around it are a series of buttons, probably 3 to a finger (probably excluding the pinkie), 2-3 buttons for the thumb, and a small analog joystick on top (like the one on the N64 pads) for player movement with the thumb. since a 3d game needs a mouse for eye/camera movement and a pad or four keys for spacial movement, the burden of myriad 'combos' falls on pure button combinations. i havent done the exact math, but i think at least four hundred or so moves can be achieved with the buttons alone, using both mouse and joystick.
yes, the learning curve would be steep, but thats only if a player wants to take full advantage of the possibilities. if hes intimidated by so many combos, he can pick the fifty or so he feels confident with and forego the rest.
anyway, done with the overlong post now, let me know what you think.
jeff
#9
Even with the input system, not everyone will need something complicated enough for a five button mouse and a non-existent joystick. It's very possible to make a game that uses a single context-sensitive cursor. Only one button needed there. What all systems need, though, is a way for the input to be gathered and for basic things to be determined about it. Did the player click? What did he click on? What part of that object did he click on?
You can be more specific with something like a conversation system. It's likely it will be based on some kind of tree. However, designers should be able to alter the system a little to meet their needs.
Instead of writing a content-less RPG, the focus of such a project should be to make a flexible system with a strong foundation that can be scripted to make RPGs. In the initial release of such a project, the base library for the system may contain enough code for someone to script together a standard RPG. However, if so inclined, a user should also be able to easily script together a game with a much more original design. The key is an interface to the system that gives the user only as much power as he can handle. If someone's just starting out, he should be able to drag in some enemies and throw together a 3d Rogue-alike. An advanced user should be able to take the same system and use the included tools to make a map and set of conversations, but also be able to implement an untraditional stat and interface system.
09/24/2001 (8:48 am)
I think you're making it more complicated than it has to be. The key thing you're assuming is that everyone is going to want to make a game just like yours. A stronger system would be broken up into simpler parts. For example you could have a system to manage statistics, a conversation system, an input system, etc. With simple things such as stats, many people would want to make slight variations on it. Not every RPG has to keep track of STR, INT, CHR, etc. I'm personally not interested in tracking any stereotypical RPG stats for what I'm working on. However, the system needs a rudimentary method for letting actions affect how the inner dice rolls are weighed.Even with the input system, not everyone will need something complicated enough for a five button mouse and a non-existent joystick. It's very possible to make a game that uses a single context-sensitive cursor. Only one button needed there. What all systems need, though, is a way for the input to be gathered and for basic things to be determined about it. Did the player click? What did he click on? What part of that object did he click on?
You can be more specific with something like a conversation system. It's likely it will be based on some kind of tree. However, designers should be able to alter the system a little to meet their needs.
Instead of writing a content-less RPG, the focus of such a project should be to make a flexible system with a strong foundation that can be scripted to make RPGs. In the initial release of such a project, the base library for the system may contain enough code for someone to script together a standard RPG. However, if so inclined, a user should also be able to easily script together a game with a much more original design. The key is an interface to the system that gives the user only as much power as he can handle. If someone's just starting out, he should be able to drag in some enemies and throw together a 3d Rogue-alike. An advanced user should be able to take the same system and use the included tools to make a map and set of conversations, but also be able to implement an untraditional stat and interface system.
#10
i dont intend to make URGE capable of anything and everything. but i do want urge to be capable of creating a 1st/3rd person shooter/rpg of any genre. URGE WILL be firmly rooted in that perspective - one player, one character (although that is not to say the sidekick/henchman option wont be available). the point and click approach has its merits, notably elegant simplicity, but it doesnt have the versatility i need. i want players to have the ability to bind as many combat moves, animated emotes, skill-related animations, etc., as they want, within reason. the whole reason i decided to try this was i found the current combat and skill systems in shooters unsatisfying. i myself am a (very) amateur practitioner of aikido. i want to be able to use some of those moves on a badguy when he kicks the gun out of my hand. i want to be able to throw my arms wide in exasperation when talking to my fellow party members to convey my point, not stand there like an automaton.
it might sound like too tall of an order, but when you really give it some thought, most of these things boil down to animations, character models, etc., things that will fall primarily on the end user - game developers and the amateur mod-makers. the hard part is the hit location engine and the like.
now the particle effects and magic/superpowers engines are a whole nother ball of wax, but those can wait until URGE 2 :).
as far as a game without a game, i do intend to release a small game with URGE, but it will not be the main thrust of the product, not by a long shot. the best idea ive come up with so far is a time travel game with each level taking place in a different time and place. this might be the best way to showcase the wide variety of genres URGE can take on. i plan to include some stock content - animations, models, textures, etc, but i will concentrate on these things only after URGE is released.
conversation trees are important, but not as important as you might think. im taking another page from the pnp rpg set here and planning on including a dungeon master/referee/whatever. so this way, when a party is involved in conversation with an npc/bot, the dm takes on the role and infuses it with a living intelligence (voice chat will be an integral part of URGE and with all the freeware out there, it shouldnt be hard to implement).
im not sure if this is what you meant, but i do intend to break URGE down into separate engines, ie action, conversation, technical (skills), yada yada, if for no other reason than to make the work easier. tools will probably include plugins for milkshape and/or blender, paint shop pro, photoshop, 3ds max, etc., etc.
if you havent already, you should check out the site listed in the first post i made, its more thought out, and ive tried to use stuff here that hasnt been said there already.
jeff
09/24/2001 (9:30 am)
i totally agree that the end user should be able to use URGE to just drag and drop monsters, weapons, spells, etc and play within minutes or hours. however, i dont agree that im making it more complicated than necessary. i totally welcome your thought that this statistic or that is or is not necessary. but it is far easier to make a wide variety of skills, stats, etc. available from the start and let the designer choose which he likes than it is to add unplanned-for options after youve done all the initial work. in other words, if you have a thousand options available, you can still choose just ten. if you have ten options available, a thousand is out of the question. i dont know how many ggers are familiar with the hero systm pnp rpg, but some point based system like that is perfect imho. with a system like that, you can use the point convention only with the 'backend', and still put whatever rules system you like on top for the player to deal with. the hero system is, quite simply, capable of anything.i dont intend to make URGE capable of anything and everything. but i do want urge to be capable of creating a 1st/3rd person shooter/rpg of any genre. URGE WILL be firmly rooted in that perspective - one player, one character (although that is not to say the sidekick/henchman option wont be available). the point and click approach has its merits, notably elegant simplicity, but it doesnt have the versatility i need. i want players to have the ability to bind as many combat moves, animated emotes, skill-related animations, etc., as they want, within reason. the whole reason i decided to try this was i found the current combat and skill systems in shooters unsatisfying. i myself am a (very) amateur practitioner of aikido. i want to be able to use some of those moves on a badguy when he kicks the gun out of my hand. i want to be able to throw my arms wide in exasperation when talking to my fellow party members to convey my point, not stand there like an automaton.
it might sound like too tall of an order, but when you really give it some thought, most of these things boil down to animations, character models, etc., things that will fall primarily on the end user - game developers and the amateur mod-makers. the hard part is the hit location engine and the like.
now the particle effects and magic/superpowers engines are a whole nother ball of wax, but those can wait until URGE 2 :).
as far as a game without a game, i do intend to release a small game with URGE, but it will not be the main thrust of the product, not by a long shot. the best idea ive come up with so far is a time travel game with each level taking place in a different time and place. this might be the best way to showcase the wide variety of genres URGE can take on. i plan to include some stock content - animations, models, textures, etc, but i will concentrate on these things only after URGE is released.
conversation trees are important, but not as important as you might think. im taking another page from the pnp rpg set here and planning on including a dungeon master/referee/whatever. so this way, when a party is involved in conversation with an npc/bot, the dm takes on the role and infuses it with a living intelligence (voice chat will be an integral part of URGE and with all the freeware out there, it shouldnt be hard to implement).
im not sure if this is what you meant, but i do intend to break URGE down into separate engines, ie action, conversation, technical (skills), yada yada, if for no other reason than to make the work easier. tools will probably include plugins for milkshape and/or blender, paint shop pro, photoshop, 3ds max, etc., etc.
if you havent already, you should check out the site listed in the first post i made, its more thought out, and ive tried to use stuff here that hasnt been said there already.
jeff
#11
btw, i did the math, and im kinda math-backwards, but i think using 1, 2, and 3 button combos on the joystick and using the 4 or 4 buttons on the mouse as classification switches (ie mouse button 1 selects from combat menu, 2 selects from conversation menu, 1 and 2 selects from alternate combat menu, etc,), you can get more than a 1300 'moves'. this assumes a slightly modified version of the above joystick, with a d-pad on top of the stick and three buttons to either side for the thumb. not that i think you need this many, but i can easily envision using several hundred unarmed combat moves, several hundred armed close-combat moves, and a like number of emotes and skill based moves.
this doesnt even take into account different inputs for tapping buttons quickly, holding buttons for a second, and holding buttons down for several seconds. or even using 'strict' modes, where you enter a command and enter 'strict' emote mode for example, where all 1300 possible moves are emotes, and only five or so commands are dedicated to shifting to another 'strict' mode like combat or whatever.
i realize that this seems excessive, but when you have a game that can cross infinite settings and genres, its more worth your playing time to learn a complex system. i almost thing of URGE as a game equivalent to a gui, i guess.
jeff
09/24/2001 (9:52 am)
oh, i forgot to mention, the joystick i referred to above is indeed non-existent, but that doesnt mean ill release URGE and pray it gets made. it means ill just have to design and market one myself (delusional much? :). it wont be necessary to buy one to play and create with URGE, but it will let the player reach the games full potential. btw, i did the math, and im kinda math-backwards, but i think using 1, 2, and 3 button combos on the joystick and using the 4 or 4 buttons on the mouse as classification switches (ie mouse button 1 selects from combat menu, 2 selects from conversation menu, 1 and 2 selects from alternate combat menu, etc,), you can get more than a 1300 'moves'. this assumes a slightly modified version of the above joystick, with a d-pad on top of the stick and three buttons to either side for the thumb. not that i think you need this many, but i can easily envision using several hundred unarmed combat moves, several hundred armed close-combat moves, and a like number of emotes and skill based moves.
this doesnt even take into account different inputs for tapping buttons quickly, holding buttons for a second, and holding buttons down for several seconds. or even using 'strict' modes, where you enter a command and enter 'strict' emote mode for example, where all 1300 possible moves are emotes, and only five or so commands are dedicated to shifting to another 'strict' mode like combat or whatever.
i realize that this seems excessive, but when you have a game that can cross infinite settings and genres, its more worth your playing time to learn a complex system. i almost thing of URGE as a game equivalent to a gui, i guess.
jeff
#12
Please consider the consumer in your development. What you are willing to do yourself for the product is irrelevent unless you will be the only one using it. It's simply not fair or even remotely realistic to force anyone wanting to use your product to have to purchase hardware to customize their computer setup just to use it. Most people would take one look at the requirement to buy custom hardware and just walk away no matter how powerful the product was.
Consider how complex 3D Studio Max is. That program has literally thousands of features, and each of those features has dozens and sometimes hundreds of settings. The developers use detail rollouts that work great, it's all mouse based except for numeric input, and it's pretty fast once you get used to it. This is just one example of a program with immense complexity and ease of use. There are many creative ways to get around your problem besides inventing new hardware that you force everyone to use.
I would see the aspect of complexity differently. I see it from two standpoints, the designer creating their game with your engine overlay, and the gamer playing the game that was just created. The designer doesn't need catlike reflex ability for 1300 features during the design process. Hotkeys for the most commonly performed functions are more than sufficient and have gotten professional software long for years like 3D Studio Max, Photoshop, CorelDraw, Quark, and more. The gamer needs catlike reflex ability, but only for direct real-time combat options. There is no way that a gamer is going to need over a thousand real-time combat options. It's not even remotely realistic to expect the average gamer to learn over 1,000 moves for real-time combat based solely on pushing buttons. I've played 2D and 3D fighting games for years, and there are generally not more than fifty to a hundred moves and combos available. Even that many takes a lot of time to master. So even if the gamer has access to over a thousand abilities, most of those are not real-time combat based and can easily be handled by heirarchal menus, panel rollouts, or something of the like.
I would very much like to see your concept flourish, but I hope you will consider changing the direction you seem to be going in regarding user interactivity.
09/25/2001 (8:29 am)
You idea is very developed already and has a lot of promise Jeff. However, I see you going in a direction that will hurt the overall product. You're considering yourself too much and willing to make too much of the product adaptive to what you are willing or interested in doing. Setting up this piece of software to use custom hardware that has be created and marketed in itself is a bad idea. If the product is free, then no one is going to spend considerable money to buy a special mouse and custom joystick. If the product is for sale, then what consumer is going to want to buy those supporting hardware products in addition to the cost of the main product itself? You're talking about hardware products that have little to no functionality outside of your product. Furthermore, you are expecting the consumer to drop any custom hardware they already have in favor of yours. Most will simply not do it. I use a Logitech Trackman Marble+, and there is no way I'm going to switch from that to a 5 button mouse for any game. Not for ANY game. Please consider the consumer in your development. What you are willing to do yourself for the product is irrelevent unless you will be the only one using it. It's simply not fair or even remotely realistic to force anyone wanting to use your product to have to purchase hardware to customize their computer setup just to use it. Most people would take one look at the requirement to buy custom hardware and just walk away no matter how powerful the product was.
Consider how complex 3D Studio Max is. That program has literally thousands of features, and each of those features has dozens and sometimes hundreds of settings. The developers use detail rollouts that work great, it's all mouse based except for numeric input, and it's pretty fast once you get used to it. This is just one example of a program with immense complexity and ease of use. There are many creative ways to get around your problem besides inventing new hardware that you force everyone to use.
I would see the aspect of complexity differently. I see it from two standpoints, the designer creating their game with your engine overlay, and the gamer playing the game that was just created. The designer doesn't need catlike reflex ability for 1300 features during the design process. Hotkeys for the most commonly performed functions are more than sufficient and have gotten professional software long for years like 3D Studio Max, Photoshop, CorelDraw, Quark, and more. The gamer needs catlike reflex ability, but only for direct real-time combat options. There is no way that a gamer is going to need over a thousand real-time combat options. It's not even remotely realistic to expect the average gamer to learn over 1,000 moves for real-time combat based solely on pushing buttons. I've played 2D and 3D fighting games for years, and there are generally not more than fifty to a hundred moves and combos available. Even that many takes a lot of time to master. So even if the gamer has access to over a thousand abilities, most of those are not real-time combat based and can easily be handled by heirarchal menus, panel rollouts, or something of the like.
I would very much like to see your concept flourish, but I hope you will consider changing the direction you seem to be going in regarding user interactivity.
#13
Let me give a couple of examples of ways to handle complex features just in case you may not have played one of these games.
Daggerfall
This roleplaying game had a ridiculous amount of features. Nearly unending terrain, literally hundreds of towns that were individual and could remember you, multiple combat moves, custom player spell creation capability, ability to own property and other things, capability to pursue the story goals at any time, or not at all, and the list goes on. I haven't played it in a couple of years, but it is the most complex RPG I have ever played. Period.
Die by the Sword
This game's combat system was created by an skilled fencer. You were able to interact in 360 degrees of movement, including sword attacks while hanging upside down in a rope trap! This game had all kinds of great combat related features including an absolutely excellent hit location and dismemberment system. You could literally cut an enemy's foot off at the ankle and they would try to fight you while hopping and falling over. The combat system was extremely advanced. It also had a system to create your own fencing moves and combos. You were supposed to literally be able to perform any fencing move humanly possible. Unfortunately I found the controls difficult and unintuitive. Because of that I never played very far. Take note of that, as people often won't use something with tons of features regardless of how cool it is if it's just too awkward.
Everquest
I really don't like this game even though I played it for over a year. However, there is one system in it that I think is very good. The emote and scripting system is something I really liked. Typing text emotes to perform physical emotes does work, and it works well if you get used to it. The only problem I ever had was remembering to use the emotes in the first play. Then again, I don't remember to use the UT emotes either, so that's a fault in me and not EQ's emote design. Furthermore, Verant later introduced a scripting system to combine emotes. Most people didn't take the time to learn it when I played, but it was very powerful. You could script a wide variety of combinations, including combining text, physical, and environment variables all in one executable emote. For example, target the nearest creature, say "Let's attack (creature name variable)", and cast a particular spell slot.
09/25/2001 (1:24 pm)
I noticed now in the last post that you said the hardware won't be required. I didn't notice that at the time I made my post, so please ignore any ire I may have expressed in my wrong assumption.Let me give a couple of examples of ways to handle complex features just in case you may not have played one of these games.
Daggerfall
This roleplaying game had a ridiculous amount of features. Nearly unending terrain, literally hundreds of towns that were individual and could remember you, multiple combat moves, custom player spell creation capability, ability to own property and other things, capability to pursue the story goals at any time, or not at all, and the list goes on. I haven't played it in a couple of years, but it is the most complex RPG I have ever played. Period.
Die by the Sword
This game's combat system was created by an skilled fencer. You were able to interact in 360 degrees of movement, including sword attacks while hanging upside down in a rope trap! This game had all kinds of great combat related features including an absolutely excellent hit location and dismemberment system. You could literally cut an enemy's foot off at the ankle and they would try to fight you while hopping and falling over. The combat system was extremely advanced. It also had a system to create your own fencing moves and combos. You were supposed to literally be able to perform any fencing move humanly possible. Unfortunately I found the controls difficult and unintuitive. Because of that I never played very far. Take note of that, as people often won't use something with tons of features regardless of how cool it is if it's just too awkward.
Everquest
I really don't like this game even though I played it for over a year. However, there is one system in it that I think is very good. The emote and scripting system is something I really liked. Typing text emotes to perform physical emotes does work, and it works well if you get used to it. The only problem I ever had was remembering to use the emotes in the first play. Then again, I don't remember to use the UT emotes either, so that's a fault in me and not EQ's emote design. Furthermore, Verant later introduced a scripting system to combine emotes. Most people didn't take the time to learn it when I played, but it was very powerful. You could script a wide variety of combinations, including combining text, physical, and environment variables all in one executable emote. For example, target the nearest creature, say "Let's attack (creature name variable)", and cast a particular spell slot.
#14
09/25/2001 (1:47 pm)
I still think you're being too specific. Disregarding how you'd want to handle input, you're assuming too much about the kinds of games the designers will want to make. You can make 1000 "skills," but all those skills are just symbolic as far as the computer is concerned. As a designer using URGE, I should be able to create a skill if necessary. I think the limited flexibilities of these systems has hurt them in the past. They mostly become people putting their own pictures and maps on top of the same game. Designers should be able to feel that they're being helped yet still making something unique, not that they're putting their own dough inside the same old cookie cutter.
#15
Now I'm thinking about a combat moves editor. Have a complex editor available to the developer that uses a skeletal animation system. It could be pretty simple, only needing support to import a linked skeleton from 3DS Max, move it around in 3D space, record keyframes, and assign some kind of damage object. For instance, a damage object for guns that is code interpreted as a projectile or beam (ranged attack), and a physical damage object that deals damage at the location of the object (attach it to hand or foot skeletal bones).
There could also be a simple combat moves editor presented as a gui for players. It could be drag and drop. Let's say the player's character knows four moves, basic punch, basic kick, aerial kick, spinning back kick. Each move is represented by little cube graphic with the move name inside it. The player opens this move editor. They then select (numbered radio box?)the number of total moves to appear in the combo. An equal number of labeled slots appears. Next they would drag and drop their character's known moves into these slots. For example, the player selects a three move combo and drags into numbered slots his basic punch (slot 1), aerial kick (slot 2), and spinning kick (slot 3). The player then uses the save interface of this gui editor to permanently save the move combo and assign it a macro or something. When executed, the combo would punch, do an aerial kick, followup with a spinning back kick, and then the combo is complete and back to player control. Giving the player this simple gui editor would allow them to make custom fighting combos in minutes that are always based on the character's current capabilities.
09/25/2001 (1:49 pm)
Well, I'm in trouble now. I'm having random ideas for URGE. Now I'm thinking about a combat moves editor. Have a complex editor available to the developer that uses a skeletal animation system. It could be pretty simple, only needing support to import a linked skeleton from 3DS Max, move it around in 3D space, record keyframes, and assign some kind of damage object. For instance, a damage object for guns that is code interpreted as a projectile or beam (ranged attack), and a physical damage object that deals damage at the location of the object (attach it to hand or foot skeletal bones).
There could also be a simple combat moves editor presented as a gui for players. It could be drag and drop. Let's say the player's character knows four moves, basic punch, basic kick, aerial kick, spinning back kick. Each move is represented by little cube graphic with the move name inside it. The player opens this move editor. They then select (numbered radio box?)the number of total moves to appear in the combo. An equal number of labeled slots appears. Next they would drag and drop their character's known moves into these slots. For example, the player selects a three move combo and drags into numbered slots his basic punch (slot 1), aerial kick (slot 2), and spinning kick (slot 3). The player then uses the save interface of this gui editor to permanently save the move combo and assign it a macro or something. When executed, the combo would punch, do an aerial kick, followup with a spinning back kick, and then the combo is complete and back to player control. Giving the player this simple gui editor would allow them to make custom fighting combos in minutes that are always based on the character's current capabilities.
#16
What would you propose as a skill system that lets designers create whatever skills are appropriate to their game, and makes actually unique and functional skills?
Practicly speaking I see no useful purpose for thousands of combat moves, skills, or most anything else. At a certain point in numbers you are duplicating things with no new functionality and only using new graphics or names. I would advocate systems in place that allow the creation of thousands of possiblities, rather than just having a library of thousands of things. There is no way you can create a preset library that has every designer's needs in it.
09/25/2001 (1:52 pm)
I agree with that Adam. I've played numerous pen and paper RPGs and they all have things in common. Many skills are often duplicates of each other, and quite a few serve no actual purpose in the game.What would you propose as a skill system that lets designers create whatever skills are appropriate to their game, and makes actually unique and functional skills?
Practicly speaking I see no useful purpose for thousands of combat moves, skills, or most anything else. At a certain point in numbers you are duplicating things with no new functionality and only using new graphics or names. I would advocate systems in place that allow the creation of thousands of possiblities, rather than just having a library of thousands of things. There is no way you can create a preset library that has every designer's needs in it.
#17
concerning your interface comments, i agree that not everyone will want to buy a special joystick to play one game. two things to consider here though: first, the joystick will be far from useless without URGE, i think such a device has merit as a standalone product (making the base rigid is just an idea, i might end up using the typical ball joint at the base in addition to the thumb d-pad on top). second, i know this sounds overly ambitious and grandiose, but i think of URGE as more than just a game, as I said above, and as more of a GUI for shooter/rpg games. the game will probably never be as popular as i want it to be, but thats no reason to fail to plan for success. 3d games arent like other games. 3d is 3d, a reflection of the real world, and whether youre a pilot, a doctor, a pirate, a mobster, a knight, or whatever, cartesian geometry doesnt change. therefore theres no reason to create certain basic elements of reality every time you make a game. I strongly believe that game design will eventually come down to specific content creation. dont almost all games use open gl or direct3d or glide? why not take the idea a step further. everyone seems to agree that the hardest part of making a game is the g/d engine. WHY do we keep doing it over and over? maybe the answer is that its easier than improving existing ones, but i find this very hard to believe. i envision an engine/platform maintained by a small number of programmers and used by a large number of artists. the easy and fun part of games, and the part that (mostly) attracts customers, is the art, not the engine.
ok, youre asking, "if youre so damn smart, why hasnt the game industry done this already? surely you dont suggest that you know something about the industry that all the game gods dont?" if you want my wholly unsupported opinion on this, i feel its a combination of things. fear, lack of vision, laziness, etc. there is no preexisting business model for a company to follow. im not a business major, so maybe im wrong and the idea simply isnt viable. the one thing im sure that the URGE idea absolutely has going for it is its infinite replay value.
as for whether or not 1300 moves are necessary, i feel that is a matter of opinion. what is not a matter of opinion is that it is easier to implement features from the ground up than it is to tack them on later in a half assed manner.
anyways, im tiring of my own diatribe, so ill leave it at that. btw, no apology necessary, i dont take forums personally. just the exchange of ideas here. the only time i take things personally is when there is someone physically present to hold accountable ;) - and you werent out of line anyway.
regards and thanks for the comments,
jeff
09/25/2001 (2:07 pm)
die by the sword sounds very, very interesting. ill definitely have to check that one out. concerning your interface comments, i agree that not everyone will want to buy a special joystick to play one game. two things to consider here though: first, the joystick will be far from useless without URGE, i think such a device has merit as a standalone product (making the base rigid is just an idea, i might end up using the typical ball joint at the base in addition to the thumb d-pad on top). second, i know this sounds overly ambitious and grandiose, but i think of URGE as more than just a game, as I said above, and as more of a GUI for shooter/rpg games. the game will probably never be as popular as i want it to be, but thats no reason to fail to plan for success. 3d games arent like other games. 3d is 3d, a reflection of the real world, and whether youre a pilot, a doctor, a pirate, a mobster, a knight, or whatever, cartesian geometry doesnt change. therefore theres no reason to create certain basic elements of reality every time you make a game. I strongly believe that game design will eventually come down to specific content creation. dont almost all games use open gl or direct3d or glide? why not take the idea a step further. everyone seems to agree that the hardest part of making a game is the g/d engine. WHY do we keep doing it over and over? maybe the answer is that its easier than improving existing ones, but i find this very hard to believe. i envision an engine/platform maintained by a small number of programmers and used by a large number of artists. the easy and fun part of games, and the part that (mostly) attracts customers, is the art, not the engine.
ok, youre asking, "if youre so damn smart, why hasnt the game industry done this already? surely you dont suggest that you know something about the industry that all the game gods dont?" if you want my wholly unsupported opinion on this, i feel its a combination of things. fear, lack of vision, laziness, etc. there is no preexisting business model for a company to follow. im not a business major, so maybe im wrong and the idea simply isnt viable. the one thing im sure that the URGE idea absolutely has going for it is its infinite replay value.
as for whether or not 1300 moves are necessary, i feel that is a matter of opinion. what is not a matter of opinion is that it is easier to implement features from the ground up than it is to tack them on later in a half assed manner.
anyways, im tiring of my own diatribe, so ill leave it at that. btw, no apology necessary, i dont take forums personally. just the exchange of ideas here. the only time i take things personally is when there is someone physically present to hold accountable ;) - and you werent out of line anyway.
regards and thanks for the comments,
jeff
#18
no sarcasm intended, but could you be more specific? :)
>>Disregarding how you'd want to handle input, you're assuming too much about the kinds of games the designers will want to make.
again, give me an example, i dont know what you mean here.
>>You can make 1000 "skills," but all those skills are just symbolic as far as the computer is concerned.
again, could you be more specific?. and i think 50-100 skills max. anything more would just be a subset of a skill. biplanes, jets, and arguably gliders all fall under the pilot skill, for instance. this isnt to say you cant specialize. wait, do you mean symbolic in that the skills are resolved by rolls behind the scenes and invisible to the player? if so i agree
>>As a designer using URGE, I should be able to create a skill if necessary.
absolutely. the previous comment and this one prompt me to say that the skills themselves should be fairly limited in number, but the moves, emotes, etc within those skills (the animations) are far more numerous. think of all the actions you could animate for the surgery skill, for example.
I think the limited flexibilities of these systems has hurt them in the past. They mostly become people putting their own pictures and maps on top of the same game.
yes, yes, yes.
>>Designers should be able to feel that they're being helped yet still making something unique, not that they're putting their own dough inside the same old cookie cutter.
yep.
09/25/2001 (2:19 pm)
>>I still think you're being too specific. no sarcasm intended, but could you be more specific? :)
>>Disregarding how you'd want to handle input, you're assuming too much about the kinds of games the designers will want to make.
again, give me an example, i dont know what you mean here.
>>You can make 1000 "skills," but all those skills are just symbolic as far as the computer is concerned.
again, could you be more specific?. and i think 50-100 skills max. anything more would just be a subset of a skill. biplanes, jets, and arguably gliders all fall under the pilot skill, for instance. this isnt to say you cant specialize. wait, do you mean symbolic in that the skills are resolved by rolls behind the scenes and invisible to the player? if so i agree
>>As a designer using URGE, I should be able to create a skill if necessary.
absolutely. the previous comment and this one prompt me to say that the skills themselves should be fairly limited in number, but the moves, emotes, etc within those skills (the animations) are far more numerous. think of all the actions you could animate for the surgery skill, for example.
I think the limited flexibilities of these systems has hurt them in the past. They mostly become people putting their own pictures and maps on top of the same game.
yes, yes, yes.
>>Designers should be able to feel that they're being helped yet still making something unique, not that they're putting their own dough inside the same old cookie cutter.
yep.
#19
Enough of the hardware though. If it's not required, and not feature limited by lack of possession of the hardware, then there shouldn't be an issue.
Engines are definitely the direction the gaming industry has taken. That's exactly what the Torque engine is about. Indie developers can buy that and shave years off their game's development time. Many professional companies license engines now instead of making their own. The Unreal engine is a good example of one engine being used for multiple games and being updated over time. The same engine is being used in Unreal, Unreal Tournament, and Unreal 2. The quality of the engine over the last three or four years has been enhanced dramaticly though. To be able to do games as different as Unreal Tournament and Deus Ex with the same engine, even though heavily modfied, shows flexibility.
That is where you are completely correct. The future lies in flexible products. Part of that entails being able to create, rather than just use. The best comment I could probably ever make regarding URGE would be to suggest that whenever possible you not use libraries of things, but instead the tools to create them.
As a side note, how about calling it an "Overlay Engine". That seems to be what it is from what I gather, namely an engine that overlays another engine. That's not to interfere with the URGE name, rather to give the product idea a classification.
09/25/2001 (2:28 pm)
I think you're right on most of that. I personally feel though that bringing hardware into the software equation creates all kinds of new problems. It would create lots of problems for you as well, because you'll have to find a manufacturer for the hardware and deal with all of the concerns relating to that instead just getting URGE published. Enough of the hardware though. If it's not required, and not feature limited by lack of possession of the hardware, then there shouldn't be an issue.
Engines are definitely the direction the gaming industry has taken. That's exactly what the Torque engine is about. Indie developers can buy that and shave years off their game's development time. Many professional companies license engines now instead of making their own. The Unreal engine is a good example of one engine being used for multiple games and being updated over time. The same engine is being used in Unreal, Unreal Tournament, and Unreal 2. The quality of the engine over the last three or four years has been enhanced dramaticly though. To be able to do games as different as Unreal Tournament and Deus Ex with the same engine, even though heavily modfied, shows flexibility.
That is where you are completely correct. The future lies in flexible products. Part of that entails being able to create, rather than just use. The best comment I could probably ever make regarding URGE would be to suggest that whenever possible you not use libraries of things, but instead the tools to create them.
As a side note, how about calling it an "Overlay Engine". That seems to be what it is from what I gather, namely an engine that overlays another engine. That's not to interfere with the URGE name, rather to give the product idea a classification.
#20
mwuhahahahaaaa, come to the dark side... :)
>>Now I'm thinking about a combat moves editor.
this is exactly the sort of thing i was talking about with my milkshape/blender comment above. obeying the first commandment, though shalt not reacreate the wheel, i figured to go with a proggie that people are already familiar with. of course, the creators of said programs might not agree, but i cant see why not, not if its good for them.
>>Have a complex editor available to the developer that uses a skeletal animation system. +
There could also be a simple combat moves editor presented as a gui for players...When executed, the combo would punch, do an aerial kick, followup with a spinning back kick, and then the combo is complete and back to player control.
good stuff
>>Giving the player this simple gui editor would allow them to make custom fighting combos in minutes that are always based on the character's current capabilities.
this gets me thinking, that the real meat of the coding would be linking the animations to the'symbolic' effects (to quote Adam's term) they represent in the game. after all the animation part has been thoroughly addressed, and theres my whole wheel belief...
09/25/2001 (2:29 pm)
>>Well, I'm in trouble now. I'm having random ideas for URGE. mwuhahahahaaaa, come to the dark side... :)
>>Now I'm thinking about a combat moves editor.
this is exactly the sort of thing i was talking about with my milkshape/blender comment above. obeying the first commandment, though shalt not reacreate the wheel, i figured to go with a proggie that people are already familiar with. of course, the creators of said programs might not agree, but i cant see why not, not if its good for them.
>>Have a complex editor available to the developer that uses a skeletal animation system. +
There could also be a simple combat moves editor presented as a gui for players...When executed, the combo would punch, do an aerial kick, followup with a spinning back kick, and then the combo is complete and back to player control.
good stuff
>>Giving the player this simple gui editor would allow them to make custom fighting combos in minutes that are always based on the character's current capabilities.
this gets me thinking, that the real meat of the coding would be linking the animations to the'symbolic' effects (to quote Adam's term) they represent in the game. after all the animation part has been thoroughly addressed, and theres my whole wheel belief...
Torque Owner Jeff Tunnell
After he showed it ot me, I was thinking of trying to evagelize somebody in the community to create a similar product for the TGE. If you can get together a team that has promise, we'll give you special attention for this project.
Jeff Tunnell GG