"Say 'hello' to my little friend!"

Scarface (1983)

One part of the gameplay is buying information for the raid. The key is to decide what info we need to get the most out of the location. Let's start with a quick example from the test level, the coin dealer.

Once we've bought the plans, we can buy detailed info on the swag:

• Coins [€5,000] → you'll get info about coins with a total value of €10,000
• Silver [€5,000] → you'll get info about silver with a total value of €10,000
• Art [€7,500] → you'll get info about art with a total value of €10,000
• Cash [€2,500] → you'll get info about cash with a total value of €10,000

Buying all that will cost you €20,000 and could result in a pay out of €35,000 after the job. But our selected fence won't take art, so it's €17,500 less. There's also info on alarms and doors and what not, each comes with a price tag, and we need to decide whether it is worth it or not.

All this to come to the point of this post:

How to show this info to the player?

At first, I wanted to show these infos on hover, "A" stands for alarm, but that info will be provided differently later.

Tooltips are a nice and easy way to show infos, but the obvious drawback is, that you need to move the mouse over the item. After toying with them, I decided to go with fixed labels - and only for elements that actually have info data to show.

"case_001" contains coins and is linked to the alarm, "case_002" contains art, "case_003" does not contain anything of value (you know of), but is linked to the alarm, too.

Adding labels is easier than adding the item's action menu (see here: Part 2), as we can simply draw the label's background (9-slice, again) and the icons during its draw event. If, and what to draw, is determined by the information you bought before starting the raid and the subject of another post.

With this in place, I'm going to add doors to the cast (and their "correct" action menu).

Laters ...

"What we've got here is failure to communicate."

Cool Hand Luke (1967)

Working with GameMaker — or around it.

One of the biggest drawbacks of GameMaker is the TOTAL lack of anything that resembles a modern UI for your game. There are no buttons, scroll bars, checkboxes, you name it, not even an input box. While creating your own buttons is a no-brainer, the lack of a working input control is really hurting. Sure, there's 3rd party code addressing that, alas, my game, my rules, and one of these rules is: NO 3rd party code.

Luckily, I don't have to deal with that yet and worry about it … later.

The second drawback is: no nesting.
Back in the flash days, you created a MovieClip, dropped your buttons onto it, and when you moved the MC around the buttons stayed where you placed them (relative to the MC's position). Great.
Not so much in GM (well, as far as I know), you're very much on your own again. Top that with the lack of event-bubbling, and you can kiss your easy UI ambitions goodbye.

Now that this is out of the way, let's focus on the thing I'm currently working on:

The Action Menu

The "action menu", opens if you click on an item and the current active character is near enough.

As RGR is controlled by a mouse, I needed some kind of menu when you want to interact with anything in the game world beyond moving around.  But the simple idea of the "action menu" opened a cornucopia of challenges and choices.

What should happen:

• "Player clicks on item" ("case_002" here)
  • if the character is not standing next to it, walk to the item, no menu yet.
  • if the character is close enough, open menu.
• "Open menu"
  • get actions, based on character and item [dummy for now, to be supplied]
  • render menu
  • handle actions and find a way to exit the menu
• "Perform action" [to be supplied]

9-Slice, the perfect tool for the "action menu" background. Easy.

The menu's background and buttons

GM's sprite editor has a convenient panel for editing 9-slices, and they are easy to use if you just drop them into a layer. If you like to use it as the background of an object that you create at runtime, you need to plot it yourself (again, as far as I know). I needed to do that anyway, as the little tip should be plotted centred on top of it. So in the "Draw" event I simply:

draw_sprite_stretched(sprite_index, -1, x, y, m_width, m_height);
draw_sprite(spr_ActionBubble_Tip, -1, x + m_width / 2, y - sprite_get_height(spr_ActionBubble_Tip));

After that, we just add the action buttons. Just. Did I mention: "no nesting"? That leaves two options:

1. plot the buttons during the "Draw" event and write my own code to handle the mouse events, or:
2. create a button base object and add them to the room, above the menu

I decided against using the draw event variant, as the menu doesn't move while being open and, TBH, it would have been a head fuck.

The next thing I wanted to add, was some kind of overall hit area, which hides them menu if you leave it. The screenshot shows it as a white rectangle. I assumed that the collision mask would still work for a 9-slice, and it would be enough to just expand it outwards for a few pixels to do the magic. I just would need to check if the mouse is inside the collision mask, using:

m_hovering = position_meeting(mouse_x, mouse_y, id);

Well, that doesn't work, like, at all. I ended up trying to get the bounding box of the menu's background and for that, I had to rummage through the docs again.

m_hovering = point_in_rectangle(mouse_x, mouse_y, m_Rect.Left(), m_Rect.Top(), m_Rect.Right(), m_Rect.Bottom()); // position_meeting is NOT working with 9-slices

This finally did the trick. I just had to fill m_Rect (my own rectangle class) with the help of the sprite_get_bbox_* methods.

Speaking of sprite_get_bbox_*, these little buggers hide the fact that it is surprisingly hard to get the absolute pixel positions for (top, left, right and bottom) for a sprite which's origin isn't at 0,0. The sprite_get_bbox_* methods return their values relative to the origin (of course they do). In order to get the REAL pixel values, you need to take that into account. Simply adding the object's x and y to it doesn't work (or it does, you just don't get the result you wanted).

// getting real sprite coords is a pain in the ass, HALFTILE/TILESIZE to create a nice border
m_Rect.Set(
	min(x, real(sprite_get_bbox_left(Item.sprite_index)) - sprite_get_xoffset(Item.sprite_index) + Item.x) - HALFTILE,
	min(y, real(sprite_get_bbox_top(Item.sprite_index)) - sprite_get_yoffset(Item.sprite_index) + Item.y) - HALFTILE,
	max(m_width, real(sprite_get_bbox_right(Item.sprite_index) - sprite_get_bbox_left(Item.sprite_index))) + TILESIZE,
	max(m_height, real(sprite_get_bbox_bottom(Item.sprite_index) - sprite_get_bbox_top(Item.sprite_index))) + TILESIZE
);

This makes sure the bounding box always covers the item, but if the menu is wider, it uses the menu's width instead.

Hey, this works!

One thing left was to disable the item's and characters' mouse events while the menu is open. I also need to decide how to explain what each icon does, either in the form of tooltips or something else, but that's for later.

I didn't mention it, but of course, there's also code that makes a character always walk to the front of an item, if possible.

Laters …

"Show me the money!"

Jerry Maguire (1996)

So I'm working on a new game.

The story begins in 1986, when Ariolasoft published a game in Germany called "They Stole a Million" [More info on Lemon 64]. It's a game where you plan and execute heists. You have to buy plans, information about the swag, hire a crew and a fence. Then you plan the job on the blueprints and hope that you were clever enough to come out of this with enough money for the next job.

Buying information about the target and the swag.

Hiring a team and then going to the planing phase ...

After reading the reviews, it was clear that it was a game I wanted to play - badly. So I bought a copy of it on tape. And I played it. For Weeks.

But I discovered that without Excel (or extensive notes) I could not get beyond the 2nd heist. I always ended up short of cash. And Excel wasn't a thing back then.

Years later, when I started making games again (Flash!) the game's "simple" idea still fueled my imagination, but I didn't want to do a port or just remake the game with new visuals, I wanted to add my own twist to it. And make it "easier". First, though, I made other games (and then no games for quite a while).

BUT I already had a name:

Rein. Greifen. Raus.

When the idea of making a new game came up, I explored some old ideas, but none caught my attention for long enough to go beyond "early pre alpha greybox" state.

There still was this heist game!

The C64 game was far too complex for a "fun" game, and I had to reduce the complexity, while keeping the idea intact. One thing I wanted to remove was the need for an Excel sheet to crunch all the numbers, I also wanted to get rid of the planing phase - even though it was the main part of the original game.

The main gameplay loop should be:

• Pick target
• Buy infos about the target, swag, alarm
• Pick a team
• Pick a fence
• Scout the target [optional]
• Do the heist in real time, repeat if needed

The current demo level with a lot of debug info, showing movement and (stub) interactions.

For testing, I'm going to use the first target of the original game: "H. Humbug & Son Antique Coin Shop" (and maybe keep it in the game as tribute to "They Stole a Million").

See you next time ...

"The stuff that dreams are made of."

The Maltese Falcon (1941)

Yikes!

So, my last post was December 2023. Since then, I've been working on Genesis64's new parser and frankly, I'm bored with it right now. It sure didn't help that this is the 4th or 5th version, which is a LOT better than the first, but still, it's the same thing I've been toying with for the last 5 (?) years or so.

I don't enjoy working on it right now, even though I still have the urge to finish it, someday.

For the foreseeable future, I'll be playing with Game Maker.

Speaking about playing. I also noticed that during the summer month, I didn't play as many games as I thought I would. I barely touched the Series X at all. Even though I bought some games (Dragon's Dogma 2 for one) and downloaded a bucket of Game Pass games.

I think I played Dragon's Dogma for about 2 hours, some "Tales of Arise" (but still J-RPG-ish games drive me nuts). I also replayed some Fallout 4, but lost interest quickly enough (and I still haven't seen the last 2 parts of the Amazon show).

I got AC:Mirage to play, and I might look into it over the weekend.

Laters.

 "Well, here's another nice mess you've gotten me into!"

Sons of the Desert (1933)

10 dim a$(2)
15 def fn a(x) = x * 2
20 a$(0) = "abc"
30 input a$(1)
40 if a$(0)=a$(1)then print sin(1), fna(2)

This piece of code doesn't make any sense, but it's a nice test case for #Genesis64's pre-parser. And now you ask yourself: "Why a pre-parser (and what is it)?"
When I first started to work on this, the Genesis64 parser actually was an interpreter, you entered #C64 #BASIC code and ... interpreted it using a boatload of RegExes (because, hey, BASIC looks like it's so easy, you could parse it with Regular Expressions alone - boy was I wrong).

Because I used RegExes to parse the code, it seemed like a good idea to make finding arrays easier, by using the C-like [ and ] instead of ( and ). I used the same reasoning for =, thinking that simple compare operations should be easier to find when I use == instead of =.

Here's the result of the (very first) pre-parser used:

10 dim a$[2]
15 def fn a[x] = x * 2
20 a$[0] == "abc"
30 input a$[1]
40 if a$[0]==a$[1]then print sin[1], fna[2]

Using this nice RegEx to detect the "start" of an array in code:
/[a-z]+\d*[\%\$]*\s*\(/

It will find everything that looks like an array up to the opening bracket, so just run this over each line, find the closing bracket and replace ( and ) with [ and ].

Almost .... correct.
Let's start with line 10, obviously a$[2] is wrong, as we're not accessing the array, but DIMing it. So it needs to check if the array variable is used in a DIM statement.
Line 15, wrong, DEF FN is followed by a "name" rather than an array
Line 20, wrong, it's a LET command, without LET, as we don't need it in BASIC v2.
Line 30, wow, correct.
Line 40, almost correct, but SIN is a function, so not an array and thus has to keep its ( and ) intact, and FN A is a function as well.

So 3 out of 5 lines that needed further testing, and I've not even really tackled comparison.
First check for DIM and DEF FN / FN, then filter out the BASIC functions (SIN, ABS, ...), oh and deal with nested things like a$(b(2)), or SIN(a((ABS(3))) ...

Nonetheless, I kept using that idea throughout three (or 4?) iterations of the parser, adding conditions for DEF FN, functions and what not, to the point where it perfectly converted C64 BASIC to "G64"-BASIC. It just took a few hundred lines of code and conditions to arrive there. With the current rush of motivation (I just released v. 2.6.7.3 of our e-learning suit WideBight), I re-read the code for the pre-parser and decided to drop that idea and just make sure the parser can deal with BASIC the way it is written instead of jumping hoops to convert it to something else first.

"One morning I shot an elephant in my pajamas. How he got in my pajamas, I don't know."

Animal Crackers (1930)

Since I missed last week's post, this week is a bit more elaborate.

When I found this game on the tapes that came with my C64 I was hooked. I think it was on one of the later tapes, because I played the games one after another, and it must have been well over a half year after Christmas that I stumbled upon:

The Sword of Fargoal

Title screen (from a cracked version) and the original "main menu"

Originally released on the VIC-20 in 1982 the C64 version made it to the stores in 1983, it is what I might call now a Rogue-lite (or Roguelike, but quite reduced, so "lite" might be more appropriate).

Our nameless hero has to venture down randomly generated dungeon levels until he (we) find the magic Sword of Fargoal, and then go all the way back up (along with a hefty time limit, more monsters and fewer stairs up).

Generating the map and showing some stats.

You gain XP by collecting gold (and sacrificing it in temples) and slaying a varied cast of monsters. With each new level you get some additional hit points, can carry more gold, and deal a tad more damage. There are healing potions, magic sacks (to carry more gold), beacons (teleport to thingies), and some spells to keep you alive - and you better uses these as you only got one try.

The spells make you invisible, regenerate HP, teleport (random location), summon a shield, let you drift and widen your light radius.

You also may find enchanted weapons for more oomph against monsters.

A cleared map and a level for which we have found a map.

You start with a covered map, and each step uncovers a 3x3 area around the player (or some more using the light spell). You make same steps, then the monsters move until you've complete cleared the map or took the stairs down to the next level. The checked spots on the map (that look like the covered pieces) contain something random: helpful things like: spells, potions, sacks, maps (that uncover later levels) and weapons OR unpleasantries like: traps, holes ...

Traps may make you lose your orientation (thus coving up the map) and holes can be used to skip levels (although not knowing where you end up).

Level 15, where the sword can be found, and made it out again.

I'd say this game was the first real killer for my (not very big) enthusiasm for going to school. It killed it right on the spot. For a few weeks (and some abysmal school tests) it was all I wanted to do. I came home, dropped my bag and played Fargoal (well, until my parents took away the C64 ... "You get it back when you can concentrate in school again").

I'd give it a 5/5 for replayability.

"You've got to ask yourself one question: 'Do I feel lucky?' Well, do ya, punk?"

Dirty Harry (1971)

If you made it this far, I'll reward you with another early C64 game I loved playing - even though it was released on the dreaded Apple II first, but I didn't know that back then.

I'm talking about

Choplifter

You're flying a heli and collect people and return them to the base. That's about as much as I knew about the game after the first round.

Title screen and on the way to rescue the first batch of hostages.

Pressing fire on the joystick in port 1 starts the game, press up to go up and left / right to fly into that direction. Pressing fire lets you shot into the direction the heli is facing. Notable was the fact that the heli kept its orientation. You could change that by pressing fire and a left / right to turn the heli around OR facing the screen, which alows to shoot straight down and hit those pesky tanks.

Landing, eyeing the damn tank. Returning to the base and "unload".

Sooner or later you'll notice people on the ground, so land and let them get into the heli and lift fast enough to avoid getting shot by a tank. Then head back to the base and release them. Repeat. Once you've got 20+ of them to safety, you start the next level.

I hated the plane. ...and it hated me.

If you found the tanks annoying, wait for the first contact with the plane.

Overall, it's a nice little game, but tbh. I never made it "that" far, I'm not even sure if I ever managed to get beyond the second level (and I didn't try hard enough to get there this time).

I'd give it a 3.5/5 for replayability.

"Open the pod bay doors, HAL."

2001: A Space Odyssey (1968)

Welcome to another week of "Oh what fun I had with early C64 games."

This week's game is ...

Wizard of Wor

You are about to enter the dungeons of the WIZARD OF WOR!! [...] As a "noble warrior", your mission objective is to descend deep into dungeon mazes, battle visible and invisible monsters, evil demons, and even the Wizard of Wor himself! Go as far into the dungeons as possible, beat the Wizard and his monster babies, while scoring as high as you can.

(from the game's manual)

Title screen and one of the basic dungeons.

First thing I noticed is that the dungeons are semi-random, and the manual confirms that there are 25 combinations, it also informs that the difficulty takes place on two levels: basic dungeons and Worlord dungeons (plus "The Arena" and "The Pit").

Ignore all the yadda-yadda, and it boils down to "shot everything that doesn't look like you".

The one thing that made this game one of my favourite games from the early tapes is that it also is a two player game, and boy, did we play it. For hours on end - sometimes when friends stayed overnight, for some hours more.

After you've killed the 6 blue things, you go for a yellow and orange one and then a giant ... fly?

We usually played as a team, but had a healthy competition when it came to the scores.

Another blue thing to shoot at.

Interestingly, it is a game that still works for me, even as single player game. A quick round from the couch (with the TheC64 mini or using Vice) is good for "wasting" some 20 minutes and with a second player around for some more.

I'd give it a 4/5 for replayability.

"Soylent Green is people!"

Soylent Green (1973)

After last week's post, I decided it would be fun to replay some of the very first games I played on my C64. Thinking about it, though, "fun" isn't always something that hits you when you look at the early C64 games.

This week's game is ...

Warren Schwader's "Sammy Lightfoot"

Again, this game "came" without a manual, so no backstory to explain what's going on.

"Sammy Lightfoot follows the travails of a circus worker who jumps and climbs through a number of perilous situations."
(wikipedia.org)

Once you connected the joystick to port 1 and selected a one or two player game, you'd be thrown into fun. The game's goal is to cross a succession of "Scenes" and advance to the next one. Each "Scene" takes place on a single screen.

Let's start with some screenshots:

The title screen and Scene 1 in progress ...

In scene 1 you need to get to the top by using the trampolines at the bottom right, cross the gap with the swinging rope, use another trampoline, hit the button beneath the red platform and finally jump onto the last swinging rope.

Scene 1 done and Scene 2.

Scene 2 looks a lot more straight forward than scene 1, get your timing right to go from right to left jumping over the bottom row of platforms, to make this a little harder, the yellow things start to move. After this, the two outer platforms move halfway up the screen, and you go from left to right using the (moving) yellow platforms. The last step is getting to the right side again, after using what I assume is a flying carpet ... or something.

Scene 3 - by now you should know the drill ...

Scene 3 makes you go left to right, up, right to left, up, swinging ... and ... I gave up here.

I don't remember getting that far back then or playing for very long (not as long as I played "Burning Rubber", that's for sure). I checked a long play and there only seem to be 3 screens, which start over after this one, adding a few more perils, so it's not like I missed a great deal quitting here.

I'd give it a 0.1/5 for replayability.

"Toto, I've a feeling we're not in Kansas anymore."

The Wizard of Oz (1939)

[I posted this over at mastodon, but figured it might not hurt here as well.]

When I got my #C64 (used, from one of my mum's co-workers) it came with a #datasette and 4 or 5 60 minute tapes full of games (turbo tape format). With it came a printed list of what was on them.

As I didn't have a clue about any of them, I just played the first game that loaded from tape.

Here it is, the very first game I played on MY C64 [drumroll]:

"Burnin Rubber"

Title and help screen

It sported some fairly basic rules I could deduce without knowing a single word of English:
You scored points for:
- bumping other cars off the track
- jumping and landing on them (the only way to crash the "tanks")
- getting bonus points after each round (track)

The tracks were simple, straight "roads" changing in width and the occasional piece of water you'd have to jump over.

Ingame and level end.

I replayed it a few times, but always had to turn down the volume, as the track playing along is a 100% annoying and maddening.

I'd give it a 2/5 for replayability.