Jump to content

  • Log In with Google      Sign In   
  • Create Account

The Code Zone Bargain Basement Blog

Gonna volunteer

Posted by , 17 April 1998 - - - - - - · 66 views

A bit of a departure from the past few days. A fellow game developer mentioned to me that people who volunteer for 22 hours of work at the CGDC get a free giga-pass. They've also got special room-rates in exchange for indentured servitude. How could I resist? I couple of hours later, I had a discount tickets on the redeye flight to LAX and was signed up as a volunteer.

After deciding to do this, I figured I'd need to put together a set of games that I could pass out to potential publishers at the CGDC. I'm working on a new main menu that'll pull the games together much more nicely than the old one. I've also gotta put together a new install program. With a few late nights, I can probably have the set good enough to burn on a dozen CD's within a week or two. I'll also need to write a short treatment, but that shouldn't be much of a problem. After all, I've got a buncha games done. It's not like I've just got a demo.

So far, the menu's coming around well. Instead of having the game info hard-coded into the menu program, it now pulls the game info out of the games themselves. That'll make it easy to add new programs to the menu by simply putting 'em in the menu's directory. It also looks much nicer --not like discount software.

Wish me luck. Hopefully I can interest a publisher or two. If anyone reading this wants an evaluation copy of my games, look for me tallest guy volunteering at the CGDC and ask for a copy!


Posted by , 12 April 1998 - - - - - - · 108 views

Not much new game development over the past few days. Had to meet the families for the obligatory rabbit-worship ceremonies, getting myself a nasty sinus infection in the process.

I did, however, get the beginnings of the AI for the Um El Bagara game written on friday. I've got some nice little Minimax functions that I use for many of the games, which work especially well with Mancala-type games because there are usually only 6 or so moves available on a given turn. With so few available moves, you can make the tree nice and deep, clobbering your opponent easily without taking a lot of time.

Factoid: that's why games like GO have notoriously bad AI. At the start of the game, there are 400 moves available, making the game entirely unsuitable for use with Minimax implementations. To look 2 full moves ahead would require 25 billion calls to the static evaluator. Games of GO are also quite long, often requiring the user to plan a dozen moves ahead. Ugh.

Design commentary

Posted by , 06 April 1998 - - - - - - · 138 views

First off, another good link. One problem I see in games nowadays is a problem of scope. Many products are so wrapped up in the video and the sound that they forget to put in an interesting well-tested game. Here is an article written by the head of Cheapass games (one of the better low-end card-game companies) about scoping. It's not about computer games, but the discussion of focus is excellent.

I like the author's "sculpture" metaphor, but I always had a metaphor of my own that I borrowed from somewhere else. I like to think of my games as either diamonds or balls of mud. Diamonds are perfect --you can't add to or take away from a diamond without having a mess. For example, Sokoban is a diamond. There have been a lot of games (Chip's Challenge, Oxyd) that tried to extend the Sokoban idea, but they were never any better than the original. Balls of mud are amorphous --you can add to or take from a ball of mud, and it'll still be a ball of mud. SimCity is a ball of mud --you can add to it or take away from it without changing it's SimCity-ness. I always try to figure out what kind of game I'm working on when I start making improvements. Adding mud to a diamond never works.

Fixed the high-score stuff on friday. Turned out that the checksum was working --when I converted the buffer to 7-bit, I made a String object out of it, forgetting that I needed a terminating NULL. A buncha garbage characters were being written out along with the buffer, so my checksums were off when I calculated 'em again. As promised, the code's to my Coder class is available here. I probably won't make it available forever, as I wanna spend my time writing end-user stuff over supporting tools. This just seemed to be a very useful tool which probably could help out someone else.

I put the finishing touches on a cute little game called ChessCards. It was certainly a quickie game, as I started it during a bored moment while doing Zap Pod!, and finished it this weekend.

[I'm not averse to quickie games. One of my games, Brain Bones, was written over a four-day weekend around the 4th of July, 1996. Some people tell me that it's the most addictive game in the set. Sometimes things just fall into place.]

Anyway, the biggest problem with ChessCards was that the entire deck is shown as four rows of 13 cards (with no overlapping). With my old card-size of 71x96 pixels, the window would need to be around 950 pixels wide, which doesn't fit my rule of making everything work with 640x480 screens. For this reason, the PlayingCard class now has a "mini" mode, which draws a compressed card of 41x49 pixels (see the link above to see the new mini cards). I still haven't figured out how to make the card backs look good. Fortunately for me, ChessCards has all the cards face-up, so I can put that off for another day :)

I think the next game I do will be a Mancala variant. One of the games from my original pack, Wari, is probably the most popular game I've done. It's undoubtedly the number one game for women (Shelly says it's because the game's actually beatable, and is thus a fine ego boost).

This probably oughta be in my booklist, but Larry Russ sells a very good book called Mancala Games. Unfortunately, he doesn't have a publisher, so he sells photocopies by mail-order. This is the best book on the subject I've seen, with rules for about 150 different games. I was thinking of doing the game Um El Bagara (The Cow Game) from the book, as it's quite a bit different from the one I've already written.

No Ferrari for me

Posted by , 02 April 1998 - - - - - - · 67 views

To confirm John Munsch's assertion. I don't drive a Ferrari, despite being a game developer in D/FW. There are three main reasons why. . .

  • Ferraris are exceedingly expensive
  • I'm 6' 7" tall, and those things are barely knee-height for me
  • I never learned to drive a stick

Until I overcome these obstacles, I'm gonna keep the 9-year-old minivan. Anyway, I never was one of those guys who got hung up on cars. I still remember when my old boss bought a new BMW that cost as much as my house! To each his own, I guess.

Well, I'm a tad ahead of schedule, so I'm gonna give a little time to fixing a couple of old bugs in my new high-score stuff. My old high-score code worked, but it had a couple of flaws. The biggest flaw was that it stored the score info as text in the registry (or in INI files under Win 3.1 or Mac). Any kid with regedit or a text editor could mess with the high score tables if he wanted to. With the new games, however, I wanted the games to support global high-scores via the internet, so I needed a bit more security. I developed this neat class called Coder that would do all kinds of cool stuff to buffers. It would do any combination of compression (huffman), encryption (simple, but probably adequate), checksum-verifying, and 7-bit ASCII conversion (for INI files). It stored what it did in the first byte of the buffer, so you just had to hand an encoded buffer to the decoder, and it could figure out how it was encoded.

Well, it all worked nicely except for the checksum business. It just never seemed to match up, and I never got around to fixing that, so that's my objective for today.

BTW, if anyone's interested in such an object, I could probably release it. It'd certainly be useful elsewhere. If anyone's interested in a handy-dandy buffer-crunching class, lemme know.

John Buys a commercial strategy computer game!

Yes folks, it's true. Given that one of my all-time-favorite computer games is "Slay", a loveable little shareware Windows strategy game, Shelly encouraged me to buy one of those large-scope tactical simulation things. Since the screen-shots looked cool, and my local comic retailer seems to be obsessed with the concept, I bought Warhammer 40K Final Liberation. It's apparently a tad different from the WarCraft-type games in that it's turn-based instead of real-time, but I figured it'd be a good start into the large-scale computer-wargame genre which was passing me by.

The demo scenario is fun, and I can beat it, but the big campaign is overwhelming. I started clobbering some heavily-armed Orcs, but we just ended up at a big standoff in the center of the screen. It reminded me of the shootout in that episode of Police Squad in which the hero and villain are exchanging gunfire. There's lots of shooting, but when the camera pulls back, it turns out that they're about 4 feet apart, firing away and not hitting each other.

Well, despite having beaten most of the orcs, the game suddenly declared me the loser, and I was treated to a video of some giant Orc muppets taunting me.

Maybe "Slay" is my limit. . .

Spritelibs and timers

Posted by , 30 March 1998 - - - - - - · 100 views

First off, I discovered that SpriteLib has moved here. The author has dropped the weird licensing stuff. You just need to put your free SpriteLib reg # somewhere in your app (like the "about" box). There's now no reason not to have this thing.

I made a long-overdue change to my timer code. In an average game, I would start 2 or 3 timers, using my GameTimer class (basically a wrapper for the Windows Timer stuff). Usually the game had a GameTimer that would drive the sprites. I had a completely separate GameTimer handling updates to eye candy (little short-lived graphical bits that aren't interactive, like explosions, sparkles, etc). Problem was, I was getting some ugly race conditions and had to add some unwanted wait-for-sync routines.

To fix the problem once and for all, there is now a single "master timer". Creating a new GameTimer object simply hooks into it. Whenever the master timer ticks, it calls all hooked objects. When nothing's hooked, the timer is quietly killed. The change seems to have sped things up a bit and has gotten rid of the need for any wait-for-sync nonsense.

I also added a new attribute to the Sprite class, Touchable. Early on, I had plenty of cool routines for collision-detection, returning all sprites that were touching a given one. Unfortunately, things got ugly with the advent of eye-candy. At some points, there can be lots of eye-candy bits on the screen (especially Zap Pod!, which has explosions everywhere). You could no longer pass an array to the routine that returned all touching sprites, as you didn't know how large to make the array. Sifting through tons of useless sprites to find your enemy was also a pain, so I added a Touchable attribute. If it's set to FALSE, the default, the sprite will not report itself as touching a given sprite. This way, stuff can be dancing all about the screen, but the important game sprites (the ships and bullets) will ignore 'em.

Zap Pod! is basically done. I put in the bonus ship/bomb code and the preferences dialog box. If you want a screen shot, go to the Code Zone site.