DZ-Jay

There is one critical point I kept forgetting to mention, in the presentation and in this thread. It is a key assumption in the enemy's targeting logic in both Pac-Man and Carol: The enemy is not allowed to move backwards. I just took this point for granted as I talked about the path-finding logic, but it must be said expressly: When the enemy looks ahead to the next tile in the current direction of travel, and finds the available exits from there; the exit that points to his current location is explicitly removed from the set to prevent it from going backwards. So the simple algorithm to find the path looks like this: Identify the current virtual tiles of the enemy and its target. Look ahead to the next tile in the current direction of travel. Identify the available exits. Discard the exit which is opposite to the current direction in the axis of movement. Compute the Manhattan Distance to the target from the tile pointed to by each exit. Pick the shortest one. Commit to the new direction. The other point that I wanted to clarify is regarding the path calculation: To be sure, we are not computing the path through the virtual map; we are merely computing the Manhattan Distance between the enemy and its target, without regard to any walls or unavailable exits. The point is not for the sprite to find its way, but for the sprite to make a decision on what direction to go when it reaches the next virtual tile. This is a very dumb algorithm -- the enemy really doesn't know where he is going, he just makes incremental decisions at each tile. In practice, it results in a very effective means to find his way, adjusting as he goes along, and giving him an opportunity to improve on his previous decisions. I hope this makes it clear. -dZ.

During development, I worked out most of the path-finding and AI logic of the enemies by writing it in a C-like pseudo-code. This allowed me to figure out the decisions and proper logic flow, then it was just a matter of "mentally compiling" the code into Assembly Language, and optimizing it from there. Because a few people had asked for it, I include below some of these routines taken directly from my original "Christmas Carol" development documents. Have a look and ask any questions. move_elf.c - Routine to move Carol within the virtual tile map. move_enemy.c - Routine to move an enemy within the virtual tile map. target_snowball.c - Targeting routine for the Snowball, to determine its target tile. zap_elf.c - Routine used by the Bad Toy to detect line-of-sight to Carol and zap her with his laser. Feedback and questions are welcomed! -dZ.

It's looking good so far. Here are a few suggestions, mostly on cosmetic stuff. These are very minor details; but in my opinion, they are the sort of cues that turn a "pretty cool game" into an "classic". The dialog boxes go out to fast and it makes it hard to follow, especially when you are not sure if another one is coming right after. It increases the player's stress without much payback. Ideally, they would be vertically centered on the screen, allowing the player's eyes to hover at roughly the same height each time. Would it be possible to have the pop-up windows grow downwards instead of upwards? Because they come one after the other in rapid succession, it forces my eyes to re-focus at different rows each time, making it again hard to keep up. Ideally, Perhaps a personal choice, but I wouldn't use expletives like "Crap" in the dialog. Personally, I would use something more subdued, like "Oh no!" or even "What??" It makes it more family friendly. It also makes it feel more "retro," since such language would never pass muster back in the day; and encountering it in a game can jar you out of that immersion. That's it for now. It looks like it's going to be a fun game. I never played the original, but it looks very much like my kind of game. :) -dZ.

It looks like it could be lots of fun between two players, sort of like a "space duel." And don't worry about spending weeks on simple stuff; it happens to us all. Not all of us can be superstars like Nanochess and Joe Z. The world still needs mere mortals like us to vacuum the red carpet and bring them coffee. -dZ.

Hi, @CrazyBoss, Not to hijack this thread, I posted a response to your question in the Pac-Man-to-Carol thread. I hope it provides the insight you were looking for.

Sounds like fun. I may just show up. :) -dZ.

For anybody interested, below are links to the original release of the Christmas Carol game here in AA, from 2010, and the development thread of the eventual production release.

04:34:43 5-11under: Tell a bit more about the direction heuristics, if you could. It's quite simple and elegant, it's almost magic. Below is a high-level description of the algorithm, skipping through the technical details of actual signal decoding and sampling. First consider the following diagram, taken directly from the P-Machinery source code: ;; NOTE: The disc is divided into 4 distinct regions for each of the ;; ;; cardinal points. Each region corresponds to 3 discrete disc ;; ;; positions, which expressly exclude the diagonals. The resulting ;; ;; disc layout is illustrated below: ;; ;; ;; ;; F 0 1 ;; ;; E N..N..N 2 ;; ;; x ';:::::;' x Legend: ;; ;; D ';:::;' 3 ------------- ;; ;; W:, ':' ,:E N: North ^ ;; ;; ::::-_ v _::::: E: East > ;; ;; C W::::::"> + <"::::::E 4 S: South v ;; ;; :::::-' ^ '-::::: W: West < ;; ;; W:-" ,:, "-:E x: Invalid ;; ;; B .;:::;. 5 ;; ;; x ,:::::::, x ;; ;; A S''S''S 6 ;; ;; 9 8 7 ;; ;; ;; ;; If the translated disc input results in one of the invalid ;; ;; diagonal values, the disc event is processed in a special way. ;; As you can see, the four cardinal points are slightly expanded to include the immediately adjacent directions, to create the normal directional zones. If your thumb lands on any of those four areas, it will be interpreted as a desire to go in the corresponding direction. So far, this is the way many games already treat the hand-controller. The problem is with the so-called perfect diagonals, which are ambiguous because they are equidistant from two of the cardinal points. Many games do not account for these, creating "dead zones," which are either ignored (sub-optimal), or interpreted as no input, or idle (potentially bad for the player). The "Joy Disc" decoder uses a special set of rules to disambiguate the perfect diagonals, making some assumptions about the player's intent. Some of these assumptions are: We assume the player is rolling his thumb on the disc, as the inty-gods intended it to be, and not just "pressing buttons." We assume that the player is playing for, you know, fun; and not trying to "break the system" to find its flaws. We assume that the player is using the disc in good faith, trying to run around the play-field effectively, and not just randomly pressing control surfaces. The algorithm: Decode the disc input into one of the 16 directional values. If the decoded value is one of the valid directional zones, we accept it. If the decoded value is one of the perfect diagonals, process it further: Compare the new decoded value against the last valid accepted value. Accept the next cardinal point in the direction from the previous to the new one. Return the accepted value. What this means is that we assume that the player is rolling his thumb on the disc and that the signal sampling rate is faster than his movement. So, if he was going, say, North, and we detect a North-East diagonal, we just assume that the player intended to go East, and was in fact rolling his thumb in that direction just when we caught it, right before he made it. So, we commit to that new direction. Ultimately, because the player's movements are constrained to the walking path of the virtual tile map, the whole system sorts itself out by discarding the input if indeed that direction is an invalid one. In such situation, consider that there is no other possible input which we could accept: if the player is moving North and pressing North-East, but there's a wall to the East; we just continue moving North ignoring the input, and avoid annoying the player. In practice, this scheme opens the possibility of accepting the actual valid direction in which the player intended to go without much downside. This is one-half of the reason why Christmas Carol appears so responsive. The other half is ... that it is indeed so responsive. I mean, the disc is sampled in real time, in between display interrupts. This is in contrast to most games, which sample the hand-controller input at 60 Hz, right after moving sprites, checking collisions, and computing the current frame. Thus, the new input is always processed on the next frame, delaying the player's reaction to the action on the screen. This is fine for most games, but for frantic action, twitch-reflex games like Pac-Man and Carol, we could use something better. P-Machinery samples the hand-controller in between frames, so by the time the next interrupt hits, we are guaranteed to have the latest direction the player has chosen, and can move sprites, check collisions, and compute the new frame with this information. Oh, and to be sure, lest anyone imagines that this is some new development, this particular scheme has been in the code since the very early Pac-Man days of the project. That and Pac-Man's fast-cornering were some of the key features I implemented for my "definitive" Pac-Man port, back in 2009. But that's a story for some other day. -dZ.

04:34:40 David Akers: I remember the first roms got lots of testing but after 30 some releases the later versions got less testing... Not a question, but an observation, related to the point above about growing the pool of testers. This is something I mentioned in my retrospective as well, because it is one of my primary lessons learned: "Beta Fatigue." Christmas Carol was on "beta" for an entire year. Enthusiasm was great at the beginning and lots and lots of feedback. 10 months or so and 30-some "beta" releases later, only a couple of people were still giving it a go. I blame myself for the long release cycle. Everyone's help was invaluable throughout those 18 months of development, and some new features came as a result of brainstorming together with the group of beta testers. Some even made it into the final game. However, it was too long and too much. The first production version of Christmas Carol, the one released at the CGE in 2012, is tagged as "2.34" -- that means that there were 34 revisions that were released to the beta testers from the start of project. Who's got the stamina for that? 😱 -dZ.

Here's a follow up question transplanted from another thread: First, as you may recall, the Ghost in Christmas Carol follows the same rules as all other enemies in Carol and Pac-Man. That is, it moves in the virtual tile map, looks ahead as soon as it enters a new tile, computes the shortest available path to its target tile, and commits to its new direction. That is important to keep in mind because the "AI" of the Ghost, as with any other enemy, is essentially the logic used to figure out what that target tile is. Everything else is just the standard boilerplate machinery used by all enemies. With that in mind, let's get to the point: how does the Ghost figure out its target? It's quite a simple thing, really. The magic is in the way the individual rules employed, work in combination with the rest of the enemies and the player interactions, from which a more complex behaviour emerges. First a bit of technical trivia: The Ghost has an internal counter that keeps track of how many tiles he travels as it moves. Actually, he is given a specific number of tiles to count at the start of each level, which is part of the difficulty parameters for each maze. The Ghost then counts down the tiles he traverses as he roams the play-field. When the counter reaches zero, he switches states briefly, re-calculates a new target, and resets the counter. The entire process is repeated throughout the life of the level. So now, on to the description of the algorithm. The Ghost starts each level with a full counter and engaged in his "Roam" mode. The first thing he does is pick a random number from 1 to 8, corresponding to the locations of the presents on the maze. It does not matter whether Carol has already picked up the present, the Ghost may choose its prior location as its target. He then uses the normal pathfinder logic described before to move towards that target, counting down the tiles as he moves through them. If he reaches the target before the counter runs out, he will immediately pick another random present location to target. However, he does not reset his tile counter, increasing the likelihood that it will reach zero soon enough. If the Ghost's tile counter reaches zero before he reaches his target, he enters "Look Around" mode: he stops right on the tile he is on, and engages the Auto-Pilot with a randomly selected script from a pool of eight available "look around" sequences. These vary from short "look left, then right" sequences, to more elaborate ones like "look left, then right, up, then down, then do a double-take; clench the eyes and shake." With the Auto-Pilot engaged, the collision detection routine is disabled, so the Ghost is essentially harmless, just standing there, looking around like a dummy. When the script concludes, it resets the Ghost back to "Roam" mode, which has him pick a random present for a target, and the cycle continues for the duration of the level. As the level progresses and Carol picks up a present, the Ghost immediately switches targets to the exact location from which Carol picked it up. He will not target Carol, only the place where she was in. If the player is quick and savvy enough to notice this, he can avoid the Ghost altogether by moving in the opposite direction. However, more often than not, the bewildered player ends up moving in what turns out to be the Ghost's path to his new target, and BAM! Carol loses her presents. The end effect of the logic above is that the Ghost appears to be running around from one end of the maze to the other, occasionally stops and forgets where he was going, and eventually continues roaming around. He doesn't know who Carol is nor what she's doing, but he will be alerted to her presence whenever he senses that one of "his" presents was taken. It makes him look a little goofy, and alarmingly unpredictable, and just an all-around nuisance who gets in your way from time to time. As you can imagine, the balance of difficulty can be tuned by changing the number of tiles in the counter. The higher the count, the longer the Ghost will travel before stopping and re-targeting. Because the Ghost moves so much faster than Carol, this increases the chances of getting in her way -- especially when she picks up a present and the Ghost just bolts towards that same spot. After all, Carol must move around and pick up those presents, and there's an Evil Snowman rampaging around as well! Reducing the number of tiles in the counter has the opposite effect: it decreases the likelihood of the Ghost ever reaching any of his targets, including the spot where Carol is when she picks up a present; giving her a much needed respite. Moreover, because the Ghost becomes harmless to the touch when he stops to look around, Carol has more chances to escape him by building a greater distance between her and the Ghost. This seemingly complex orchestration of what are essentially rather simple rules, is one of those emergent behaviours that so fascinated me when observing Pac-Man in my youth. The Ghost Of Christmas Presents' AI in particular, is a key ingredient in that delicious recipe that is Christmas Carol, one that makes it stand distinctly apart from its Pac-Man heritage. As I said during the presentation, and I continue to insist, the underlying machinery that Carol takes from Pac-Man is just the raw materials from which a game is forged. Pac-Man has its own fabulous way to impart complex and interesting emergent behaviours on its enemies; Carol has her own. -dZ.

04:27:29 Carlos Madruga: Small tester pool is indeed a problem with homebrew creation. Any ideas on how to compensate for that, other than just paying people to test your game? This is an excellent question, one in which I hope others will chime with their own ideas. A small pool of testers is indeed a problem in our community, mainly because it is such a small community to begin with. In my view, the best way to increase the size of the pool is to reduce the friction for people to join and motivate them to participate. For ideas on this, I usually try to put myself in other people's shoes: Honestly, I have a life and a job, and I'm growing older increasingly faster each year, cutting my time shorter each time. So why would I spend any of it, and apply any effort in something that provides value to someone else? A few answers come to mind immediately: Because I know the person, and I wish them to succeed, and would like to help as I can. Because applying my effort is quite easy and painless, and perhaps even a bit of fun. Because I'm excited about this particular project and would love to get my hands on it early. Because the person promised to reward me with money/in-game credits/free game/merch or loot/etc., for my trouble. Because finding a pernicious bug in a game can be a big challenge, and big challenges are my thing. Because the person has a high standing reputation in my community, is someone I respect and admire, and I would feel honour to assist in some way. Etc. Not all of them apply to everyone, and still there may be many other motivations which are unique to others; but from that we should be able to figure out how to make the prospect more appealing. Let me be more blunt: if your approach to potential testers is just a plain and cold, "here's my new game, does anybody want to give it a try?"; then you may want to reconsider your own motivations. Get to know people; build up your own reputation by helping others; engage the community and participate in various projects; offer players something in return for their efforts -- even if it is just to mention their names in the screen or manual; make the endeavor seem fun and engaging and personal; not dreadful, boring work to make you look good. Also, make sure to focus on making it easy and convenient for others to participate and provide feedback. Not many things will reduce your pool of testers more than forcing them to jump through hoops and follow arcane rules and processes in order to provide what is essentially to your benefit. That's what worked for me. I made tons of friends in AA during the development of Christmas Carol, and I first got to know a lot of them during design and feedback conversations in the beta-testers mailing list I created for it. Everyone was invited, even a bunch of people who joined for the sake of getting a free ROM and never offered any feedback. It did not matter, plenty others did. If it's easy and painless, quick and convenient, and your game is fun and interesting, and your approach is nice and sincere; then why wouldn't they jump at the chance to play? Anyway, I would love to hear what others have to say. -dZ.

04:22:33 Carlos Madruga: Looks like a pretty powerful framework used for this game. I wonder if Intybasic coders might somehow benefit from it to make better games. This has been discussed in the past. Unfortunately, the P-Machinery framework is not a good fit for IntyBASIC's programming model, at least not right out of the box. That is not to say that IntyBASIC is wrong or insufficient; they both offer two distinct ways of approaching the problem. The main barrier to easy integration of the two is that in the IntyBASIC model, the "main" program runs for as long as it needs to, doing all the work needed to compute a frame in sequence, and then relies on the program synchronizing itself with the display interrupt routine via the "WAIT" command. In contrast, P-Machinery treats the display interrupt routine as the "main" program, which then triggers appropriate events according to the results of computing the frame. These events are queued up, then executed in sequence outside the critical path, each one queuing up its own events as necessary. The display interrupt routine in P-Machinery is the game's engine, and it includes the event queue manager. In order for this to work in IntyBASIC, you would have to re-arrange the way that IntyBASIC handles the display interrupt, which unfortunately, is not directly available from the language itself. Consequently, you would have to replace the "epilogue" and "prologue" libraries with a custom one. It's not impossible, and perhaps not even that hard, but at that point it's just a "BASIC" compiler on top of an entirely different programming framework, which may run counter to Oscar's designs. It would render useless most of the higher-level features of the language, reducing it mostly to a fancy "if/else" expression compiler. That said, it may be a project I could tackle -- if I ever finish the framework for release. -dZ.

04:15:59 Anders Carlsson: Did you know that Christmas Carol vs. the Ghost of Christmas Presents is by far the most played game in the AtariAge Classic Games Tracker? Currently at 13340 minutes (222 hours), with Tower of Doom in second place with a mere 4578 minutes. 04:18:10 Anders Carlsson: Actually it is still the fifth most played game ever, covering every games system from 1972 to 1999. Wow! I did not know that! I'm humbled. 😊 Then again, I bet you anything that a good chunk of those hours came from the few guys who beat the game over and over and rolled over the score to yellow. -dZ.

04:15:22 SteveJonesonlywatching: what would you say was your main contribution to the game versus what Joe contributed? ie what was the division of the creative input? While I am forever indebted to Joe for his wonderful help, motivation, mentoring, and technical assistance throughout the development process; I don't think he would disagree if I claim that Christmas Carol is my own creative and development work. That's not to diminish his credit at all. I will go further and say that during the original three-weeks project that turned Pac-Man into Christmas Carol back in December 2010, we both were constantly working on getting it running. Joe offered technical solutions to some problems, sometimes even algorithms and code, but I would then have to adapt these into my framework or implement them wholesale. He served as a sounding board to my ideas, and provided feedback and expertise. And of course, he created those fantastic sound effects which give life to the entire game! You actually can read all about that stage of the project in the tread titled "The Birth Of Christmas Carol." It shines a stark light on our great collaboration, and gives a bit of insight into how the story and characters of Christmas Carol's world evolved. Joe's participation in the 18-month journey that took that "prototype" into a full-fledged CIB production was more attenuated, mostly because the underlying framework was a bit more stable and I've already gained enough experience to take the training wheels off. He still was one of the primary testers and contributors of ideas, plus he published the game in a phenomenal gatefold box with an awesome cartridge and sticker, and handled all the logistics for release. If you want more information about Joe's and other's contributions, check out the credit sequence, which plays from the title screen of the game. They are also at the end of the game's manual. :) -dZ.

04:05:48 Carlos Madruga: How often do enemies recalculate the path based on the most recent player position? Very good question! The enemies' "pathfinder" routine is called as soon as they enter into a new virtual tile. As shown in the presentation, at that point they choose the shortest path to their target tile and commit to that direction, but they will continue moving in the current direction until they reach that tile. When they reach the new tile, they "turn" by switching to the last committed direction, and call the pathfinder routine again. Moreover, you may remember from the presentation that the turn actually takes a few steps to complete: As soon as the enemy enters a new virtual tile, the actual process has the enemy "look" in the new direction, but continue to move in the previous one, until it gets aligned with the path at the center of the tile; at which point it actually can start moving in the new direction: If you look carefully in Christmas Carol (as in Pac-Man), you will see the enemies changing their orientation early, giving you an indication of which direction they will travel next. It's more subtle in Christmas Carol since the distance to travel is merely 4 pixels between tiles, but the effect is there and quite noticeable. Once again, this is the underlying mechanism of Pac-Man as well as Carol. It's the generic "combustion engine" that makes the proverbial car move. What makes a car special and different from another is all the stuff built on top and around it. By the way, you will noticed that I said "shortest path to their target tile" rather than "to the player position." This is important, for in Carol as in Pac-Man, the sprites do not necessarily base their targets on the player position directly, and sometimes at all. Which target an enemy follows and how it chooses it, is the actual secret sauce that makes Pac-Man such an enduring and enjoyable classic -- it's what gives each individual ghost its identity, and what imparts on it what appears to be rational behaviour and personality. I'd like to think that the same is true for Christmas Carol's design choices on the matter. 😏 -dZ.

04:04:45 SteveJonesonlywatching: so you can be in an open space but not be able to move in what looks like open space because you are not on the virtual tile path? To be clear, the virtual map is implemented in such a way that it guarantees a sprite will never be in a tile from which it cannot escape. That is, adjacent tiles share their exits. So being able to move, say, to the right on one tile, implies that you can move to the left from its neighbor to the right. This is the basic principle, in Pac-Man as in Carol. The main mechanical difference in the virtual map between Pac-Man and Carol is in the resolution: Pac-Man tiles coincide with the background cards, so every card used to draw the maze (a straight, a corner, a junction, a wall, etc.) is potentially part of the map. Carol tiles, on the other hand, are half the resolution of the background cards. To account for this (and to be able to implement Pac-Man faithfully as originally intended), the virtual map is slightly offset from the background cards. Take a look below and notice that the "path" connects the center of the background tiles and that the virtual tiles at the edges of a background tile are not part of it. Those appear as black squares in the image below. This gives an identical result to the way Pac-Man works: the sprites can only move across the center line of the path and turn only at the center point of a tile. It's just that Pac-Man tiles are the same size as the visual background cards. The sprites in Christmas Carol can only move through those tiles aligned with the center of background cards (just like Pac-Man), leaving a lot of empty space. This is why Carol and her enemies "zig zag" their way around the open play-field: So then ... if the path is still constrained to the center of the background cards, why is the virtual map in Carol smaller? The answer is quite simple: to give a higher resolution to the enemies in making their path calculations. Remember, if the play-field is twice as big in Pac-Man than in Carol, and Pac-Man's enemies make decisions every 8 pixels (the distance between two tiles), then making Carol's enemies make decisions at the same rate would result in a much slower reaction time. This, in my opinion, is one of my key innovations in what was intended to be the "definitive" port of Pac-Man to the Intellivision: We scale the play-field, but we also scale the sprites' speed, and consequently their animation and decision rates. All in order to maintain the balance of the original. Let me know if this does not answer the question. -dZ.

Hi, @timdu, that's a great question. "Christmas Carol Adventure" (aka "Christmas Carol 1.5," aka "Super Pro Christmas Carol," aka "Christmas Carol Supreme -- with extra sour cream") is planned for a Christmas 2021 release. At least, that's the plan, such as it is. As it should be apparent by now, these plans should be taken with a rather large helping of salt. I may seem like a mild-manner programmer during the weekdays, but on my free time, I exercise my most impressive super-power: procrastination. More than a pro, I can castinate like a master! 😆

04:00:31 Carlos Madruga: Manhattan Distance... interesting... Yes, very interesting. I honestly do not know how Pac-Man implements distance computation, for I've never actually looked through the source code, but it seems logical to assume that it also uses Manhattan Distance. In any case, it is the solution offered by Joe Z. when I was struggling to optimize path distance calculations. Euclidian geometry is quite expensive to compute on an Intellivision because the CPU lacks dedicated circuitry for multiplication and division. This would be especially detrimental in a game like this because of the constant computation of multiple available paths by various enemies. Manhattan Distance (also known as Taxicab Geometry), on the other hand, is quite easy to implement using only addition and subtraction: Given two points on a two-dimensional grid, the result is the sum of the difference in each axis: P1: (x1, y1) P2: (x2, y2) Manhattan Distance = |x2 - x1| + |y2 - y1| Essentially, it's how many blocks you have to walk in each direction on a grid-plan, in order to get from one corner of the city to the other. Hence the name. For Christmas Carol, this turned out to be a great and easy solution to what I thought was a complex problem. Live and learn, and thanks to Joe Z. for the suggestion! -dZ.

Hello, everyone, I thought I'd open up a Q & A thread on the topic I presented in the Virtual Expo 2020. I noticed there were a few questions and comments I missed in the chat window -- what with being overwhelmed by the entire production, and being nervous to speak in public. I will try to address those below as best as I can. Feel free to ask anything else! :) Considering that I went from zero game-development experience, to actually making a successful and beloved game, by the mere grace of many veterans who helped me; it is my genuine pleasure to be able to pay forward any wisdom I may have gained. :) -dZ.

Hi, Claus, Brian's nick in AtariAge is @bhall408. You can contact him directly to get more information. -dZ.

That's not what I heard. UPDATE: (For clarity, not this year, but the future is not written yet.)

I personally hate them. When they came out in the early 1980s, I begged my mom to buy them for me because I thought that it would be the answer to all my woes playing arcade games on the Intellivision. They sucked. The worse part is that the ones I bought recommended in the instructions to remove the golden metal plate from the disc and attach directly to the plastic harness, so the 10 year-old me dutifully obliged, which resulted on warped and bent metal plates. They sort of ruined my hand-controllers once I decided to remove the sticklers and put the plates back. :( Personally, I love the Intellivision disc controller. I think it can be a great asset if used correctly (by programmers and players). The trick is to treat it not as a switch, but as a "d-pad," where you roll your thumb on top, round and round, instead of pressing specific directions. -dZ.

Me too, or at least composite.

If I may make a suggestion, it looks like the hand-controller handler could use a bit of damping. The idea being that the controller provides some initial resistance to movement, so as to smooth out the player movement and not forcing him to "tap lightly" at various points in order to align the sprite properly on the screen. The game looks great so far. The visual style reminds me of the early Space Quest games, with their beautiful use of EGA graphics. However, it does look like you have to make constant micro-adjustments to the cursor control in order to position it where you want it. That could be annoying and frustrating to the player; damping should help with that. -dZ.

Hello everyone, Pardon the shameless plug, but I've been reminded that I didn't provide a link to the Christmas Carol book during the event. The book is available for purchase directly from my site here: https://www.carolvsghost.com/book Of course, if anybody has any questions ordering or the product itself, please contact me directly. :) Also, for those interested, you can follow the book's thread here in AtariAge, where I've posted a few behind-the-scenes comments, including some of the hand-drawn illustrations and how they came to be. Thank you so much again! -dZ.