Web languages: Flash #
I wanted to learn Flash so that I could build some simple demos illustrating various concepts on my game programming pages. Unfortunately it looks like it costs $500 to get the flash developer kit! I should try Java instead.
Labels: project
Textures for desktop backgrounds #
I really liked the Textures Archive. It’s not just that they have a large number of textures categorized into colors. They also allow you to customize the texture by modifying its color, contrast, etc. Yes, I could do this myself using The Gimp, but it’s much easier with this web site.
God Games: Transport Giant #
I tried out the Transport Giant demo. I like the premise. I love the graphics. I generally like this sort of game. However, there are some interface annoyances that, although forgiveable back in 1995 with Transport Tycoon, can't be overlooked in 2004. Unfortunately, the interface is annoying enough that I'm not planning to buy the game.
In this game you build transportation routes between cities and industries. Your goal is to make money, deliver goods, or whatever the scenario goals are. The demo limits you to transporting goods by horse on roads, but the full game also offers trains, ships, blimps, airplanes, and helicopters. It would be nice if in these "run a business" games, not all other businesses have to be your competitors. It would be nice if I could run the sawmill to goods part of the transportation chain without having to first run the wood to sawmill part. Railroad Tycoon 3 seems to have addressed this problem.
- When building stations, the “entrance” is always on the northwest side. This means building a road to get to certain stations is awkward.
- When building roads, adjacent roads don't always connect. You have to go back and connect some of the corners.
- There's a way to get a list of all your stations. But this list only offers the name. If you want any other details (cargo, profit, traffic, etc.), you have to click on a station in the list and then press a button (you can't even double click the station name). There's no way to go back to the list; you have to open up the list again and start at the top, scroll down to the next station, click on it, and so on.
- A minor bug: demolishing a single square of roadway costs $900,000 (in contrast, building it costs $5000).
- There's a way to get a list of all the vehicles, towns, and industries. But it has the same problem as the list of stations. There's only a name and no information about it. If I want to pick the town with the largest population or the lumber yard with the most lumber, I have to manually click on each one, write down or remember the number I want. If I want to see some information about all of my 94 horses, I have to click on each one (and even then, I can't get basic information like amount of revenue generated).
- When I want to assign horses to go on a certain route, I bring up a “schedule” screen. It seems like a reasonable UI. But to actually choose a horse, I have to click on the horse, then click on an arrow button. I can't just click or double-click on the horse. To choose a station to visit, I have to go back to the map (which is partially obscured by the scheduling dialog box) and click on the station. I can't choose from a list (especially a list sorted by something reasonable—like stations that process the same kind of good the horse is carrying). Once I choose the station, I have to choose what kind of cargo the horse should carry from there. I have to click on the cargo type icon, then click on an arrow button. It should automatically choose the type of cargo that is produced at that station. These extra steps make the interface more "general" (a sure sign that software engineers were designing this UI!) but they make the common case harder.
- I can't tell what's actually available at a station or what that station would like to have. There is a "Requires" list but it's often empty.
- I can't expand a station by clicking on it. I have to go into a separate expansion menu and then choose the type of station. This would make more sense if I could get a list of stations and upgrade many of them at the same time. Once I do go into the menu, there's a list of options, but they don't give me a good idea of the magnitude of the benefit.
- One of the things that annoyed me in Transport Tycoon is that sometimes I want multiple vehicles to travel the same route. If I want ten buses on a particular route, I have to repeat the setup ten times. In this game there's a shortcut—duplicate route. However, it only works for the initial route. After setting up lots of identical routes, I might need to change something. For example, in the demo scenario, after you deliver 50 wooden boards to a fort, it longer accepts boards, and only accepts passengers. I had to go into each of my 20 horses and change their route to deliver passengers. It was too much work, so I just let my horses keep delivering boards, at a loss.
- When I go into the schedule screen and I don't have a horse already, I have to exit the screen, go into a different screen, and buy a horse. I should be able to buy a horse and give it a schedule all from one screen.
- After a while, the horses got stuck at one particular station. There wasn't really anything I could do at that point.
The main goal in these sorts of games is to make money efficiently. To do this I need to be able to evaluate all the things I've set up—stations, routes, vehicles, industries. There seems to be no way to do this. I'm not sure how I'm really supposed to play the game if I can't know how much money each of my vehicles makes. Is corn profitable? I can't really tell. If there were a way to get the aggregate or annual revenue/cost for an individual vehicle, it would make my job possible but tedious. What I really want is a table listing all my vehicles (or stations, industries, routes) and how much each of them brings in, how much it costs, how many days it makes per trip, and other metrics. I want to group them by vehicle type, cargo type, destination station, or other attributes. For stations I need to know the amount of traffic coming through, the wait time is for loading/unloading, the average amount of goods I'm storing there, and so on. If I want to decide whether to build some extra, like a loading crane, how can I decide whether it's worth it? If have to know whether loading time is an issue. I want an Excel-like view: a table of rows and columns, each column sortable and filterable, with grouping (aggregation). These are the things I'd demand if I were running this business in real life; how can I run the business in a game without the data?
Maybe the game designers thought it'd be more fun if you weren't overwhelmed with data. That's a good goal, but I didn't find it fun, in a game about running a business, to run a business blind. I had nothing to use to make decisions. I think they need to start with a list of what the player is supposed to do and design the interface to match that, instead of designing the interface to match the data structures or internal simulation model. It looks like it could have been a great game, but ruined by a bad interface.
Labels: review
Books: Get in the Game #
Over the weekend I took a quick look at Get in the Game! by Marc Mencher. I don’t actually work in the game industry and don’t have a good way to evaluate the material. However, one thing stuck out (Chapter 2, pages 16–17):
Here’s an example of C code:
Printf("("Hello World" " \n);Here’s an example of C++ code:
Ship.GetX(*ship); Cout>> ""The stuff we want is over here";";Here’s an example of Visual Basic code:
Public Sub Main() Send CGI_CONTENT_TYPE_TEXT_HTML Send vbCrLf Send "Hello World!" End SubHere’s an example of Java code:
System.out.println("("Why is this Java code");");
If you know these programming languages, you’re probably laughing right now. Fortunately this isn’t a book that attempts to teach programming.
Labels: review
More updates to my A* pages #
I had a 5 day weekend (including Christmas). While not playing with magnets, I made some more updates to my A* pages, this time to the space usage, map representation, and AI sections. I didn't use PyGame for any of these sections, but I expect to for the upcoming Movement section, which will describe how to take a path and convert it into a smoothly moving object.
Labels: project
Fonts in OpenGL #
GLTT looks like a fairly easy to use library for rendering TrueType fonts into an OpenGL world.
Labels: programming , project
Updates to my A* pages #
Over the long (Thanksgiving) weekend, I made major updates to my A* pages for the first time in years. So far I've rewritten and added lots of diagrams to the A-Star Introduction and A-Star Heuristics pages.
To make the 16 diagrams, I wrote an interactive A* explorer. It uses PyGame and Peter Norvig's A* code. It was surprisingly easy to write. I really love Python.
Labels: project
Economics in games #
The economic model in Railroad Tycoon 3 looks pretty interesting. (I'd link to it but I can't find a site that I can view. It all seems to be Flash. Ick.) Each product has a price at each spot of the map. You can view the map, click on a product, and see green for high prices, yellow for medium prices, and red for low prices. Without any players, the price differentials lead local transporters (by river and over land) to transport goods from one place to another. The players can come in and do this more efficiently, by investing in rail lines. Your job is to find products that you can buy at low prices (typically, but not always, where they're being produced) and sell at high prices. A few years ago I had wanted to write a game like this but never got around to it.
In addition to transporting goods, you can create your own goods. You have to build a factory (or other building) that takes raw materials and produces another good. By building factories, you can create supply and demand. From what I've read on message boards, you have to do this to master the game.
There's a free demo available of Railroad Tycoon 3. I've been playing with it a bit.
Game development books #
This weekend was rather hot (100 degrees F) so I decided to keep the computer off and read instead. I'm continuing to read Andrew Rollings and Earnest Adams on Game Design, but not every weekend. Some unorganized observations:
I really like this book! No, it doesn't show you how to implement a BSP tree or interface to force-feedback joysticks. It's about the bigger picture, like how the game elements are put together, what makes a game challenging and fun, how interactive stories work, and so on. It's not about one particular genre of games; it covers all sorts of computer games. If your game design isn't fully fleshed out, this book will give you ideas. If your game is fully designed, it's still worth looking through this book, to get an idea of all the things you forgot to consider.
You have to like a book that uses "there is no spoon".
I liked the descriptive parts of the book (these are common story patterns ...; these are motivations for writing a game ...; these are the kinds of challenges that are commonly found in games...) more than the analysis/reviews ("[Dance Dance Revolution has] an interesting gameplay innovation, but one that is hardly likely to amount to anything other than an amusing diversion"; "the last third of [Half-Life] is a real letdown in gameplay terms"). The analysis of existing games is useful because it gives you something to connect to, but I haven't played many of the games they looked at so it didn't mean anything to me. The last third of Half-Life might not have good gameplay, but since I haven't played it, there's nothing I can do with their statement. My guess would be that professional game designers will have seen more of the games than I have (or at least the ones in the genre of games they're designing), and thus it's useful for them. The descriptive parts of the book were more universal, and I found them more useful.
Game development books #
I've been reading Andrew Rollings and Earnest Adams on Game Design. So far I've gone through 100 out of ~550 pages. It starts out covering what goes into a game from a high level -- challenge, victory, gameplay, interaction, and so on -- as well as the kinds of games out there. The book is organized well and I've enjoyed reading it so far. One of the things I like most is sections that contain a list of questions you should ask yourself about your game. The lists are short, the questions clear and concise, and they definitely make you think through the issues. As I go through the rest of the book, I'll post my thoughts on this blog.
Disclaimer: New Riders has sent me a whole bunch of books. So far, AR&EA on Game Design is my favorite. Other game-related books I've received: Chris Crawford on Game Design (Crawford), Get in the Game! Careers in the Game Industry (Mencher), Developing Online Games: An Insider's Guide (Mulligan,Patrovsky), and something about 3ds Max. Non-game-related books I've received: Python Web Programming (Holden), Linux Firewalls, Advanced Linux Programming (Mitchell,Samuel,Oldham), and a few others.
Counter-Disclaimer: I've been a big fan of New Riders programming-related books ever since I took a look at their MySQL and Python books; they were much better for me than the O'Reilly books on the same subjects. Many years ago, when I was universally condemning all game programming books, Andrew Rollings's Game Architecture and Design was the first book that seemed worthy.