It has come time to create a moving platform datum in my game and I am interested in hearing some ideas on how to design it.
Here's a couple of ways it could work...
1. make a way for any movable atom to ride any other movable atom, then create functions that "ask" about this behavior (atom/movable/CanRide(atom/movable/a))
2. create a bare bone vehicle datum, inherit that and then create specific moving platform code
3. just write a moving platform datum
4. ???
5. profit (just kidding)
I was also thinking of the different ways the moving platform's path could be set at design time. I was thinking of making some sort of pathing object that can find all of its connected neighbors, add those to a path list, and give that list to any atom touching the current path at run time, before deleting its self. There could also be another path object that doesn't delete its self for other uses. I guess this would be similar to like invisible train tracks and the moving platform is like a train on the tracks.
Has anyone tried doing this before, and if so, what types of problems did you run into, and what advice could you give? What design choices did you make?
Thanks =D
ID:1073764
 Dec 3 2012, 3:53 am
|
|
I should mention this is for top down style.
I'm just trying to wrap my head around how to approach the implementation. There are so many ways to do it. | |
Top down as in not platformer (Mario-like)?
Just trying to be clear, I got even more confused now. | |
Zaoshi wrote:
Top down as in not platformer (Mario-like)? Top down like Final Fantasy III on SNES or Zelda A Link To The Past on SNES. | |
Well, one solution is to have waypoints that change the direction of any platform that enters. So instead of drawing an actual path on the map, you only draw the tiles where the platform will change direction.
| |
So when platform moves simply move all it's contents by same amount. Contents would include mobs, objs and everything else. BYOND API makes this part really easy.
| |
Zaoshi wrote:
So when platform moves simply move all it's contents by same amount. Contents would include mobs, objs and everything else. BYOND API makes this part really easy. Of course, turfs do not move so you would have to move the contents of the platform's location Sorry just nit-picking :) | |
Zaoshi wrote:
So I assume this is platforming game, if not then don't bother reading further. Because, I like to write code that is reusable. If I'm going to make something that can move the player around, might as well do it in a way that can be extended to other datums in the future. 2. Sounds redundant to me. I was actually struggling to come up with different ways to implement it, by example. I can think of a lot more ways, with code. But those would be long winded examples. 3. Wait what? The whole point of making a post like this isn't a code question, but a design question. We should be discussing how to properly implement a powerful "platform" or even "generic vehicle" of sorts. Well, here's a list of things to consider: 1. We should have the option to decide if the atoms on the platform are allowed to move or not. Some platforms will allow this, others wont. We need to have a good way of handling this too, so we can later determine what type of consequences there are for falling off of a platform while its moving... while its stopped... things like that. We should also make this in such a way that it can be extended and overwritten so in case I want to add something like an electric powered platform in the future, it can still have the same functionality but extended in a way that makes sense to the electric powered version of the platform. 2. Maximum contents, easy enough. We need a way to determine how many atoms can ride on it. 3. Providing a function (ie: CanRide()) that will allow us to determine who is allowed to ride the platform. Or perhaps we should provide both a way to consider who can stand on the platform (CanEnter()), and who can ride on the platform (CanRide())... and maybe even another function that asks what to do if someone who is on the platform is standing on it but isn't allowed to ride it (default behavior, don't allow moving)CanMove(). We might want only certain atoms that have certain items, or have achieved certain social status to be the only atoms allowed to ride specific platforms, for example. We might also want to filter by other variables or logic that is unknown to us at the moment. So we should provide a method that can return true or false and let us extend it in the future. 4. Pathing. How will the platform interact with paths, and how will its automated movement work. How far should we extend the capability of movement behavior? 5. Damage. We should make it possible to elegantly damage the platform in case this is some type of mechanic we might want in the future. There should also be a way to repopulate "dead" platforms in case they are necessary to reach certain regions. 6. Multiplayer. We must consider any odd multiplayer cases that could cause unintended bugs or "features" haha. For example, a pass thru mode in case there's some way people figure out how to block the platform from doing its job. | |
You might want to have a few bitflags to keep track of who/what can ride on the platform, and handle checks using the built in Enter() proc.
#DEFINE PLAYER 1 Having the custom flag set would simply call an empty proc which the author would have to code themselves, in case they want to include something like a level or inventory requirement. I think my solution for movement should be sufficient, assuming you don't want anything whacky like diagonally moving platforms. Just give the platform an initial direction (easily set in the map editor) and waypoints that change its direction. There could be "static" waypoints (i.e. when a platform enters, always send it east) and "dynamic" ones (when a platform enters, turn it 90 degrees). As far as things like moving off the platform and multiplayer logic, that stuff should be implicit in the rest of the game's code. If you have empty space that can be fallen into from a regular tile, then the player should also be able to fall off from the platform. If they don't fall but are just blocked from moving, they cannot move off the platform unless there is a suitable adjacent tile. Similarly in multiplayer, if players can occupy the same space then they should be able to ride together. Otherwise, they can't. I imagine that platforms should never be blocked by anthing - it is up to the author to give it a logical path to follow, as well as a way to stop and start if desired. | |
I assume you mean Cross() instead of Enter()
movable atoms only call Enter() on turfs unless they're transferring from map to contents. (and turfs can't move) | |
No, I meant Enter(). It is called every time an object tries to move onto a turf...
| |
Magicsofa wrote:
No, I meant Enter(). It is called every time an object tries to move onto a turf... The platform wouldn't be a turf. It would be an obj, so it can move. You'd use Cross() to find out when something is trying to "enter the object", which isn't the same as actually Enter()ing the object (moving into its contents). Regardless of what you meant or didn't mean, this is the route I'm taking because I only see further complications with making the platform a turf and not an obj. Edit: If you were implying the platform is a turf, then how exactly would that work? Sorry if I didn't catch what you meant the first time. | |
OH yeah, you are right...my bad!
Well, you could still use the Enter() proc of the platform's loc. However with pixel movement Cross() probably is a better idea, this way you can have the player get taken away by the platform even if they are slightly off the edge of it | |
Magicsofa wrote:
OH yeah, you are right...my bad! We still get Cross even without pixel movement :D In fact, if Move() fails, Cross comes next. | |
What's the reason for defining this at the top level: datum? I can't really think of a good enough reason why it would be necessary. At top-level, this means every single object in your game, whether it's mappable or not, will inherit whatever platform procs or vars you define there, unless you are making a datum subtype. Either way, I just don't think that's the ideal way to go. I think simple is better in most cases, and this is one of those cases. You mentioned that the platform is an object, so then you should define your platform procs under obj/platform.
However, if I were designing something like this, I would actually define the platform procs directly under the parent type of whatever types of objects I expect will be using my platform. So if only mobs are going to use my platform, then I will define the platform rules directly under /mob. If both mobs and objects will use it, then I would define the rules directly under /atom/movable, since turfs don't move, and they obviously won't be riding on the platform. This is because if you think about it, the rules are not actually applying to the platform. The rules are mostly involving what happens to the mob when it tries to step on the platform. I think this would be the most simple method to use, depending on what type of platform we are talking about. | |
I don't think I said anything about defining it in /datum... I was talking about making a datum (ie: /platform) and its parent type would be /obj to be mappable
| |
Nevermind that then. I was just misunderstanding your original post.
Anyway, it's hard to come up with a solution to this without more information. Are you actually using pixel movement, or is your game strictly tile based? Just what kinds of platforms do you plan to make with this? For example, is it something more like a vehicle that runs on a set or very strict path, such as a train or roller coaster? Would you instead use this for something like huge conveyor belts seen in lots of platformers? Would you use this for something like sliding on ice, or directional floors like those seen in NEStalgia? The problem is, each of these types of things would require almost a completely different set of rules, so it may be best to break the code up and define procs for each of these situations individually. | |
The game is tiled based.
This is more for things that have an exact path, like a roller coaster. In the case of a floating platform, its just like a "mine cart on invisible mine cart tracks" type of thing. Doing stuff like "sliding on ice" and "directional floors" is already built in to my game. | |
1. Why have CanRide() function? If it's platform it's just a moving dense object, why such difference?
2. Sounds redundant to me.
3. Wait what?
4. I don't know either.
5. Everyone wants it (every line I typed costs you $0.99).
I think most common way is to remember what player is standing on, then every frame just add to player's position whatever velocity his "ground" has.