Warcraft 3 took over 4 years. Starcraft took 7. If you can ship a product when it’s done, you can do these types of things. If you are building your own technology, and you don’t have a ton of time and money, it’s not possible to get tools at Blizzard’s level.

When making a game, your biggest concern should be finishing that game. If you can’t put together a great game, then it doesn’t matter how good the mod support is. It won’t catch on and people won’t make mods. When you have a great product bringing in a lot of money, then you can spend a ton of time making a sequel with all the features you want.

With this approach, users don’t have to look at the codebase, but they still can reuse the game elements. But of course, the editor is more complex than just drag and drop.

Also, I’m not sure you have the right idea for starting a sequel. I’m pretty sure everyone always starts with the game code for the previous game. You don’t have to look at the old codebase because everything there is still there. If you decide that you want to get rid of something, you can delete it or change it.

If you are working with a scripting language or some sort of visual scripting language, you have no advantage in this situation.

I’m not sure your analogies are helpful in this situation. Game logic is complex interdependent systems. Obviously you should make everything as independent as possible and as reusable as possible, but I don’t think anyone has ever architected a system where you can just drop in components independent of each other and call it a new game. If such a system existed, it would be pretty horrible to work with because you couldn’t make any assumptions about what other systems are there and what sort of objects your characters are interacting with.

That was a great answer. There is something I want to note.

“You can share game code between games regardless of what method you choose. I’m not really sure what you are getting at with this point. Even if you aren’t using a scripting language or visual tool to define some behaviors, you should be architecting your gameplay code into reusable components as much as you can”
You are right. In the programmer’s perspective, either code or visual component is reusable. However, as you pointed out, the community might need it too. Also, I’ve seen a lot of games, the next sequel is just a difference in gameplay/graphics. I think by using visual editor will greatly enhance the productivity (also for other applications which are not games, I prefer to write code than drag and drop like in Visual Studio, since it is more controllable and faster), because we don’t have to look at the old codebase and manually take out what we need.

I can imagine the game engine is like the IDE for the game, pretty much like Visual Studio to the general application, where things can be dragged and dropped. Except Visual Studio is IDE for general application, while game engine is for game specific. What do you think about this?

I posted a question related to your article on Stack Exchange: http://gamedev.stackexchange.com/questions/17331/game-engine-and-data-driven-design

Please visit if you have time. I want to hear your opinion as well.

The problem comes down to the fine line that everyone keeps forgetting: Designers aren’t programmers. Don’t treat them like one – don’t give them a ‘development environment’ with a scripting language, and variables, and maybe even a debugger.

Programmers end up sitting there writing script hooks and designers sit their writing crap code that fucks everything up, then programmers have to come fix it! I always wonder why people do it to themselves?

Their games deserve better.

I guess a lot of these terms are quite new and need some time to be bandied about a bit before they’re given solid definitions.