I'd guess I'd wonder what tools a game designer would like to be using then? As a programmer, I have no problem implementing a game design in code to prototype it. I wouldn't mind a quicker route, but it's not mandatory.

But I'm thinking about non-programmers: if we were to imagine a "pure" game designer, what would their tools look like? I would imagine that for something like tile-based games, it would look something like RPG Maker XP or Tile Studio (though obviously Tile Studio just makes maps, it has no real gameplay authoring). I guess Gamemaker.nl would also be something like this, though it seems to have a relatively strong scripting bent, at least some kinda of dialog-driven scripting.

In other words, if you were looking to design a game within the constraints of a tile-based game engine (3D is still fairly open-ended for this question), what would the tools look like? What would the verbs and nouns be?

I'd see the obvious first step as having a grid and a palette of tiles and letting the user "paint" the playing field, ala Tile Studio. The second step, the more interesting step, is populating the game with "sprites" that have some kind of behavior (path-following, attack the player, NPC, pick-ups, power-ups, buttons, triggers, etc.).

What would be the next step? Motivations? Goals? This is where scripting usually comes into play, I guess...

IMHO this is kind of a dead-end area. Past a certain point, you can't design new, interesting ideas without needing new tools - which, of course, brings us back to needing programmer time to build those tools.

Sure, we could probably get a really rich package with tools like Flash, Virtools, and the various game-maker apps out there. But those have limited potential. If you want to design a multiplayer FPS, you're sunk.

Suppose we did build tools to let us design MFPS games, or whatever genre you like. At some point, new ideas in that genre (or new genres) will arise, and will be beyond the capabilities of the tools. So the designer, if he wants to see his ideas come to life, again needs a programmer.


The designer-programmer relationship is not a bad thing, and trying to eliminate it will only lead to compromises: either you have all design and no implementation, or fancy code with no gameplay, or a kind of lukewarm soup made of a little design and a little implementation - but no more than that, because one person can only do so much, after all.

The most effective way for a designer to realize his ideas is to work alongside a programmer who is skilled at rapid prototyping, and maybe someone who has mathematical skills in data modelling. (Never, ever, ever underestimate the power of Excel for designing games!) Sometimes, for compact designs, the designer/programmer can be a single person - in fact, that's common in the hobbyist and indie spheres. On the other end of the spectrum are mass commercial games, which may have two or three designers and dozens of programmers working on various things.


I may simply be biased by my own experiences, but personally I think a much more interesting question is "how can we reduce the round-trip time of an idea going between the designer and the programmer?" Techniques like data-driven design, high-level logic scripting, and compartmentalized abstraction in design are helpful, but I'm not convinced that there aren't other tricks out there waiting to be discovered.

Quote:

Original post by ApochPiQ IMHO this is kind of a dead-end area. Past a certain point, you can't design new, interesting ideas without needing new tools - which, of course, brings us back to needing programmer time to build those tools.

I wouldn't say I completely disagree with you (I am a tools programmer by trade), but I think that may be too narrow a view to be productive. Or rather, the wording you used may be less vague than you intended.

Ask an artist if they need more than a pencil (in regards to tools) to design new, interesting ideas. Of course not. Or think of a musician with a software synth. There are certainly tools in every domain that are capable of fully (or nearly so) expressing the full domain, both the known and the yet-to-be-invented.

The problem is that in games we don't fully understand our domain (or at least we're certainly not in general agreement on it). Of course, would could argue that a C compiler is all that one needs, but that's somewhat cheating as that's simply using one tool to build other tools.

Quote:

Sure, we could probably get a really rich package with tools like Flash, Virtools, and the various game-maker apps out there. But those have limited potential. If you want to design a multiplayer FPS, you're sunk.

Yeah. There's certainly no tools out there that address the multiplayer FPS game design... huh!? I guess you're indicating that the tools you mentioned don't necessarily address your example game, but I'd argue that Virtools would address it (though not necessarily with the performance qualities of Unreal3, for example).

Quote:

Suppose we did build tools to let us design MFPS games, or whatever genre you like. At some point, new ideas in that genre (or new genres) will arise, and will be beyond the capabilities of the tools. So the designer, if he wants to see his ideas come to life, again needs a programmer.

I think that's more a product of the current/past thinking on how game tools are built. Most, when they think of game tools, they think of level editors targetted toward a specific game engine. That's essentially what you describe above. But I've worked with tools that are game engine agnostic (though they still required programmers).

My point is that I think there clearly exists (or could exist) a tool that allows people to work in the design space with fairly ample freedom without being programmers.

Quote:

The designer-programmer relationship is not a bad thing, and trying to eliminate it will only lead to compromises: either you have all design and no implementation, or fancy code with no gameplay, or a kind of lukewarm soup made of a little design and a little implementation - but no more than that, because one person can only do so much, after all.

I'd argue not that a designer/programmer pairing is advantageous, rather that the skillset of a good game designer includes the fundamentals of a good programmer (algorithms, data structures). I don't believe that programming as we normally understand it (C++, VisualBasic, Java, Lisp, Python, whatever) is a critical ingredient.

Quote:

The most effective way for a designer to realize his ideas is to work alongside a programmer who is skilled at rapid prototyping, and maybe someone who has mathematical skills in data modelling.

I'd agree that this is a effective way for a designer to realize his ideas, and it may be the the best way currently, but I see that as a failing of the tools we have now, not an intrinsic quality of the game design process.

For example, 30 years ago it was unthinkable that an artist would author their own procedural shaders or other high-end CG materials. Now, even in the game space with it's notoriously ad-hoc and broken tools, artist-driven shader authoring is expected. I believe we'll look back on game design in the same way.

Quote:

On the other end of the spectrum are mass commercial games, which may have two or three designers and dozens of programmers working on various things.

And tell me honestly, are those programmers really working on stuff that couldn't/shouldn't exist in some toolset with a usable UI on top of it? In my experience, it is incredibly rare that I find programmers actually working on anything unique to their game that couldn't be more effectively authored at a higher level with the appropriate tools.

Quote:

I may simply be biased by my own experiences, but personally I think a much more interesting question is "how can we reduce the round-trip time of an idea going between the designer and the programmer?" Techniques like data-driven design, high-level logic scripting, and compartmentalized abstraction in design are helpful, but I'm not convinced that there aren't other tricks out there waiting to be discovered.

I would certainly agree with that sentiment. And I believe that's the genereal view of most programmers out there worth their salt: how do you decouple the engineering effort from the content-creation effort? My opinion is that the most decoupled you'll be able to get it is to eliminate the engineering effort from the equation, and make the game design process one of pure content-creation. (And I use the word content here as inclusive of gameplay.) I don't think that game development is necessarily an engineering problem. I think it currently is an engineering problem because resources have simply not been dedicated to removing the engineers from the equation (because engineers are typically integral to game team decisions, no one wants to take the long term view that their job should be eliminated/minimized).

Clearly I'm not advocating the elimination of engineers from the industry/medium of game development, just advocating/suggesting that engineers shouldn't necessarily be part of a specific title's development effort. (And of course, I'm speaking in the long term -- obviously, for today's AAA titles, programmers are integral because, as iterated above, the tools don't exist -- yet!)

I suppose I should clarify: when I talk about tools I don't mean special-case, one-off, per-project tools (or even highly domain-specific tools like level editors, 3D modelling packages, etc.). What I was referring to in that post was turnkey, build-everything-in-this-package systems like game-makers. Of course tools of some kind exist for working on FPSes... but I'm certainly not aware of any "idea goes in here, FPS comes out here" turnkey package.

In fact, in terms of turnkey solutions, I think that's a bad direction to take for tools. Since the programming becomes homogenized between all games produced by the tool, the potential range of features is limited. Sure, you could expose the underlying engine to allow extension with new visual effects, AI logic, or whatever - but at that point we're no longer in turnkey land, and we've yet again opened up the need for specific programmer effort to further the field of FPS games.


Outside the realm of turnkey packages, though, I absolutely agree - current production-assistance tools tend to leave a fair bit to be desired.

Again, maybe I'm biased from what I've done, but I do believe that many people rolling their own engines and such (at least in the commercial space, vs. the hobbyist space) really do need to do so. In cases where a new engine isn't actually warranted, engine licensing has long since filled that niche; we don't really need a "FPS engine maker tool" because we already have a solution to that problem, which works quite nicely.


Maybe I'm career-suicidal, but I've actually been working specifically on production-assistance tools that will minimize the amount of "programmer time" needed to produce a given chunk of content. They're all highly domain-specific, even game-specific, but I'm not sure that's terribly important at the moment. Another member of our team is working on a closely related project and his toolset has already radically changed the way things are done in the content pipeline.

In some ways, we're really just catching up with what many houses have known for years: that the engineer-artist dependency can be reduced quite a lot with proper data-driven systems and high-level abstractions. But it's an interesting trend.

Despite the direction we're going, though, I really don't see things making the huge leap from domain-specific, production-assistance tools to general-purpose tools. The realm of "general purpose" is simply far too large; a tool that, say, 75% of game developers could make use of is going to have to be so generic that it requires a fair bit of work to tailor it to domain-specific uses. (All general, domain-agnostic tools I know of work this way.) So at that point you're back to needing dedicated effort to bring tools up to the game design's level. Maybe not necessarily programmer time, but highly technically-skilled time at the very least.

Combined with the natural inertia of us engineers trying to keep our jobs, and I'm not sure we'll ever see such tools emerge, let alone complete turnkey solutions for larger-scale game genres than tile-based RPGs.

I don't know... I think we may be giving our "tech" too much credit here. From my experience, at the game design level, games simply aren't that different from each other, even across genres. I do believe a "turn-key" solution is possible, as much as a turn-key solution is possible for 3D modeling packages (Maya), digital art (Photoshop), or video editing (Avid).

You keep using FPS as an example, which leads me to think we're talking about two different things, as we've practically had turn-key FPS solutions for a decade. I would argue that any company/individual writing their own FPS solution for a commercial product is not focused on game development but rather game tech development. See Unreal3, Doom3, Crytek, and Source. Maybe you don't consider those turn-key solutions?

Quote:

In fact, in terms of turnkey solutions, I think that's a bad direction to take for tools. Since the programming becomes homogenized between all games produced by the tool, the potential range of features is limited.

I don't know. I think that's like saying "because all movies are made with cameras the type of film you can make is limited." I understand your argument from a technology perspective, but from the perspective of producing games I don't think it stands.

Quote:

The realm of "general purpose" is simply far too large; a tool that, say, 75% of game developers could make use of is going to have to be so generic that it requires a fair bit of work to tailor it to domain-specific uses. (All general, domain-agnostic tools I know of work this way.) So at that point you're back to needing dedicated effort to bring tools up to the game design's level. Maybe not necessarily programmer time, but highly technically-skilled time at the very least.

To be clear, I'm not proposing a single end-all-be-all tool... even word processors continue to have new features/versions these days. But, word processors generally function in a universal way, compatible with typewriters and desktop publishing software alike. The same applies to cameras, paint, Photoshop et al, and programming languages. You can have both a general tool and an evolving tool. Right now, as you pointed out, we largely have a lot of specialist tools, very few of which are devoted to "game design" and rather are devoted to specific domains of game design: levels, AI state machines, particle effects.

Of course, we're likely talking about slightly different points within different contexts. I'm thinking from the perspective of the author (game designer), and I am specifically thinking of what he's trying to accomplish and how to enable that. Of course, other tools would be involved for various components (artwork, audio, animation, whatever), but the assemblage of these components, the authoring of *gameplay*, is something that should be strived for. Considering that the end product is fairly well-defined (look at the last 100 games you played and tell me it's not!), I don't know why the toolset cannot be so equally.

I wouldn't consider licensed engines like Unreal to be turnkey FPS solutions, no. My acid test is fairly simple: could an average 12 year old produce a playable game all his own using the package? If so, it counts as a standalone turnkey solution. Most game-maker tools satisfy this need quite well, and as such, I think they're relatively good solutions to the "general game design tool" problem in their respective domains.

However, I don't see the average 12 year old being able to produce his own game - one that obviously isn't a miniscule mod - given nothing but the Unreal engine sources. It's a huge job going from a licensed engine to a full game, and one that requires a lot of programmer effort. Many licensees do heavy retooling to the code they license - some much heavier than others, obviously, but this all requires code work. Even in cases where the original engine doesn't need modification, integrating custom gameplay into a licensed technology is far from being a programmer-free experience. That's why we're not seeing a lot of arts and writing majors using Torque to produce their own RPGs, for instance.


Now, I totally agree that it's possible to get closer to a turnkey solution in the sense that I'm thinking of the term - a package where I just cram in my art, story, and a little gameplay logic, and poof - out comes a finished game. The model of the RPGMaker type apps is what I'm comparing with here. I definitely think it would be possible to do something similar to RPGMaker in the domain of, say, multiplayer FPSes.

However, I'm not convinced that it would be a good idea. The MFPS genre is huge (technology wise), and involves a lot of rapidly-moving technology. The leap from sprite-based 2D engines to 3D engines is absolutely massive. Worse, the age factor is much more significant in the 3D world. While a 2D sprite game is more or less immortal (aside maybe from minor art quality/resolution issues) at this point in history, a 3D game can go from cutting-edge to dated in 18 months. And a turnkey system that produces nothing but "really dated" graphics is not going to sell well.

Of course at that point we recreate my quandary from earlier: if I want to update the graphics technology, I have to have access to 3D programmer time. Now maybe the producers of this turnkey package are doing that for me, which would be cool, but it's going to mean that the license for this thing costs a lot - which in turn removes it from the playing field for most hobbyists and people who aren't deeply invested in programming technology. So it kind of shoots itself in the feet at that point.


This just strikes me as a really hard problem. I think the core difficulty here is that "game design" and "implementation of game design" are not orthogonal problems at all - they're deeply intertwingled (I've always wanted to use that word in a sentence...). And since implementation is heavily tied to programmer time at some point, I think it may be impractical (albeit not theoretically impossible) to try to totally divorce programming effort from design effort. A design is nothing unless it is realized, and yet realizing a design needs programming. At the very least it needs high-level game logic programming (even RPGMaker needs some of that).

So to be honest I don't really know what might be possible here, but I don't envy whoever tries to build such a tool - IMHO they're in for a very tough fight. It would be pretty cool have, though [smile]

Quote:

I wouldn't consider licensed engines like Unreal to be turnkey FPS solutions, no. My acid test is fairly simple: could an average 12 year old produce a playable game all his own using the package? If so, it counts as a standalone turnkey solution. Most game-maker tools satisfy this need quite well, and as such, I think they're relatively good solutions to the "general game design tool" problem in their respective domains.

Well that certainly does clear things up. You mean turnkey for an individual, non-professional game developer, and here I was thinking you meant turnkey in the context of our dayjobs.

So, your turnkey definition actually lines up closely with what I was originally proposing. And you're right, for 3D games it's certainly harder because we can't say yet that 3D is aesthetically "complete" -- not yet. This generation is making a pretty serious stab at it, at least as far as the average consumer is concerned.

But I think that largely has to do with the fact that people, in the role of designer, are not all that great at working in full 3D spaces through 2D interfaces (the computer). Also, the art requirement is several orders of magnitude higher (for the average computer user), basically putting it in the hands of technically trained modellers.

I think that with the increased capabilities of hardware 5 years down the road, and with an appropriately rich source of "stock" content, we could get closer. But it may be another decade for this approach to work in AAA-quality 3D.

Now 2D... that's very well-defined. I think that packages like RPGMaker et al could be far less genre-specific *and* far simpler.

Quote:

So to be honest I don't really know what might be possible here, but I don't envy whoever tries to build such a tool - IMHO they're in for a very tough fight. It would be pretty cool have, though [grin]

I'll send you a free copy when I finish it. [wink]