I was going to sum up the NYC Games Salon that I went to on 9 January, but: 1) I got into the Carnegie Mellon ETC in Adelaide, Australia which has thrown my schedule off-kilter with doctor's appointments, visa applications and the like, and 2) seeing as Gamasutra has already blogged it better than I would have been able to, I'll just refer you to that and point out two things that really, really bothered me:
The DWI Simulator's development started in Torque, until they decided it wasn't as good as they wanted, so they switched to a web-based Java app. What? As you programmers know, Java runs on OS X and Linux, and even Windows. As does Torque. The big difference? Java can run within a web browser, without installation. Torque, while required to run natively in a "full app" context, has significantly more graphical/input chops. It's better for full-fledged games, and could make the simulation that much more immersive, by not having to deal with the headaches of a browser paradigm.
As was evidenced when the Java-version of the game failed to run properly in his web browser. Now, he didn't say what, exactly, they didn't like about their Torque version, but I'd wager it has more to do with developer familiarity than any sort of defeciency in Torque. There's nothing wrong with being upfront about such unfamiliarity, but there is something wrong with asserting (without evidence!) that the pathetic Java3D toolkit could somehow make a better simulation experience than Torque.
And I realize that there was no actual Inspector Carbone game, it was still being designed, but I really don't like these non-material metrics for gameplay, we'll call them "Glue Points."
See, Inspector Carbone used a system of "Eco-Points" to represent several metrics: financial capability of residents, willingness to live greener, capacity for ecological responsibility education, et cetera. These nebulous points grew with time, but fell with upgrades. There's a flaw in the mechanics when a metric representing education falls after installing CFL bulbs.
I think that's just a symptom of the simulation being too simple. SimCity simulates urban development quite well, but it breaks simulation parameters up sufficiently to resemble real-life parameters. Taxes, energy, water, population, zoning. It all adds up to a realistic simulation, than if something like "City Life Points" had been used to "glue" several distinct aspects together.
Anyway, it was a great event and I wish I could go to another. Here's hoping one comes to Australia. :)
Thursday, January 18, 2007
Subscribe to:
Post Comments (Atom)
3 comments:
The DWI Simulation was not written in Java3D, i guess you missed that point of the presentation. The reason why Torque was not used was due to the fact that at the time of the presentation Torque did not support the Shaders we used in the simulation (motion blurr, etc.).
Also, we did not go into detail because it is bad form to trash someone product when it is still in development. Torque is a good app but was not a good solution for what I was developing.
Thanks for the post.
The lack of shaders, etcetera makes sense to me. Torque was significantly less mature back then. I guess my main beef (fuzzy as it is through the sands of time) is that the browser is becoming an awkward, unstable scaffolding upon which developers are cramming in full-fledged runtimes (Java3D, Unity, Flash).
If you can roll your app into a simple executable package and ship it that way, why bother with browser logistics? That was my main concern, or at least it's my main concern now. ;)
Thanks for the comment!
Well I see your point of view on the rolling into a simple executable. But, in some school environments the easy of having a web based simulation make the IT and implementation for a teach much simpler... or even an national or international organization can simply host the simulation.
Check out the finally version snap shoots.
http://www.vrshell.com
Post a Comment