if (MapEngine.MapArray.ReadItem(Posx, (Posy + 1)) = "Empty")The '=' should be '=='. The = sign is used to assign things, while the == operator is used to check if they are equal.
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
C# Workshop - Week 1 (Ch. 1 & 2) - Advanced
This line:
The '=' should be '=='. The = sign is used to assign things, while the == operator is used to check if they are equal.
The '=' should be '=='. The = sign is used to assign things, while the == operator is used to check if they are equal.
Wait, you're sure static fields can only be accessed by static members? That's not how it was in C++... and I don't see why that would be the case. Why can't instance members access static fields?
They can. I think he meant it the other way around. Static methods can only access static variables. Instance methods can access both static methods and static variables. It is very much like C++.
Don't worry Troll, I got your back. :)
Don't worry Troll, I got your back. :)
You can access static public static members, from instance methods if you treat them as static. So if you have a class foo, that has a public static member bar. If you have a method in foo that is an instance member of foo, we will call it getbar. If getbar tries to get bar just using bar, it will fail. If you try to access it by foo.bar, then it will work. Non-public members can only be accessed by static methods.
theTroll
theTroll
I was trying to come up with a more intuitive for handling a character's death in my battle system using event handlers. I came up with this:
I was just trying this out to test how well I knew events and event handles. It works and all. But this is just bad design, right?
using System;public class Character{ public event EventHandler Death; public void OnDeath(object victim, EventArgs e) { Character a = (Character)victim; // unboxing Console.WriteLine("{0} has defeated {1}", this.name, // this.name should be the killer a.Name); // a is the invoker of the function } int hitpoints; // The amount of life a character has string name; // The characters game name public string Name // set and retrieve the characters name { get { return name; } set { name = value; } } public int Life // set and retrieve the character's life { // points. If hitpoints is less or equal to 0 get // invoke the The killer's death routine { return hitpoints; } set { hitpoints = value; if (hitpoints <= 0) { if (Death != null) Death(this, null); } } }}class program{ static void Main() { Character villan = new Character(); Character hero = new Character(); villan.Name = "Shredder"; // set names hero.Name = "Ryu"; hero.Death += villan.OnDeath; // Swap eath other's death routine villan.Death += hero.OnDeath; hero.Life = -3; // Manually kill our hero, but pretend // the villan did it. }}I was just trying this out to test how well I knew events and event handles. It works and all. But this is just bad design, right?
Quote: Original post by Knuckler
I was trying to come up with a more intuitive for handling a character's death in my battle system using event handlers. I came up with this:
*** Source Snippet Removed ***
I was just trying this out to test how well I knew events and event handles. It works and all. But this is just bad design, right?
Yes, it's a bad design: Your hero and your villian end up having to know each other far to intimately. What happens when we add in two villians (as they tend to gang up on the good hero)? The problem is not so much the event, but what the event is doing. You have to tell each person about the other in order for the event to work. Instead, you might consider a method like so:
public void TakeDamage(Character attacker, int amount) { hitPoints = Math.Max(hitPoints - amount, 0); if (hitPoints == 0) { ++attacker.KillCount; Console.WriteLine("{0} killed {1}, he has killed {2} characters.", attacker, this, attacker.KillCount); if(Died != null) Died(this, attacker); } }Note: the event remains, but this time we can use it for more general purpose notifications. For instance, you might register a handler with the event which will send appropriate notification to a quest or an event system (like a raid event where a boss dies). Note that even in this code I would suggest moving the notification of the characters death elsewhere. For instance, you might want to notify all players in a particular room that somebody has died. In this case you would probably call a function like currentRoom.NotifyDeath(this, attacker);. A party might register for the Died notification, to notify party members, even if they aren't in the same room.
[Edited by - Washu on July 12, 2007 10:33:08 PM]
I had a feeling it didn't seem right. I see it now. The character handler would be better suited for the surrounding area or the game battle system. Each character would register their "death" handler with the battle system or area so that when invoked the system could use that info to remove the player for the area or game. Characters shouldn't directly know about one another, but through the game system.
Quote: Original post by Knuckler
I had a feeling it didn't seem right. I see it now. The character handler would be better suited for the surrounding area or the game battle system. Each character would register their "death" handler with the battle system or area so that when invoked the system could use that info to remove the player for the area or game. Characters shouldn't directly know about one another, but through the game system.
Maybe, or maybe not. Events aren't always the proper way to do things. I would instead probably just have the character notify the system on his own death. It depends on exactly what you're trying to do as well.
Quote: Original post by WashuQuote: Original post by Knuckler
I had a feeling it didn't seem right. I see it now. The character handler would be better suited for the surrounding area or the game battle system. Each character would register their "death" handler with the battle system or area so that when invoked the system could use that info to remove the player for the area or game. Characters shouldn't directly know about one another, but through the game system.
Maybe, or maybe not. Events aren't always the proper way to do things. I would instead probably just have the character notify the system on his own death. It depends on exactly what you're trying to do as well.
A good heuristic is to always do the simplest thing to get it done. Only increase complexity if you feel the pain.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
