I am reading https://github.com/walterhiggins/ScriptCraft/blob/master/docs/YoungPersonsGuideToProgrammingMinecraft.md and want to try it out with my son.
I see there is a list of events available, though, being new to this mod, I am not sure I can implement what I am thinking of.
Say, I have a territory around my castle, say, square of 300x300 blocks on a plain field. I know the coordinates of the square.
Now, can I track if any mob intersects the bounds from outside to inside?
If it's possible, what's the event I should look for?
Then, can I add some mechanism that would through something in the direction of the mob's position? How could it look like? Or, even just signalling that a mob is in the zone.
Generally, I want to track mobs and do perform some actions for events.
First and foremost, kudos for exploring this with your son.
I wish I could provide exacting details, but my familiarity with ScriptCraft is limited. However, given that is based on Spigot (not Forge, as suggested in the comments), I can provide an answer from that perspective. I’ll leave the nitty-gritty details of accessing POJOs to your expertise with JavaScript.
While player movements fire PlayerMoveEvent events, there is no corresponding event for other entities/mobs. If there were, it would be a matter of checking whether an entity’s location has breached your perimeter and handling it accordingly.
The simplest approach would be to define a function that calls getLivingEntities() on a World, iterator over the list to determine the type of entity and perform whatever actions are desired; say, announce that it has breached your barrier. This function would be registered as a scheduled task with the BukkitScheduler as a repeating synchronous task. I found this example for scheduling a task, though it is for a single delayed asynchronous task.
load(__folder + "../drone/drone.js");
load(__folder + "../core/scriptcraft.js");
Drone.extend("big",function(){
server.scheduler.scheduleAsyncDelayedTask(global.plugin,function(){
(new Drone()).box(1,500,100,500);
print("done");
});
});
On a large server with many entities, the approach would be optimized by accessing each Chunk containing the protected area and retrieving entities contained therein with getEntities().
Related
I have a question about the naming of different concepts in object-oriented-programming.
Without trying to explain it through general means, let me illustrate it with two examples of the different concepts I'm speaking of.
I think a good way to illustrate this is the way how to handle damage immunity in games. Let's talk about fire that damages the entities that walk inside of it. Suppose, for example, there are spirits that are immune to fire, so they should not receive damage when walking there.
There are two ways to handle this kind of example situation (actually, three, but one isn't very 'useful'. I will state what it is at the end).
Firstly, the Entity class contains a boolean method/attribute called isImmuneToFire, and the method in the Fire class responsible for handling the process of damaging is checking on that. If this boolean is true, just return the method, if not, call the method damageBy(amount, source) in the entity class.
Secondly, the damage-handling method inside of Fire just calls damageBy(amount, source). Everything regarding immunity is just handled within the individual implementation of the method by the Entity classes. It's more like delegating the actual, repetitive work of immunity-handling to the responsible classes, while giving them more accurate control (for example, some entities could be immune to fire damage for 5 seconds after being hit once, or a player could wear fire immune armor, etc.)
I hope I could illustrate it good enough. Do these two different concepts have a name, or are they too 'marginal' to get one?
The mentioned third concept is to just brute-forcefully check the objects inside the damage-handling method (with instanceof in Java, for example) for their classes and thus deciding on whether damage should be dealt. This of course is a simple approach that just destroys any dynamical aspect and modularity. But if someone has a name for that, I'll accept it of course. Until then, I'll just continue on with calling it the Concept of BFSJ Code, short for Brute-Force Static Jumble Code.
If I'm allowed to tweak your question a little bit I would rather consider this under the light of Double Dispatching. Instead of having the source of damage checking whether it can damage an object, or the object receiving the damageBy(amount, source) message having two switch among all possible values of source, you could get rid of the conditional logic in both places by having Fire send the message fireDamage(amount) instead. That way the source of damage will not have to check whether the object is immune to it or not, and the object will know what to do in its source-specific method.
I'll give you an example about path finding. When you wnat to find a path, you can pick a final destination, a initial position and find the fastest way between the two, or you can just define the first position, and let the algorithm show every path you can finish, or you may want to mock this for a test and just say the final destination and assume you "teleport" to there, and so on. It's clear that the function is the same: finding a path. But the arguments may vary between implementations. I've searched a lot and found a lot of solutions: getting rid of the interface, putting all the arguments as fields in the implementation, using the visitor pattern...
But I'd like to know from you guys what is the drawback of putting every possible argument (not state) in one object (let's call it MovePreferences) and letting every implementation take what it needs. Sure, may you need another implementation that takes as argument that you didn't expect, you will need to change the MovePreferences, but it don't sound too bad, since you will only add methods to it, not refactor any existing method. Even though this MovePreferences is not an object of my domain, I'm still tempted to do it. What do you think?
(If you have a better solution to this problem, feel free to add it to your answer.)
The question you are asking is really why have interfaces at all, no, why have any concept of context short of 'whatever I need?' I think the answers to that are pretty straightforward: programming with shared global state is easy for you, the programmer, and quickly turns into a vortex for everyone else once they have to coalesce different features, for different customers, render enhancements, etc.
Now the far other end of the spectrum is the DbC argument: every single interface must be a highly constrained contract that not only keeps the knowledge exchanged to an absolute minimum, but makes the possibility of mayhem minimal.
Frankly, this is one of the reasons why dependency injection can quickly turn into a mess: as soon as design issues like this come up, people just start injecting more 'objects,' often to get access to just one property, whose scope might not be the same as the scope of the present operation. [Different kind of nightmare.]
Unfortunately, there's almost no information in your question. Do I think it would be possible to correctly model the notion of a Route? Sure. That doesn't sound very challenging. Here are a few ideas:
Make a class called Route that has starting and ending points. Then a collection of Traversals. The idea here would be that a Route could completely ignore the notion of how someone got from point a to point b, where traversal could contain information about roads, traffic, closures, whatever. Then your mocked case could just have no Traversals inside.
Another option would be to make Route a Composite so that each trip is then seen as the stringing together of various segments. That's the way routes are usually presented: go 2 miles on 2 South, exit, go 3 miles east on Santa Monica Boulevard, etc. In this scenario, you could just have Routes that have no children.
Finally, you will probably need a creational pattern. Perhaps a Builder. That simplifies mocking things too because you can just make a mock builder and have it construct Routes that consist of whatever you need.
The other advantage of combining the Composite and Builder is that you could make a builder that can build a new Route from an existing one by trying to improve only the troubling subsegments, e.g. it got traffic information that the 2S was slow, it could just replace that one segment and present its new route.
Consider an example,
Say if 5 arguments are encapsulated in an object and passed on to 3 methods.
If the object undergoes change in structure, then we need to run test cases for all the 3 methods. Instead if the method accepts only the arguments they need, they need not be tested.
Only problem I see out of this is Increase in Testing Efforts
Secondly you will naturally violate Single Responsibility Principle(SRP) if you pass more arguments than what the method actually needs.
I've noticed that my dependency injected, observer-pattern-heavy code (using Guava's EventBus) is often significantly more difficult to debug than code I've written in the past without these features. Particularly when trying to determine when and why observer code is being called.
Martin Oderski and friends wrote a lengthy paper with an especially alluring title, "Deprecating the Observer Pattern" and I have not yet made the time to read it.
I'd like to know what is so wrong with the observer pattern and so much better about the (proposed or other) alternatives to lead such bright people to write this paper.
As a start, I did find one (entertaining) critique of the paper here.
Quoting directly from the paper:
To illustrate the precise problems of the observer pattern,
we start with a simple and ubiquitous example: mouse dragging.
The following example traces the movements of the
mouse during a drag operation in a Path object and displays
it on the screen. To keep things simple, we use Scala closures
as observers.
var path: Path = null
val moveObserver = { (event: MouseEvent) =>
path.lineTo(event.position)
draw(path)
}
control.addMouseDownObserver { event =>
path = new Path(event.position)
control.addMouseMoveObserver(moveObserver)
}
control.addMouseUpObserver { event =>
control.removeMouseMoveObserver(moveObserver)
path.close()
draw(path)
}
The above example, and as we will argue the observer
pattern as defined in [25] in general, violates an impressive
line-up of important software engineering principles:
Side-effects Observers promote side-effects. Since observers
are stateless, we often need several of them to simulate
a state machine as in the drag example. We have to save
the state where it is accessible to all involved observers
such as in the variable path above.
Encapsulation As the state variable path escapes the scope
of the observers, the observer pattern breaks encapsulation.
Composability Multiple observers form a loose collection
of objects that deal with a single concern (or multiple,
see next point). Since multiple observers are installed at
different points at different times, we can’t, for instance,
easily dispose them altogether.
Separation of concerns The above observers not only trace
the mouse path but also call a drawing command, or
more generally, include two different concerns in the
same code location. It is often preferable to separate the
concerns of constructing the path and displaying it, e.g.,
as in the model-view-controller (MVC) [30] pattern.
Scalablity We could achieve a separation of concerns in our
example by creating a class for paths that itself publishes
events when the path changes. Unfortunately, there is no
guarantee for data consistency in the observer pattern.
Let us suppose we would create another event publishing
object that depends on changes in our original path, e.g.,
a rectangle that represents the bounds of our path. Also
consider an observer listening to changes in both the
path and its bounds in order to draw a framed path. This
observer would manually need to determine whether the
bounds are already updated and, if not, defer the drawing
operation. Otherwise the user could observe a frame on
the screen that has the wrong size (a glitch).
Uniformity Different methods to install different observers
decrease code uniformity.
Abstraction There is a low level of abstraction in the example.
It relies on a heavyweight interface of a control
class that provides more than just specific methods to install
mouse event observers. Therefore, we cannot abstract
over the precise event sources. For instance, we
could let the user abort a drag operation by hitting the escape
key or use a different pointer device such as a touch
screen or graphics tablet.
Resource management An observer’s life-time needs to be
managed by clients. Because of performance reasons,
we want to observe mouse move events only during a
drag operation. Therefore, we need to explicitly install
and uninstall the mouse move observer and we need to
remember the point of installation (control above).
Semantic distance Ultimately, the example is hard to understand
because the control flow is inverted which results
in too much boilerplate code that increases the semantic
distance between the programmers intention and
the actual code.
[25] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design
patterns: elements of reusable object-oriented software.
Addison-Wesley Longman Publishing Co., Inc., Boston, MA,
USA, 1995. ISBN 0-201-63361-2.
I believe the Observer pattern has the standard drawbacks that come with decoupling things. The Subject gets decoupled from Observer but you cannot just look at its source code and find out who observes it. Hardcoded dependencies are usually easier to read and think about but they are harder to modify and reuse. It's a tradeoff.
As to the paper, it does not address the Observer pattern itself but a particular usage of it. In particular: multiple stateless Observer objects per single object being observed. This has the obvious drawback of the separate observers needing to synchronize with each other ("Since observers are stateless, we often need several of them to simulate
a state machine as in the drag example. We have to save
the state where it is accessible to all involved observers
such as in the variable path above.")
The above drawback is specific to this kind of usage, not to the Observer pattern itself. You could as well create a single (stateful!) observer object that implements all the OnThis, OnThat,OnWhatever methods and get rid of the problem of simulating a state machine across many stateless objects.
I will be brief because I'm new to the topic (and didn't read that specific article yet).
Observer Pattern is intuitively wrong: The Object to be observed knows who is observing (Subject<>--Observer).
That is against real-life (in event-based scenarios). If I scream, I have no idea who is listening; if a lightening, hits the floor... lightning doesn't know that there is a floor till it hits!. Only Observers know what they can observe.
When this kind of of things happen then software use to be a mess -because constructed against our way of thinking-.
It is as if and object knew what other objects can call his methods.
IMO a layer such as "Environment" is the one in charge of taking the events and notifying the affected. (OR mixes the event and the generator of that event)
Event-Source (Subject) generates events to the Environment. Environment delivers the event to the Observer. Observer could register to the kind of events that affects him or it is actually defined in the Environment. Both possibilities make sense (but I wanted to be brief).
In my understanding the Observer Pattern puts together environment & subject.
PS. hate to put in paragraphs abstract ideas! :P
We have two domain types: Users and Locations.
We have a method on the LocationRepository: GetUserLocations().
The existing implementation:
var user = UserRepository.GetUser(userId);
var locations = LocationRepository.GetUserLocations(userId);
To me it makes more sense to retrieve the locations associated with a user from the User type i.e.:
var user = UserRepository.GetUser(userId);
var locations = user.GetLocations();
I think the latter implementation reads more cleanly and as an API client I have to deal with fewer types (i.e. the LocationRepository is not required). On the other hand, there will be more code to maintain as I have to write the "facade" to the LocationRepository.
Should I act on my instinct and create a facade on the User type to the LocationRepository, or should I be happy with the status quo and live with a sequence diagram that "feels" wrong to me (i.e. retrieval of the location information feels like it is being retrieved from the wrong "point of view")?
I would approach this from a perspective of maintainability. I agree that doing it with the facade on LocationRepository would "feel right", and would probably make the code slightly more readable.
The tradeoff, as you said, would be more code to maintain. But how much code are we talking about? Is it a lot, and would you have to update it often? Or can you write it once and forget it, and have it be easily unit testable? If it's the former, just swallow it, go with the current implementation, and remind yourself it doesn't really affect functionality. If it's the latter, it might be worth putting in the effort for that good feeling and more readable code elsewhere.
It is surely possible to model our stuff something like this:
Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
.Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
.OfType<User>().CreateNew("John Doe");
Maybe the repository instances should not be visible to the "end developer" and be encapsulated in the model.
However, because we might not have easy access to the Universe.Instance, we do need one or more "entry points" to where to actually get any data from.
UPDATE:
I think on the one hand it should be a goal to keep the number of there "repository facade entry points" as low as possible because that comes closer to the real world, as there is supposed to be only one "Bing Bang" where everything comes from and which spawned all existing data ultimately ;-) ... That said, on the other hand of course today's systems are always big compromises which we have to make, because the ability to model the real world is limited, there are performance implications and so on...
One way you can go in your concrete example however is to use your repositories for always retrieving fresh data, as in:
LocationRepository.Instance.GetUserLocations(userId);
...whereas you use your User model class to hold the result in a property, as in:
var locations = myUser.Locations;
This property would use lazy load technique to load the data from the LocationRepository at first demand and then hold the result. This communicates that the locations are only loaded once, which makes things for developers who use your library easier. You can then decide if you want to make the LocationRepository.GetUserLocation(userId) also visible to the end developer or not. Keep in mind that when going that route you will also need to build some kind of implicit as well as explicit refresh mechanism and lifetime management.
This over-all approach has proven to be very useful for me. However, the async world of Silverlight et ál now adds some new caveats, as such properties cannot be refreshed instantly and synchronously with a new value in one line of code anymore. When we request a refresh, we now have to leverage binding techniques and/or use a callback to then be able to further process the refreshed value.
All in all, the ultimate goal I believe still would be to see for example a UserRepository just as another regular domain type, apparently with the responsibility to create new single User instances and add them to the storage of users, as well as to provide filtered views (queries) on all available users. It would be acceptable that myUser.Locations as well as myLocations.ByUser["John Doe"] hold a reference to the same result. This UserRepository could then merely be a property of another class responsible for holding it, like CompanyStaff for example. Carrying that idea further is what brought me to that Universe.Instance thing. ;-)
I'll be as direct as I can concerning this problem, because there must be something I'm totally missing coming from a structured programming background.
Say I have a Player class. This Player class does things like changing its position in a game world. I call this method warp() which takes a Position class instance as a parameter to modify the internal position of the Player. This makes total sense to me in OO terms because I'm asking the player "to do" something.
The issue comes when I need to do other things in addition to just modifying the players position. For example, say I need to send that warp event to other players in an online game. Should that code also be within Player's warp() method? If not, then I would imagine declaring some kind of secondary method within say the Server class like warpPlayer(player, position). Doing this seems to reduce everything a player does to itself as a series of getters and setters, or am I just wrong here? Is this something that's totally normal? I've read countless times that a class that exposes everything as a series of getters/setters indicates a pretty poor abstraction (being used as a data structure instead of a class).
The same problem comes when you need to persist data, saving it to a file. Since "saving" a player to a file is at a different level of abstraction than the Player class, does it make sense to have a save() method within the player class? If not, declaring it externally like savePlayer(player) means that the savePlayer method would need a way to get every piece of data it needs out of the Player class, which ends up exposing the entire private implementation of the class.
Because OOP is the design methodology most used today (I assume?), there's got to be something I'm missing concerning these issues. I've discussed it with my peers who also do light development, and they too have also had these exact same issues with OOP. Maybe it's just that structured programming background that keeps us from understanding the full benefits of OOP as something more than providing methods to set and get private data so that it's changed and retrieved from one place.
Thanks in advance, and hopefully I don't sound too much like an idiot. For those who really need to know the languages involved with this design, it's Java on the server side and ActionScript 3 on the client side.
I advise you not to fear the fact, that player will be a class of getters and setters. What is object anyway? It's compilation of attributes and behaviours. In fact the more simple your classes are, the more benefits of an OOP you'll get in the development process.
I would breakdown your tasks/features into classes like that:
Player:
has hitpoints attribute
has position attribute
can walkTo(position), firing "walk" events
can healUp(hitpoints)
can takeDamage(hitpoints), firing "isHurt" event
can be checked for still living, like isAlive() method
Fighter extends Player (you should be able to cast Player to Fighter, when it's needed) :
has strength and other fighting params to calculate damage
can attack() firing "attack" event
World keeps track of all players:
listens to "walk" events (and prevents illegal movements)
listents to "isHurt" events (and checks if they are still alive)
Battle handles battles between two fighters:
constructor with two fighters as parameters (you only want to construct battle between players that are really fighting with each other)
listens to "attack" events from both players, calculates damage, and executes takeDamage method of the defending player
PlayerPersister extends AbstractPersister:
saves player's state in database
restores player's state from database
Of course, you game's breakdown will be much more complicated, but i hope this helps you to start thinking of problems in "more OOP" way :)
Don't worry too much about the Player class being a bunch of setters and getters. The Player class is a model class, and model classes tend to be like that. It's important that your model classes are small and clean, because they will be reused all over the program.
I think you should use the warpPlayer(player, position) approach you suggested. It keeps the Player class clean. If you don't want to pass the player into a function, maybe you could have a PlayerController class that contains a Player object and a warp(Position p) method. That way you can add event posting to the controller, and keep it out of the model.
As for saving the player, I'd do it by making Player implement some sort of serialisation interface. The player class is responsible for serializing and unserializing itself, and some other class would be responsible for writing the serialised data to/from a file.
I would probably consider having a Game object that keeps track of the player object. So you can do something like game.WarpPlayerTo(WarpLocations.Forest); If there are multiple players, maybe pass a player object or guid with it. I feel you can still keep it OO, and a game object would solve most of your issues I think.
The problems you are describing don't belong just to game design, but to software architecture in general. The common approach is to have a Dependency Injection (DI) and Inversion of Control (IoC) mechanisms. In short what you are trying to achieve is to be able to access a local Service of sorts from your objects, in order for example to propagate some event (e.g warp), log, etc.
Inversion of control means in short that instead of creating your objects directly, you tell some service to create them for you, that service in turn uses dependency injection to inform the objects about the services that they depend on.
If you are sharing data between different PCs for multiplayer, then a core function of the program is holding and synchronising that piece of state between the PCs. If you keep these values scattered about in many different classes, it will be difficult to synchronise.
In that case, I would advise that you design the data that needs to be synchronised between all the clients, and store that in a single class (e.g. GameState). This object will handle all the synchronisation between different PCs as well as allowing your local code to request changes to the data. It will then "drive" the game objects (Player, EnemyTank, etc) from its own state. [edit: the reason for this is that keeping this state as small as possible and transferring it efficiently between the clients will be a key part of your design. By keeping it all in one place it makes it much easier to do this, and encourages you to only put the absolute essentials in that class so that your comms don't become bloated with unnecessary data]
If you're not doing multiplayer, and you find that changing the player's position needs to update multiple objects (e.g. you want the camera to know that the player has moved so that it can follow him), then a good approach is to make the player responsible for its own position, but raise events/messages that other objects can subscribe/listen to in order to know when the player's position changes. So you move the player, and the camera gets a callback telling it that the player's position has been updated.
Another approach for this would be that the camera simply reads the player's position every frame in order to updaet itself - but this isn't as loosely coupled and flexible as using events.
Sometimes the trick to OOP is understanding what is an object, and what is functionality of an object. I think its often pretty easy for us to conceptually latch onto objects like Player, Monster, Item, etc as the "objects" in the system and then we need to create objects like Environment, Transporter, etc to link those objects together and it can get out-of-control depending on how the concepts work together, and what we need to accomplish.
The really good engineers I have worked with in the past have had a way of seeing systems as collections of objects. Sometimes in one system they would be business objects (like item, invoice, etc) and sometimes they would be objects that encapsulated processing logic (DyeInjectionProcessor, PersistanceManager) which cut across several operations and "objects" in the system. In both cases the metaphors worked for that particular system and made the overall process easier to implement, describe, and maintain.
The real power of OOP is in making things easier to express and manage in large complex systems. These are the OOP principles to target, and not worry as much whether it fits a rigid object hierarchy.
I havent worked in game design, so perhaps this advice will not work as well, in the systems I do work on and develop it has been a very beneficial change to think of OOP in terms of simplification and encapsulation rather than 1 real world object to 1 OOP class.
I'd like to expand on GrayWizardx's last paragraph to say that not all objects need to have the same level of complexity. It may very well fit your design to have objects that are simple collections of get/set properties. On the other hand, it is important to remember that objects can represent tasks or collections of tasks rather than real-world entities.
For example, a player object might not be responsible for moving the player, but instead representing its position and current state. A PlayerMovement object might contain logic for changing a player's position on screen or within the game world.
Before I start simply repeating what's already been said, I'll point towards the SOLID principles of OOP design (Aviad P. already mentioned two of them). They might provide some high-level guidelines for creating a good object model for a game.