I get it. I get what put me off about ATITD. It's a manual labor simulator.
Humanity went through the industrial revolution, then the information age, and now the internet age, all so I can pay $14 a month to simulate the life of an Egyptian laborer. I'd rather pay Blizzard to let me pretend to be a dragon-killing hero, or CCP to make me an internet spaceship captain.
Wednesday, December 16, 2009
On virtual goods
Here is what I don't get about companies that sell virtual goods: My "virtual credit balance" is just a number in your database. You want me to pay real money for you to change that number. It's just a tiny piece of data that has no effect outside the virtual world. Why would I want to do that?
"But wait," you say, "what about a bank account balance? Isn't that just a tiny piece of data too? And people work very hard to change it!"
True, but that number represents the full faith and credit of the bank, from which I can withdraw real cash to exchange for real goods and services.
OK, decorating my virtual fishtank with a different background image is a kind of real service, in that it affects the pixels on my monitor (and yours, when you come visit on account of some made-up fishtank crisis). But I personally do not a attach a very high value to this service.
"But wait," you say, "what about a bank account balance? Isn't that just a tiny piece of data too? And people work very hard to change it!"
True, but that number represents the full faith and credit of the bank, from which I can withdraw real cash to exchange for real goods and services.
OK, decorating my virtual fishtank with a different background image is a kind of real service, in that it affects the pixels on my monitor (and yours, when you come visit on account of some made-up fishtank crisis). But I personally do not a attach a very high value to this service.
Game Review: A Tale In The Desert
I've been meaning to try A Tale In The Desert for a while now, since it's a fairly successful MMORPGs with a truly deep crafting system (the other one being Star Wars: Galaxies, which won't install for me anymore). I just downloaded and played the starting-island portion over about three hours. Unfortunately the UI is really annoying so I won't put more time into it.
Strengths
Another resource you need early on is grass. You can pick grass anywhere the ground is green, but each time you pick up a handful you have to wait a few seconds for the character to animate, then move aside and click again. The gathering animations should be interruptible. Or, if the goal is to limit the rate of gathering, then you should be able to "batch-gather" a large amount of the resource with a single mouse click, like WoW's "make all" button. (edit: apparently there is a way to automate grass-gathering during times you are offline, but you first have to gather 2500 units by hand!)
Along the same lines, there is no automation for "processing" steps like cutting wood into boards. You sit there clicking, waiting for an animation, clicking, waiting for an animation, etc. Worse, the blade breaks every so often (for no apparent reason), sending you on another shale-finding quest. I can understand exposing players to these mechanics temporarily, but not on a long-term basis. You should reach a skill level that allows some automation or batch-processing, or at least invent a little point-and-click game (with decreasing difficulty as your skill increases) to control the frequency of success and failure.
If the native widgets aren't ideal for your intended use, then go ahead and write your own custom widgets, but be careful and design them well (good examples are the custom GUIs in certain 3D apps like Lightwave and Houdini).
Just keep in mind it's incredibly tough to correctly handle all of the corner cases and behaviors that users expect from modern widgets. Sure, your homemade button works when I click it, but what about keyboard focus? How does it move when I scale the containing window? Does it work well on a tablet PC with a touch screen? A PDA with a stylus? Does it handle Unicode text rendering? Right-to-left languages?
Widgets that get this stuff wrong feel unpolished. Like, for example, ATITD's windows, which you can only resize by dragging a pixel-wide line somewhere in the interior, or the super-annoying pop-up notifications, which appear directly under the mouse cursor, preventing you from clicking nearby until you dismiss the pop-up.
It's a shame the UI is so annoying, I was really looking forward to seeing some more advanced features. For instance, check out the ATITD wiki page about plant genomics!
Strengths
- The crafting system is indeed deep. Basically the entire game is about making stuff. You gather resources (modeled nicely and placed throughout the world) and build tools (also nicely modeled) to transform them into ever more complex products. The starting-island tutorial is basic but I read some fascinating things about advanced crafting on the wiki. For instance, you can grow grapes and make wine, but first you can try cross-breeding grape strains to get seeds with better growing properties, and during the growing season you take a series of actions to "tend" the field, which affect the final quality of the wine produced. ("Product quality" seems to be a good way to add depth to crafting - SW:G uses this too - but obviously it complicates the server since it can't treat all instances of an item type as fungible).
- No combat, although there is PvP in the form of competing for achievements. ATITD proves that there is actually a good middle ground between purely social "chat rooms" and purely combative PvE/PvP games.
- It's a grind.
Another resource you need early on is grass. You can pick grass anywhere the ground is green, but each time you pick up a handful you have to wait a few seconds for the character to animate, then move aside and click again. The gathering animations should be interruptible. Or, if the goal is to limit the rate of gathering, then you should be able to "batch-gather" a large amount of the resource with a single mouse click, like WoW's "make all" button. (edit: apparently there is a way to automate grass-gathering during times you are offline, but you first have to gather 2500 units by hand!)
Along the same lines, there is no automation for "processing" steps like cutting wood into boards. You sit there clicking, waiting for an animation, clicking, waiting for an animation, etc. Worse, the blade breaks every so often (for no apparent reason), sending you on another shale-finding quest. I can understand exposing players to these mechanics temporarily, but not on a long-term basis. You should reach a skill level that allows some automation or batch-processing, or at least invent a little point-and-click game (with decreasing difficulty as your skill increases) to control the frequency of success and failure.
- ATITD uses its own widgets and controls for the GUI, but implements them poorly.
If the native widgets aren't ideal for your intended use, then go ahead and write your own custom widgets, but be careful and design them well (good examples are the custom GUIs in certain 3D apps like Lightwave and Houdini).
Just keep in mind it's incredibly tough to correctly handle all of the corner cases and behaviors that users expect from modern widgets. Sure, your homemade button works when I click it, but what about keyboard focus? How does it move when I scale the containing window? Does it work well on a tablet PC with a touch screen? A PDA with a stylus? Does it handle Unicode text rendering? Right-to-left languages?
Widgets that get this stuff wrong feel unpolished. Like, for example, ATITD's windows, which you can only resize by dragging a pixel-wide line somewhere in the interior, or the super-annoying pop-up notifications, which appear directly under the mouse cursor, preventing you from clicking nearby until you dismiss the pop-up.
It's a shame the UI is so annoying, I was really looking forward to seeing some more advanced features. For instance, check out the ATITD wiki page about plant genomics!
Game Review: Galactic Civilizations II
Galactic Civilizations II was developed by a small team at independent studio Stardock. It's a sci-fi 4X game, essentially "Civilization in space," or an evolution of the Master of Orion series.
Strengths
Strengths
- The beginning is always peaceful. This is a great feature! One of the most annoying things about Civ games is the tremendously unbalancing effect of early battles, like having your settler taken out by barbarians or conquering an enemy city before their defensive unit moves into place. In GalCiv, you have to get pretty far into the technology tree before you can build units with any offensive capability whatsoever, and the techs that enable you to invade other planets are even deeper. This ensures that all players have some time to expand freely without worrying about military threats.
- The AI doesn't cheat (at all but the highest difficulty levels). Stardock put enough effort into the AI to make it competitive without giving it unfair advantages in economy/tech or the ability to peek at your map.
- Turn-based action is addictive. There is something about quantized jumps of progress that make the action more addictive than a real-time game. This is the same principle behind the prevalence of numerical levels in RPGs (compared to continuous skill improvement). I think it has to do with the "rush" you get from large spikes in activity, which you wouldn't get from continuous evolution.
- The first couple of turns are the most exciting. It's fun to uncover nearby plans and imagine the possibilities for developing them (and how to stop the AI from getting there first!). I think this is because I'm an "explorer"-type player.
- The technology tree is very well-designed. Aside from the late-starting offensive techs, I also like the rock-paper-scissors aspect to military techs: there are three kinds of weaponry and three kinds of defenses, each specialized against one of the weapon types. The techs are sufficiently resource-intensive that you can usually pursue only one line of development. This mimics real-life arms races where new technologies are developed specifically to counter the opponent. Also, in an expansion pack, Stardock added unique tech trees for each race. This makes game-balancing a lot more difficult, but if you can pull it off (e.g. Starcraft), the variety contributes a lot to replayability,
- The map view is cluttered. When zoomed in, it's difficult to see smaller ships and distinguish their nationality. The schematic zoomed-out view shows ships much more clearly, but is cluttered by the large number of trade-route freighters all over the place.
- They still haven't solved the micromanagement problem. I always bog down and lose interest in the later stages of 4X games. The ratio of management effort to turn duration grows beyond what I'm willing to tolerate. I make strategic mistakes like not searching the map for sneak attacks while clicking through turns waiting for a tech to complete. The game needs more powerful automation of planet development, and some ways to direct your attention to important spots on the map (like a "proximity alert" when an enemy unit pops up well behind the front lines).
The New Client Application Landscape
Back in the early 2000s, selecting a development platform for client software applications was easy. You wrote C++ code using the native OS APIs (Win32, Carbon, X11) or thin wrappers on top of them. It also became practical to write clients in higher-level languages like Python or Java, provided you were willing to put up with some rough edges in the implementations of GUI toolkits and cross-platform issues.
There's nothing fundamentally wrong with these platforms, and despite all the hype about web applications taking over the world, I think it's perfectly reasonable to develop new client software with them (provided you "pay your taxes" to keep up with modern OS requirements like packaging systems and user data persistence). In fact, good cross-platform toolkits like Qt and WxWidgets have made OS-native client development easier over time.
However, as I consider developing a new, graphically-intensive client program intended for a large user base, I feel obligated to look at browser-based platforms, specifically Flash and JavaScript.
Flash
The Flash Player has already become popular as a game client platform, notably for Zynga's Facebook games, and even some MMOs. It has no standards-compliance issues because there is only one canonical implementation. Its sound and graphics features are solid and well-optimized, although the 3D API is still pretty limited. There are some GUI controls libraries for Flash, but they are not as well-developed as those in a desktop OS or a good JavaScript framework.
JavaScript
From a desktop developer's point of view, JavaScript is essentially a bare-bones scripting language interpreted by the browser, coupled with a small "standard library" including an API for manipulating the browser's layout and display engine (the HTML DOM). JavaScript applications work by pretending to be a web page with various elements that appear, disappear, or move around according to the script. There are many "widget libraries" for JavaScript that emulate desktop GUI controls to some degree of success. Although JavaScript-based controls sometimes feel clunky, it's important to remember that you get the full benefit of the web browser's page-layout engine and its HTML controls (buttons, sliders, etc) for very little code. This could be a powerful advantage for writing GUIs that make heavy use of traditional desktop-style controls.
Future browsers will (hopefully) also include WebGL, a complete JavaScript interface to OpenGL which renders into an HTML canvas. In theory, you could port most sophisticated rendering code, like a modern 3D game engine, to this interface. Unfortunately, WebGL is just an emerging standard and there is a risk that browsers won't ship it widely or support it well. It could join the long history of widely-promoted but seldom-implemented standards like VRML or the non-audiovisual parts of MPEG.
Limitations of the browser as a platform
Flash and JavaScript both have some important limitations:
In the end, the decision of which platform to use will depend on a few factors:
On the server side, not much has changed over the last few years. The first tool I'm going to reach for will still be Python, writing directly to the Linux POSIX APIs. Python has a rather nasty (though constant) performance penalty versus compiled code, but I can usually get around that by selectively translating critical sections into C.
(The only situation where this approach might fail would be a system that had to run arbitrary, hard to vectorize scripts very very fast - something like a game engine simulating a large number of independent AI agents. In this case you might need to look into a more JIT-oriented platform like Java. However, without going this far I think it's possible one could get the performance penalty low enough to make it reasonable just to throw more hardware at the problem.)
There's nothing fundamentally wrong with these platforms, and despite all the hype about web applications taking over the world, I think it's perfectly reasonable to develop new client software with them (provided you "pay your taxes" to keep up with modern OS requirements like packaging systems and user data persistence). In fact, good cross-platform toolkits like Qt and WxWidgets have made OS-native client development easier over time.
However, as I consider developing a new, graphically-intensive client program intended for a large user base, I feel obligated to look at browser-based platforms, specifically Flash and JavaScript.
Flash
The Flash Player has already become popular as a game client platform, notably for Zynga's Facebook games, and even some MMOs. It has no standards-compliance issues because there is only one canonical implementation. Its sound and graphics features are solid and well-optimized, although the 3D API is still pretty limited. There are some GUI controls libraries for Flash, but they are not as well-developed as those in a desktop OS or a good JavaScript framework.
JavaScript
From a desktop developer's point of view, JavaScript is essentially a bare-bones scripting language interpreted by the browser, coupled with a small "standard library" including an API for manipulating the browser's layout and display engine (the HTML DOM). JavaScript applications work by pretending to be a web page with various elements that appear, disappear, or move around according to the script. There are many "widget libraries" for JavaScript that emulate desktop GUI controls to some degree of success. Although JavaScript-based controls sometimes feel clunky, it's important to remember that you get the full benefit of the web browser's page-layout engine and its HTML controls (buttons, sliders, etc) for very little code. This could be a powerful advantage for writing GUIs that make heavy use of traditional desktop-style controls.
Future browsers will (hopefully) also include WebGL, a complete JavaScript interface to OpenGL which renders into an HTML canvas. In theory, you could port most sophisticated rendering code, like a modern 3D game engine, to this interface. Unfortunately, WebGL is just an emerging standard and there is a risk that browsers won't ship it widely or support it well. It could join the long history of widely-promoted but seldom-implemented standards like VRML or the non-audiovisual parts of MPEG.
Limitations of the browser as a platform
Flash and JavaScript both have some important limitations:
- You can't communicate over arbitrary TCP sockets. In both platforms, client/server communication has to use XML-RPC features.
- You have no control over the "event loop." This is a potential source of problems with input polling and timing control. In particular, the WebGL code I've seen uses a wonky technique for frame timing: the script schedules an "update" function to run at periodic intervals (or with a zero timeout, which tells the browser to handle inputs and then return immediately to the script). This feels clunky compared to the high degree of control you get with a native client, which can explicitly select on file descriptors with precise timeouts and/or pause for graphics buffer swaps.
- The programming language will be different from the server side, making it difficult to share libraries and move code back and forth. There are a couple of "language translators" that target JavaScript (Pyjamas for Python and GWT for Java) but this seems like a fragile approach.
- Client-side storage options are limited. There are ways to store small stuff, but typically not hundreds of megabytes of 3D models and textures. I suppose you could do something crazy like install a small native web server on the client and access it via HTTP to localhost.
In the end, the decision of which platform to use will depend on a few factors:
- How much does the application resemble typical desktop GUI software?
- Are you continuously rendering a changing scene, or does the app sit and wait for input?
- How much client-side storage is needed, and is client-side software installation going to be a problem?
On the server side, not much has changed over the last few years. The first tool I'm going to reach for will still be Python, writing directly to the Linux POSIX APIs. Python has a rather nasty (though constant) performance penalty versus compiled code, but I can usually get around that by selectively translating critical sections into C.
(The only situation where this approach might fail would be a system that had to run arbitrary, hard to vectorize scripts very very fast - something like a game engine simulating a large number of independent AI agents. In this case you might need to look into a more JIT-oriented platform like Java. However, without going this far I think it's possible one could get the performance penalty low enough to make it reasonable just to throw more hardware at the problem.)
Subscribe to:
Posts (Atom)
