Noodlings Not a dev journal but a noodling journey
#1
Posted 25 October 2024 - 05:45 AM
This leads to a lot of noodling. And my noodling in MZX leads me to asking questions about how this or that works. So rather than post a new thread every other day in Robotic Talk, I'll just throw them in here.
My latest noodling is trying out a concept I stumbled upon while trying to make some Twin Stick shooting action with MZX. Basically, I didn't understand MZX well enough to do what I wanted to do, and this time I came in knowing this and decided to stick with the more 'vanilla' mzx commands to see how far I could get. And apparently, very VERY far. One of the questions I had already was how to get ring and potion effects when there's no command for all of them and you can't PUT an item on the player to simulate an instant effect...and their 'hack' was like...not evident to me that it made me realize I don't know anything at all about the original pre-sprite-engine mzx at all, so...that's a lot of what I'm playing with...pre-sprite era stuff just to see how far robotic 'extends' mzx.
At any rate, the twin stick noodling thing that didn't go right the first time spawned an idea...what if robotron but you don't shoot, turrets around you do...and you can get shot by them so you should not do that...and that's what i've been noodling on.
Here's a video of me trying to speed run this test level without doing one of the main mechanics of the game which is deactivating the enemy generators on the way to retrieve the mcguffen so the return doesn't have as many enemies. I also forgot I had the super bomb I just learned how to program in with avalanche then change the rocks into explosions and make the player invincible for a couple of cycles so it doesn't kill him....learned all that for situations like i had there...and forgot that's a game element lol
https://youtu.be/qllEwjvHkWE
Oh well!
Right now I'm looking at how to refactor the robotic that handles the zone activation and scrolling. Currently it's hardcoded to 4 zones of 4 specific colors, so I'm now looking at how to make it so a level robot will store the level data with all of the zones, their colors, etc. and a global bot will figure all that out and let the robots used as sensors sort it out cause i'm using ALIGNEDNS and ALIGNEDEW along with HORIZPLD and VERTPLD to create 'infrared sensors' to shift zones....you can see them in the video, there's two white blocks near the zone changes. one of those white blocks is a robot, the other is just a white block. It sends a message that the zone changed so the main zone controller gets new cordinates of where to scroll, what walls to bright and what walls to darken, and all of the generators run independently, so they're just running if the zone is set or not. Same with the guns, they just keep checking if their zone is active or not.
Welp, I'll be asking all my questions here from now on, I guess. And showing other noodlings, of which I've many. One of them is a rather sizable collection of ANSI art I made in service of a game that UFO50 beat me to, but mine was going to be all BBS door games and such...with different BBS's to connect to for different difficulty levels and similarly with an 'underlying story' tying everything together. It's a rather giant scope of a game for one dude, especially one who digs ansi art and wanted to make it as an excuse to do a game with dope static screens...but...that's for another day.
#2
Posted 25 October 2024 - 11:18 PM
How it looks after hammering out the features I REALLY must have and the ones that are neat looking, but don't help gameplay or make the action more confusing than it already is.
I noticed there's no ZZT RESTORE feature, so I tried to RESTORE JUSTENTERED. I don't know if that does anything. Does the internal one time label respond as if it has been zapped?
Anyway, next up is to experiment with more MZX built in items as that was the goal with this one...make mzx itself just 'feel' different even though it's mostly the same old stuff. I'm not sure if i"ll add custom weapons or not. I feel like bombs, instead destra (BLAST) and just the cannon layout should be enough. What I really need to figure out is how to keep track of monsters killed. Since the player technically isn't shooting the monsters, there's no points being made. It also sucks that other weapons don't hurt monsters despite having checked "ENEMIES BULLETS HURT EACH OTHER". That said, I've got a fun idea of something to try with dragons and firewalking...so even if some of my other expectations have been let down, there's still plenty more little bits of noodling I want to get to with this 'engine', if you can call it that. I haven't moved any of the big stuff to the global robot though, it's copy and pasted on each board, but it appears that the variables carry over...it's definitely tracking what stage the player is on.
Till next time.
EDIT: Video of same game in DOSBOX. It drops frames doing the namco arcade screen garbage, but otherwise runs fine. https://youtu.be/5sVtfenvAhk
This post has been edited by hseiken: 26 October 2024 - 12:27 AM
#3
Posted 27 October 2024 - 05:31 AM
#4
Posted 27 October 2024 - 09:12 PM
hseiken, on 25 October 2024 - 05:18 PM, said:
I'm not sure what the question is here. MegaZeux does not zap any labels automatically, so unless you're explicitly using ZAP on "justentered", you shouldn't need to RESTORE it. If you have "justloaded" in the same robot, in some circumstances that will take precedence over "justentered". If the robot is also receiving a label immediately, unless that label is a subroutine and the robot #returns from it, it will also take precedence over "justentered".
A side note re: #ZAP/#RESTORE vs. ZAP/RESTORE that you can ignore if you don't care:
xx̊y (OST) - HELLQUEST (OST) - Zeux I: Labyrinth of Zeux (OST) (DOS OST)
w/ Lancer-X and/or asgromo: Pandora's Gate - Thanatos Insignia - no True(n) - For Elise OST
MegaZeux: Online Help File - Keycode Guide - Joystick Guide - Official GIT Repository
#5
Posted 30 October 2024 - 09:02 PM
#6
Posted 03 November 2024 - 12:13 AM
I know now and again, there will be Day of Zeux and even Hour of Zeux competitions and it's about entertaining each other, but in the form of a competition ultimately...but what about an ACTUAL competition? Like...programmatic competition?
So, there's a genre of games that are based around programming some AI to do your dirty work on your behalf. One of the most commercial ones, and first game that I was exposed to of this kind, is the Carnage Heart series, though if you look up the genre, there's games that predate it by a decade and others take a wild spin on the concept, like GroBots, where your robots are actually an organism and you program it's 'dna' on how to consume energy and defeat competition, including splitting cells into multiple new ones, etc. All that is to say, it's a fairly mature if under appreciated genre of game that could easily be made into a fun MZX event, but it would have to be done carefully to fit within how MZX is intended to operate (i.e. no one that's touched any inner workings of MegaZeux had the idea it would or even SHOULD be used this way, so there's nothing built in to do it, thus...rules and special board...)
1.) Each robot submitted into battle must adhere to the default robot's built in commands to respond to weapons, walls, get info about other robots on the board, etc. This stuff cannot be messed with and likely would create a specific way the logic must be stuffed into it to properly compete. These robots are the starting point...but should be further restricted to...
2.) Only Use A Small Subset of Robotic...i.e. we can't have Lachesis or Lancer coming in and using one robot to alter time and space to win because robotic can literally create and destroy the world. So no The final list of commands would likely be most useful in this regard if double checked by the gurus of the art to make sure no combination of things can allow any player to create a super cannon black hole maker or something.
3.) The most important of these restrictions and part of the -default robot code- listed in item 1 is uniform response code to being pushed, pushed into a wall, bombed, etc. and limiting all robot attacks to the standard shoot, spitfire, etc.
4.) The final limit here is that no robot code should exceed something pitiful, like 4kb.
5.) The arena should be maybe no more than 4 screens large, have it's own programming to report gather robot location data to share with all of the combatants, as well as display health on screen, time, ammo left (oh yeah, we should most definitely limit ammo, and use mele/push as a legit attack method when out of ammo...or at least always include stage hazards where pushing robot into one is last defense) and only include a handful of terrain/hazards...I would elect fire or lava (not both), goo, custom block, custom floor, custom break, water currents, spinners. Participants might even get to create their own boards so long as they include the 'default arena bot' that makes the game happen as intended included in it and only uses the selected items...otherwise a randomly generated board, preferrably from blocks of interesting bits ratehr than full every-character-is-random (though that could be a funny game) would be created at battle time.
6.) If it's not already obvious, the only attacks a robot can have are shoot, spitfire, missile, bomb, etc. so no custom weapons unless the arena has something in it that might allow for that because really the sky's the limit here...arenas that create pickups of limited ammo weapons the programmers can account for? Sure, why not...but defaultly, basically, the point is no one should be firing a duplicate of themselves that runs different code they also programmed at anyone ever.
I'm sure there's other stuff I'm forgetting, but like I said, it was a thought I had...might be fun, definitely will be something I noodle with myself in terms of creating the 'baseline bot/baseline arena' so that just passing a bot to someone should be enough if i tell them what variables give them arena and opponent information. However, dropping the idea here, maybe it excites someone into giving it a shot. I mean, the final version of this idea is a full on megazeux made editor, battle runner, arena editor, weapon editor, and then you can start just going full on 'this is just battle bots now' with various bots with their own specs of speed, armor and firepower. All that said, that's nothing for me to be worrying about at this very moment.
#7
Posted 04 November 2024 - 12:08 AM
IT's kind of fun coming up with stupid challenges like this. I made a sharp shooter challenge, too. Both are pretty difficult. Gives me urge to try a bunch of mini challenges tied together ala Wario Ware, but everything is sorta classic ZZT/MZX based.
Hmm.
#8
Posted 04 November 2024 - 02:20 AM
#9
Posted 04 November 2024 - 05:08 AM
Some ansi graphical flourishments. I was thinking while making this, it would sure be nice if there was an ALT+B block command to switch between custom block types...sorta like how you can paste from Overlay or Vlayer as Custom Floor or Custom Block (No custom Breakable?!), I think just a simple Block operation similar to paint could change all of the blocks into custom break, block or floor.
How about it?
#12
Posted 05 November 2024 - 09:59 PM
#13
Posted 07 November 2024 - 06:23 PM
Also, I highly recommend playing with timed LAZERWALL [DIR] [DURATION] to make some super cool animations. I made a timer robot which just sends message to all customlazerwalls 'STEPx' (x is a number) one after another, looped. Each laserwall responds to the looping 8 count timer and when you organize these walls...whoo, what a disco! A...DANGEROUS DISCO!
#14
Posted 10 November 2024 - 02:55 AM
Picture is work in progress I've been doing on my noodlings World(lulz...their's nothing connecting any board really) of trying to make a 80s ansi style version of Bank Panic, one of my favorite arcade games.
I'm also using the MSDOS version, so doing crazy coding is out of the question, sprites and all that, so it's a like an electromechanical version, with robots moving around the board, changing their appearance and trigginering moving small bits of graphics here and there. It's been fun hacking it together. Hopefully I can get all the details in because as simple as the game is (just get money on all 12 doors), there's a TON of nuance and timing to all of the details. However, I saw someone basically made THRUST in character mode with the most basic of MZX robotic and did SORTA what I"m doing, which is making 'tabs' out of robots if I'm doing larger 'meta game' stuff.
It's certainly a kind of programming i understand better. I can do the lua cha cha, I've done the java hustle, but overall, this feels more like home, Hypertalk...at least in some principles...i.e. the idea of 'me'. and a physical thing that is 'me' in the space you're trying to manipulate. I tend to like that kind of thing. "WHERES THE CODE FOR THIS BACKGROUND?" Click it and inspect. Best way, if you ask me.
#15
Posted 10 November 2024 - 03:46 AM
So I got the editor view and what the game looks like (so far). In the editor, I've grown accustomed to just use a goofy smiley face for a robot and every robot has it's first two lines to Transformers (more than meets the eye) into the scenery so I always know where they are because their position is very strategic to making this electro mechanical pinball machine contraption work.
I started looking at robots more than somethign that can manipulate everything omnipotently like a regular program/scripting language and instead treat them like tools of real space. In this case, all of those robots on the edges are nothing but, in real life, would just be infrared sensors. They're linked to the cars...so basically if a sensor sees a car too close, it pushes it's butt around the corner.
The other thing I started doing with my noodlings is use invisible custom floors to determine what should happen in that situation. So in this case, the grey double arrow characters are all 'yes you can change lanes' flags. Physical flags on the ground. This I understand. "if something number and other number and blah blah' Naw, cause if i move this physically, i don't have to recode nothing, all the bots know where and who they are, the floors are still the floors.
So for a more...rather a 'less abstract thinker' as myself, this makes it super easy to leave a project then come back to for me. ANd it's also fun looking at this as an elaborate rube goldberg machine, too... lol
#16
Posted 23 November 2024 - 04:30 AM
So one of the biggest 'ughs' of ANSI mode is the non square characters. Graphically, this really isn't an issue. What IS an issue is when comparing speed to
moving up and moving left, say. The character ratio makes moving up and down twice (maybe 3 times?) as fast as left and right. So what to do?
There's a lot one can do. One is to graphically design a square frame work to visually latch on to. This first image is that.
The second is to actually lock the player avatar into a 3:1 grid. This is basically done by locking the player movement (duh) and then force 3 horizontal moves and one vertical move coupled with forced cycles to get the timing right (basically, each horizontal move, cycle that many times vertically).
There's other aspects this look came from that can be deployed and that is 'looking good'. In the 3:1 movement grid which forces this, using custom walls, the look of the game can be 'fixed' to be pretty nice.
And all cause I was mapping out classic arcade pacman mazes and trying to make them look 'good'.
Fun times linking all of those GCC arcade pacman stages together as a metroid vania ish thing...
#17
Posted 26 November 2024 - 07:18 AM
https://youtu.be/k0_ja3GnAUw
Been noticing a GINORMOUS performance hit in DOS using sprites, not even unbound ones. Not sure how to investigate this or to just rule out sprites altogether. I do know I'm having to do a lot more loopy type commands rather than just using 1 robot to do the 1 thing which is make themselves do thing and there's commands to do 'just do it' like move player east...BECOME SPRITE would be so dope.
Anyway, I rambled about that already. I will keep working on the PC with sprite ideas and just use DOS for classic style MZX stuff.
That said, the Encyclopedia still has that BIG CHARACTER demo that totally still works...which means maybe I can make a shooty game that uses big sprites, with each one as a different color (since the color was use to make all the robots that make up the 'sprite' move in unison...meaning I could have up to 14 (no black) 'characters' on screen as big sprites made of small robots...it would be enough to do something like Atic Atac I think... that usually had at most 3 monsters, you could only throw one bouncy weapon at a time so thats 4 sprites. The items could be any color cause they don't move...they all just have to know when the player's sprite lego man touches any part of it. It's still a shame that robots can't pass through each other. Like 'BECOME GHOST' would be cool too, now that I think of it...same thing with the doors and warps, etc. Could be interesting to see if that's possible as something to noodle with down the line...
#18
Posted 29 November 2024 - 01:45 AM
In all seriousness, gameplay wise, this simple concept might be useful in figuring out these dang sprites.
#20
Posted 29 November 2024 - 08:50 AM
https://youtu.be/KUTDbzKc4EY
#21
Posted 06 December 2024 - 03:57 AM
I've been working with sprites. In this scene, you can see the lookup table i created for a generic sprite.
In the demo, every 5 frames it switches to the next angle. It's not actually using cosine or anything, but it still gives the impression of curving movement because the resolution is so tiny.
So this being the case, I'm working on an 'object sequencer' system which I hope will be useful for a boiler plate ANSI action game system because you know, all the eggheads that had a damn MSDOS/PC computer kept playing with EGA graphics and VGA and SVGA, and meanwhile you got computers like the C64 and the TRS80 with text based action games that are mind blowing. ANd all through the 80s...all MS DOS could do was give people headaches with what video card to use to see their factory demo graphics? No, we deserve better in the MSDOS Text Based domain. Sure, we had the ANSI scene, the ASCI scene, altogether known as the artscene in America but dammit...all of that talent was lost....used as a packaging for pirated games...not games themselves...
Well, that's where I hope to fill this gap. I've always wondered what it would be like to see shadow of the beast in ansi form. No I'm not going to make it, but that kind of thought process is now the main thing going forward. Having figured out sprites well enough to at least test what would look interesting, that's good enough for me. However, some stuff NEEDS to be playable and this idea for an ansi shmup is like....I can't shake it...so...
Anyway, long story short about this video, you see some circles of sprites, then i go in and edit some stuff and you get one going in the opposite direction and bigger circle. The idea is just to show that you don't really need calculus when the pixels are so big. Sometimes you just need the easy way out where math doesn't make you feel dumb. Where you beat the math system by faking it until you make it. Where you simply create and angle lookup chart that matches the extremely low requirements of motion on your low res display.
Peace be with you. Next up, generifying this sprite to be anything in any game....
that's teh end goal.
It's definitely going to be the basis for some sorta sprite based mzx inhouse system...I'm still working out what kinds of things I'm willing to let go of for ease of use.
#22
Posted 08 December 2024 - 12:28 AM
#24
Posted 08 December 2024 - 05:51 AM
And then i realized the sprite will not jitter if i shove in setview's in a place extra.
This looks nicer, now?