[cwags55]

Thanks for help with my previous question.

Ok, I am now working on the AI. I want to make a 2x2 enemy made entirely out of robots. What would be my best route in coding?


---------
| 1 | 2 |
---------
| 3 | 4 |
---------

[Dr Lancer-X]

Why do you want to make it entirely out of robots? Wouldn't one robot and a sprite be easier?

[cwags55]

It definitely would be easier, however, I just wanted to make a quick game and I am using some old engines of mine, thus, it would would be more difficult in the end to retool to fit sprites.

[Quantum P.]

Is there a collision-checking mode for sprites in MegaZeux? I know that sprites can float over any kind of terrain, and it's probably pretty easy to determine if a sprite is over any tiles that are ordinarily impassable. However, is there a built-in command that says, "move in the given direction unless it would put the sprite over a space-occupying tile"?

[Risu2112]

cwags55, on Dec 8 2006, 10:13 AM, said:

It definitely would be easier

you're right it definitely would be easier.


You are greatly underestimating the difficulty of linking robots together into one solid moving block that doesn't just disintegrate. It takes an incredible degree of precision and coding magic to make such an enemy work, just use a sprite.

Go open up some of, oh I dunno talon's tale's bosses and see for your self, and even those weren't perfect.

This post has been edited by KenOhki2112: 08 December 2006 - 06:29 PM

[Dr Lancer-X]

Quantum P., on Dec 9 2006, 04:19 AM, said:

Is there a collision-checking mode for sprites in MegaZeux? I know that sprites can float over any kind of terrain, and it's probably pretty easy to determine if a sprite is over any tiles that are ordinarily impassable. However, is there a built-in command that says, "move in the given direction unless it would put the sprite over a space-occupying tile"?

MZX's collision detection is comprised of a check to see if the sprite would collide with anything (and what it would collide with) if the sprite was at a certain X Y. So, if there's a possibility that the sprite is going fast enough to move through walls when just a single check is being done, multiple checks will be needed.

[Exophase]

However in MZX games most sprites/entities almost always move one character at a time, afterall, that is 8 or 14 pixels. So Quantum P.'s description is pretty much exactly like what it is, since you can move in relative coordinates (which are the same as directions)

I was actually pretty surprised that you described MZX's system, people seem to expect/prefer an event based system (like being sent to labels after a collision happens)

[T-Bone]

Lancer-X, on Dec 8 2006, 11:33 AM, said:

Why do you want to make it entirely out of robots? Wouldn't one robot and a sprite be easier?

That's what I'm thinking. I quickly avoided using coupled robots once I started poking around with sprites. A group of robots are not as reliable as sprites, plus there's the issue of them breaking apart. A sprite is a complete mass, so making it move, flows fantastically better than a group of robots. Plus: by using sprites you'll use less code and only one robot.

[cwags55]

hmm, only problem is, I know nothing about MZX sprite code. ...All my coding knowledge is based on stuff from 2002.

Is there a way to lock an overlay to particular robot the same way you can the player. i.e (rel to player)

So like a 'rel to (robotname)' ?

[LogiCow]

sort of like "put c00 customblock p00 at "('robotname.thisx'+1)" "('robotname.thisy'+1)" ?

[Exophase]

cwags55, on Dec 12 2006, 03:59 PM, said:

hmm, only problem is, I know nothing about MZX sprite code. ...All my coding knowledge is based on stuff from 2002.

Is there a way to lock an overlay to particular robot the same way you can the player. i.e (rel to player)

So like a 'rel to (robotname)' ?

Now's the time to learn. At least read the help file's section on it. Trying anything else would be a serious headache that can be easily avoided.

[Risu2112]

Yeah I held out too for quite a while, trust me. Just learn sprites, it's not very tough at all.

[cwags55]

Has anyone written up a sprite tutorial here on DMZX? I am at work and can't tinker around with MZX and learn it at the moment.

[hob nado]

Sprites are pretty easy, you just have to set a bunch of counters which you will always forget the names of and have to go look up all the time. It goes something like this:

set "spr0_refx" 12
set "spr0_refy" 14  // sprite 0 will reference the image at (12, 14)...

set "spr0_width" 5
set "spr0_height" 5 // ...and be 5 by 5 characters in size

put c?? sprite p00 at 25 25  // draw sprite 0 at (25, 25), p?? refers to the sprite number

set "spr0_x" 30
set "spr0_y" 35  // move him to (30, 35)

set "spr0_off" 1  // and later, turn him off

There is, of course, a lot more you can do with them, like sync the overlay to the sprite as if he were the player, or control the order in which sprites are drawn on top of each other or where they're referenced from, etc. Just go read the help file when you can; it's all about counter manipulation.

[cwags55]

That simple huh. Thats really not as difficult as I thought.

Thanks.

How would you sync a sprite to a robot?

[hob nado]

You wouldn't, you'd just have a hidden robot controlling the sprite as if it were the robot's graphic.

Edit: If you really wanted to, every time the robot moved, you'd have it set the sprite x and y coordinates to the robot's thisx and thisy.

[cwags55]

Sprites are so simple. How would I sync a sprite to the player? I think I have most everything else figured out.

[Wervyn]

Simplest way to do this is simply to put it at the player's coordinates (or an offset) every cycle. However, once you really start working with sprites as game actors, it's typical to write code to move them around on their own, and call collision detection, rather than binding them to physical objects. Essentially, you'd lock the actual player somewhere offscreen, and have a robot controlling the player sprite by handling keypresses, and checking for collision with walls and other sprites. The system is designed to make this sort of thing fairly easy to do. The catch is that if you do use this method, you're really committing to a code-display separation, and pretty much everything in the game world has to be represented by a sprite if you want to interact with it. :touching is managed by calling collision, for instance. For some of my own examples of this, albeit hacked together under the constraints of a DoZ, you can check out Run! (game 9532) from the Christmas 2004 DsDoZ.

"Nothing wrong with a little shameless plugging."

[cwags55]

Oh ok. Nice. And I can use a standard 'rel player' code to sync it if I were actually sync rather than using a home made actor. Got it.

Thanks guys. This will help Hamlet 3s developement cycle for sure.

[Pyro1588]

one other tip. if you've got one sprite per robot (i.e. a sprite player and sprite enemies,) it can be easier to have the sprite use the robot's id instead of whatever unique number you choose to assign it.
basically this means instead of

set "spr0_refx" 12
set "spr0_refy" 14
set "spr0_width" 5
set "spr0_height" 5
put c?? sprite p00 at 25 25

you have

set "spr&robot_id&_refx" 12
set "spr&robot_id&_refy" 14
set "spr&robot_id&_width" 5
set "spr&robot_id&_height" 5
put c?? sprite "robot_id" at 25 25

as long as it's just one sprite per bot, this can make managing sprite numbers easier. just a tip.

[cwags55]

Awesome, thanks.

So I won't be able to test some of these things untill tonight, but do sprites have similar properties to an overlay?

i.e.

When you place a sprite, does it leave what was underneath it or does it clear it?


Can you use the 'Sprite' code the same way you can use smething like 'Solid', so
if c?? sprite p?? at 1 1 "go"?

[Wervyn]

Sprites are separate graphical entities from both the board and the overlay, and affect neither. Sprites always appear over the board layer, and can be configured to appear over the overlay (set spr#_overlay 1).
Sprites are also usable in a similar way to other built-in entities like solids or customblocks, and you can use something like that if statement to check for the presence of a sprite. However, if you're interested in collision detection, what you actually want to do is use "if c?? sprite_colliding pNN at x y then label". This will call a collision check based on what would happen if you moved the sprite x by y spaces on the board. You can then use the spr_collisions counter to get the number of collisions that occurred, and the spr_clistN psuedo-array to get the ID of each collision in the list. -1 represents a collision with the background (customblocks only), and any other number represents a sprite id.
It's relatively simple to loop through that list, send any relavent touch messages. With a good robot naming convention, this is pretty simple, just name your robot "spriteN" where N is the sprite ID. If you're using the robot_id trick to reference your sprites, try sticking . "@Sprite&robot_id&" in your robot code to rename it for this purpose. And oh, be sure to abort changing the values to move the sprite, if you don't want to send it through the wall.

"Be sure to drink your Ovaltine!"

[cwags55]

Awesome thanks.