Vaporware: how soon is soon enough?

[Alexander Morou]

Greetings,

I've been a part of the RPG Making Community since 1998 (I was 16 then), and there's one common trend I seem to see quite often: vaporware. While most of the time the folks involved mean well, I've always wondered, how soon is soon enough to showcase your project?

In 2000, I had a project called RPGCK, it went as far as a renderer and basic NPC/Dialog management, I even had the beginnings of an interpreter for my own language; however, it just never got done.

Over the past four years I've been working on software related to other areas, mostly focusing on refining the process of writing software that automates complex patterned logic, such as a parser compiler, and the code-generation that comes with it. The process of automating certain patterns comes into play for making games, if you want your game to be self-sufficient and not dependent upon a game.exe so that your resources are a bit better protected (since they're inside the .exe, or something else), is my major goal right now. I spent a good year and a half creating IDE abstractions so that I could create a program which could allow add-ins to inject new kinds of game types, map types, designers, and the general building blocks that make up a designer program in a way that was very simple and allowed for a consistent visual model.

I eventually plan on posting about my project, once all the grunt work is out of the way, but the main question is: when is soon enough and when is too early?

 

[Brewmeister]

If you were talking about marketing a game, you certainly wouldn't want to start 'hyping' it too early. And 'hype' seams to last shorter nowdays than it used to. I'm guessing maybe a month before release. How soon do the pros start hyping their games?

For here, this is more of a learning institution than a market. You could follow the guidelines for the project forums, which I think support the problem you've mentioned: projects fizzling out before they've even reached puberty, so to speak.

I think a lot of people make the same mistake (myself included) of trying to start developing a game in RMXP/VX, without much upfront planning. Quite honestly, you could spend more than half of development before even cracking open the game maker. Putting together a plan, developing characters & story, outlining mechanics, creating specs for artists & coders, blah blah blah...

A few paragraphs describing a story, a few characters & a list of planned features does not a project make.

I would be inclined to hold off until I have something rather substantial before posting a thread. i.e. a full story outline, a world map if even a sketch, demographics, back story, a list of features that actually support the story & the gameplay rather than a wishlist of cool scripts, fairly well developed characters, and a clear vision of the game mechanics, style, genre...
I would also probably want a fair amount of at least concept art.

Probably around the time where you're almost ready to fire up the game maker & start building, or shortly before if you want help hashing out any of the aforementioned up front work. Of course that all depends on how self-sufficient you are. If you need a lot of help and advice, post it sooner. I, personally would probably wait much longer... say shortly before beta testing before posting anything.

Sounds like you've been busy. Looking forward to seeing what you put up.

be well

 

[Perihelion]

I think a lot of people make the same mistake (myself included) of trying to start developing a game in RMXP/VX, without much upfront planning. Quite honestly, you could spend more than half of development before even cracking open the game maker. Putting together a plan, developing characters & story, outlining mechanics, creating specs for artists & coders, blah blah blah...

A few paragraphs describing a story, a few characters & a list of planned features does not a project make.

I've personally jumped the gun on that in the past, but I heartily agree. Thorough planning is an essential part of the game-making process, not only to ensure you're actually going to do something with it but also so you don't fuck it up and have to go back and change things later. My pipe dream game is never gonna happen, but pretending it is for a moment, I'm not touching a game maker until I know exactly what I'm doing. A complete scene-by-scene outline and a script for at least a good chunk of the game, exhaustively detailed notes on mechanics and worldbuilding, a goodly amount of graphics, diagrams of dungeons and puzzles, etc.

That said, there is merit in getting feedback on your ideas when they're still in the formative phase. Other people might point out things you missed or got wrong. Having a project thread can also keep you motivated to keep working.

As far as Alex's question goes, uh...I dunno, but I would err on the side of not overhyping it, especially since you're making a fancy programming thing nonemost of us don't understand. :scruff:

BREWMEISTER I DID NOT GIVE YOU PERMISSION TO EDIT MY POSTS MISTER

 

[Alexander Morou]

Well,

To put it simply, I'm fascinated with the act, and art, of automation. Instead of writing a single parser for a language, I myself would prefer, and am actively, to write a program which automates the act of writing a parser. In the case of making a game, instead of making a program where you double click on a map in the game project, and it shows the map editor; I would prefer, and have, to abstract the concept of a designer and the designed such that the elements involved can be interchanged without any real coding involved (in this case, meta-data would be used to associate actions, and images to designers, and images and designers to the designed). In the case of code generation, instead of writing a dozen or so specific blocks of literals, of a specific language ("if (" + condition + ')'), and only interchanging the parts needed; I would, and have, write a code generation framework that would construct syntactically accurate code every time, because instead of working with text fragments to build code, it uses objects (block.If(condition)), which are then systematically transformed into text with language specific translators.

All of these tie into the final project I'm interested in writing, a game designer which allows you to design plug-ins in the program, an abstraction of a scripting system which allows one to use one or more languages in their game, the ability to define new kinds of data so you can make your game the way you want and not have to embed the data of your customized battle's monsters into the script. I'm only halfway there, but I think it's worth the effort of the long haul. (It's important to stress that a large portion of this is still in the development phase, some of it isn't even that far, I don't want it to sound like an advertisement or hype, because there's a good chance a lot will change, especially given the title of the topic.

 

[Feldschlacht IV]

A complete scene-by-scene outline and a script for at least a good chunk of the game, exhaustively detailed notes on mechanics and worldbuilding, a goodly amount of graphics, diagrams of dungeons and puzzles, etc.

The problem with this is, at least 40% of this is going to change when it makes that transition from theory to practice.

 

[Perihelion]

A complete scene-by-scene outline and a script for at least a good chunk of the game, exhaustively detailed notes on mechanics and worldbuilding, a goodly amount of graphics, diagrams of dungeons and puzzles, etc.

The problem with this is, at least 40% of this is going to change when it makes that transition from theory to practice.

Depends on how good your planning is, but I agree in principle. I don't generally keep my outlines so rigid I can't change anything, but having a detailed outline when you're going into something as time-consuming as making a game is really helpful and will probably result in significantly fewer changes later and/or higher overall quality.

 

[Brewmeister]

The problem with this is, at least 40% of this is going to change when it makes that transition from theory to practice.

For an inexperienced game-builder, I'd agree. As your experience goes up, that percentage should drop quite a bit. You'll start taking the technical aspects into account during the planning stage.