Andrew Davie
-
Posts
5,982 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Andrew Davie
-
-
11 hours ago, Al_Nafuur said:
only 10 digits?
🤷♂️
a decent 2600 game nowadays has 15 for each player:
Oh, but WenHop is an indecent game!
-
1
-
-
I'm thinking -- since Mellon Husk is a billionaire, and I have 10 digits available for the score... I really should allow 10 digit scores, as true multi-billionaires do.
-
1
-
-
Here's a version that implements that behaviour -- if you generate coins in a block of < 10 then you just get that many points. If more than 10, less than 20, you get 10 x the number of coins as your score. If you get 20 or more, then you get 100x the number of coins as your score. It incentivises generating large areas, which takes gameplay time to do. I'll put onscreen "x10" and "x100" indicators up sometime to make it obvious what's happening.
-
1
-
1
-
-
26 minutes ago, Jetboot Jack said:
Sorry if this is already answered - if you hit one boulder with the pickaxe does it become a coin or only "merged" boulders generate coins when hit, so two and up merged boulders?
What is the player facing gameplay advantage of connecting up many boulders before you hit them - more coins than usual, more valuable coins, a bonus or some other reward?
sTeVE
P.S. It looks absolutely lovely!
Current mechanics aren't final. But here's what happens now... you hit one boulder with the pickaxe 4 times, it changes to a dogecoin. If you are still holding the direction, you immediately move over it and grab the coin. End of story. However, if you let the joystick go just as the 4th strike happens, then it changes the boulder to a doge-coin and a chain reaction starts -- any boulders adjacent to that coin also become dogecoin, and so forth.
The merged block defines the limit of that chain reaction. Currently that's all that happens. However what I'm working on right now is a counter, so I will be counting the number of boulders converted to dogecoin from your single original coin. The larger the area the bigger the score bonus. That is, convert 3 boulders to coins, maybe 100 points. Convert 30, then maybe 50000 points. So you will want to bulid up the areas first and THEN convert to dogecoin.
Also, another mechanic, you will only have a limited number of pickaxe/strikes available so you really do want to maximise the dogecoin harvest by building up large boulder groups first, before expending your precious tools for mining.Also also, don't forget to hit left difficulty if the iCC display is bugging your eyes - you can just switch back to normal chronocolour.
Edit: forgot to mention -- if you drop coins on blocks of boulders, that also starts a chain reaction, and you get the same scoring/points for that, too. So far I've found a number of strategies that are significantly different in execution, but which give an awful lot of dogecoin action. It's all happening.
-
1
-
-
-
1
-
1
-
-
9 hours ago, Propane13 said:
As a gameplay element, are you thinking of limiting the amount of pickaxe uses? It might be interesting to have them only good for 20 hits or something, but then you have to find additional pickaxes to continue.
it could also be fun to be able to stock up and buy them at a store in the Asteroid Belt or from the UFO store or something. I'm just thinking it could be an interestingway to scale difficulty between novice and expert players.
Yes, thanks for the suggestion. Here's the new mechanics...
I've ditched the idea of rocks changing to dogecoin when completely surrounded by other rocks. I've also changed the operation of the pickaxe. It used to just pulverize a rock. New behaviour is that you pickaxe a rock and it and all the connected rocks change to dogecoin. This gives a good "meaning" to the mechanism of showing the rocks as connected, too - you can instantly/easily see which ones will change to dogecoin. Furthermore, any dogecoin touching a boulder will turn that rock to dogecoin too. It adds interesting mechanic - for example, if I limit the amount of picks you have/can do, then you really want to first conglomerate the rocks into larger groupings, and then do the "picking" to convert to dogecoin. Another way is to drop existing dogecoin onto rock groups. I deliberately slow down the coin generation to give some visual eye candy as it happens. There's a bug where falling boulders disappear - but ignoring that, it's all happening!
I'll release a binary when I fix the falling boulder blank/bug.
-
2
-
-
Well, three versions in a night is a bit over the top... but if you're on a roll... so this is the last version for tonight. I have realised that due to the game mechanic change of using a pick to shatter rocks, you can technically no longer get trapped (so you don't need suicide). It actually adds quite a lot to the gameplay, so now you really are mining rather than just moving around through dirt. Here's a bit of gameplay video showing that. Also, added some sounds. All rudimentary placeholders stuff, but it's feeling pretty solid to me.
-
4
-
-
I was just watching my interview on @ZeroPage Homebrew, as one does, and was thinking "hey, boy this new boulder merge thing would look brilliant on Sokoboo". It really does give a nice feeling of continuous walls/areas. Maybe I'll get back and do yet another Sokoboo. Doing it again but with ARM would be super-quick.
-
1
-
-
-
2
-
-
Well, the dogecoins are in, and I've added a new mechanic - instead of pushing boulders, you now hack at them with a pickaxe. Obviously extremely early/placeholder graphics, but it seems to be quite a nice gameplay element. In the video I'm just going through a few variants of creating coin and mining it. I like.
-
3
-
-
Here's a short video showing the concept. The diamonds here will be dogecoins. The shapes are a quick hack here, but essentially whenever a totally rock/diamond surrounded area is found, it changes to the treasure. More obvious later in the video. what you're looking for/at here is when I drop rocks onto other rocks, and they "conglomerate", when an area inside that rock block I'm forming is totally surrounded by other rock, then it becomes the diamond/coin.
Seems to offer some interesting mechanics.
-
1
-
-
I just thought of an interesting gameplay mechanic which a quick-n-dirty test shows actually seems workable. The idea is that when a position (i.e., a square area on the grid) is completely surrounded by rock, then it changes into a dogecoin. Think of maybe some sort of high-pressure mid-rock magic. Anyway, I like it because you drop rocks to form the big blocks of rocky area... but inside those rocky areas are now dogecoins, and you now need to break apart the rocky areas to get the coins. It seems to lead to interesting gameplay, and now rather than scatter dogecoin randomly around the screen, you actually have to generate them by selective rock-dropping. Forming areas of rock with cells totally surrounded by other rock isn't exactly the simplest thing to do.
I'll work on it for a while and then release a version for opinions. -
16 minutes ago, Gemintronic said:
The formation directly below the player looks.. girthy.. substantial? rock hard? *cough*
I'm wondering if you watched the ZPH show a year or two back where wen hop was shown? In particular the dogeship with the animating dogeballs?
-
1
-
-
Here's the first binary of the "rewrite" version. It's just a single planet/screen with the "auto-merge" rocks working. Essentially all you can do is move around and dig away dirt under the rocks, watch them fall and merge. Single-click to switch to mid-view. Double-click to switch to overview. When you're dead, hold down the button to restart. There's a tune, of sorts, running in the background. @Pat Brady helped me with the transcription; TY. I hacked the 2nd channel to be a sort of random-distortion backing track; I know it's horrible!
One thing I'm working on in the display is left/right wraparound. So, the playing area is 40 "characters" wide, and you scroll over that as you move... but I'm going to have "infinite" movement left/right - you just kind of wrap around the left/right edge of that 40-wide area. It will be interesting, and possibly add to the game mechanics.
The iCC display is enabled by default - but I'm undecided about that. To toggle on/off, switch the left difficulty (F5 on emulators). Sometimes I love it, sometimes it really annoys me.
-
6
-
-
When migrating this project from BD, I was looking at my "ROMs" directory. When I do a build, the Makefile automatically puts a time-stamped copy of the binary in that directory. I set this up around 8/8/2022. For those of you in the USA, who do dates different to the rest of us, that's 8/8/2022. Anyway, that was 194 days ago - and the directory has just over 10,500 binaries in it. So that makes just over 50 builds a day, every single day since then. That's a lot!
-
2
-
2
-
-
A little more work on this - I've increased the playfield size a bit by reclaiming the score area and instead overlaying the score. It's sometimes hard to see, but I can always put a black surround on the digits. But I'm thinking at this point perhaps having no score at all (unless really needed) on the screen, and devote the entire to the playing area. Anyway, we can see what it looks like in this video.
The major change here is the "auto-config" of the falling rocks. The game will have more of a moving/digging through underground chambers with large solid blocks of rock, and perhaps mechanics where the rock sections behave as a single unit, rather than individual characters. Anyway, this is a first step towards that, and as you see, the individual characters can still fall - a bit like in BD, when they settle, there's a bit of a readjustment going on there and the characters coalesce into a more solid-feeling wall/passageway type of thing. I quite like it. Eventually you will have to use tools to break through these sections of rock.
-
5
-
-
13 hours ago, Gemintronic said:
If anyone is up for the challenge of getting these things running from scratch on an ARM platform like the Raspberry Pi 4 that'd be impressive.
I'm wondering if this might be simpler than it seems. That is, running VSCode and Atari Developer Studio? Essentially use VSCodium (already done: https://learncgames.com/how-to-install-vscodium-on-a-raspberry-pi/ ) and then you just have the ADS issue. I assume it's a build required?
-
1
-
-
58 minutes ago, Gemintronic said:
I tried AtariDevStudio on VSCodium for x64 Windows and it opened, compiled and ran a bB game. ADS doesn't appear in whatever marketplace it uses so I had to install the extension from file. I suspect some integration might not be, er, integrated but I'm not familiar enough with ADS or Visual Studio Code to know. Did the CTRL+SHIFT+P thing to open up the command palette and go from there.
Had not heard of vscodium before, but I hate any and all tracking and so thought I'd give it a go on my MacOS machine (M2).
Working just fine and after manual install of the ADS extension, everything appears to be working as expected. TY.
I read that the licensing of the vscode code says that if you use the open source code you cannot use the Microsoft extensions/store, so ADS will never appear in the install options under vscodium. If I understood that correctly. So a manual install is the price you pay. It's not hard.
-
3
-
-
Aside from doing a bit of component-soldering, I've not done a lot on this project in the last few days.
One thing I have started thinking about is an enclosure, and I designed/printed up a "top plate" to see what it might look like. The idea here is multiple parts that slide/slot together to form an enclosure that is easily disassembled for access to the internals.
-
8
-
-
Chess
in Atari 2600
1 hour ago, AW127 said:Hy Andrew. After a longer time, i wanted to ask, if this error in BitChess could be fixed in the meantime, which occurred at that time, if one of the pieces was exchanged? Do you remember, I had reported about it once here in this thread, when I let BitChess play against another chessprogram on my C64 and there was an error in this game, when the C64 program managed, to bring a piece through to the line and i then wanted to select the swap-piece (a queen).
Could that be fixed meanwhile, or have you not worked on the program again so far? I ask, because I would like to play a few more games on the PC, against BitChess (by myself and against other chess-programs), to be able to better judge the playing-strength of BitChess. But for that, a game should of course run through completely without an error.
Sorry, no I will not be returning to this project.
In the long run, a chess engine running on an ARM-based cartridge with (perhaps) dual core processor would be the way to proceed.
BitChess isn't/wasn't good enough - many months of expert development goes into 6502 chess engines, particularly the evaluation algorithms. This one isn't nearly strong enough at this stage, and I'm not inclined to spend more time as I have other projects that I expect will take all available time for the forseeable future.
Sorry...
-
34 minutes ago, Thomas Jentzsch said:
Did the show not happen? I cannot find the stream.
See post 2 up - show postponed.
-
1
-
-
3 hours ago, bigmessowires said:
TL;DNR - I'm personally interested in seeing what kinds of games people have been able to make without the use of coprocessor technology. Right now I don't think there's any easy way for me to find those, since there's no separate category for them, and the info isn't part of the game descriptions either. I would appreciate a way to find these games and judge them against each other. That is all.
For an interesting comparison on the differences between ARM-enabled and not, in the "same game" perhaps if you look at YouTube videos of Boulder Dash -- essentially the same game/concept. The ARM allows you to do a lot, lot of extra pushing of the TIA. Don't forget the extra power having extra RAM gives you, too.
32K ARM-enabled: https://www.youtube.com/watch?v=wIfdXMwiuoI
16K, not ARM: https://www.youtube.com/watch?v=w6Ge6G9sT9E
-
4
-
-
OK, that mouser parts has identified the issue, I guess. I saw a packet with 10uF capacitor, and matched that to C11 - and noticed a second 10uF capacitor in the placement list so I thought two 10uF capacitors, great. I will most probably find the actual C11 - an unpolarised capacitor - in one of the as-yet-unopened plastic bags. Thanks for the cross-reference.
-
My multimeter is misbehaving. Not a huge surprise when I think about it; it's been idle for years so the battery must be suspect. Digging up those 2K resistors which read 1775 yesterday - today they read 2200, and only when I tried several times did they settle down at 1990. So, new battery or new multimeter before I complain about tolerances again.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Wen hop? The Search for Planet X
in Atari 2600
Posted
In a spacesuit...?
