Moving platforms

Page: 1 2
Dec 5 2012, 8:35 am (Edited on Dec 5 2012, 8:45 am)
I see. Here's my idea on how it could be done:

First of all, I think your cart or whatever vehicle you are using needs to actually be a mob, not an object. This is going to allow for the necessary amount of flexibilty for this idea to work.

Define a proc to check for when your cart's Cross() proc gets called, and if it does, check the return value of your CanEnter() proc to see if you need to override Cross() and make it return 0 to prevent the player from entering.

Next, make a proc to check for when your cart's Crossed() proc gets called. When it does, check the return value of your CanRide() proc to see if the player can ride or not, and if they can, ask them if they want to actually ride in the cart. If they accept, check the return value of your CanMove() proc, to see if the cart can move or not. If it can, prepare the player for the ride like so:

Disable the client's built-in mob movement, temporarily save all of the stats attached to the player's mob, change the client.mob var to the cart mob, add an overlay to the cart with the exact same icon as the player's original mob, and delete the original mob! This will transfer the player's client to the cart mob and replace the player's mob with nothing but an empty, soulless overlay, attached to the cart, but the players themselves will never see the difference! One advantage to this method is that it opens up the option to let the player control some or all of a vehicle's movement. With some tweaking, I imagine it would work for mounts just as well.

After the switch has been made, and the player is prepared to be moved, all you have to do is call whatever movement proc you have defined for mobs, since that's what the cart is, and the client should follow it just fine, with the player icon overlay glued right on top.

For the pathways or "tracks", what I would do is define as many "waypoint" objects as I need to complete the distance. These waypoints would be numbered, so that the cart starts with the first one, then the second, third, etc. These should be invisible, zero-density objects that get placed at the corner or "intersection" of each movement path. In other words, wherever you need the cart to turn, place the next number waypoint object.

For the proc itself, you would probably want a list of all the waypoints in a path, then basically cross out each one as they get Crossed(), so it would be a repeating cycle of Move() and Crossed() for each new waypoint on the path, until the end is reached. In reality, as long as Crossed() doesn't lag too much, the cart should be able to move seamlessly along the path. Even if there was a small amount of lag, the fact that waypoints exist only at turns would hide it pretty well.

I hope this is helpful advice in designing your moving platforms. I would have given code examples, but I'm not too experienced, and knowing my luck it probably wouldn't even compile! Anyway, I actually learned some things myself from brainstorming these ideas.
Dec 5 2012, 6:04 pm
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.

You guys need to stop mixing up concept and implementation.
Dec 6 2012, 12:43 am
In response to Toadfish
Mixing concept and implementation is what I'm really good at! I don't see what the problem with it is. They are quite inseparable, and as far as I'm concerned, I would like to just throw them into a blender for all eternity! Concepts are mostly just ideas that your imagination comes up with, and they really mean nothing unless you have a way to actually implement them. I prefer to design my concepts more like theories, with full outlines of the implementation process. Otherwise, you won't know if your idea will even be possible to implement.

I see the separation of concept and implementation as a flaw. It has lead to them becoming highly compartmentalized and nobody figures out how to connect the dots. This is reflected in all of the resources and tutorials in BYOND. Either they give you some concepts or they give examples of implementation, but never both at once. If that keeps up, then everyone will just sit around thinking of concepts, and never actually get anything done.

We need to unite concept and implementation with comprehension. All the ideas need to get blended together. For example, instead of making guides about what certain procs and vars do, we instead need to be making guides that actually explain all the things that they can be used for. Strategies like this would actually accelerate and simplify the development process. DM is a very simple language. It's just that all the guides make it look super complicated, and that needs to change.

Sorry to go off topic like this, but this is about design philosophy and I wanted to give a response.
Dec 6 2012, 3:01 am
As simple as DM is, the programs written in it are still complex. The DM Reference (sometimes) has good examples of how to use a proc rather than just its arguments and what they mean.

Concepts are the easiest part in my opinion. Maybe it's not always easy to conceive of a fully fleshed out game right from the start, but still I think envisioning what you want your program to do comes naturally to people like us who are interested in gave development. The hard part is the implementation, and that is what I use libraries for - to see how other people implement a concept that I already have.
Dec 6 2012, 8:49 am
In response to Multiverse7
The point being, you want input on how to implement moving platforms -- you already have the concept. Then you don't want to know how to implement moving platform datums, whatever that means, because this is a detail specific to an implementation which might not be relevant in another (for example, unless he meant something extremely general, it doesn't apply to OP's 1st and 2nd suggestions).

Consider questions like "I want to know how to slice an apple with a spoon". Well, they have an answer, and we could write up a very detailed algorithm for slicing up apples with spoons, but what the asker really wants to know is how to slice an apple. And maybe there are better tools for the job, like a fork, or a knife.
Dec 6 2012, 1:18 pm
Magicsofa wrote:
The hard part is the implementation, and that is what I use libraries for - to see how other people implement a concept that I already have.

You just reiterated the problem I was describing. The knowledge of concept and implementation are divided and compartmentalized. This puts everyone in a state of "hive mind", where they don't know how to implement their concepts, so they just resort to libraries or ask someone else for help. As an analogy, we need to think more like spiders spinning a web, and less like bees working in a hive, that only understand part of the problem.

Toadfish wrote:
this is a detail specific to an implementation which might not be relevant in another (for example, unless he meant something extremely general, it doesn't apply to OP's 1st and 2nd suggestions).

I don't see why it couldn't be. The outline I made covers suggestion 2 very well, and I'm sure the capability could pretty easily be extended to cover the first as well. Honestly though, I really don't see any use for making this particular case more "general" than it needs to be.

Consider questions like "I want to know how to slice an apple with a spoon". Well, they have an answer, and we could write up a very detailed algorithm for slicing up apples with spoons, but what the asker really wants to know is how to slice an apple. And maybe there are better tools for the job, like a fork, or a knife.

Your apple slicing analogy doesn't work very well here. Let's say someone asks you to design an AI puzzle solving algorithm. The problem in the first place is that it just simply wouldn't work out. You can't just make a single code base and expect it to eventually solve any rubik's cubes, sudoku, jigsaw, and crossword puzzles. The algorithms for each one would be so different from each other, that you really just need to either decide on the best one to use, or implement each one separately. Similarly, it just wouldn't be wise to come up with one system that covers every possible instance of moving platform. It would overcomplicate things, you likely wouldn't even use half of it, and it would just reduce the performance anyway. For situations like this, I prefer to take the problem head-on, and directly implement what I need the program to do.

Let me quote the OP here:
FIREking wrote:
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.

This gives me the idea that he is looking for ways to actually implement moving platforms, not just talk about general concepts.

We should wait for FIREking to clarify, before this gets too far off-topic.
Dec 6 2012, 2:50 pm (Edited on Dec 6 2012, 2:58 pm)
I'm not sure if moving platforms should have its own object. Let's take some situations into consideration.

1) It's already an object--however, this doesn't imply that further creating a datum would over-complicate things further; however, I do feel like you're putting design style(whether it be a convention or not) at risk here.

2) Instead of making one object(note that I am referring to a data structure that encapsulates(i.e., class, for instance) information and not an actual /obj type that you would use) for movable platforms, how about just having a platform object that can create variants of it? I'm not sure how you would approach this, as this would be a personal preference style, but how I would do it is have flags(e.g., IS_MOVABLE) or just simply derive them from the base object(i.e., Platform)

3) Consider some scenarios here: later down the line you might want to add another type of platform, one that falls, for instance, when you step on it--for this, I think what I suggested would work perfectly fine.

It's all about simplicity, baby!

"...it is simplicity that is difficult to make."
-- Bertholdt Brecht

EDIT: My comment doesn't tell you how to implement it, which is why it's very abstract in a sense. However, it does help you consider what you need and don't need--the implementation is left up to you.
Dec 6 2012, 5:17 pm (Edited on Dec 6 2012, 5:23 pm)
You're a little confused about what I'm saying here. We're arguing, but I don't think you disagree with me.

Let's say someone asks you to design an AI puzzle solving algorithm. [...]

This is exactly what I'm saying. You have a goal and you have ways to solve this goal. If your goal is "solving a puzzle", then there is no general "puzzle solving algorithm" that will do the work for you. So you shouldn't ask how to write "a puzzle solving algorithm", but how to solve puzzles, and figure the details from there. Maybe all the puzzles you're interested in are jigsaw puzzles, so it's pretty easy to solve those. But you wouldn't get very far if you want a "puzzle solving algorithm", nor will finding a general puzzle solving algorithm be the most effective way to get you what you do want: an AI that solves jigsaws.

Similarly the words "moving platform datum" conceal a word in them that's not going to do you any good. If what you want is for your game to have moving platforms, and you want to know how to implement them, you don't care if they're a datum or an addon proc to moving atoms or naturally generated by how the pixel movement works or whatever. You're not looking for a specific implementation of a "moving platform datum", you're looking for an implementation of "moving platforms": a more general question that allows for more kinds of answers. The datum is an implementation detail which might or might not be there, and whether it is doesn't matter.
Dec 7 2012, 5:06 am
In response to Multiverse7
Multiverse7 wrote:
You just reiterated the problem I was describing. The knowledge of concept and implementation are divided and compartmentalized. This puts everyone in a state of "hive mind", where they don't know how to implement their concepts, so they just resort to libraries or ask someone else for help. As an analogy, we need to think more like spiders spinning a web, and less like bees working in a hive, that only understand part of the problem.

I feel like you are accusing me of leeching code from other people. I don't just "resort" to a library. It is pretty rare for me to actually include a library in my project. And if I do, I always end up making modifications to it. Usually though, I just look at the method employed by the library creator and try to learn from it.

Think about when you first started learning to program, in DM or whatever language. You had no idea how to implement anything. Nobody started programming with any knowledge of how to implement their ideas. That's why you have to learn it. You have to learn the vocabulary and the syntax, just like any spoken language. Once you have gained some of that knowledge, you can start learning about design, how to write a program that doesn't just work, but works well.

Of course, there are plenty of people, mostly young kids, who try to ask for The Code to do something. It's because they are young and inexperienced, and I suppose they would be the ones having a hard time going from concept to implementation in their own brains. But I'm certainly not one of them, and many of the other people here are not like that either.

Besides, it is important to realize the major difference between concept and implementation. A concept should always look the same - if your concept is a game of tag, that concept should stay pretty solid throughout development. Implementation on the other hand can go many different ways. Failing to understand that there are many methods to implement a single concept would result in a crappy programmer.

Toadfish wrote:
If what you want is for your game to have moving platforms, and you want to know how to implement them, you don't care if they're a datum or an addon proc to moving atoms or naturally generated by how the pixel movement works or whatever.

It is pretty clear that fireking wants to create a datum...
Dec 7 2012, 8:11 am
Toadfish wrote:
If your goal is "solving a puzzle", then there is no general "puzzle solving algorithm" that will do the work for you. So you shouldn't ask how to write "a puzzle solving algorithm", but how to solve puzzles, and figure the details from there.

That makes sense, but it's the details that matter the most, in the context of programming, not the concept, especially since concepts are not very hard to come up with. A concept is something that should just come naturally to you, but the details are what you really have to think about. The details (things like syntax and method of implementation) are what developers really struggle with, when designing software or games. If we didn't have to worry about the details, then practically anyone could design programs, since all they would need to do is come up with concepts.

Maybe that will be the reality in the future, if IDEs are made to interpret and display syntax in a more intuitive and symbolic form. Right now though, we have to worry about the syntax of DM in order to successfully implement our concepts. However, if that syntax were presented to us better in the resources, then that would become less of an obstacle. If I completely understood all the syntax of DM, then I would already be an expert programmer, and many others would as well!

You're not looking for a specific implementation of a "moving platform datum", you're looking for an implementation of "moving platforms": a more general question that allows for more kinds of answers.

Like I was saying, it's the details that matter the most, in programming. In fact, that's really the only thing that computers can understand, so if we want to talk in their language, we need to be thinking more like them. We actually do want a specific implementation in this case. I'm not going to tell you not to think of general concepts, because that still helps when coming up with a final solution. However, it will take a lot longer to reach that solution when having a "general" discussion, because the topic would very slowly get more narrow. This is an example of hive mind. So, in this case it's better to directly target the problem in question, and think of our own versions of "complete solutions", or concepts with supporting details. In this way, the desired solution will be found much faster, than through discussing general concepts.

____________________________________________________________ _____________________

Magicsofa wrote:
I feel like you are accusing me of leeching code from other people.

I was not targeting you or anyone specifically, so please don't take this personally. I don't blame anyone who use libraries. The problem is derived from how the libraries, and other resources, have been designed. Although, some are certainly made better than others. The libraries are just not explained and commented well enough for new programmers to fully understand them. There is nothing wrong with using libraries, as long as you are using them correctly. However, I fear that is often not the case. For about 90% of cases, you must know exactly how the library you are using works, otherwise something is guaranteed to go wrong in the future. That's just the way code works. I suspect there are many new programmers who try to use libraries in their projects without having a clue how they work, and down the road something breaks, and they just give up.

Now libraries can be good resources for new programmers to reverse engineer and learn from, but I would warn against using them in their projects without them having a really good idea about how they work. This wouldn't be as much of a problem if the libraries just had better comments and documentation, that even new programmers could understand. What I'm saying is that you can't just think of a concept, then grab a library to implement it. Programming doesn't work that way, but I think there's a lot of potential new developers here in BYOND who think otherwise. You don't hear about it because their projects just end up failing, and they simply give up. We can prevent this from happening by providing more comprehensive resources.

Besides, it is important to realize the major difference between concept and implementation.

I never said that wasn't important. Yes, we have to always acknowledge that in programming there is always more than one way to do anything. It's just that some ways are better than others. However, before you can think of many possible implementations, you have to at least be able to think of one. There are many people who just don't know how to implement their concepts at all. They just don't know where to start, because they lack the comprehensive understanding needed to connect concept with implementation. This is what I mean when I talk about them being divided, leading to this state of "hive mind". Again, a better structured guide on what all the procs and vars should actually be used for would help this a lot.

All the resources, whether it be the guide, the reference, tutorials, libraries, or demos, all have the concepts and implementations split up, and everything is scattered around randomly. There is just a lack of structure and organization in how the information is presented, that makes everything seem very abstract. There are many who would argue that programming languages are abstract, but I believe that is a highly false claim. It's just that people don't look at the entire language for what it is, and so they never really acknowledge the structure of it. They just happily code away within their paradigm using only the knowledge they need to know to get the job done, as if it were some kind of art form. This is an example of the "hive mind", and it can mostly be eliminated by creating a much better structured guide, especially with a simple language like DM. I think it's sad that the DM language doesn't have an official wiki anymore, because that would also help a lot.
Dec 7 2012, 8:36 am
I see what you mean now. I think I sometimes take my intuitive knowledge of programming for granted. I used to mess around with QBASIC, when I was just 10 years old, and I even managed to make a couple (very crappy) games. My dad had showed me a few commands and the rest I learned from the extremely bare-bones reference and by experimentation. It was many years until I started learning DM but, I came with a basic knowledge of how a program works and that has helped me immensely.

When looking at people's issues in the developer help section, I find that a big problem is understanding exactly how and when the code will be executed. Maybe a few articles about object oriented programming would help :)

What was this thread about? Platforms?
Dec 7 2012, 9:37 am
QBASIC seems unusual to learn. Did people actually even use that language for anything? Still though, you are really lucky to have learned to program anything at just 10.

I come from more of a "hacker" background, such as manipulating existing software to do things it wasn't designed for. I used to break things just for fun, and see what results I would get. I wasn't into anything dark or malicious; just learning from changing around software programs and such. I always had a tendency to think outside the box. I had thought it would be easy for me to go right into actual programming, because of how I was oriented towards manipulating things, but it turned out otherwise. The "hacker" mentality of change something and get results, just doesn't apply in actual programming, and so I struggled with grasping these new technical methods of getting something to do what you want. Programming turned out to be so much more specific and strict than I would have expected. A lot of times I still find myself trying to apply what seems totally logical, rather than the needed syntax, and have to correct myself when the compiler gives me errors. When you are stuck thinking one way, it becomes hard to think in another way.

Yes, I think there should be articles on the basic ideas of object oriented programming and the paradigms within it, although there are external articles outside BYOND that talk about those things, but can be hard to find. I learned from some of them myself. Basically, you can't expect that every new programmer in BYOND will have any sort of background in programming, so BYOND specific tutorials on these basic programming concepts would help get people to a level where they can actually begin testing things and learning themselves.

However, I still think it's the syntax of DM that represents the biggest obstacle when trying to develop a game. The guide needs to be completely rewritten and made more concise, especially with all of the new aspects of the language that have recently come up. The reference also needs to be redone in a more organized way. All the procs and vars should be listed based on what their function is, not just what object level they are defined under. Some kind of database or table structure would help. The resources also need index pages of some sort, listing them by category. Right now we have to use the search engine to find anything.

Magicsofa wrote:
What was this thread about? Platforms?

I know right. We derailed this thread too far. It seems like I can never help someone out or offer advice without getting into a heated debate about something. I guess that's to be expected when discussing philosophy. That's what the ancient Greeks did all the time.
Dec 8 2012, 3:52 pm
That makes sense, but it's the details that matter the most, in the context of programming, not the concept, especially since concepts are not very hard to come up with. A concept is something that should just come naturally to you, but the details are what you really have to think about. The details (things like syntax and method of implementation) are what developers really struggle with, when designing software or games. If we didn't have to worry about the details, then practically anyone could design programs, since all they would need to do is come up with concepts.

I'm sorry but, you keep missing the point: when you're asking about the details, don't narrow down your question with details you aren't sure of.
Dec 8 2012, 4:10 pm
Which I'd like to add, is quite a fair statement, and benefits the OP by ensuring he gets the best solutions in terms of implementation, not merely the solutions his question hinted he wants. It's basically the folly of pre-implementation in design.
Dec 10 2012, 3:32 am
Well here's a quick vehicle implementation:

vehicle
    parent_type = /mob
    icon = '_vehicle.dmi'
    var/mob/rider = null
    
    proc/Ride(mob/m = usr)
        set src in oview(1)
        src.dir = m.dir
        rider = m
        src.loc = m.loc
        m.loc = src
        m.client.mob = src
        src.underlays += rider
        
    verb/GetOut()
        set src in view(1)
        rider.dir = src.dir
        rider.loc = src.loc
        src.client.mob = rider
        new/obj/vehicle(rider)
        del(src)
    
obj/vehicle
    icon = '_vehicle.dmi'
    
    verb/Get()
        set src in oview(1)
        src.loc = usr
        
    verb/Ride()
        set src in usr
        var/vehicle/v = new(usr.loc)
        v.Ride(usr)
        del(src)
Feb 12 2013, 4:57 am
If the platform is moving repeatedly, then every time it moves, have it check for mobs that are in its obounds.

Then the platform moves, and then applied that movement to the mobs as well.
Page: 1 2