[tcaudilllg]

The topic of this thread is to discuss the pluses and minuses of existing game creation systems, particularly with the intent of creating guidelines for the creation of a new generation of game creator systems that are user friendly and flexible enough to realize ideas with.

I'll start by sharing my opinions on what's been done been done in the past, and what went wrong.

Verge 1 - not flexible. Good for FFVI clones but little else. Tools are difficult to use and bug-ridden, so the actual creation of said clones requires a lot of expertise.

Verge 2 - too flexible. The tools issues carry over from VERGE 1.

Verge 3 - more complicated even than Verge 2. What it does have going for it are good tools.

SphereRPG - Good tools, but even less hand-holding than VERGE 2. Uses Javascript, which makes use of the notorious "undefined" keyword. Even putting a textbox on the screen becomes a chore.

RPGMaker (pre-XP) - Easy to use interface, but catastrophic limitation to DQ-style battles means every game plays exactly the same.

RPGMakerXP - Heard good things about this. Verge 3-quality tools and user access to program scripts. However, it is proprietary.

Zelda Classic - Does Zelda games well. Has been used for lots of derivative designs as well. Is still evolving.

OHRRPGC (Hamster Republic) - Still evolving. However it has many of the same issues as RPGMaker.

(Hajo's system) - Limited to 3/4 perspective. Good tools.

Ika - The same issues as with Sphere, but with fewer tools.



What exactly do designers need to realize ideas?

Two main formats, 2D and 3D.

• 2D format is used when realism isn't a factor.
  
• 3D games are used when it is.
  

The ideal GCS would be a 3D system which permits the positioning of the camera overhead. Yet, there is the problem of the designer's artistic ability: all 3D studio software now available requires at least a sense of proportionality to use effectively. The one advantage held by pixel art over all other forms is that anyone can draw it, because errors of proportion can be remedied with time and effort. A solution is needed for the proportionality problem if 3D art is to overtake pixeling in the mind of the indie designer. (although it should be noted that pixeling will still not be a completely lost art due to the use of textures).

Additionally, 3D art programs of the day have difficult, cumbersome interfaces, with little attention given to usability. It has become an expectation that 3D studio users will complete training to use the interface provided. A GCS should require minimal training -- every element should be as intuitive and fun to use as possible.

Game design is a gradual, evolutionary process. For every great leap, there is a bad game. Great games appear when someone takes a small step forward that had been apparent for a while, but was a little too radical for most to pursue. This is why games evolve relatively slowly -- few people have the ambition to push the envelope into a new stage of evolution.

To make an open source GCS successful, it is necessary to make the "envelope" as easy for enterprising designers to push as possible. I believe the key to this is modularity.

Rather than using a freeform "web" modular system, it would be best to use a top-down system that permits modules to be swapped in and out without impacting the function of the higher level modules. One approach to this system would involve using "layered" code -- lower level modules would insert themselves into higher level modules by "patching" the higher level module with their code -- kind of like the way higher layers are drawn over an image's lower layers: a greater whole is created, but the lower layers remain integral despite any changes to the upper layers. When lower-tier modules are switched out, the state of the code tree reverts back to the higher module's state. This would give flexibility while making the insertion of code relatively painless. It also maintains the divide between the programmer who writes the module, and the designer who assembles the modules into a coherent system. The designer is able to specify what the module does, and the programmer is able to code it to work with the existing system. The GCS would basically rely on snippits of code which are patched on top of each other at run-time, according to the designer's direction. The designer doesn't need to know how the module works, only what it does. This makes the design process simple and straightforward.

[Nodtveidt]

My two cents...

Whatever the case may be, I think it's important to have a system like this run on as many platforms as possible. So not only should the game system be modularized, but the tools themselves should be the same. Obviously a Windows version is only going to work one way (unless you really LIKE the headache of moronic toolkits), but other systems would probably require a GUI toolkit for an editor. A lot of users outside of the Windows and Mac world have this strange obsession with "user choice". :) So an editor made with one GUI toolkit isn't going to get along with users who hate that toolkit (example: I hate anything made with GTK or anything Motif-based, Qt is where it's at). Of course, you could always just make a Windows-based editor using the normal API like all smart Windows developers do and then just have any Unix users run it in WINE.

RPG Maker always had its game engine apart from the editor. Not all game creation systems are this smart. A good cross-platform library is best to use for this; I've become very proficient with SDL as of late, especially with knowing that the same C/SDL code can be built on virtually any system that supports SDL with the very minimal of changes (if any at all). Of course, this is another area where user choice and modularization might come into play; maybe the developer of the game wants to use another sound library, for example...the system should be able to link a different library, like FMOD or Bass. Of course, sometimes that will limit the portability of the production, but if the developer is smart enough to change the library, he will likely be smart enough to know that fact.

I have plenty more thoughts on this subject, as I've prototyped several RPG builder applications over the years, but I'll curtail further comments for now until any other ideas come through. :)
_________________
If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace

[tcaudilllg]

I have grappled with the platform problem for years. I don't think it will ever be resolved because there is too much money in it. Java is probably the most sensible solution because it is ubiquitous. If only Java would divorce itself from its programming language, it would reign. That language should have been made from the beginning with one purpose in mind, and that is to write compilers in other languages. I don't know who got the idea to affix a front end to the VM to the platform itself, but it is the single biggest issue facing that platform today. There are people who would be using the VM if not for the language: they dislike it and want to use something in their own style. This is what allowed Microsoft to overtake Java with their .NET framework, which today gives you a choice of, I think, three different languages -- all in the comfortable confines of Windows.

Java was the biggest disappointment ever. Stupid marketing decisions all around.

I think that the people who want platform universality need to take control of Java from Sun. Sun is already dedicated to improving the virtual machine and the development language. That's a fixture around which you can make a strategy: Sun is profitable, stable... 15 years since Java and nothing else in the Microsoft-free world has challenged its dominance as the universal one-world platform solution. I guess nobody can see the reason? Or is everyone still stuck on Sun as the "anti-Microsoft" despite the fact that if it did win against MS it would probably be everything MS was and probably worse? It's still a profit-driven company with the potential to become a harmful monopoly.

The way to work with Sun is to avoid indulging its mistakes. Java is ubiquitous and available for every platform you can think of. What's needed is acceptance of this ubiquity by compiler programmers, and the leveraging of it by creating programming language compilers specifically for the Java VM. If the VM becomes dominant, all of the other issues will eventually take care of themselves as all that energy pivoted towards Windows becomes instead refocused on the Java platform.

But what can we do? We're talking about making an RPG design system, right? Until something "happens" on the Java front, the project would be tasked with mimicking Java's own strategy of platform ubiquity by sheer force of portability, which would be more doable than you might think if the system took off. There are only, what, five platforms in use today including Java? Alternatively we could write one program in straight Java, but the ubiquity plan has more promise I think because it encourages growth and participation. Still, the aim might not be to have something ubiquitous, but just to create a standardization of RPG creators themselves through a common format which encompasses the modular architecture -- kinda like what's being done with Playstation emulators today, what with their "one-size-fits-all " plug-in architectures.

That's what we need to agree on: the architecture. Then we can create our own approaches to modeling it.

The architectural level, I think, should be something like VERGE: direct access to a virtual machine with dedicated functions. The virtual machine would be something like DirectX in that it does a lot of the memory management for you. There would be no memory management functions because the only functions needed would be understood and agreed on. If you wanted more functions, you would have to extend the virtual machine itself. Compilers could be written for specific languages which would compile source in those languages to the VM language. This would allow people to write in any language they wanted for the system.

There is a problem of the modularity, however: allowing many different languages means having to develop libraries specific to each language for use in the system. The system would use a JIT which would patch the modules onto the base codes, then compile the codes and run them on the VM.

The modular patching system would require something along the lines of phpBB's system, which uses a search-and-replace language to automate the editing on individual files. The patches, which would exist as distinct files, could be created by contrasting the edited text against the original: you would load a file and edit it, and then save those edits as a patch which could be applied at runtime by the system. In essence, it's an evolution of the phpBB system: instead of aiming for compatibility between patches which compete over the same source, the focus is on swapping patches in and out under the pretense that they are alternative manifestations of a deeper and more fundamental process. It would be necessary to exclude the replace function, however, because usage of it would mean entangling the designer in the intricacies of code. Each module should do something definite and clear so long as it is given a module; if the module below it fails, by no means should the module itself fail. The need for an error control system is apparent, although this would have to be a provision of the module writer.

[Nodtveidt]

Java is ultimately a poor choice for a number of reasons. Yes, it runs on a great number of platforms, but one thing to keep in mind that although it runs on many platforms, it runs poorly on many platforms as well...my system, for example. I think most non-Java programmers see Java as a last resort; an umbrella solution when all other quick solutions have failed or would require too much effort to implement otherwise.
_________________
If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace

[tcaudilllg]

Then I guess we're aiming for a specification, unless you can think of any other ubiquitous platform.

Java doesn't run that badly... in fact I think it tends to run pretty good nowadays that we've got 1ghz+ machines, and given the fact that faster technologies are used in the JVM.

But let's turn our attention to the specification. If the specification is good, people will at least aim for compatibility with it.

Minimum graphics routines: surfaces, polygon renders and animations; transitions; screen mode calls/window size setting.

Music routines: MP3, OGG, WAV.

Movie routines: AVI, MP4, FLV.

Standardized joypad routines, with plug-in extensibility. Keyboard interface; mouse interface.

Anything I forgot? Now that I think about it... why not give direct access to SDL? SDL does all of these, that I can think of... make a command in the VM language for each SDL function, and put these in the hands of the programmer.

The usefulness of a VM lies in the fact that interpretation is minimal and a lot of innovations in VM performance enhancement can be applied. For this purpose it is necessary to structure the VM to take eventual advantage of these enhancements.

Still I'm beginning to think that the VM isn't needed at all. What was needed was just that sequential patcher, for the simple reason that it divorces the designer from the programming. That is the key innovation, because it provides the means to using a compiler effectively without actually understanding the code. A recent development in emulation scene has been the abundance of emulators all of which use the same cores, but have different enhancement options. They are nothing more than Visual Basic projects which call upon libraries made in other languages. That is a factor of Visual Basic's enduring success, in that it acts as a glue for components made in more capable languages.

I'm seeing two elements in the design: the sequential patcher, and the use of tools which are capable of designing content specific to each patch level. This way the designer makes their content first, and then arranges the patches to process the content they have made. The designer needs to know only which patches to use for their specific content types, and which patches they patch. A top-down approach which can be organized with a tree-control.

Example:

• intention is to create a 2D sidescroller
  
• designer needs patches for sprites, 2D movement, classical physics, enemy scripting.
  
• designer loads in a base patch which defines the game loop.
  
• designer patches the base with AI modules, sprite modules, graphics loading modules, transition modules, movie modules, sound modules, input modules, and physics modules. Each of these modules is designed to deal with a properties list which is provided by their child modules.
  
• Property modules, which have been created with content creation tools, are patched into the modules which have responsibility for processing them.
  
• The game-loop source code is saved to a new file, patched sequentially from top to bottom, and compiled.
  

[tcaudilllg]

I've been looking into VMs. I think the most reasonable cross-platform solution involves implementation on both .NET/DotGNU and Java, between which I believe every base would be covered.

I hadn't heard of DotGNU. I'll have to look into it.

[Ninkazu]

What about LLVM or HLVM?

[tcaudilllg]

[Verious]

I don't think patching is a good solution because it introduces far too much room for errors and conflicting patches, which creates a very fragile system. A much better solution would be to create a plug-in based programming model, which could be hidden by very user-friendly interface for non-programmers.

The game designer could select the plug-ins they want to load and each plug-in could subscribe to the specific game engine events it wants to handle. The game designer would need to be able to prioritize the plug-ins in order to control the order of execution and the system would need to support event bubbling with the ability to cancel subsequent events. Functionally, it would be similar to event handling in the HTML Document Object Model (DOM).

By encapsulating functionality in plug-ins each piece can be individually tested and integration issues are minimized.

I would recommend using .NET (Mono on Linux and other platforms) because it is widely supported, has lots of great development tools (including Visual Studio), and supports more than 30 different mainstream programming languages (including C#, VB.NET, J#, Iron Ruby, Iron Python, etc.).

[tcaudilllg]

[tcaudilllg]

Assuming we did go the plug-in route, where would we go from there? That's another point I want to make: we could use the patch system immediately, with code we already have, while we would have to adapt code considerably more-so for use with plug-ins.

I'm really sold on the patch system because I think it's very elegant for how it separates the designer from the programmer without forcing the two apart completely.

Either system has specific merits, therefore why not let's provide for both plug-ins and patches in the same system? I for one wouldn't have a clue how to help with the plug-ins, but I could adapt existing code for the patch system. I suppose if you go one route or the other, you make it difficult for some people who want to contribute to actually do so.

I concede that the plug-in system would become extremely successful once you had a few dozen modules. There would probably be people using the system past that point that otherwise would not even be producing games at all. I can just imagine the stereotypical otaku-girl getting a kick out of this.

[Nodtveidt]

I would actually recommend against dotnet and mono for the same reasons as Java...widely supported sure, but low performance in many cases. Intelligently written C or C++ is going to be far more efficient. I would also avoid MP3 support. Yes, it's widespread and popular, but also proprietary and you limit the usage of the system by introducing it due to the maddening license scheme it carries with it. OGG is a good choice though, and you might also consider FLAC. And don't forget about the MOD and MIDI users. Of course, if the system were truly modular, the developer could add any library they wanted, including an MP3 library...by doing this, the licensing issue falls into their hands and their hands alone...the project and its maintainers are free from the grief.

Some people may argue against SDL, which is to be expected. But as far as complete libraries go, there's simply nothing better than SDL; it handles everything you need for a game engine and then some. Obviously DirectX is ultimately a better choice on a Windows system, but there's really not a lot of difference in terms of performance in Windows. For other systems, SDL really *is* the best choice available, especially in the case of X-less systems...building SDL for svgalib gives even those users access to the system.
_________________
If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace

[tcaudilllg]

How about this way:

• offer both plug-in interfaces and patch interfaces. We could do this by having separate top modules for either.
  
• open one main fork for .NET, while allowing forks for other platforms to register themselves as part of the project.
  
• make the thing LGPL, so that people can choose to buy their modules if they wanted to. In this way people who write code (like DevX) can make money. I don't think you can make extensions to a GPL project without making them GPL too, can you?
  

This way, the groundwork for growth is laid without ignoring the necessity of a default starting point.

I really don't see the need for a high-performance system at a time when acceptable 3D graphics are in reach for $150 tops. The age of expensive computing is over -- unless you are actually trying to compete with the big boys (which is kinda futile in its own right), decent enough 3D graphics are available to you with .NET.

I think MP3 support should be available through an appropriate plug-in; however OGG is clearly the best choice overall.

...I just wish there was a platform that everyone could agree on! It makes projects like this insanely difficult to get started. The platform issue is becoming the biggest waste of effort ever, in my estimation.

[tcaudilllg]

Anyway, let's look at the platforms involved:

• Linux
  
• Windows
  
• MacOS
  
• WindowsCE
  
• Android/Symbian/etc.
  

Java is the choice for the generic platforms, in my view. Linus, Windows, and MacOS all use different architectures. WindowsCE code also runs on Windows via .NET framework. .NET framework is all the four big platforms actually have in common.

There is something strange about the open source movement in that its representatives will not fight MS on its own grounds. MS is always trying to make its proprietary stuff the standard, while the open sourcers won't even unite around a plan to make open source software ubiquitous. Instead we see the open sourcers adopting .NET (half-heartedly) at the expense of any drive to create a rival ubiquitous platform. Windows-based PDAs aren't going anywhere -- they're gaining steam, in fact thanks to phones -- and still... I mean what the hell is going on? Are these people clueless or what? The whole field is pathetic, and hardware specificities reign supreme in an age where they have become functionally indistinguishable.

I would love to create a game that would run on everything, but it's just not possible without either making myself feel like a sheep for using MS tools, after they lied and cheated for years without ever repenting for it, or using a programming language that I pretty well despise. Or I'd have to make my own virtual platform. That would be an insane amount of effort and is not going to happen. I feel as though I am presented with the choose self-integrity or self respect, neither of which I feel I should sacrifice.

[Nodtveidt]

No, the real problem is that they try to fix a problem that doesn't exist. Any time you try to bring about some kind of platform-independent system, it's always going to have issues on one or more platforms. Furthermore, I already stated to you that this kind of thing always happens with community projects...people will always disagree on the details, and thus, progress is hard to make and sometimes even hard to get started.

In reality, there is absolutely nothing wrong with traditional development. The issue is with the programmers...they've become FUCKING LAZY and want the compiler and libraries to do all the work for them. .NET did little more than further this real issue...the system became a little easier to use, but introduced shitloads of dependencies and created a whole new throng of lazy fucks.
_________________
If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace