Here, I found it fun to write a small bot to play automatically. Just paste this JS code in the dev console. It reached 9000 points on my first attempt to let it run. Feel free to tweak the code to make pac-man survive longer :-)
function bot() {
/* direction of the enemy: to our right (1) or to our left (-1) */
dir = (enemy.x > player.x) ? 1 : -1;
/* if pac-man... */
if (
/* ...has no powerup or powerup expires in less than 10 "ticks" */ powerTicks < 10 &&
/* ...is headed toward enemy */ player.vx == dir &&
/* ...is too close to enemy */ abs(player.x - enemy.x) < 25 &&
/* and if enemy's state is not "eyes flying back" */ enemy.eyeVx == 0
) {
// "ArrowUp" or any arrow key reverses the direction of pac-man
document.dispatchEvent(new KeyboardEvent('keydown', {code: 'ArrowUp'}));
document.dispatchEvent(new KeyboardEvent('keyup', {code: 'ArrowUp'}));
}
}
setInterval(bot, 100);
The strategy is ultra simple. Every 100 ms it evaluates the situation and chooses to move away from the enemy (ghost) if it's too close to it, and has no powerup (or if the powerup is expiring very soon).
The corner cases where pac-man dies is the game difficulty progressively increases (the ghost becomes faster) until you eat it, so sometimes some pellets are left in the middle and pac-man doesn't have enough time to eat them until the ghost reaches it. The ghost will progressively get faster and faster and death is guaranteed. You could improve the code by tempting the ghost to get close to one edge, then cross over to the other edge and quickly eat the middle pellets.
Also, as soon as new pellets are added, one should prioritize eating the middle pellets.
Also, one could add code to detect the powerup pellets, and chose to NOT move away from the ghost if it calculates it can eat the powerup pellet before the ghost reaches pac-man.
I simply changed the distance to be dynamic based on closeness to the edge and it's getting into the many 100's of thousands. This simple change also seemed to fix the edge case of the respawn hitting the player is solved since the player never gets into that magic position (the enemy has to be in a very specific position for the eyes to reach the end just as the player does).
function bot() {
/* direction of the enemy: to our right (1) or to our left (-1) */
dir = (enemy.x > player.x) ? 1 : -1;
nearWall = enemy.x < 10 || enemy.x > 90
/* if pac-man... */
if (
(
/* ...has no powerup or powerup expires in less than 10 "ticks" */
powerTicks < 10 &&
/* ...is headed toward enemy */ player.vx == dir &&
/* ...is too close to enemy */ abs(player.x - enemy.x)
/* ...the distance before running away can be lower if we're near an edge */
< (dir == 1 ? player.x / 7 : ((100 - player.x) / 7))+7 &&
/* and if enemy's state is not "eyes flying back" */
enemy.eyeVx == 0)
) {
// "ArrowUp" or any arrow key reverses the direction of pac-man
document.dispatchEvent(new KeyboardEvent('keydown', {code: 'ArrowUp'}));
document.dispatchEvent(new KeyboardEvent('keyup', {code: 'ArrowUp'}));
}
}
setInterval(bot, 10);
I'm kind of a 'why not what' kind of guy when it comes to comments. For example "powerTicks < 10" took much less time for my brain to parse (and I get extra information, I see there is a variable called powerTicks then "/* ...has no powerup or powerup expires in less than 10 "ticks" */" did. Then my eyes had to scan for the closing comment to get to the important part.
Parsing has been used to describe the human activity of puzzling out meaning from a string of symbols for longer than electronic computers have been around.
Yeah, I do not know why OP would imply that. The brain does actually parse. In terms of language processing, the term "parse" may refer to the mental process of syntactic analysis, in which case the brain analyzes the grammatical structure of a sentence to comprehend its meaning. Besides that, there is auditory parsing of sound patterns, along with visual parsing of visual scenes to recognize objects, shapes, and patterns.
Sure, the brain does not follow the same principles of formal grammars used in computer science, but I think the term "parsing" still applies.
This is really cool. My bot score stayed low because there was a single dot remaining near the middle which Pac-Man couldn't reach. They went back and forth for a long time until the ghost became fast enough to get him. Still fun to watch.
How did you (or how does one) discover that the game state consists of the variables enemy.{x,vx,eyeVx}, player.{x,vx}, powerTicks? (And are there others?)
I reverse-engineered it. This whole exercise took me about 30 minutes while half coding and half watching a TV show. Since the JS code was neither minified nor obfuscated, it was easy. Here are my exact steps:
In Chrome, right-click on the page -> View Source. Go to the "Sources" tab. When you open the tree on the left you find a file, that was dynamically loaded (so you wouldn't have found it by just looking at the HTML source of the main page), https://abagames.github.io/crisp-game-lib-11-games/pakupaku/... that seems to contain the game's code. And indeed it's less than 200 lines and implements the core game logic.
There is a main function, update(), containing a conditional "if (!ticks)" that seems to do initialization. "ticks" is probably zero at the start of the game. The code initializes multiple variables, including "player" and "enemy":
Then with a bunch of console.log() statements added to the update() function (just edit the code and type Ctrl-S to save it, Chrome allows this sort of in-place code editing), I got a sense that player.x and enemy.x was the x position, with the scale going from 0 (left edge) to 100 (right edge). Then with more console.log() statements I found enemy.eyeVx was normally 0 when the enemy is a ghost or 1 or -1 if the ghost has been eaten and its eyes are flying respectively right or left.
I figured by literally typing "play(...)" in the dev console that these functions play a sound. Therefore based on the sound names "powerUp" and "explosion" I realized this code block is called when pac-man collides with a ghost. And either it has a power-up ("powerTicks > 0") or not, in which case it dies.
At this point I had the meaning of "player", "enemy" and "powerTicks" and that's all I needed to write the bot.
The source code for the page doesn't have any reference to a game-specific source code, so it must have been loaded dynamically and can be found from devtools [1]. You can then read the actual code and find that every state is in the global scope, so they are directly accessible without any trick. It hasn't been minimized so all variable names make sense and you can even guess their purposes without actually checking.
deep reinforcement learning guy here. Youre looking at coding up double dqn, and probably training it for about 5 to 30 minutes. Very likely it would not outperform a simple near perfect algorithm, and would fail in some weird ways that would annoy you a few tens of thousands of times. Youd have issues like it refusing to go left, ever, after dying. So youd need to know about epsilon then epsilon decay etc.
Coding that from nothing (and understanding it) could take days. Weeks to months if you dont know ml stuff.
In this particular case I think basic Q Tabular Learning could play optimally, no neural net required.
I could be wrong though, throw a full conv at it without temporal difference and see what happens! (probably a kinda okayish score)
You could probably throw a small fully connected net at it, and 'train' it via genetic algorithms: ie have a population of nets, let them each run a few games, and pick a few top scorers to seed the next generation with some mutation and cross-over.
This random exploration is less efficient than back propagation, but at least you don't have to muck around with temporal differences. (And it would be hard to figure out how to tweak the weights for backpropagation in this multi-step game; without falling back to reinforcement learning.)
The problem seems simple enough that evolution via mutation and artificial selection has a decent chance to get good in a reasonable amount of computing time.
With the right small neural network architecture you could probably just repeat random weight initialization until you find one that works. This is known to work for some of the Atari games. The trick is, of course, to engineer a good input encoding and to find the right model complexity and architecture in the first place.
NEAT? An added bonus of the evolutionary neural search is that you can still explore the solution space with small networks, which isnt really true of backpropogation without evolution. You run out of states.
The script took, at most, 5 hours to write (inclduing the time for this poster to play the game, understand the game, reverse engineer the game, and implement a bot). What type of "ML solution" to the same problem would take less than 5 hours?
This sounds like a simple enough problem that one could work out a provably optimal algorithm in less time than it takes to get even a non-optimal ML solution working.
But both approaches would be an interesting exercise in their respective domain!
Come to think of it, it might even be an interesting toy problem for a SAT solver! Overkill in the same way as an ML approach, of course.
You inspired me to spend the last two days to build my own bot[1]. The highest score[2] it reached is 300k but it is cannot consistently reach this score (the average score is around 50k). The algorithm is to reverse the player direction only if one of the following conditions is satisfied:
1) enemy is running away from player && power is about to expire && player is close to enemy.
2) player is getting too close to enemy's respawn point && player is too far from wall opposite to him && player has little or no power.
3) enemy is close to player (<20 units away) && the player and the enemy are facing each other.
A live preview of the algorithm in action is deployed on github[3].
This is great. That's what Alan Kay envisioned when doing Smalltalk 45 years ago: opening up a computer program while it's running and tinkering with its code directly.
And it's quite funny that JS was designed after Self/Smalltalk well before anyone cared about interactive tooling, towards which we evolved independently.
I recall manually entered commmands have access to some APIs that are not normally accessible. Maybe timing related? So in the theoretical extreme, a timing attack to access something in your entire system memory and upload it via HTTP... while you watch the game play :)
Do they? It's easy enough to 'give' any API accessible to the console to the page by setting a variable from the page to point to a console-only accessible function.
Given there aren't many sites that say "just open the console and paste this command to win the big prize", I suspect that any console-only API's aren't very powerful if they exist at all.
Because normies are extremely susceptible to things like "hack Facebook, see the PMs of any hot girl u want!111 just right-click and paste this into your browser console trust me bro"
As well as the usual engagement driving "challenges" like "Omg did you know there's no country starting with Z! Bet you can't think of one!" meanwhile comments are filled with "duuuuh Zanzibaaaar!" and post engagement is >>>>>>>>>>>>
Per my experience The optimal strategy is to deprioritize eating the ghost. You can get some nice streaks sometimes eating him but it generally doesn’t help.
What you want to do is use the power up to collect the middle dots. The sides you can collect safely on reflexes alone. By about 3000 points it becomes impossible to recover if you don’t pick up the middle and have consumed your power up. Eating the ghost is ok if it happens incidentally.
Because you’re trying to use the power up to collect the middle that often means the ghost will be further from the middle than you when you finish a line. So finish a line, then 180 immediately to collect the middle again. The worst case is you end up with your power up ending just as you’re finishing a line and you are on the side. But up until very high point values I think it’s always safe to grab the power up as it tends to be on the sides.
Edit: 6800
Might play more if other HNers step up their game :)
Crazy enough, that strategy really works! Barely got to 1000 by eating ghosts and easily to 5000 using your strategy.
I'd say there is even a (very slight) disadvantage to killing the ghost: As long as it's on screen (and preferably slowed down) you know where it is. Once you kill it, you don't know exactly when and where it will reappear.
Interestingly, the points you get for a kill are NOT tied to how many ghosts you've killed before. They only depend on the speed of the ghost, which in turn depends on your overall score.
So I think one addition to the strategy would be to try to keep the ghosts alive as long as practical early on, then start hunting them when you have, say, 1500+ points and kills can actually give a significant bonus.
I have now had several games in the 17000s range although I see I’m not the top scorer here anymore. I don’t think I can go any faster without getting to a physical keyboard vs my touch screen!
A couple more notes: I see now that the score multiplier goes up by 1 for every row cleared AND for every ghost eaten. I don’t think this changes much about my recommended strategy except sometimes you can pause or delay to set up a free ghost kill without breaking the originally stated strat and it’s worthwhile to do so.
At very high levels (15000+) I’m finding it necessary to double tap rapidly to induce small pauses to let the ghost catch up. The timing of these pauses is very tough at high speeds. But the gameplay feels almost safer and more formulaic. Not sure if that’s a function of anything changing in particular. It might just be the normal Strat but fast enough that it normalizes. I might try to do this on a keyboard to get them frame perfect pauses going lol
Edit: worth noting my high score went from 7k to 16k in one game without realizing it had been a particularly good game. The scores ramp up very quick late game and it’s not quite as huge of a gap as you might think
The biggest part of my strategy is to do a lot of stutter steps/dash dancing to try and collect the power up as close to the ghost as possible. Doing so is more likely to lead to a sort of "combo" state where your pacman can spawn kill the ghosts without any additional input. Fast reflexes can keep your combo state going if you know when to stutter step and when to turn back around and start comboing again in the opposite direction Getting your game state into such a combo state is even stronger in the late game as your pacman moves so fast it can almost always set up for a lot of safe kills quickly. And additionally, as you pointed out, by getting a ghost kill for every power up you get, you hasten the speed at which you grow your multiplier
Only other observation has been that the common failure mode is screen wrapping while the ghost is fleeing but without enough time to kill him. Don’t do this. Just wait until he is chasing you to screen wrap.
Mostly following your advice, I got 14257. I found if I could easily eat the ghost, it was worth taking a few extra steps to go for it. The real key is knowing you can successfully leave 6 on either side to carefully pick up after getting the middle.
YES! I play this way even with the original version on Atari, as well as all of the various other 8-bit versions (Ms. Pac Man, Super Pac Man, Pac Man Jr., etc.)
11,800 with a multiplier of 40 ;D
It's really all about the endgame knowing when how to manipulate the ghost's position. Sometimes it's worth it to wiggle back and forth until the ghost gets close to you in the middle to be able to get the dots on the edge. But yes once you pick up the power-up you need to pick up the middle dots.
Heh. My first or second game, I just happened to get like 650 points. And then spent the next 20 minutes trying to figure out what the hell I had done. Turns out you can sometimes get into a rhythm where you don't even have to turn for a while and score a lot of points.
The game's designer/developer, Kenta Cho[1], has made countless experimental games for decades.
I'd nearly forgotten about his work until I saw this post, and I'm very happy to see that he hasn't stopped with experimental game design after all these years, and I have a huge backlog of games to play[2].
These are amazing. I use to play a space shooter game long time ago where you capture the incoming bullets by holding click and throw them back at correct angle. It was single button and mouse movement. Looking at these games, it feels like that one must have been by the same guy.
Wow, that's fun. I wish I could articulate why the music and dying sound effect are both so great. The gameplay has a great rhythmic feeling to it. It's also really tense. I scream every time that damn ghost catches me.
The best part is when I die I feel like I made a dumb mistake, and that if I improved just a few things I could be way better.
Too many games these days give you the allure of depth and complexity by making things difficult in the wrong ways.
There is something to be said about “easy to learn difficult to master” curve, as well as overall basic simplicity and the feedback loop being very transparently clear and “tactile.”
The one game that never fails to hook me in that way is Quake 3. Every mistake feels like your own, but with a very clear and obvious path for improvement. Every improvement step feels incremental and doable, none of that “noscope 180 from the bushes where i had zero chance to spot the enemy” situations.
Even on kills where it initially felt like some annoying cheap trick, i watch the killcam, and walk away very impressed and eager to try out their approach myself. And it always makes perfect sense. As opposed to a lot of more modern games, where killcam only frustrates me more.
Imo this is the same thing that made the original DOOM a massive sensation, but I feel like Quake 3 would be easier to relate to for a lot of people (on HN or elsewhere). At the time, I was too young and growing up in a wrong part of the world to catch that original DOOM hype. But with Quake 3 (and imo even quake 1 and 2), that phenomenon truly transcended countries and cultures.
The best part is when I die I feel like I made a dumb mistake, and that if I improved just a few things I could be way better.
I think I've heard Miyamoto talk about that. When the frustration is all with yourself (rather than with the game itself), and you just know that if you try one more time, that'll be the one where you won't make any dumb mistakes. I think it's the cornerstone of every action game that appeals to me.
Isn't the ghost spawn at least somewhat predictable?
I think it picks the farthest edge from where you ate it. Also, it only spawns at the edges, so don't eat the ghost near the edge if you're not sure where it will spawn.
Yes the ghost is faster than you, but it can't wrap around the stage like you can.
I think you're appreciating (what I also appreciate) that the chomp, ghost bite sound, and death sounds are all in the same tempo/bpm, so that when things happen it's in "rhythm"
If you look closely, the chomping visual doesn't -actually- match up with the chomp sound, it's closer to if there was a track of chomping at a certain chomps per minute that gets toggled on/off if pacman is chomping. Same with everything else-is, so you mute/unmute sounds when the event happens, rather than trigger a sound play.
It sounds like you need to experience eight bit computing! My Commodore 64 from 1986ish still lives after a re-capping a few years ago. I grew up with Sinclair ZX80, 81 and Speccy too.
Nowadays we have such capable hardware that we can model near photorealistic stuff in real time. Not quite but not far off.
Those manic sounds and graphical effects are what you get when the hardware is very limited and some very talented people decide they want more, a lot more.
See if you can run up a simulator and get something like a Jeff Minter game running on whatever your IT gear is. You may like Attack of the Mutant Camels - the sounds are quite surreal, given the target hardware.
Consider taking a look at RetroPie or something similar.
That's more fun than I expected it to be! I like all the little subtle choices - how the ghost respawns, the speed of the ghost vs pac-man, the time it takes for the ghost to flash. It's simple, but I could feel myself learning the timing as I played and working through the strategy, such as it was.
I reached over 110000 points by below code. We may can reach 50000 by average.
Basic strategy is that player turns lately as possible so that enemy can't catch with a distance in a bit. However, this strategy has extremely weak point, that is if yellow feed remains in the center of screen, player can't reach forever.
I'm not so interested in this game already.
But I think this can improve to close perfect, which player can infinitely escape from enemy, by considering "Offense" aspect, like player's invincible mode and enemy's escape mode.
Oh, I had completely forgotten about aba games (the work of Kenta Cho) for some years until seeing this HN post! He has been making little mini-games and posting them on his site (both browser-based and windows-based) for more than 20 years now.
Holy cow. Tumiki Fighters was one of my favorite games a long long time ago. I remember there "only" being 3 or 5 games though! Even then I thought this was brilliant work
I don’t know if anyone else noticed, and I’m not sure whether this is intentional, or maybe the dev found it too hard to do well in browser-based games, but it seems like most of his games don’t sync the sound with actions happening in the game.
For example, in Pac Man, the dots chomping sound seems like it’s just a repeating sound that is toggled on and off, vs. actually syncing with the timing of chomping the dots.
Also, if you check out his other web-based games [1], you’ll notice the same thing — the actions (by tapping) cause a sound that is just repeated at a pre-set rhythm that doesn’t sync with when you tap.
It’s subtle, but can actually have an adverse affect on the performance of the game. I often use sound feedback as a way of timing, and when this doesn’t match what I’m doing, it can definitely throw me off my rhythm.
The Timber Test game [2] is a perfect example of this, particularly on the later levels where you need to cut the log into equal fractions, but the sound timing is always the same, making beeps in unequal intervals.
Controls would be better if left arrow went left, and right arrow went right. As is, they both toggle, which can lead to wrong inputs when trying to stall (left/right in succession)
I was trying to figure out why I despise the controls. I think you are right. The first time I hit left it did something, the second time it ignored me.
It was hard until I realized that the ghost doesn't change when you cross the edge of the screen. After that, it turned into an uninteresting stalemate.
The controls really need to be edited, though. Left should be exclusively left, and right exclusively right. Having them both toggle makes input the primary challenge.
This reminds me of the book Flatland which is about what a 2 dimensional universe would be like and the experience of a 3 dimensional entity visiting it. Great read! https://en.wikipedia.org/wiki/Flatland
I wonder whether anyone has done a Pac-Man variant inspired by Flatland.
Say, a powerup temporarily turns the screen to 3D, with the ghosts only perceiving the 2D slice. Pac-Man might be a cone that can 'shrink' to squeeze around ghosts, can jump through 3rd dimension to 'teleport', can move back and forth between different 'levels' floors in a building, etc.
It's not exactly Flatland or everything you describe, but there is an old arcade game named Pac-Mania where Pac can jump over the ghosts in 3D but they only move in 2D.
Absolutely not. It can do a lot of things but any interpreted language is going to run at a snail's pace, especially not one designed specifically for the C64.
Each game really needs to be written in isolation in assembly to work round the limitations, e.g. some might need a sprite multiplexor, some might not.
Nice. Now do it on a Mobius band: there's a "ceiling" and "floor", and when you go out the left, you end up on the ceiling on the right, and vice versa. Two ghosts chasing you, one on the ceiling and one on the floor.
I have been looking for 1D game ideas to implement on an addressable RGB LED strip. 1D pacman seems perfect, as it's instantly recognizable even with a single-pixel pacman and ghosts, by using the right colors.
Long ago – early 80s – UHF & cable-syndicated TV station WPIX (NY) offered live broadcast call-in videogames controlled by the caller's voice yelling "pixx!". Here's a peek of some of the forms it'd take:
"Behind the scenes, the voice activation was really operators in the control room pushing the buttons." :)
The simple control of this 1D PAKU-PAKU game (or others you're considering) could be wholly voice-operated. (A fun trigger word nodding to an old 'Friends' episode might be: "Pivot!")
With modern voice-recognition/voice-printing, it might even be possible to have a multiplayer game where even though N players are all yelling the same trigger-word, the recognition disambiguates the speaker to control only their sprite. Or, use a larger vocabulary of control-words for more actions. 'Nibbler' with yelled commands "Up!"/"Down!"/"Left!"/"Right!" might be diabolically frustrating.
Very cool ! I like the idea of voice controls. Right now I have a 22-foot long LED strip on the fascia of my house. I was thinking of putting a physical button for visitors or random pedestrians to play the games, but voice control would be more fun.
Another thought: have the 1D RGB strip spin around its long-axis to enable rapid LED cycling to stroboscopically plot the domain in 2D, despite the action & rendering array being "only 1D".
Should be named ·--· ·- -·- ··- ·--· ·- -·- ··- . ("Paku paku" in morse, though I changed the characters to be more obviously plausibly one dimensional themselves so your favorite converter may not work.)
Ghost spawns to never be on a player. It’s not fair.
The big dots should give X seconds of ghost eating ability, not just make the existing ghosts edible. That way new ghosts that spawn instantly after you eat a big dot wouldn’t hurt you.
Absolutely fantastic, please make a version for Playdate or gameboy DMG and put it on itch.io for $10-$100 so I can give you money for this case study in gameplay perfection.
It's so beautiful and inspiring that one lone coder can still make something with so much joy and playability in an era of multimillion dollar games that take the work of hundreds of people for years on end.
In college I made a 1D space invaders game - but it ran on an Arduino (with one physical 'shoot' button) and was played on an 8foot RGB LED light strip. I had it mounted on a wall and I would catch students and professors playing it from time to time during the quarter. It was surprisingly fun.
This pac man game would be awesome to play on an LED strip as well!
It does not seem to work on my side. I get a blank canvas with 0 on top left and HI 0 on the top right. Everything else is blank.
In developer tools I've noticed that one of the GET on the main.js script is returning 404 so maybe that is the problem?
When you eat a ghost, the dots under the ghost don't get eaten. So you skip over 1-2 dots at higher levels when eating a ghost. Then you have to go back to snag them.
Diving into mrb's 1D Pac-Man bot adventure is like stepping into a coder's dream, complete with a shareable JavaScript code that's ripe for tinkering. Along comes AnotherGoodName, who cleverly tweaks the code, turning a good run into an epic high-scoring saga by solving those tricky edge cases. mrb's reaction, a simple 'Of course! Nice.', captures the essence of community-driven coding - where one good idea sparks another, and everyone's game levels up!
Artifcial constraints/trade-offs creating new unexpected properties.
Examples:
- up to 21 million Bitcoins limit - Artificial scarcity
- original 140 character limit for tweets, later expanded to 280, then removed for paid users
- up to 500 users per group in WeChat groupchat
- ip· o· gram. ˈlipəˌgram, ˈlī- : a writing composed of words not having a certain letter (as the Odyssey of Tryphiodorus which had no alpha in the first book, no beta in the second, and so on)
- wireframes vs realistic prototypes (low-fidelity vs high-fildelity)
- monochrome UI for smartphones to remove distractions
mrb's venture into the world of 1D Pac-Man with an auto-playing bot is a neat twist on a classic, complete with shared JavaScript code for all to tweak. Then AnotherGoodName steps in, tweaking the bot to dodge those pesky edge-case issues, skyrocketing the score into six digits. mrb's response to this upgrade? A cool 'Of course! Nice.' - a nod to the joys of collaborative coding and the magic that happens when minds meld over games and code.
Took me a while to realize that it treats a (potentially repeating) key press as the condition to turn around, which badly messes with you if you assume the game has direct control.
It better be landscape only on mobile. Add a pitfall bomb (what was that game that created a hole for the critters to fall into, and you could walk over them, but the climb out and the hole heals in a short period... ? Let the ghosts to fall in a hole, then you can place more than one ghost on the path, but you need as many "hole bombs" as there are ghosts on screen+1 (or N)... to not make it rage quit-worthy.
"what was that game that created a hole for the critters to fall into, and you could walk over them, but the climb out and the hole heals in a short period..."
Almost completely broken on Firefox 121/Mac OS. I was wondering what the fuss was about because it was just a mess. But threw it up on chrome, and looks completely different...
Also there is a weird latency thing if you hold the direction key down and then switch to the other direction.
However, when I loaded it in a new firefox profile it worked fine. A little confused because I tried running it with dev tools loaded and cache disabled and I still had the problem, but I have to think that the problem has something to do with adblock/privacy badger and some stored data. But maybe disable cache doesn't apply to the local storage API.
I'm loving this thread about the 1D Pac-Man bot. mrb starts with a great concept and then AnotherGoodName comes in and boosts its performance. It's like a mini hackathon in here!
This was way more fun than it should be. Wonderful!
Reminds me of Linelight on Steam and my game Kanso, both have 1D game mechanics (but with 2D visuals).
This is so fun! Makes me feel like I’m conducting a 1 dimensional random walk. Who knows, maybe this is being used to generate pseudo stock prices or something.
not as "1D" as I'd imagined, but much more fun. I'm still toying with the idea of making a game that "renders" a 1D projection of a 2D space. (yes, I know, the line would be infinitely thin, I'll compromise on that by stretching it vertically so it's visible)
The evolution of mrb's Pac-Man bot through community input, especially AnotherGoodName's contribution, is a perfect example of the power of collective brainstorming in tech. It's like watching a good idea become great through teamwork!
[edit] It seems that Pixi is one rendering method, and the graphics themselves are abstracted via a "terminal" and "view" class, so the engine focuses on positioning art rather than handling sprite draws directly.
It's a nice set of opinionated choices. In particular, implementing collisions for 2D sprites. I built a game engine like that with particles and collisions (and particle collisions!) in AS3 on top of Starling at one point... sadly, I can't make games with it anymore.
Not really a demo but one of the games he (Kenta Cho) has created using his own library. Imagine it as his yoga or meditation practice. The outlet for his creativity. The Crisp Gane Lib framework allows him to implement game ideas extremely quickly with little friction. Gameplay first!
Bruh, the ghost moves faster than you do! But this is a pretty cool idea, difficulty level spikes after the first screen though, especially if you waste the power pellet, then because the ghost moves as fast or faster it becomes impossible to goad it to either side enough that you can get the remaining pellets.
I was expecting the same game, but from paceman's pov. so you'd see a small line for the dot and a bigger line behind it for the ghost. After thinking about it, I think the game would function the exact same as the lined one, just a drastically different perspective.
mrb's journey into automating 1D Pac-Man turns a nostalgic game into a coder's playground, sharing their JavaScript bot that impressively scored 9,000 points on its maiden run. Enter AnotherGoodName, who amps up the game by fine-tuning the bot's edge strategy, blasting the score through the roof. mrb's reaction to this ingenious tweak? A simple yet appreciative 'Of course! Nice.', showcasing the spirit of collaboration and innovation in the programming community.
The corner cases where pac-man dies is the game difficulty progressively increases (the ghost becomes faster) until you eat it, so sometimes some pellets are left in the middle and pac-man doesn't have enough time to eat them until the ghost reaches it. The ghost will progressively get faster and faster and death is guaranteed. You could improve the code by tempting the ghost to get close to one edge, then cross over to the other edge and quickly eat the middle pellets.
Also, as soon as new pellets are added, one should prioritize eating the middle pellets.
Also, one could add code to detect the powerup pellets, and chose to NOT move away from the ghost if it calculates it can eat the powerup pellet before the ghost reaches pac-man.