I have the following code:
Creature::cancelWalk()
{
Player* player = getPlayer();
if (!player) {
if (getMonster() && getMonster()->getMaster() && getMonster()->getMaster()->getPlayer()) {
player = getMonster()->getMaster()->getPlayer();
}
}
if (player) {
player->sendCancelMessage(ret);
player->sendCancelWalk();
}
}
After a brief analysis, it's easy to understand I want to achieve something simple:
If the creature is the player itself, then sendCancelMessage and sendCancelWalk. Else, if the creature is a monster that also has a master that is a player, send the same stuff to the client.
Is there a better way to write this code without adding other methods on Monster, Creature and Player classes?
Monster and Player both are "siblings" deriving from Creature.
Assuming the various functions don't have different effects on multiple calls, try introducing some temporaries.
Player* player = getPlayer();
if (!player)
{
Monster monster = getMonster();
if (monster)
{
Master *master = monster->getMaster();
if (master) player = master->getPlayer()) {
}
}
if (player) {
player->sendCancelMessage(ret);
player->sendCancelWalk();
}
Beyond that, you might want to look more carefully at your design. If you have lots of nested pointers that you need to sequentially check for NULL before dereferencing, it might be worth specifying and enforcing invariants that the pointers are not NULL (which means only construct parent objects if all the component parts can be created, and never construct objects if they can only be partially constructed).
For example, if we assume that getMonster() returns non-NULL which guarantees that getMaster() and getPlayer() also don't return NULL ....
Player* player = getPlayer();
if (!player)
{
player = getMonster()->getMaster()->getPlayer());
}
if (player)
{
player->sendCancelMessage(ret);
player->sendCancelWalk();
}
Related
I have 3(Three) BoxCollider2D components where 2(two) have OnTrigger checked in my Object and both have different functions. Due to having OnTrigger on both, the projectiles I am casting collide with the wrong collider and instead activate that function. Is there a way to ignore 1(one) OnTrigger collider?
I have already tried Layer-based collision detection and set up a layer. Unfortunately, the object now collides with the collider which eliminates the player on collision
However, there are several ways to solve this problem. All kinds of physics.checks as well as raycasts but this code helps you to ignore the obstacle collider.
public Collider2D playerCollider;
public Collider2D obstacleCollider;
public void Start() => Physics2D.IgnoreCollision(playerCollider, obstacleCollider);
I have a very simple script I use to handle collisions in my games.
It's very easy to setup because it makes everything drop and draggable, which is a much easier way to program.
Below is the script and below that is instructions on how to use. Note it is a layer based system, but you can select multiple layers.
[System.Serializable]
public class TriggerEvent : UnityEvent<Collider> { }
[System.Serializable]
public class CollisionEvent : UnityEvent<Collision>{ }
public class EnterEvent: MonoBehaviour
{
public TriggerEvent TriggerEnteredEvent;
public CollisionEvent CollisionEnteredEvent;
[SerializedField]private LayerMask validLayers;
// Initalize Event System
void Awake()
{
if (OnTriggerEnter == null)
{
TriggerEnteredEvent = new TriggerEvent();
}
if (OnCollisionEnter == null)
{
CollisionEnteredEvent = new CollisionEvent();
}
}
// Called if transform is a trigger
void OnTriggerEnter(Collider collider)
{
if (validLayers == (validLayers | 1 << collider.gameObject.layer))
{
TriggerEnteredEvent?.Invoke(collider);
}
}
// Called if transform is not a trigger
void OnCollisionEnter(Collision collision)
{
if (validLayers == (validLayers | 1 << collision.gameObject.layer))
{
CollisionEnteredEvent?.Invoke(collision);
}
}
}
This is how it would work, and in this example I will be "coding" it from the perspective of a Bullet.
Basically I want to check if I (The Bullet) hits either the terrain or an enemy then call the relevent funcitons in the Bullet class respectively.
Obviously if I hit an enemy I want to deal damage.
So this will be my example bullet class
public class Bullet : MonoBehaviour
{
public int BulletDamage = 10;
public int BulletSpeed = 5;
void FixedUpdate() => transform.position = Vector3.Lerp(transform.position, transform.position + transform.forward * speed * Time.deltaTime, 1f);
public void OnEnemyHit(Collision collision)
{
// Try to get the enemy script
Enemy enemy = collision.gameObject.transform.GetComponent<Enemy>();
if (enemy != null)
{
enemy.DealDamage(this.BulletDamage);
}
}
public void OnTerrainHit(Collision collision)
{
Destroy(this.gameObject);
}
}
Add the EnterEvent script to the bullet.
Add the Bullet Script to the bullet.
There will be a space on the Inspecter where you can add your events. It should have a Plus and Minus in the top right corner. Press the plus.
From the inspector drag the bullet in game GameObject to the open space provider.
In the dropdown to the right, click on it, look for the Bullet Script, and select the OnEnemyHit function from it.
Create another event, do the exact same, but this time select the OnTerrainHit funciton instead - now but would be called in the order you added them.
Just underneath the event system should be the be able to see a dropdown for the Layers. Select all the layers you want your bullet to interact with. In this case it will be the Enemy and Terrain.
Finally remember to setup your layers properly. Ensure the Enemy has an Enemy Layer, the Terrain has a Terrain Layer, Bullet bullet layer and Player has a Player Layer
i have an example : player object, obstacle_1 object and obstacle_2 object. How do I check which one player collides with? I mean I want to do script_1 for colliding player with obstacle_1 and do script_2 when player collides with obstacle_2. Example:
private void OnTriggerEnter2D(Collider2D collision)
{
//script 1 when this object(player) collides with obstacle_1;
//script 2 when this object(player) collides with obstacle_2;
}
It seems like you're asking how to differentiate between objects. There are many ways of doing so, and it's hard to say which will work best for you since you didn't give a lot of context. Here are some ideas:
One of the simplest ways would be comparing the object's names:
private void OnTriggerEnter2D(Collider2D collision)
{
if(collision.gameObject.name == "Obstacle_1"){
//React to obstacle 1
}
else if (collision.gameObject.name == "Obstacle_2"){
//React to obstacle 2
}
}
I really wouldn't encourage this though, since the name of the objects can be changed quite easily.
You could add Tags to obstacle_1 and obstacle_2, and compare tags, like:
private void OnTriggerEnter2D(Collider2D collision)
{
if(collision.gameObject.CompareTag("Obstacle 1")){
//React to obstacle 1
}
else if (collision.gameObject.CompareTag("Obstacle 2")){
//React to obstacle 2
}
}
This is a bit better, since changing tags is not as easy as changing names, but there's still room for spelling errors. Comparing strings is not very efficient either, especially if done frequently.
You could create different components for obstacle_1 (BouncyObstacle) and obstacle_2 (SpikeObstacle), and then have your player try to get these components, like:
private void OnTriggerEnter2D(Collider2D collision) {
if(collision.gameObject.TryGetComponent(out BouncyObstacle bouncyObs){
// React to bouncy obstacle
}
else if(collision.gameObject.TryGetComponent(out SpikeObstacle spikeObs)
{
//React to spike obstacle
}
}
This is a little bit better, but every time you want to add a new obstacle, you need to add an if to your player code.
Again, it's hard to say which solution would be best. From your snippet, it seems like the player class is responsible for reacting to the obstacles, and this means that every time you want to add a new obstacle, you need to open the player class and change the OnTriggerEnter method. Perhaps it would be better to move this responsibility to separate components. That way you'll be able to add as many obstacles you want without changing any of the previous classes you made. Something like:
public class BouncyObstacle : MonoBehaviour
{
void OnTriggerEnter2D(Collider2D other)
{
if(other.TryGetComponent(out Player player))
{
player.Bounce();
}
}
}
public class SpikeObstacle : MonoBehaviour
{
void OnTriggerEnter2D(Collider2D other)
{
if(other.TryGetComponent(out Player player))
{
player.Kill();
}
}
}
// etc..
I'm designing a card game and I want to follow the MVC pattern. Is the concept below fine? It's language agnostic (not written in any actual programming language).
class GameModel
{
Player p[maxPlayers];
Deck d;
Rules r;
method nextTurn()
{
p[activePlayer].makeTurn( ...some paramaters...);
...
}
method addObserver(int classID, int index, Observer o)
{
switch(classID)
{
case id_model:
this.addObserver(o);
break;
case id_deck:
d.addObserver(o);
break;
case id_player:
p[index].addObserver(o);
break;
...
}
}
}
Also, the View will need to know things like "how many cards does this player have?", shall I write (in the Model) methods like:
method cardCount(int playerNr)
{
return p[playerNr].cardCount();
}
or shall I solve this via the Observer pattern (the View would observe players and they would notify the View about the cards drawn or thrown).
Thanks in advance for your suggestions!
Caroline
I am fairly new to Test Driven Development and I just started learning the SOLID principles so I was hoping someone could help me out. I'm having some conceptual trouble understanding the Single Responsibility Principle in the context of developing unit tests and methods in the TDD paradigm. For instance, say I want to develop a method that deletes an item from a database- before my code would have looked like the following...
I'd start with defining a test case:
"Delete_Item_ReturnsTrue": function() {
//Setup
var ItemToDelete = "NameOfSomeItem";
//Action
var BooleanResult = Delete( ItemToDelete );
//Assert
if ( BooleanResult === true ) {
return true;
} else {
console.log("Test: Delete_Item_ReturnsTrue() - Failed.");
return false;
}
}
I'd run the test to make sure it failed, then I'd develop the method...
function Delete( ItemToDelete ) {
var Database = ConnectToDatabase();
var Query = BuildQuery( ItemToDelete );
var QueryResult = Database.Query( Query );
if ( QueryResult.error !== true ) {
//if there's no error then...
return true;
} else {
return false;
}
}
If I'm understanding the Single Responsibility Principle correctly, the method that I originally wrote had the responsibilities of deleting the item AND returning true if there wasn't an error. So if I follow the SOLID paradigm the original method should be refactored to look something like...
function Delete( WhatToDelete, WhereToDeleteItFrom ) {
WhereToDeleteItFrom.delete( WhatToDelete );
}
Doing the design as such, changed my method from a boolean function to a void function so now I can't really test the new method in the same manner I was testing my old method.
I guess I could test for thrown exceptions but then doesn't that make it an integration test rather than a unit test because there's no actual exception thrown in the method?
Do I design and implement an extra function which checks the database for use in my unit test?
Do I just not test it because it's void? How exactly does that work in TDD?
Do I pass in a mock repository and then return it after it's state has changed? Doesn't that just essientially bring me back to square one?
Do I pass in a reference to a mock repository and then just test against the repository after the method completes? Wouldn't that be considered a side effect though?
So the single responsibility principle says: They should be exact one reason when I need to change a function.
So let's look at your function:
function Delete( ItemToDelete ) {
var Database = ConnectToDatabase();
var Query = BuildQuery( ItemToDelete );
var QueryResult = Database.Query( Query );
if ( QueryResult.error !== true ) {
//if there's no error then...
return true;
} else {
return false;
}
}
Database changes: ConnectToDatabese() needs a change, but not this function
Changes in the db structure: BuildQuery() needs to be changed (maybe)
...
So on the first look, your function looks good. The naming on some places is a little bit confusing. A function should be start with a small letter. For example "connectToDatabase()". It is a little bit surprising that connectToDatabase returns an Object.
The name BuildQuery seems to be wrong, because BuildQuery( myItem ) returns a query wich is deleting something.
But I would never have such a long complicated function which just one testcase.
You need to write more test cases.
For the first test case you could write the function like that:
function Delete( ItemToDelete) {
return true
}
The next testcase could be "call the buildDeleteQuery function with the item id". At that point you need to think about how you call your db. If you have a dbObject, which does that you could mock that Object.
function Delete( ItemToDelete ) {
buildDeleteQuery( ItemToDelete.id )
return true
}
Now more and more test cases. Remember that there will be also test cases for buildDeleteQuery. But for the outer function you could mock buildDeleteQuery.
Now to answer some of your questions:
When you first write the test and then write the code, you will have testable code.
That code looks different, because the tests should be not to complicated. When you want easy tests you will automaticly have more smaller functions.
Yes, you will write a test for every function you call.
Maybe you will mock objects. And if you are not able to test your db call without a wrapping function you will create a function, which allows you to test that functionality.
Remember your tests are the documentation of your code. So keep them simple as possible.
But the most important thing: Keep practicing! When you start with TDD it takes some time. A good and fun resource is: Uncle Bobs Bowling Kata Just download the slides from the website and look how tdd is done step by step.
This seems to be a problem that comes up a lot. I've been coming up with the same solution nearly every time but was curious if people have a better method of accomplishing this.
I have one class that is a list of instances of another class. The state of the parent class is dependent upon state of ALL the children
As an example. Say I have the following classes
class Box
{
int _objectId= <insert_unique_id>;
int _itemCount = 0;
public void AddItem()
{
_itemCount = Max(_itemCount + 1, 5);
}
public int GetId()
{
return _objectId;
}
public bool IsFull()
{
return _itemCount == 5
}
}
class BiggerBox
{
Map<int, Box> _boxes;
public void AddToBox(int id)
{
_boxes[id].AddItem();
}
public bool IsFull()
{
foreach(var box in _boxes.Values)
if(!box.IsFull())
return false;
return true;
}
}
All additions to a "Box" are done via the BiggerBox.AddToBox call. What I would like to do is be able to determine box.IsFull() without iterating over every single item every time we add an element.
Typically i accomplish this by keeping a SET or a separate collection of what items are full.
Curious, has anyone come up to an ingenious solution to this or is the simple answer that there is no other way?
There are two things you need to do in order to accomplish what you want:
Be able to control every entrypoint to your collection
React to changes to the objects in the collection
For instance, if the objects in the collection are mutable (meaning, they can change after being added to your collection) you need your main object to react to that change.
As you say, you could create a separate set of the objects that are full, but if the objects can change afterwards, when they change you either need to take them out of that set, or add them to it.
This means that in order for you to optimize this, you need some way to observe the changes to the underlying objects, for instance if they implement INotifyPropertyChanged or similar.
If the objects cannot change after being added to your main object, or you don't really care if they do, you just need to control every entrypoint, meaning that you basically need to add the necessary checks to your AddItem method.
For your particular types I would implement an event on the Box class so that when it is full, it fires the event. Your BiggerBox class would then hook into this event in order to observe when an underlying box becomes full.
You can upkeep the number of complete (or non-complete) boxes in BiggerBox class, and update it in all the functions.
E.g., in AddToBox it could be:
bool wasFull = _boxes[id].IsFull;
_boxes[id].AddItem();
if (!wasFull && _boxes[id].IsFull) // After this update box has become full.
completeBoxes += 1;
It is also possible to implement this upkeep procedure in other hypothetical functions (like RemoveFromBox, AddBox, RemoveBox, etc.)