Jump to content

Whack-A-Lackey


Followers 6

Recommended Posts

Ever since creating Whack-A-Lackey, I intended to release the source and open a forum discussion to answer the questions that would follow. I tried waiting until I finished logging everything from GW6, but I’ve been far behind for too long.

 

My main reason for creating a topic and releasing the source is to get everyone thinking about other fun things we could do with Wherigo. Just to clarify, anyone can discuss in the forums what they have created and, more importantly, learned while putting their cartridge together. By no means am I starting this thread due to any obligation or responsibility as a moderator. I do not intend to lecture through this, either. My intent is to show what I did, let people look through it, and answer questions if there are any.

 

Anyway, let’s get started. I’ll use this opening post to tell what I did and highlight some things you may not know. From then on, it’s an open the floor. You can ask me what does what in the code, what I was trying to accomplish by writing it a certain way, the process by which I went about creating and testing the cartridge, how it came to have the lackeys et. al in it, etc.

 

The Game

If you have heard of whack-a-mole, it's a similar concept. Up to five lackeys appear on the field at random intervals and in random places for a varied point value. To whack a lackey, you have to arrive at that zone in time. I also include some power-ups that appear infrequently while the game progresses: atomic hammer, gold hammer, black hole, field extender, bomb, angry muggle, and the acceleratron (all documented in the cartridge's Instructions item). The power-ups change certain aspects of the game, usually for a limited time. You can whack muggles, forum moderators, and even Groundspeak Lackeys. I wrote the code in such a way that it’s really easy to change what you’re whacking and add more at a later time.

 

I chose to stay with the adjective “whack” regardless of some alternate meanings. Many people are familiar with the game “whack-a-mole”, which makes explaining that game much easier. I’ll take the occasional joke in exchange for this sort of name familiarity. It makes people feel much more at ease learning a game like this if they can already relate.

 

From Whack-A-Mole to Whack-A-Lackey

At first, the game involved whacking moles. However, I wanted it to have multiple difficulty levels. I began tossing around geocaching-relevant ideas and somehow came across Whack-A-Lackey. I just couldn't resist the way the name sounded. I wrote a "check this out" email to one person at Groundspeak and asked if I could use the lackeys in the game. Each lackey featured in Whack-A-Lackey has given his or her consent. This arrangement was also perfect because I needed images of what you're whacking and all the lackeys have their own icons (the same goes for forum moderators and is the precise reason I did not ask reviewers at that time).

 

I mention this because I wanted to point out this was not a surprise to those featured in the game. To use anyone's name and/or likeness, you do have to get permission from the person. (And Groundspeak owns the pixel images, so I did have to get usage permission for those as well.) I would have loved to be there, though, when they first saw what I had created. ("He did WHAT with Wherigo?") Come to think of it, that would have even been worth the cost of a plane ticket from North Carolina to Washington! But I digress.

 

Terminology

You’re probably familiar with calling whatever you whack in the field a lackey, but since you can whack different things, I wanted a generic term to avoid confusion. I call this a “mole” and consistently do so throughout the cartridge code.

 

I use the words “function” and “method” interchangeably when I write in the forum. In lua, the correct term is “function”. I usually program in C# and the term is usually “method”. For all intents and purposes, these two words will mean the same thing.

 

Making the Cartridge

I started out in the builder by creating a zone, the overall game timer, and the items, the latter of which are used to start and stop the game and display instructions. After I was satisfied, I saved the cartridge, checked it in the emulator, and closed the builder. The rest was hand-coded. I wanted to do the first part in the builder so I had a template for the objects and their property values. As a side note, I’ve been exposed to Wherigo and lua only since January and I did not have a private line to Groundspeak. Programming concepts don’t change with the language. The only thing I had to pick up on was the syntax: how to write what I wanted in lua.

 

If you’re uncertain about opening the source in notepad and—gasp—learning how to program something, that’s okay. The most important thing in programming is being able to think things through step-by-step. If you can do that, try learning a little. One of us in the forums will be glad to help—and I certainly don’t mind helping people take the first step. I was a certified tutor in my college years. I don’t want someone’s uncertainty or fear of programming to be the primary cause of the community losing out on what could have been a phenomenal cartridge.

 

Investigating Possibilities

When creating a cartridge like this, I had to experiment to see if certain things were possible with Wherigo. Basically, this was a proof of concept. For certain experiments, failure would mean the game couldn’t be built while in other cases it would have simply resulted in making coding and managing the cartridge more difficult:

  • Moving Zones – I was confident about this due to the demo spacecraft cartridge. The moles must be able to move around the field. I did not like the possibility of having moles in a static place. That’s not fun, is it?
  • Moving Zones Reliably – It’s one thing to be able to move a zone, but what about moving it to random locations inside a boundary? Could I get the random positioning logic working? Would it always display correctly? Would the player be able to enter the zone properly? Could this be done constantly or would it consume resources after a while?
  • Creating Objects From Scratch – I could have coded the zones and timers as permanent, fixed number of objects, but this would have limited the number of moles in the cartridge. Due to the way I coded the game, you could have more than ten or twenty moles on the field at a time if you so choose. I decided on five because that’s how many zones would fit on the Colorado’s screen without scrolling.
  • Arrays – This cartridge heavily relies on arrays. For those not as familiar with programming, think of an array as a two column table: row numbers (called indexes) are in the left column and whatever value (zone, timer, number, etc.) I want to store will be in the right column. I have arrays storing mole zones, the timers, and whacking points (among other things): the position (index) of something in one array corresponds with the matching zone/timer/point value in another. I wanted to investigate classes, which I thought might be better to use in this circumstance, but decided to leave that for the next cartridge experiment (a sample RPG).
  • Passing Arguments to Other Methods – It was really sketchy how far I could take this when creating zones and timers from scratch. For instance, I was using a “for” loop to create zones. The number in the loop corresponded to the zone’s position in the zone array (starting at one). However, I needed to know if I could pass that same number to my “MoleWhack()” method, which has code that runs when the player whacks a mole. It turns out I could and this proved extremely useful to know. Had I not been able to do this, I would have had to write a lot of code in a different way. If you’re looking at the source, check out line 1826 or search for “local status, err = pcall(MoleWhack(z, x))” to see what I mean. (I’ll mention “pcall” in a moment.)

 

What’s in the Code

You’ll see a good number of functions in the code. I created a function if I needed to do the same thing from multiple places or doing so would make the code easier to read and understand. I also commented everything a great deal (painfully remembering I could not use an apostrophe in comments due to lua mistaking that for something else). Most comments were for my benefit, actually; I like making notes so I could figure out what I was doing or thinking when I look back on it a year later (or someone else looks at it). Between the version everyone sees and the source I released to the public, I was surprised to see I didn’t really need to do much work. In fact, I simply removed chunks of code I wasn’t using anymore and reordered where I put a few methods. But I did want to leave it as close to what it was when I finished it. It makes for an interesting study into one’s mind.

 

The main engine behind the cartridge can be seen in the “StartGame()” function. It is responsible for creating all game objects and getting things going. It looks like a very long method because I’m also writing the code for the timer and zone events in it. For instance, a timer’s “OnStart()” function doesn’t run “StartGame()” and “StartGame()” doesn’t run it, but I had to create the code that runs when a timer starts and this is done within the “StartGame()” method.

 

The “pcall” function in lua has not yet made it to the forum, so I think I might need to mention that in this post. It stands for “protected call”, meaning that if an error happens in the code beyond it, the cartridge won’t crash. I dislike using pcall or try/catch blocks in code because it’s much, much better practice to fix the problem than use this as a way around. However, resuming the cartridge from a save in the middle of the game could produce unforeseen effects in the code. You see, the Wherigo player won’t save my arrays when the user saves his or her game. That means if the user resumes a game, the timers will expire and try to use an array that no longer exists. (I hope that wasn’t too complicated to follow.) Therefore, I use “pcall” and some specific code to make sure the cartridge won’t crash should this happen.

 

The Coding Process

I built the cartridge around the intent of extending it (for instance, adjusting the number of moles, game time and size, maximum time a mole would be on the field, what the moles were to be called, etc.). This is important to realize early on when developing any software, Wherigo cartridge or otherwise. Knowing this means you avoid hard-coding values and put all your settings in one easy to access place.

 

I began by coding one step at a time. First, I created the core functions and experiments, which involved creating a zone from scratch and moving it to a random place. The demo cartridge’s code helped me figure this out. I loaded what I had written into the emulator and tested it. Next, I created the timers from scratch and tested that. Then the code to assign a name to each mole followed by an array to track which names were in use so, say, Jeremy wouldn’t show up in two places at one time (though I bet some at Groundspeak might swear this happens on a frequent basis). After someone’s suggestion (show the point value with each mole as part of the name), I had to store the moles’ point values in an array because I needed to know the how many points the mole was worth as the mole was moved to another place in the field (and not just when/if the mole was whacked). As you can see, it was an iterative process. And since this was all experimental, I really had to focus on testing each part every step of the way. I cannot stress enough the value of testing along the way. And, yes, I had times where I had to sit and wonder how in the world I could do something. One time, I had to ask my question in the forum.

 

Eventually, I had a working cartridge I could test in the field (after testing it in the emulator many, many times over). I already had a place in mind and chose the cartridge’s field size specifically because people could find a convenient soccer/football field the world over. So, no, the field size was not arbitrary. The first time through, I had a problem with a size and a few things. The next time I went out, I had created a “debug” item in the game, which let me set various values while in the field. You can actually enable this in the code by uncommenting line 2390 (“zitemAdminControl:MoveTo(Player)”). This helped a great deal because I didn’t have to continue loading test versions with slightly different values. After I was reasonably sure of how it worked, I invited someone with me to a test session to get his feedback (when developing software, I highly value such commentary and recommend you listen to your players as well). I made some changes and tried it again. Between each time in the field, I tested the cartridge in the emulator again and again, making sure things worked as expected. So, as you can see, I played it a lot. It’s the same with geocaching: I will spend at least twenty minutes in the field averaging and testing coordinates.

 

After I finished the first version of the game, I came up with the idea for bonus items. I wanted them in the game because they would add a little spice to an otherwise repetitive experience. Quite frankly, I think this little touch does add more excitement, but that’s left up to the player to decide. Adding this feature was extremely easy to do because I coded the game to be flexible—another thing you can keep in mind and do when developing your cartridge.

 

At Geowoodstock VI

GW6 was a fun time and it was an honor to demo the cartridge there. In fact, I was rather concerned I might be stealing Groundspeak’s thunder! It was coincidence I happened to create the game around the time of GW6. In fact, I wasn’t planning to demo it until someone at Groundspeak asked. Since I planned to hang around the Wherigo booth, I agreed.

 

I visited the event grounds on Thursday and chose a place to play the game. Obviously, I couldn’t take up too much space to full game I developed, so I knew I had to create a special, smaller version of the game.

 

I’d have one shot at testing the game and little margin for error. To create this special version, I walked the perimeter of the game field to get some coordinates. That night, I loaded the tracklog into MapSource and found a distance radius that would work as the game’s field size (a 130’ radius, compared to 240’ in the published version). I made a copy of my cartridge’s code and adjusted the game’s field size and points to reflect what I had to work with at GW6. I also appended “GW6” to the cartridge’s name.

 

I arrived early Saturday morning and began testing the cartridge. None of the moles displayed. It was a great time if you wanted to panic, but that wouldn’t fix anything. I got my laptop out and looked through the code. Everything seemed to be in order. I played it again in the emulator and it reproduced my problem. Huh. Eventually, I figured out I hadn’t renamed the cartridge everywhere in the code (and, no, a global find and replace would not have caught it). I fixed the error and loaded the cartridge in the emulator for a quick check. After that, I loaded the compiled cartridge onto my Colorado and looked at it from there. Shortly after, the folks from Groundspeak arrived and we had a quick cartridge loading session (in which I also learned that, for some reason, my laptop did not like two Colorados connected at the same time).

 

For those who attended GW6, now you know the rest of the story.

 

-------

 

Well, as you can see, there’s a lot going on in the cartridge, much I had to consider, and took some time for me to explain. I hope I didn’t bore everyone! While I would prefer to be concise with my answers, I would rather avoid surprises by giving a complete answer.

 

By the way, I'm amazed the forum could take a post almost five pages long.

Link to comment

I'll have to study your post in more detail later, but thanks for posting the dissertation quality post :unsure:

Ha-ha. I thought about saying, "I opened the cartridge's source, post any questions here," but that wouldn't have been nice. You have no idea how long it took me to write and revise that.

 

 

Makes me envious that I am not a programmer. Thanks for posting this. It certainly gets the creative juices flowing.

I've said before to people that I'd collaborate if the programming aspect is all that's getting in their way. However, my time at the moment is filled with many geocaching things I have to do.

 

Once I finish logging (the 350+) GW6 finds, I'll begin experimenting with creating an RPG-like battle in Wherigo. My current focus is on how far I can take Wherigo beyond the "go here, interact with NPC or object, go there" paradigm.

 

Who knew my forum avatar would be so appropriate for this? I wonder if anyone can anyone identify the reference?

Link to comment

Right, I found what it was, I'm just not going to spoil it for anyone else. :unsure:

Ah, the good ol' days. "Night Stalker" was my favorite. I'll go back to it every now and then. Interesting parallels between the start of that industry, dawn of geocaching, and Wherigo as it is now. If I wanted to play any cartridge, I'd have to travel 160 miles, out of state.

 

I'd better quit making chit-chat in this topic. I'd hate for people to have to scroll through more than six posts like this to find the answers they need.

Link to comment

Hello Ranger Fox

Thanks for your post. I would like to adopt your idea and start with the code from your cartridge, but have a question.

If i open the code in the builder what will happen? Will the file be corrupted? Because i understand that you only laid the foundation of your cartridge with the builder and added the other (difficult) part manually.

Link to comment

Hello Ranger Fox

Thanks for your post. I would like to adopt your idea and start with the code from your cartridge, but have a question.

If i open the code in the builder what will happen? Will the file be corrupted? Because i understand that you only laid the foundation of your cartridge with the builder and added the other (difficult) part manually.

"Adopt" my idea? In what way? If that involves editing and later distributing the cartridge code, you'll need my permission. The Creative Commons license I extend to the public is non-commercial, no derivative works. Actually, I haven't thought beyond releasing the code for educational purposes within this thread. I've always been flexible and open to new ideas.

 

The cartridge is builder friendly and the code will not be harmed should you save it in the builder. You won't see too much, though: a few zones, the items, some extremely basic event coding on the items, and every media item I'm using. The author function section, which you won't see in the builder, controls the game's logic and assigns the media to the different levels and provides the mole names (via arrays).

 

It's extremely easy to add new moles or replace the entire set. I can see people having fun with the code by adding different people to whack. That's why I don't mind private releases among friends; making your own set of people to whack is just too fun to do.

Link to comment

Request sent

 

ofcourse my intention was non-commercial. this catridge is a great event idea. I would like to convert it to our event theme (geocoinrace in the netherlands)

To keep everyone else up on what we're talking about, I said I didn't mind private builds for events. In exchange, I'd like to hear of the stories and the good time had.

 

When I get some time, I'll post some instructions on how to change what you're whacking. It won't be difficult to follow.

Link to comment

I'm a great believer in 'less is more' and loved the era of 'Pac-man', 'asteroids', etc. having pumped lots of cash into these coin-op machines at the time.

I think using concepts from these old games is a great way to gain inspiration for developing Wherigo cartridges.

More recently, phone-based games which utilise GPS are available such as Fruit Farmer by Locomatrix.

Is it possible to have realtime graphics on the screen in Wherigo?

Would it be possible to have a pac-man maze, and control the pacman by physically moving?

How about 'Recording' a maze by walking around your favourite park?

Mr. Do?

Dig-Dug?

Breakout?

Pong?

Some of these involve just running over and back, but would be great fun if you could interact with the screen.

Edited by johnrm
Link to comment

Is it possible to have realtime graphics on the screen in Wherigo?

Would it be possible to have a pac-man maze, and control the pacman by physically moving?

 

At the risk of getting "Whacked" for going off topic, my guess is that the answer would be no. The Builder and Player don't appear to support animation, if I'm understanding your question correctly.

 

It does, however, raise an interesting question. Would it be feasible to do a *reverse* Whack-a-Lackey? Instead of chasing down the various Zones that appear and disappear on the playing field, could it be engineered to be CHASED, in a Pacman style, around a playing field and you try to avoid getting captured?

Link to comment

While animation is not possible (animated GIFs were discussed in an early thread, and are not supported), you can change the media associated with an object at any time. In theory, you could have a separate image for each of pac-man's possible positions in the maze. Pretty sure that you'll bump into some cartridge size limitation before you get a meaningfully large maze. But the priniciple might be applied to other schemes involving this kind of position-based animation.

Link to comment

Is it possible to have realtime graphics on the screen in Wherigo?

Would it be possible to have a pac-man maze, and control the pacman by physically moving?

 

At the risk of getting "Whacked" for going off topic, my guess is that the answer would be no. The Builder and Player don't appear to support animation, if I'm understanding your question correctly.

 

It does, however, raise an interesting question. Would it be feasible to do a *reverse* Whack-a-Lackey? Instead of chasing down the various Zones that appear and disappear on the playing field, could it be engineered to be CHASED, in a Pacman style, around a playing field and you try to avoid getting captured?

Interesting concept. I think it would be possible. I'd call the game "Getaway" or "Cops and Robber".

 

You'd section off a 250' radius, the same with Whack-A-Lackey. I'd include an additional zone having a 15' less radius. If you leave the inner zone, a warning comes up you're about to leave the area. If the player leaves the larger area, it's game over.

 

Every second, the "chaser" zones will move a certain number of feet. The higher the difficulty level, the farther the distance. There will also be a random chance the zone will not move towards the player, seeming to wander. The lower the difficulty level, the greater chance of this "disinterest".

 

The goal would be for the player to stay away from those chasing zones for a certain length of time.

 

From the moderator side: I see this forum as a way to talk about cartridge ideas and explore the possibilities. Getting off topic could mean the beginning of a great idea, which is something that makes this section of the forums a little different from others. I think everyone can tell when the discussion wanders unnecessarily and it's up to those same participants to make a reasonable, timely decision to get back on topic. I believe a moderator should only get involved when such self-moderation fails, disrupting the conversation of others.

Link to comment

While animation is not possible (animated GIFs were discussed in an early thread, and are not supported), you can change the media associated with an object at any time. In theory, you could have a separate image for each of pac-man's possible positions in the maze. Pretty sure that you'll bump into some cartridge size limitation before you get a meaningfully large maze. But the principle might be applied to other schemes involving this kind of position-based animation.

I'd be more concerned about enforcing the walls in such a maze before the animation. You can't really control a person's movement if s/he deliberately decides to cheat. The only way to make this effective is to make it location-based in an area with stuff in the player's way. Unless it's something really special or for educational purposes (such as information about a battlefield or other historic site), I'd prefer looking into making cartridges that can be played by a wider audience.

 

For Pac-Man, you'd not only have images of the player's current position in the maze, but also the player's position with every configuration of power pellet and ghost. Such numbers are astronomical: if the grid was only 50x150, I would guess you'd have 7500^6 screens with four ghosts. That would be an estimated 177,978,515,625,000,000,000,000 (178 sextillion) screens. Something like that would be more feasible if we could either draw full images on the fly or make a table of separate images to display to the player.

 

I've already written out instructions to add your own moles to Whack-A-Lackey. I'll post it once I proofread it.

Link to comment

You'll never stop someone cheating in any game.

 

How about the classic '3D Maze' it requires a finite number of images, and for the Colorado at least there is a built in compass, so turning 90 degrees can be reflected graphically.

 

I'm not into GUI programming, and haven't warmed to the builder yet, but dont't mind contributing ideas to the forum.

Link to comment

Some people have expressed an interest in creating private builds and would like to know an easy way of changing around the moles in Whack-A-Lackey. This post will tell you how to do that in however-many-number-it-happens-to-be steps.

 

Find Your Moles

The first step, of course, is to figure out what moles you want and get pictures for each of them. You’ll need a name and picture for each mole. The pictures need to be in JPEG format and I have found images no more than 130 pixels wide and 150 pixels tall tend to work. Any more and you might see some scrolling issues when someone whacks the mole, meaning the player won’t be able to see his/her score and game time remaining as easily. This is certainly not favorable.

 

You also need to know which level in the Whack-A-Lackey game you’re replacing. I suggest replacing the Muggle level as that’s the least important level in the game. Brave individuals who want to add a fourth level to the game need to know there are certain hardcoded places in the game, such as scoring, that assume there are three levels. I’ll have to come out with an update to address this.

 

Add the Mole Images

You can do this in the builder. Open the cartridge code and select “Media”. If you’re looking at my original code, you’ll see a large, organized list. I have images I’m not using at the top, lackey images denoted by “Lackey_” in front of the image name, moderators with “Mod_”, and muggles with “Ped_” (and the three moles) because I really hate typing and using the m-word because I don’t care for Harry Potter. (Instead, I name them “pedestrians”.) In the zip file, I prefix each type of image with “l_”, “m_”, and “p_”, respectively.

 

Naming the Images – It is very important you give all images meaningful, easy names. The player won’t see the image name; it’s only for your reference since you’ll be typing it later. Prefixing the image’s name helps organization. What’s more, the image name in the builder is very close to your image’s variable name in the code—and you’ll be using that variable later on.

 

If you want to replace the muggle level, delete all images after the last moderator image. After that, add your own images. I would suggest following my naming convention and prefixing your images’ names as I have done mine so they are organized in the window. You’ll have to deal with the names soon in the source code, so be sure the names are meaningful, easy to type, and don’t include international characters.

 

Save the Cartridge

After this step, you’ll need to open the cartridge in a text editor, so you’ll need to save the code you just modified. I created the Whack-A-Lackey code with the builder in mind, so the builder will not mess the code up.

 

Open the Code in a Text Editor

I prefer notepad, but whatever works for you…

 

Add Your Mole Type

Do a search for zinputGameType.Choices in the code. The line will look like this:

 zinputGameType.Choices = {"Muggles", "Forum Mods", "Lackeys"}

This is the list players will see when they want to select what they whack. Change one of the mole names to whatever you’re using. The same goes with the zinputGameType.Text value a few lines away from that.

 

Next, you’ll need to handle the player selecting this new mole type. Do a search for zinputGameType:OnGetInput. You’ll see the three mole type names listed in this function. Remember which mole type you added or replaced in the zinputGameType.Choices section? You’ll have to do the same here. Enter your mole type here, exactly as you typed it before, but in lowercase. Within the “if” block, you’re able to adjust the game’s settings based on the mole type: the maximum number of active moles, the game’s maximum distance from the center, and the maximum and minimum number of seconds a mole will be on the field. Do not adjust the gameType variable. That particular variable tells other parts of the game what is being whacked. However, pay attention to this number; you’ll need it later.

 

Next, scroll up a little bit and find the WhatsItCalled() function. This function is called when we need to tell the player what s/he is whacking. Remember that gameType value? Look for it here and replace the name of the mole below it. When I programmed the cartridge, I didn’t need to have something special to change a word to its plural form beyond adding an “s”. Perhaps I’ll have to update the code to include this.

 

You have now added a new mole type (really, just renamed an existing one). Let’s add the moles next.

 

Locate Your Images’ Variable Names

The code for an image in Wherigo looks like this:

zmediaLackey_jeremy = Wherigo.ZMedia(cartWhackALackey)
zmediaLackey_jeremy.Name="Lackey_jeremy"
zmediaLackey_jeremy.Description=""
zmediaLackey_jeremy.AltText=""
zmediaLackey_jeremy.Id="cdda586a-e563-4977-9900-bff886eacd45"
zmediaLackey_jeremy.Resources = {
{ Type = "jpg", Filename = "l_Jeremy.jpg", Directives = {},},
}

Notice in the builder I called my image Lackey_jeremy and in the code it will be called zmediaLackey_jeremy. I must use this latter name when I reference the image in the code. I needed to point this out before continuing. If you’d like to see what your images are called in the code, follow the steps in the next paragraph.

 

Your images should be listed towards the top of the file. If you’re having problems locating them, go to your text editor’s Find command (usually Ctrl+F) and do a search for one of the image names. For instance, I would search for “Lackey_jeremy” if I needed to find Jeremy’s image.

 

Add the List of Mole Names and Images

Do a search for --Establish the list of lackey icons (a comment I use in my code to tell you what I’m doing at that point). You’ll see an “if” statement that checks for the value of gameType (remember that from before?). At this point you see two variables, moleMedia and moleMediaNames. The first holds a comma-delimited list of image variables and the latter tells the game what the player should see them called. That’s how I can display zmediaLackey_jeremy and call it Jeremy in the game.

moleMedia = {zmediaLackey_signal, zmediaLackey_allison, zmediaLackey_annie }
moleMediaNames = {"Signal", "Allison", "Annie"}

The two variables are arrays (the programming term for a list or table). The position of something in one corresponds to the other (for instance, when zmediaLackey_signal is displayed, the name Signal from the other array will be used because they are both the first item on the list; the same will be true of the tenth item). Be very careful of the order in which you type your moles in the lists. You’ll notice except for Signal, I typed all lackeys and moderators in alphabetical order so I can easily and quickly add another image to the list without having to count. It cuts down on the propensity for a dumb error. I’d suggest following my lead and adopting that practice.

 

I have some commented out code in the muggle section (anything prefaced with “--“ in front of it will be ignored by lua). You can either remove that block or ignore it. I was trying to add the images dynamically to the cartridge, but that didn’t work as well as I hoped and I ran out of time to experiment. Perhaps I should have given them an ID or something.

 

Summary

In the above documentation, you were shown how to add mole images through the builder, change what the moles were called as well as some game settings, and add the moles’ images and names to the game. If you have any questions, please ask. If you’d like to see documentation on another part of the game, ask why I did something a certain way, or anything else, just post to this topic.

 

I’ll be on a cache run in Oregon from July 3rd through the 6th, but I’ll be checking in to the forums at night. If I finish with the moderator stuff, I’ll spend some time answering questions.

Link to comment

I am going to try to translate this to dutch language. the muggles will be no problem(we have them over here as well).

the mods and lacky's will be changed to geocoins and (well)known cachers.

Most time will take the images.

 

Ranger Fox: if i change the text in a editer, will i encounter problems chanching the text from english to dutch?

Link to comment

Try using wordpad if you're going to use an international character set.

 

You could also leave the three levels intact and add a few additional levels if you'd prefer. Do a search for all if/then statements testing the value of gameType. That variable controls what you're whacking and the dynamic values that set the game, such as field size, time span an object is in the field, frequency a bonus item shows up, the maximum number of objects that are ever in the field at one time (yes, you could modify the cartridge to have ten or even twenty objects in the field at once, though I think that would overload the one playing the cartridge, much less the Player application itself), etc.

 

The block of code at line 1755 controls the assigning the names and media images to what you're whacking. The function at 982 controls the name of what you're whacking (it will return "Lackey", "Mod", or "Muggle"). Finally, the function at 1044 controls all those variables I mentioned in the previous paragraph. Also check out all the constants starting at line 1004. I made sure to document those well. You can really have some fun and change the game around with them.

 

And, yes, I did code the cartridge with the intent to make it really easy to change around and tweak.

 

Have fun with it! Feel free to post here if you have any questions or need help. I'd love to see people in the Netherlands running around having fun with this.

Link to comment
Try using wordpad if you're going to use an international character set.

The Groundspeak builder will eat anything that isn't a 7-bit ASCII character, so any text editor will do (and Notepad on XP can handle UTF-8 anyway).

 

Fortunately, Dutch hardly needs any accents, and on the occasions where they are theoretically required - eg "één" meaning "one specific item" as opposed to "een" meaning "the number one" or just the indefinite article - Dutch speakers don't make a big deal out of it if they're not available.

 

(At my work we have to deal with situations in some languages where leaving the accent off a letter in the middle of someone's name changes it from the equivalent of "Smith" to the equivalent of "<has inappropriate relationship with> quadrupeds". :laughing:)

Link to comment

Fortunately, Dutch hardly needs any accents, and on the occasions where they are theoretically required - eg "één" meaning "one specific item" as opposed to "een" meaning "the number one" or just the indefinite article - Dutch speakers don't make a big deal out of it if they're not available.

 

That's just right sTeamTraen. Are you Dutch? :blink:

Link to comment

Changing the title is a little more problematic. A cartridge's title is tightly linked (for some unknown reason) to the cartridge's object name. To change the cartridge's title, you'll have to change the object's name.

 

Sure, you can change it. I like getting credit for stuff I make, so please make sure you mention in the cartridge it's based on my Whack-A-Lackey game.

 

Do you remember I mentioned all those tasty variables around line 1004? Check out this line:

geocacheUnlockScore = 700	--This is the score you have to get to unlock the geocache coordinates

Therefore, you get the coordinates for the cache when your score is greater than or equal to the score cited in this variable AND when the device ID is not "desktop" AND when the gameType equals three (for the Lackey level). This is on line 1157.

Link to comment

I do want to change the title if that is ok. whack a lacky does not make any sense in dutch. Nobody knows what a lacky is.

Instead of whacking the emphasis is on the running.

 

Ofcourse you(RF) get all the credits for designing this game. It will be mentioned all over the cartridge. I will send you a concept before publishing but that is still miles away. I still have to finetune the images. And then translating all the info and text. All the way making backups so i dont have to start at the beginning every time i make a mistake.

 

i have searched the file for the cartridge name. I found this:

cartWhackALackey.Id="5beb6dbb-1d03-4d6a-890e-8f727aa3073f"
cartWhackALackey.Name="Whack-A-Lackey"
cartWhackALackey.Description=[[Images of Groundspeak personnel: Copyright 2008. Groundspeak Inc.  Used with permission.

Images of moderators used with permission.]]
cartWhackALackey.Visible=true
cartWhackALackey.Activity="Puzzle"
cartWhackALackey.StartingLocationDescription=[[]]
cartWhackALackey.StartingLocation = Wherigo.INVALID_ZONEPOINT
cartWhackALackey.Version="1.10"
cartWhackALackey.Company="Ranger Fox Adventures, Ltd."
cartWhackALackey.Author="Ranger Fox"
cartWhackALackey.BuilderVersion="2.0.5129.5086"
cartWhackALackey.CreateDate="5/6/2008 7:55:19 PM"
cartWhackALackey.PublishDate="1/1/0001 12:00:00 AM"
cartWhackALackey.UpdateDate="11/23/2008 12:06:46 AM"
cartWhackALackey.LastPlayedDate="1/1/0001 12:00:00 AM"
cartWhackALackey.TargetDevice="PocketPC"
cartWhackALackey.TargetDeviceVersion="0"
cartWhackALackey.StateId="1"
cartWhackALackey.CountryId="2"
cartWhackALackey.Complete=false
cartWhackALackey.UseLogging=true
cartWhackALackey.Icon=zmediabannericon

 

What will happen if i change this or delete something? Edit: changing has no effect on the cartridge but will the ID give troubles?

-- Cartridge Info --
cartRenJeRot.Id="5beb6dbb-1d03-4d6a-890e-8f727aa3073f"
cartRenJeRot.Name="Ren-Je-Rot"
cartRenJeRot.Description=[[Images of Groundspeak personnel: Copyright 2008. Groundspeak Inc.  Used with permission.

Images of moderators used with permission.]]
cartRenJeRot.Visible=true
cartRenJeRot.Activity="Puzzle"
cartRenJeRot.StartingLocationDescription=[[]]
cartRenJeRot.StartingLocation = Wherigo.INVALID_ZONEPOINT
cartRenJeRot.Version="1.10"
cartRenJeRot.Company="Ranger Fox Adventures, Ltd."
cartRenJeRot.Author="Ranger Fox"
cartRenJeRot.BuilderVersion="2.0.5129.5086"
cartRenJeRot.CreateDate="5/6/2008 7:55:19 PM"
cartRenJeRot.PublishDate="1/1/0001 12:00:00 AM"
cartRenJeRot.UpdateDate="11/23/2008 12:06:46 AM"
cartRenJeRot.LastPlayedDate="1/1/0001 12:00:00 AM"
cartRenJeRot.TargetDevice="PocketPC"
cartRenJeRot.TargetDeviceVersion="0"
cartRenJeRot.StateId="1"
cartRenJeRot.CountryId="2"
cartRenJeRot.Complete=false
cartRenJeRot.UseLogging=true
cartRenJeRot.Icon=zmediabannericon

 

There are lots more ID statements all over the cartridge. is it ok to leave them?

Edited by delta123
Link to comment

i have searched the file for the cartridge name. I found this:

cartWhackALackey.Id="5beb6dbb-1d03-4d6a-890e-8f727aa3073f"
cartWhackALackey.Name="Whack-A-Lackey"
cartWhackALackey.Description=[[Images of Groundspeak personnel: Copyright 2008. Groundspeak Inc.  Used with permission.

 

What will happen if i change this or delete something? Edit: changing has no effect on the cartridge but will the ID give troubles?

-- Cartridge Info --

cartRenJeRot.Id="5beb6dbb-1d03-4d6a-890e-8f727aa3073f"

cartRenJeRot.Name="Ren-Je-Rot"

cartRenJeRot.Description=[[images of Groundspeak personnel: Copyright 2008. Groundspeak Inc. Used with permission.

 

There are lots more ID statements all over the cartridge. is it ok to leave them?

You [u]should[/u] change the cartridge ID, because that will be used by the Wherigo website to identify your cartridge. The other Id's are only used internally in your cartridge and therefore can be left as-is

Link to comment

I did forget to mention anything about the cartridge's GUID, didn't I? Good catch.

 

After a quick look, I doubt this is the case. (I certainly hope not!) The GUID in the code begins with 5beb while the cartridge listing's GUID is f600. I would hope an uploaded cartridge gets its own GUID. I believe the GUID inside the cartridge's lua code is only to identify objects within the cartridge itself and the Wherigo web site does not use these to identify a cartridge. If you upload a new version of the cartridge, the site already pairs your upload with the cartridge listing itself and I doubt it inspects the lua code at that time. Highly unlikely. When uploading a new cartridge, a new GUID is created on the site and paired with your uploaded cartridge. Again, no lua inspection and GUID extraction.

 

You made a very good point, Kalkendotters. I'm 99% certain what I stated is the case, but I'll check with Groundspeak for the final word. I can usually make accurate guesses like these due to both what I have seen of Groundspeak's work on gc.com and wheigo.com and what I know of and believe to be good web application design.

 

Edit: I added some detail.

Edited by Ranger Fox
Link to comment

Yesterday my translated Whack a lacky cartridge was published in the Netherlands. Here it is called REN JE ROT. It was launched at the geocoinrace event. A little movieclip is found

. You can find the cachelisting trough my profile. Thankyou RF for giving the dutchies the opportunity to try this out. Edited by delta123
Link to comment

You'll never stop someone cheating in any game.

 

How about the classic '3D Maze' it requires a finite number of images, and for the Colorado at least there is a built in compass, so turning 90 degrees can be reflected graphically.

 

I'm not into GUI programming, and haven't warmed to the builder yet, but dont't mind contributing ideas to the forum.

 

You lot have hit on what I'm currently working on - Packman / mazes.

 

I have a working game where have to move round the maze avoiding 'Squirrels'. In my case all you see are the paths leading off from your current position and the relative location of the squirrels. This in theory means you can have huge mazes because all you need to do is show what the player can see i.e. the exits from an intersection which is probably no more than 5 or so paths.

 

I've been writing it in an easy to modify way, so its at the point I can add in new points and how they link to each other in a list, and then the code goes off and creates zones and adds a couple of squirrels (that you need to avoid while you go round the maze). I've even got it so that players arn't going to need to modify author code to handle what happens when players reach an intersection, it can be done in the builder using its tools for creating new code. My current test game has 43 intersections in the packman map and 2 squirrels

 

As for cheating, I've got code in there to make sure you stick to the paths and don't jump off them as the squirrel runs down the path your on (as if players would do that).

 

Sounds good (I hope). The problem is that the Oregon is struggling a bit mainly because I've used zones so that I could see what was happening in the emulator. Also the intersections of paths in my local park are a bit too close together and something takes out the Oregon. I need to find somewhere better to setup the game. I think I will change zones so that they show up as objects and forget zones - makes it easier to see on the GPS anyway as well as reducing the processing burden. I also need to tidy up the user interaction side of things whilst the bit behind the scenes is working, the decorative and humorous interface is currently lacking.

 

I'm also waiting with interest to see what problems people are having with my Snakes Wherigo given similar techniques are used in that.

 

So, a bit of work still to do yet before releasing a Wherigo and making the code fully available for modification.

Edited by a_snail
Link to comment

You'll never stop someone cheating in any game.

 

How about the classic '3D Maze' it requires a finite number of images, and for the Colorado at least there is a built in compass, so turning 90 degrees can be reflected graphically.

 

I'm not into GUI programming, and haven't warmed to the builder yet, but dont't mind contributing ideas to the forum.

 

You lot have hit on what I'm currently working on - Packman / mazes.

 

I have a working game where have to move round the maze avoiding 'Squirrels'. In my case all you see are the paths leading off from your current position and the relative location of the squirrels. This in theory means you can have huge mazes because all you need to do is show what the player can see i.e. the exits from an intersection which is probably no more than 5 or so paths.

 

I've been writing it in an easy to modify way, so its at the point I can add in new points and how they link to each other in a list, and then the code goes off and creates zones and adds a couple of squirrels (that you need to avoid while you go round the maze). I've even got it so that players arn't going to need to modify author code to handle what happens when players reach an intersection, it can be done in the builder using its tools for creating new code. My current test game has 43 intersections in the packman map and 2 squirrels

 

As for cheating, I've got code in there to make sure you stick to the paths and don't jump off them as the squirrel runs down the path your on (as if players would do that).

 

Sounds good (I hope). The problem is that the Oregon is struggling a bit mainly because I've used zones so that I could see what was happening in the emulator. Also the intersections of paths in my local park are a bit too close together and something takes out the Oregon. I need to find somewhere better to setup the game. I think I will change zones so that they show up as objects and forget zones - makes it easier to see on the GPS anyway as well as reducing the processing burden. I also need to tidy up the user interaction side of things whilst the bit behind the scenes is working, the decorative and humorous interface is currently lacking.

 

I'm also waiting with interest to see what problems people are having with my Snakes Wherigo given similar techniques are used in that.

 

So, a bit of work still to do yet before releasing a Wherigo and making the code fully available for modification.

 

Just remembered I have a .gwc file on me for you to have a look at if you want. Comments welcome.

Packman.zip

Link to comment

Just noticed when the original articles where posted :)

 

I was having similar thoughts over Christmas and Packman looked like the easiest of the old style games to implement with the twist that your in the maze rather than looking top down.

 

I was also pondering something along the lines of the game at the end of a TV game show called the Adventure Game where you have to cross a grid with out getting vaporised by an invisible vortex. You took it in turns to move. The way to tell if the Vortex was on the destination point was to throw a bread roll at it - quality show around 25 years ago at a guess.

Link to comment

Just noticed when the original articles where posted :P

 

I was having similar thoughts over Christmas and Packman looked like the easiest of the old style games to implement with the twist that your in the maze rather than looking top down.

 

I was also pondering something along the lines of the game at the end of a TV game show called the Adventure Game where you have to cross a grid with out getting vaporised by an invisible vortex. You took it in turns to move. The way to tell if the Vortex was on the destination point was to throw a bread roll at it - quality show around 25 years ago at a guess.

The problem with the invisible maze idea is the player can quickly get lost in which way s/he came because the point of reference just isn't there. I played one of those in the field and it took a while. I would have preferred to have physical reference points or some virtual breadcrumb trail.

 

I also thought of an idea like Pac-Man. Again, the problem was a lack of enforcing a wall. However, the idea of "Keep Away" did come to me. Once again, you play it on a football field. A number of "ghosts" will try to chase you. Your job is to keep away from the ghosts while going around and picking up "flags" for points (or, perhaps, you have to clear a certain number of "flags" before the time limit to win the game).

 

Since then, I learned that while the Colorado is great at running a game like this, the Oregon is absolutely horrible at anything involving zone movement and calculation. One of my location-specific cartridges, "Sadie's BiG Adventure", had to be scaled back because the Oregon kept slowing down when a player was on a dialog screen and zones were moving in the background. Is the hardware limit that easy to hit or is the Wherigo Engine itself inefficient in some aspect?

 

The "Keep Away" game idea just doesn't sound as appealing and exciting as "Whack-A-Lackey", though.

Link to comment

Just noticed when the original articles where posted :P

 

I was having similar thoughts over Christmas and Packman looked like the easiest of the old style games to implement with the twist that your in the maze rather than looking top down.

 

I was also pondering something along the lines of the game at the end of a TV game show called the Adventure Game where you have to cross a grid with out getting vaporised by an invisible vortex. You took it in turns to move. The way to tell if the Vortex was on the destination point was to throw a bread roll at it - quality show around 25 years ago at a guess.

The problem with the invisible maze idea is the player can quickly get lost in which way s/he came because the point of reference just isn't there. I played one of those in the field and it took a while. I would have preferred to have physical reference points or some virtual breadcrumb trail.

 

I also thought of an idea like Pac-Man. Again, the problem was a lack of enforcing a wall. However, the idea of "Keep Away" did come to me. Once again, you play it on a football field. A number of "ghosts" will try to chase you. Your job is to keep away from the ghosts while going around and picking up "flags" for points (or, perhaps, you have to clear a certain number of "flags" before the time limit to win the game).

 

Since then, I learned that while the Colorado is great at running a game like this, the Oregon is absolutely horrible at anything involving zone movement and calculation. One of my location-specific cartridges, "Sadie's BiG Adventure", had to be scaled back because the Oregon kept slowing down when a player was on a dialog screen and zones were moving in the background. Is the hardware limit that easy to hit or is the Wherigo Engine itself inefficient in some aspect?

 

The "Keep Away" game idea just doesn't sound as appealing and exciting as "Whack-A-Lackey", though.

 

In the case of this game, I was using actual paths in a relatively flat grassy park so its really obvious where you are meant to go and how to get to any point on the map (Packman isn't intended to be a hidden maze). I agree a football pitch would be much harder given you have no reference points, that said, the game is a play anywhere so if people where really keen they could play it. On a larger scale, I could also have used streets for paths and the buildings act at the visual boundaries.

 

There is code to make sure you stay on the path and don't cheating by heading down a side street the game doesn't know about, so virtual walls are enforced. No avoiding the squirrels!!!

 

In some ways not knowing where you are in the maze is one of the points of a maze (for which this game could easily be adapted), and I'm sure an enterprising player would soon work out that their gps was plotting where they had gone so far and use that to help navigate (no so easy on the Oregon I admit where you would have to save the game, swap to map view to see where you had been and then reload the game).

 

The nodes I'm intending to change from all those types of nut to just "Nut" (or "Path"/"Junction" if the player had been there already) simplifying the whole thing and giving it the virtual bread crumbs. I just went of on a tangent one day trying to find as many type of nut as I could for the game because it sounded good at the time, but in reality over complicates it - kind of interesting though.

 

Collecting flags and avoiding ghosts on a football pitch I like, but the Oregon just can't do many moving things, I would say 3 is the absolute limit, which is well, not really enough. The game its self would be fairly easy to do. One issue might be time, processing events every second might be a bit too unresponsive for a fast action game like that.

Link to comment

I did forget to mention anything about the cartridge's GUID, didn't I? Good catch.

 

After a quick look, I doubt this is the case. (I certainly hope not!) The GUID in the code begins with 5beb while the cartridge listing's GUID is f600. I would hope an uploaded cartridge gets its own GUID.

 

I got burned on that very thing back here. I had one cartridge totally overwritten by the newer one. Good thing I keep lots of cartridge backups. However, since then they could have made changes.

Link to comment

... It's been a while since the last posting ...

 

Because I do not get any further with my project, I looked once again at this great Whack-A-Lackey code hoping to find some inspiration. My focus was on dynamic zone building and especially on how to destroy zones before they get saved.

 

I found this code:

 

--Destroy all the previous zones and timers
local allZones = cartWhackALackey:GetAllOfType('Zone')
txt = txt .. "Zones: " .. table.getn(allZones)
for _,zone in ipairs(allZones) do
 if zone.Name ~= "Cache" then
   zone.Visible = false
   zone.Active = false
   zone = nil
 end
end

 

I've played around a bit with it but I couldn't figure out what's the effect of this line of code:

zone = nil

 

Actually it should destroy the zone(s), or not? But it doesn't. In the emulator zones that have been set to 'nil' remain existing (not visible and inactive but existing) and they are also present in a later .gws file. So what is the purpose of this line of code? Enlightment would be very welcome. Thx.

Link to comment

I was trying to destroy all but the final cache zone when the game ended. That bit about setting a zone to nil was something I automatically put in there due to my C# background, wanting to set all expensive objects to null as soon as I can. Unfortunately, I wasn't successful in that endeavor because the zones did in fact persist even after a game save. I guessed there was something with the Wherigo engine where, once a zone is created and registered, no one anticipated the desire for it to be destroyed.

 

To cope with this, when a game is started (the StartGame() function), I do a test for the alreadySetUp variable (search for the section with "--Set up mole zones"). If that variable is set, I refrain from creating new zones and use existing ones. Same thing with the timers. By the way, I call them "mole" because, when I was writing the game, you were whacking moles. It was only after I was almost done did I come up with the idea to whack the Lackeys.

 

Now that I look at the Battleship cartridge's code, it looks like I failed to check for a reply and I'm just creating new zones. I guess if everything is inactive, that won't tax the engine as much, but I should really go back into that cartridge and test to see if the zones already exist.

 

In other news, I updated both cartridges' code to reflect the deprecation of table.getn for #. matejcik was the one who pointed that out, so thank you.

Link to comment

Thx for answering. - Hm, mysterious ‚nil‘-Command.

 

BTW: I’m struggling with the problem that my cartridge gets unstable and crashes after a restore (maybe because the lua file is too big). Funny enough I was able to eliminate almost all the crashes, by setting all zones (approx. 80) to ‚nil‘ right after restore. Unfortunately I could not find a solution, how to avoid the crashes, when the Player is in the ‚Inventory‘ Section. So I downsized the project (dumped 120 pics :( ) and now the cartridge runs stable again after a restore.

Link to comment

That brings up an interesting point of investigation. The community has settled on six to eight active zones being the maximum, stability-wise, for a cartridge. To my knowledge, we never have looked into images. Each image added (even if not used) to a Wherigo cartridge will create an object when the cartridge is run. I do not know if the Player (it's my convention to use "Player" to denote the application and "player" or "user" to denote the person), upon loading the cartridge, will load all images into memory or will only load the images when referenced. There are arguments both for and against loading images when the cartridge loads versus loading on demand (that being when you want to take that resource hit). I could understand your problem being, on restore, the Player loading everything into memory.

 

Well, either way, the best person to answer this and look into the problem is the person who created the Player you're using. Which is it? As long as you can reproduce this outside the emulator, someone is now able to take a look at it.

 

By the way, if you can reproduce this problem in the emulator, there's a little trick I use when developing my cartridges. When I can't figure out what my cartridge is doing or what some variables are, I use the lua "print" command:

print("Value of the variable var " .. var)

When you're in the emulator, this will print the line to the "Lua Debug" tab. If you're doing something on a cartridge's resume, you might want to pepper your code with this and see if there's one specific statement on which the cartridge always crashes. Just remember to comment out these statements before releasing your cartridge: the print statement will power off a Garmin Oregon and will cause one version (perhaps even the recent one, too; I haven't tried it) of the iPhone Player to display a pop-up error each time it encounters the statement.

Link to comment

We‘re getting off topic here.

 

To my knowledge, we never have looked into images. Each image added (even if not used) to a Wherigo cartridge will create an object when the cartridge is run. I do not know if the Player [...] upon loading the cartridge, will load all images into memory or will only load the images when referenced.

I don‘t think the images are the problem, but the number of references to them. The first thing I did was to shrink the images to an absolute minimum size (about 1 KB). No effect. But when I removed 120 image definitions from the source the restore bug was gone. However, I’m not sure if the size of the rest of the source file is also a factor. Overall my editor counts ~ 10,000 lines (including the blank ones) of code, which is quite a bit, I think. I am not an expert in memory architecture but it seems to me that somehow there were too many pointers/addresses in my code. No matter whether image, function or variable. Or I am completely wrong?

 

Well, either way, the best person to answer this and look into the problem is the person who created the Player you're using. Which is it? As long as you can reproduce this outside the emulator, someone is now able to take a look at it.

The crashes can be reproduced both on Oregon as well as on the Colorado. So it seems that this is not a typical Oregon phenomenon.

 

BTW: When I start the game from scratch I can play it through (outdoors of course) without any crash. I don’t really understand this. I really would like to know what's happening during a restore.

Link to comment

As a courtesy I want to inform @Ranger Foxthat I adapted this cartridge into GC9JX7K

 

I first of all translated into Dutch but I also heavily changed how the game is presented to the players: instead of whacking moles, I transformed it into Santa Claus throwing around christmass balls you have to collect. Likewise the bonusses are changed into more meaningful extras (a poison ball, a super grabber, ...)

 

Adaptation was done solely with notepad and is fairly easy but still requires detailed attention as one typo makes a huge difference. I enjoyed reading the code and the comments :-)

I suppose it should go into your list https://www.geocaching.com/plan/lists/BM2WTWH The credits to Ranger Fox and the original Whack-A-Lackey are in the About ("Over") message of the Instructions Item in the cartridge.

 

Thank you very much for sharing this as an open source cartridge. I always learn a lot by looking at the code and it generates ideas for new cartridges.

Link to comment

Thank you for the compliments, too!  That’s a fun holiday adaptation. 
 

Whack-A-Lackey was my first major arcade style experiment. As I learned more, the code in later cartridges got a lot cleaner. The code comments  in different places are still fun. 
 

I look forward to reading the logs!  That’s a cache owner’s reward for making and placing something people appreciate. 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Followers 6
×
×
  • Create New...