Petscii Jetski – a C64 game in BASIC

Introducing Petscii Jetski!
 
Instigated by Nick Montfort, we returned to the Commodore 64 to write a 10-line game & visual poem.
A very long time ago I used to be into C64 programming, at first BASIC and later assembly. I have severe existential reservations about going back to “things that I gave up years ago”, but it really was like coming home in a holy & broken sort of way.
In a world full of ever-shifting Javascript preprocessors and package managers, a simple predictable machine is a comfort, and yet the BASIC implementation is excruciatingly slow and full of strange decisions. For example, on this 1 Mhz machine, the BASIC implementation only runs floating point, which is really slow. This meant that the C64 was special in that assembly was perhaps a 1000 times faster than BASIC, a much bigger difference than in modern languages.
 
Play Petscii Jetski online at https://nickm.com/montfort_juul/petscii_jetski/ and read a detailed discussion of BASIC optimization at https://nickm.com/trope_tank/TROPE-20-01.pdf

Notes on Running an Online World for 15 years

You know about that online world that launched in September 1997 and is still running? No, not Ultima Online, the other one.

I was reading Raph Koster’s notes on the launch of Ultima Online back in 1997, and it made me realize that the online world that I programmed also launched just over 15 years ago, nearly at the same time as UO. If you didn’t grow up in Denmark, you have certainly not heard about it, but it’s called Højhuset (literally high-rise, from the metaphor that it was a series of stacked rooms). It’s still running at www.n.dk (only go there if you speak Danish).

This is what it looks like: It’s made up of non-scrolling rooms in a diagonal grid. Users can dress up, chat, and so on as expected. Users have their own apartments which they can decorate. Here is a screen shot with a celebrity visiting:

Højhuset

And most importantly: You can have nice things. The world was always a bit of a compromise between a chat system and game-like elements such as inventories and a currency, but it turned out that this was quite a feature. There have historically been long-running feuds between users who think of it as a chat system, and those who think of it as a game with the goal of amassing the most items. I initially thought that this would be a problem, but in practice this created social cohesion in each group – this was a valuable lesson for a game designer, that an external enemy does give users reason to come back.

As someone who is into game definitions, the height of the “is-it-a-game-or-not” feud was when a user had found a “Player” class in my program, and used this as proof that yes, this was a game. (New game definition: A game is a piece of software that declares itself to be a game.)

My role in this was always as a subcontractor, but I have been providing support and updates for 15 years now. One of the things I did learn as a programmer was to document my code and avoid any quick & dirty fixes which could come back to bite me. The main program (in Java) has always run on a single server. At the height of popularity, there were 2000 simultaneous users, but the improving speed of servers always just always made it unnecessary to spread across multiple machines.

Of course, there were also numerous attempts at hacking the system, which always is a point of pride for a programmer. People still try, here is even someone posting some debug output from such an attempt on Pastebin.

There were also microtransactions going back to the late 1990’s (this mostly paid via text messages).

Having read & written so much about video games since, it is hard to remember what thoughts went into my head when I was first starting out on this project, but I had played MUDs at the time, and I am sure I had read an article about the need for artificial scarcity in virtual worlds. And the strength of scarcity was one of the things that made the biggest impression on me. In the very early versions, there was no automatic dropping of items – this had to be done manually by a superuser referred to as the “superintendent” (“vice”). When going online, that user would always be met with cries encouraging the dropping of items (“smid!” in Danish). I leave you with a bit of user art, in which the superintendent gets fed up with being asked to drop items.

 

Smid!

(There was actually a brief period of time in which a new chat system was introduced on the site to replace the one I made, but users demanded the old one back. Warms your heart.)

Things you don’t see because you weren’t looking for them

It’s one of those things I have seen so many times in game designs, my own, those of students, or anybody else: In the middle of the screen, right in the players’ field of vision, you have placed a giant GUI element communicating something really important such as time left. And players don’t see it.

They don’t understand how much time is left, they are confused when time runs out. You ask them afterwards and they don’t quite believe that there even was a timer there.

This is a good example of that effect:


(Via Free Williamsburg.)

Our New game: High Seas – The Family Fortune

High Seas Logo

High Seas – The Family Fortune
I am happy to announce my secret side project: High Seas – The Family Fortune.

It is our attempt at making a fairly innovative yet accessible casual game.

Get it here.

High Seas play 1 480

From the Press release:

“High Seas: The Family Fortune” brings players into the world of Tricia McDormand – a disenchanted young woman who has been trudging along at her father’s map company for years. That is, until one day, a long lost map of her late Grandmother – a legendary pirate – is found. With the map in hand, players join Tricia as she sails the seven seas in search of the mysterious family fortune. In order to power Tricia’s ship, players must drag rows of jewels and align them by shape or color – and receive big bonuses for aligning by shape and color. Players travel to 16 different island locales, and complete challenging puzzles to discover clues that reveal the great McDormand secret that has eluded historians for years!

Features

  • Yes! It is a matching tile game, but with some radical twists!
  • Physics model: You can interact with all tiles on the screen, all the time.
  • No waiting for tiles to fall. Free interaction without making matches.
  • Match on shape or color.
  • Developed story (!): Tricia travels the world following her grandma’s map in search of the Family Fortune.

Credits

  • Developed by Soup Games & The Planet. Published by GameTrust.
  • Game Design: Mads Rydahl and Jesper Juul.
  • Graphical and Model Design: Simon Sonnichsen.
  • Graphics & 3D: HappyFlyFish / Michael la-Cour and Jesper Fleng.
  • Additional Graphical design: Mads Rydahl.
  • Sound: K?v Gliemann.
  • Story writer: Heather Chaplin.
  • Programming: Jesper Juul.


Methods

I could write a lot about the methods we used, but some of the work was surveying the history of matching tile games as previously mentioned, and after that a long prototyping phase with lots of iterations and user testing. I may do a longer writeup, depending on how the game does, I suppose.

Play the game!

In the meantime, please try and buy the game!

Nordic Game Jam – The Sheep

This weekend saw the 2nd Nordic Game Jam held at the IT University in Copenhagen. In Danish, here is the press release and some pictures. With 80 participants, it seems to be the largest game jam in the world so far.

Since I wasn’t an organizer this year, I could focus on actually making a game. With the great team of Thomas Dougans, Rasmus Keldorff, Mike Sj?rslev Khamphoukeo, Tim Nielsen and myself, we created the two-player strategy game Baa-aah: The Lord is my Shepherd.

The core of the game is protecting your sheep from drowning in the rising water, while attacking your opponents’ sheep. To this end, you can terraform the land, building and breaking dams. Additionally, your sheep can be sacrificed to dramatically raise and lower a portion of the playing field. Here is a screenshot towards the end of a game:

Lord is my Shepherd

Method-wise, we started by creating a level editor before making anything playable, and then we simply toyed around with making different levels, playing them, and refining the basic gameplay.

The game isn’t anywhere finished, but it’s actually playable and fairly fun, and I am quite proud that we did this in <48 hours.

Oh, and we were voted best game of the event by the participants ;)

(There’s a jury prize and an audience prize.)

Research for the Industry

John Hopson has a quite critical article on academic game research over at Gamasutra: We’re Not Listening: An Open Letter to Academic Game Researchers.

But honestly, even I walk past most of the academic presentations at industry events. Even I have trouble really getting excited about most of the games research being done out there. From the perspective of someone on the inside, the average piece of academic games research just doesn’t get the job done. It’s not a question of the quality of the research or the intelligence of the researcher or the game makers; it?s a question of bridging the gap between the academic and business cultures.

I must admit that I am a “cup is half full” kind of guy on these matters. It just isn’t possible to make everybody happy all the time. Of course, when I really am trying to make developers happy, I would like them to be, and the article has some good ideas for that. But there is still work to be done on the managing of expectations:

The researcher must lay out the entire impact of the idea, from the cost of implementing the proposal to the resulting changes in player experience and the metrics for measuring that impact. Getting players to identify with the main character is great, but researchers have to finish the rest of the sentence: “This will help players identify more strongly with the main character which will result in an improvement in measures of overall player satisfaction and an increase in total playing time.”

Actually laying out the cost of implementing a change on a specific project – I would be happy to help, but I need more data than what’s publicly available.

*

That said, I am actually working on some research that is intended to both satisfy a purely theoretical curiosity, and to lead to recommendations like the one above – “do this, and player satisfaction will increase“.

Do that, and game developer satisfaction will increase.

Immature designers imitate; mature designers steal.

I am finishing an article on matching tile games, and the question of imitation and originality keeps coming up. I’ve often heard the idea of “the bad artist imitating, the good artist stealing” attributed to Picasso, but it is actually from T.S. Eliot in a 1922 essay:

Immature poets imitate; mature poets steal; bad poets deface what they take, and good poets make it into something better, or at least something different. The good poet welds his theft into a whole of feeling which is unique, utterly different from that from which it was torn; the bad poet throws it into something which has no cohesion. A good poet will usually borrow from authors remote in time, or alien in language, or diverse in interest.

Spot on for game design: The good designer welds his or her theft into a whole of feeling which is unique, utterly different from that from which it was torn; the bad designer throws it into something which has no cohesion.