Hi, i'm trying to figure out how does:
1) Pixel movement works in byond?
2) How to do it with projectiles.
I'm not asking for any code but any procs that may help with this or anything similar is welcomed and i can try to figure out myself.
Basically im trying to design my own pixel movement system and the pixel projectiles librarys aren't what im really looking for.
I'll know you'll ask me to reference up pixel_x and pixel_y but are there any maths involved in making a really good pixel projectile system?
ID:155887
 Feb 17 2011, 8:48 pm (Edited on Feb 17 2011, 9:01 pm)
|
|
That'd be a good starting point. Just don't copy and paste code from libraries. It's bad practice for one, not to mention the hordes of problems it causes in the long run because of excess variables and what not. Remember, libraries are meant to be learned from, not used.
| |
DemonicK wrote:
Remember, libraries are meant to be learned from, not used. It's the reverse, actually. They're built to solve a problem in a plug-and-play fashion. Any learning material in them is often an afterthought--or at least not their main purpose--and has often been clouded by optimization. This isn't always the case, but as a rule of thumb, if you're trying to learn by reading libraries all you're going to get is a headache. I think you're thinking of demos. | |
These are decent places to start:
http://www.byond.com/members/ Forumaccount?command=view_post&post=99026 http://www.byond.com/members/ DreamMakers?command=view_post&post=77879 The Vectors article may be more advanced than you need if you just want box collisions, but it can do a lot of cool things. | |
Gamemakingdude wrote:
Hi, i'm trying to figure out how does: As others have said, you can use the pixel_x and pixel_y vars to move objects a fraction of a tile at a time. Most approaches define a proc that moves an object a specified number of pixels. Generally, the proc checks if the move is valid, and if so, it performs the move (updating pixel_x, pixel_y, and loc accordingly). Edit: I forgot to mention it initially, but another big way that approaches to pixel movement vary is collision detection. Most people use rectangles to approximate the shapes of objects. The benefit is that turfs are rectangles, so by treating mobs as rectangles too every object is the same shape. Some people use circles, but by using a different shape you then have to worry about circle-circle collisions, circle-rectangle collisions, reectangle-circle collisions, and rectangle-rectangle collisions. My libraries treat all objects as rectangles (2D rectangles in the Sidescroller library, 3D rectangular prisms in the Pixel Movement library). There are different ways to check if a move is valid. There are some very simple methods but they have drawbacks. Depending on how you'll be using it, you might not like the drawbacks. The simplest method is to check if the move would place the object inside another one. If so, it's not valid and no move is made. This is very easy but has some drawbacks. For example:
+---+If mob A moves down and right it'll place them inside the wall so the move is invalid. However, what you'd usually want to happen is that the mob slides along the wall to the right. If the gap between mob B and the wall is 5 pixels and the mob tries to move down 10 pixels, this move would place them inside the wall and is invalid. What you'd want to happen is that the mob moves 5 pixels down instead of 10. When making my pixel movement libraries (Forum_account.PixelMovement and Forum_account.Sidescroller) I made sure I addressed this problem by using a more complex method. Instead of just saying "oh, the move would put you inside the wall so it's invalid, you don't move at all", the library figures out how the move can be adjusted so that you still move in the desired way. Before making my pixel movement demos and libraries I looked to see what existing approaches existed. Most of the demos I found used the simple approach I mentioned. Here is the list of what I found: PixelMovement by Ebonshadow (110 lines / 20 lines) * does not support "sliding" along walls when your move is oblique to the wall. * doesn't perform partial moves, they just fail completely Simple Pixel Movement by VcentG (430 lines for code+demo) * very buggy * the code doesn't seem to support variable sized bounding boxes * doesn't check all necessary tiles for collisions K_Pixel_Movement by Kakashi24142 * no longer available alternate movement by Jotdaniel * no code * strange implementation - pushes you out of walls by moving you backwards * this also doesn't allow for sliding along walls. Pixel Movement by Wtrbooger * no code * no obstacles so there's no way to evaluate it C Pixel Movement/Collision by Cody123100 (500 lines / 250 lines) * overly complex code * doesn't allow for sliding along walls CG - Pixel Movement by Chris Gayle * no code * seems to mask bugginess by having a very small step size * limited movement makes it hard to tell how robust it is Simple Pixel Movement by IainPeregrine * not on hub, available here: http://files.byondhome.com/DreamMakers/2008-03/ IainPeregrine-0001/simple_pixel_movement.html * playable demo here: http://www.byond.com/members/DreamMakers/files/2008-03/ IainPeregrine-0001/PX_part1.zip * limited code available and it's not in a .zip * collision detection is easy, collision resolution is not. The demo resolves collisions by making you explode, which would be a rare application of pixel movement. * it's hard to tell how useful this code would be for other applications. Demo by Mr.Tophat * from a forum post: http://www.byond.com/developer/forum/?id=741448 * broken link: http://www.byond.com/members/MrTophat/files/pixelsample.zip Megaman Files Pixel Movement Demo by Fugsnarf * from a forum post: http://www.byond.com/developer/forum/?id=736605 * broken link: http://www.byond.com/members/Fugsnarf/files/MMF2test.zip Zelda: Link's Awakening Pixel Movement by Fugsnarf * from a forum post: http://www.byond.com/developer/forum/?id=730563 * deleted hub entry: http://www.byond.com/games/Fugsnarf/ ZeldaLinksAwakeningPixelMovement | |
Sure, and it's piss easy. Basically, you displace an atom's location every time it should move until it tries to move and it's already displaced "off" of its current tile, then you move it to the adjacent tile and readjust the displacing.
Though I don't know how fluid the results would be over a network and with multiple players nowadays, that is something to find out.
No differently than you'd do it with another movable atom such as a mob.
Just to make it clear, there's absolutely nothing to it other than using the pixel_* vars and BYOND's regular location/movement system (Move(), loc, etc).
If you want to do more in-depth collision detection than tile-based collision, you'll have to resort to some math to implement your bounding-box-based (or whatever you choose) collision, but nothing too groundbreaking. The rest is programming logic.
I believe there are many examples already on the forum and hub if you need a base or some pointers to get started from.