[tcaudilllg]

I am lazy. I admit it. I'm one of the laziest people you will ever meet, at least when it comes to programming.

I don't even know where to start. What should I do? What should I use? So many options and none are a perfect fit!

We should make the kit on an SNES ROM. Those will run on anything.

Why not XULRunner? That runs on everything, doesn't it?

[Mattias Gustavsson]

[tcaudilllg]

OK another question: who is interested in pursuing the plug-in idea? Would the community be interested in collaborating on the design and implementation of a GCS?

[tcaudilllg]

I do intend to produce a GCS myself. What I will do is this: I'll make a GCS using the patch idea (the plug-in idea is way too difficult for me -- I don't have the time to learn all this new stuff when programming isn't really my vocation anyway) and it'll have the warts it does. I don't have the expertise to do the 3D engine, so my version won't have that. This is too much for one person to do anyway. But, maybe someone will build something better based on my design. Maybe.

I'm really thinking Flash is the ideal platform. Seriously.

Update: I've been thinking a little more and I think XULRunner could just be the ideal platform. The engine could be designed, in fact, as a Firefox add-on. This makes it immediately accessible to anyone. I believe CANVAS can do pretty much anything we require. There are arguments for the slow speed of Javascript BUT the truth of the matter is that people who rely on this system are always going to be a bit behind the curve anyhow. If they were in step with the curve, they would, like most of you, be working in the industry. So we really don't need to worry about inhibiting the user's "potential".

Update: I just read this, and it changes EVERYTHING.

http://blog.wolfire.com/2009/09/preview-of-webkits-webgl-canvas3d/

There is no reason not to do this project completely in HTML 5. Every capability we need is there. I think this idea can work. We don't have to play the platform game, because a higher power has intervened and made the platform question moot. I've also checked out the audio capabilities of HTML 5 and not only are they better than IE's (you can preload all the files before you play them with naught but a command!), they are integrated in both Firefox and Google Chrome.

The only thing it doesn't handle is client-side saving -- but the add-on system can take care of that.

We might also be able to get some help from the open source community with this tack. I think a lot of people would be interested in making a viable game platform on Mozilla.

[Nodtveidt]

I recently deleted Firefox in favor of Opera, so I'm out on this angle.
_________________
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]

[Mattias Gustavsson]

If you're concerned about keeping this thing portable, why not just use C and a multi-platform graphics/sound/input layer (like SDL).

C is probably the most portable language out there - there's compilers for pretty much everything - and it will also run on low-end devices (being fast enough and having low memory overhead and no large runtime required).

You could add your scripting language of choice to the system - be it an existing one or a custom one - and that would be what you used for creating games. You'd make your own UI widgets, ones that work well for your purposes, and they'll look and work the same on all platforms.

The other things you've suggested here will most likely be orders of magnitude more difficult to get running, and even if you do, they will most likely have built-in limitations that you won't be able to work around.
_________________
www.mattiasgustavsson.com - My blog
www.rivtind.com - My Fantasy world and isometric RPG engine
www.pixieuniversity.com - Software 2D Game Engine

[Hajo]

C definitely is very portable. For closed source project it has the drawback that one must provide binaries for all kinds of systems. Open source is easier, people can compile the sources themselves.

Interpreted languages/virtual machines are better in the aspect that one bytecode can be run on different architectures, and the creator doesn't need to care about providing binaries for all the platforms.

Java was mentioned somewhere above in this thread. For many projects it looks like a good compromise to me, but as soon as one starts to bundle libraries, like OpenGL bindings, one needs to provide different packages for different systems again and the benefit of "one package runs on all platforms" is gone.

[tcaudilllg]

The only thing that can satisfy everyone is sheer manpower. That's why a prototype needs to be completed first.

Questions that need to be answered:

• how to design the interface
  
• what tools are needed
  

Really right now things are changing so much -- the whole platform scheme of the past 20 years is dying before our eyes thanks to increased standardization and virtualization. It almost doesn't matter which platform a person uses anymore, because it can be emulated on any other platform. Although this admittedly is not yet completely true, it probably will become true over the next couple years at the rate things are going.

So let's just leave the platform issue to the side and concentrate on how to design the thing.

First question

• what could we do to make game design easier for us?
  
• what could we do to make game design easier for other people?
  

[Hajo]

Game design is in large parts independant from platform or language questions.

- Game idea/vision
- Game design
- Game implementation
- Game distribution/installation

The upper half of these steps is mostly system independent. The lower half is system dependent.

We have very few or even no tools or measurements to help with developing ideas, and onyl few to help with designs.

On the other hand we have editors, libraries, toolkits and such that help with implementation, and also installation.

I'd be interested in things that help me with the first two steps, creating a vision and converting this vision into a good design.

[tcaudilllg]

Good ideas can only be had through exhaustive exploration of available possibilities, combined with a sense of openness and, probably, humility. Openness to considering the situation as it really, completely is, and not how you'd like it to be. Ideas which are completely responsive to real conditions always turn out good in the end.

It might help to have a system by which ideas themselves could be represented in terms of their hierarchical substructure, looking at them from a purely cognitive, progressive perspective. A concept tree design.

If anything, one needs training to be a good designer. Training in game balancing, training in game mechanics.... At root, games are interactions between moving actors, which are defined by changing actor properties dependent on the actions made and the actors involved. To facilitate thinking in this manner, you might have a tree of all the actors, with the option of defining events for each actor. Each event would be branch, which would have as its branches the actors who are specified as interactors for the event.

For example, say Mario has an event called stomp. The stomp event is registered as being applicable to actors of type goomba and koopa troopa. All events are collisions, of course, so you would essentially define events as general collisions or collisions from certain directions. This way you don't even need to do collision detection in code, because there is no case in which you have an event without a physical collision with something or another. (with the exception of "watch" events like time overs).

To make things easy, you'd want to distance the user from the keyboard as much as possible. You'd also want to reduce their reliance on their own memories, giving them lists of all available options. You want to keep learning to a minimum, so that experimentation is as unencumbered as possible.

[tcaudilllg]

One thing I've been reflecting on: programmers like memorizing things. They like having to recall long chains of operation: they can see a variable and remember immediately all its previous forms, dialing back through its history reference by reference. For this reason, making a development system that is "fun" for programmers necessarily creates a system that is "not fun" -- even difficult -- for the non-programming inclined. The reverse is also true: programmers will not enjoy using a "hand-holding" system, no matter how powerful it may actually be compared to a programmer-mentality centric presentation.

VERGE was created by programmers for programmers. That was its critical flaw, in that programmers will not hesitate to use more mainstream methods like libraries and compilers to produce games. Like Grenadier said, in the late 20th century there were few free libraries available for game design purposes. VERGE 2's success was a reflection of this scarcity, not of the system's utility. VERGE 3 was faced with the situation of programmers all of a sudden having gobs of C/C++ development libraries to choose from for every platform, and no compunction at all to rely on VERGE's notably idiosyncratic system.

[RampantCoyote]

[tcaudilllg]

What I meant to say is that the really exceptionally talented programmers -- the ones who eat, sleep, dream programming -- get their kicks from going through things step-by-step. They actually like going through the motions and performing complex tasks.

I would define you as a designer, not a programmer. To you, programming is just a means to an end. You can't tell me that you get a thrill out of writing recursive loops; doing test-driven design; etc. Certainly not as much as Nodtveidt does, or the VERGE programmers.

Obviously ideas must be thought through before you can know their merits.

There are many times that I've resorted to the brute source method of proposition investigation. It's no different than considering every available plan, or going over every available funding source when trying to figure whether a plan is feasible. When you take shortcuts, you are left with less than optimal results.

I'll say this: had there been more brute force idea investigation over the past few years, the unemployment rate just might have turned out a good deal lower.

[Mattias Gustavsson]