game Archive

Commodore 128 Assembly Programming #16: Worm part 3

Continuing with the Worm game. I thought I had worked out how to make the tail end of the worm go away, and then once I started to describe it I realized it wouldn’t be that simple. We have to keep track of each “body part” of the worm in order from front to back, so we always know which one is the next to drop off as the worm “moves.” That means we will have a list of pointers to those body parts, and pointers into that list.

Double pointers are challenging, so that will be a fun task I wasn’t expecting. I may do a whiteboard video to draw it out better than I explained it here. The pointer list will be in a 2K area of memory, wrapping around to the beginning if necessary, with two pointers into that list for the head and tail of the worm. Got the head pointer done in this video, and will add the tail pointer and the code to move the tail along in the next one.

Design Notes on a MULE-type Game

I’ve been playing some Stardew Valley lately. I got it from gog.com for $15, which is the most I’ve spent on a game in a long time. It’s a very well-made game, and even more impressive when you find out it was done by one man. Not many people can code well enough to make a complete game work, and do good graphics, and do good music, etc. Most games are made by teams of people with different skills, and when one skill is missing, it shows.

Anyway, as usually happens when I play newer games, I was soon drawn to the old games, which got me thinking about a couple that I want to do web-based (or nowadays maybe mobile-based) versions of. Or more likely new games inspired by them.

The first one on the list is M.U.L.E., a 1983 game. One great thing about MULE on the Commodore 64 was that it allowed four players to play at the same time. I can’t think of any other C64 game that did that, though there may have been a few. Playing it alone against the computer gets dull after a while, because the computer players are kinda dumb and predictable. So I’ve thought for a long time that it would make a good networked multiplayer game, but wasn’t sure just how to do it. It’s a fairly slow-paced game that can take a couple hours with four human players, so that’s a long time to expect four players to stay connected and playing. Full networked multiplayer means you have to deal with disconnections, lag, and all that. It would add a pretty big layer of complexity to a game that fit on a 170K floppy disc. A team has been working on adding multiplayer to Stardew Valley for several months now. I don’t really want to get into that, so that’s where I was stuck a couple years ago the last time I brainstormed on it.

Now I think I’ve got it figured out. I can go with a turn-based style, turning the interactive multiplayer parts into more of an auction, which fits with the game’s other auction portions. Kinda like a lot of social media games, where you’re competing against other people, but you login and take your turns whenever you want (but without the annoying upselling). That will change the game considerably, but that’s not a bad thing, because it eliminates any copyright concerns. It’ll really be a new game with some ideas from MULE, not a remake.

I’m programming it in Perl, at least on the server end of things. If anything needs maximum speed, I’ll refactor that part in C. It’ll use JSON for communications between client and server. That’s pretty universal, so a mobile app could easily handle that, and it’s human readable, which is nice when you’re debugging.

So as I’m planning it right now, there’s a game server running, and then a web-based client which could run on the same server or a different one, which talks to the game server. That means a fully browser-based client in Javascript could work too, or a mobile app written in Java or whatever they’re using these days. I’ll need a clear API for talking to the game server. Security (user accounts, logins, sessions) will have to be handled by the game server.

One thing I’ll have to figure out is how to get paid for it. For a long time, the easiest way to get paid online was to slap ads on things. That’s getting less profitable all the time, though, as ads pay less and less for a variety of reasons. Many content producers are moving to a patron-type model, where people voluntarily pay for things they like, and that seems to be working, at least for some of them. I was skeptical of that at first, because I was around in the shareware days, when maybe 1% of users paid for the software if you were lucky. Voluntary payment seems to be working better now, for a couple reasons. One is that it’s simply easier to click a donate button that’s right there when you’re in the game than it was to put a check in the mail later sometime. Another is that the prices tend to be lower. If you were asking $10 for your shareware package in 1985, that’s about $20 in today’s dollars. That’s not nothing. By comparison, I’ve bought several games on sale from GoG for less than $5. That’s easier to pay.

Another possibility would be a “free first one” model, where they can sign up and play for a month or a certain number of games, and then have to pay to keep using it. Users could get around that by creating new email addresses somewhere like Gmail, but most people won’t go to that trouble to save a few dollars. I could also combine a kickstarter-type program with any of these ideas.

More to come. I think I’ll do a play-through video of MULE soon, since talking an audience through the game might help me focus some ideas.