[hseiken]

So I tend to get ideas and what to try those ideas then get stuck somewhere on the idea for whatever reason. Either I'm unsure if it's really fun because, well, just because I find something jolly novel doesn't mean everyone else will. And so I start thinking, "Eh, is this REALLY the cool thing to devote my attention to?"

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.

[hseiken]

https://youtu.be/f_mknRII3iE

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

[hseiken]

Tried loading up Megazeux on the uConsole, but the vanilla UConsole apparently has 'broken dependencies' that Megazeux needs. Specifically libc6 and SDL2. It's been a while since I linuxed...so for now, it's DOSBox Megazeux..I think this will humble the scope of my experience quite healthily, but it'll be fun to see where I've been needlessly being wasteful with cycles and what not...

[Lachesis]

hseiken, on 25 October 2024 - 05:18 PM, said:

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?

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:

Spoiler

if I am remembering correctly, in ZZT, objects that have used #BIND share the same #ZAP/#RESTORE labels state. #RESTORE will always restore all instances of a label, and it has some bizarre remote-targeting feature that doesn't quite work properly (Lancer tried to explain it to me once).

In MegaZeux, a copied robot will inherit a copy of the initial ZAP/RESTORE labels state of the robot is it copying, but they diverge after the copy occurs. A robot can only RESTORE its own labels and it will only restore [#] instances of the provided label, rather than all of them (you can provide a large number to simulate restoring them all).

[NoahSoft]

Noodle it up bud looking forward to fun MZX!

[hseiken]

Today while I was walking to the store, I had a dumb thought, but might as well post it here.

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.

[hseiken]

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.

[NoahSoft]

Actually, a battle-bots style comp with user submitted Robots would be pretty sweet.

[hseiken]

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?

[hseiken]

Blah.

[hseiken]

Wolfenstein anyone?

[MicMotorhead]

Right down to the one-block cyan doors. I'd think of Wolfenstein, even if you hadn't mentioned it.

[hseiken]

So, to become more familiar with Robotic, I've been thinking of classic arcade games I like, (not the usual ones, but some of them are!) and seeing if I can make a board that looks like an MSDOS character version of the game from 1982. I've been having a lot of fun figuring out how to utilize the fact that robots can either do literally everything on the board or I can have them act as 'IDE Tabs', where one robot handles one subroutine, another one handles another...and one of the most fun things I've been exploring is cutting out code and making the robot just BE the mechanic. For instance, I probably made the dumbest 2 digit timer of anyone ever...with two robots...one that changes it's graphics 0-9 and when it wraps back to 9 from 0, it sends a message right next door to the same robot with it's same code being mildly modified to be only triggered by a message sent by the other digit. Boom 99 seconds on the clock. Same thing with a life bar, just made a row of robots and each one checks if it should look different when PLAYERHURT.

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!

[hseiken]

Been enjoying sitting with Megazeux on the Couch ™.



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.

 

[hseiken]

Guess I should have shown off some of the HEAD ON action...

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

[hseiken]

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...

[hseiken]

And then fast forward a day after playing with sprites and there's some shooty business going on...

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...

[hseiken]

.. lulz

In all seriousness, gameplay wise, this simple concept might be useful in figuring out these dang sprites.

[hseiken]

And with color.

[hseiken]

So I have been busting my head against sprites and i think i FINALLY get it now. Coupled with the fact I can decouple 'jobs' of robots to do different things instead of having to be clever about nested loops and other silly stuff I hate, I went back and made my FATSCII sprite test graphics that I couldn't get working way back in the day....working! Yay!

https://youtu.be/KUTDbzKc4EY

[hseiken]

https://www.youtube....?v=lo9sG5qRQIg

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.

[hseiken]

So now that I got a 16/8/4/2 way movement system at my disposal, I must further test this, so now I've got 16 angled bits of line to go with the 16 angles of movement. This could get interesting...

[hseiken]

https://youtu.be/SYQV_lzym0M
16 way movement demo in action...

Next up, away point sprite bot...

[hseiken]

https://youtu.be/OGnlHkJ7d-w

And then i realized the sprite will not jitter if i shove in setview's in a place extra.

This looks nicer, now?