Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

124 Neutral

About DarkZlayer

  • Rank
  1. I don't know a lot about cross browser compatability, but one thing you should do to help ease the pain is to have each browser just pass in their respective x,y into functions that actually handle it: Instead of duplicating code do this: function FirefoxMouseMove(e) { HandleMouseMove(e.pageX, e.pageY); } function ChromeMouseMove(e){ HandleMouseMove(e.clientX, e.clientY); } function HandleMouseMove(x,y) { document.getElementById("x").innerHTML="clientX: "+x; document.getElementById("y").innerHTML="clientY: "+y; } Sorry I cannot help more than that, but hopefully it's better than nothing..
  2. Heres a couple quick things I noticed skimming over it: 1. You can actually have setters and getters, instead of setName(). In the prototype of an object you can do this: Parent.prototype={ get Name() { return this.name; }, set Name( val ) { this.name = val; } } then you can call get an set the name with parent.Name or set it with parent.Name = "asdf"; You can also call the parent prototypes constructor with: Parent.call(this, -arguments-); inside of the childs constructor. Not really required, but can make it easier to follow along.
  3. DarkZlayer

    Scan room while wandering

    IF you can do each separately then combining them is simply a matter of calling the functions... Also, how do you use a point to represent direction? Could you post your code?
  4. This is an interesting problem, and without mapping out -all- the possibilities you like there is no clear cut way to go about doing this. Naturally the first thing I thought of though would be something like this. I'm certainly not proficient in PHP, so I don't know standards, but I have an idea of how to make it work without a very deep switch statement or a db (I think). I'll be building off of purely what you've given in your example to help keep this (hopefully) reasonably short Assuming the action comes as one thing from a single input split it into an array based on a space. $verb = $word1; // simply to get a more readable name $verbFile = "/verb/" . $verb . ".php"; if(file_exists( $verbFile ) { // have an individual object for each verb since they need to know how to act require_once( $verbFile ); }else { die( "Invalid Verb" ); //probably should fail more gracefully } Take out the need for a switch statement, if there isn't a file for the verb, assume it's useless. Lets now define a verb, and an Action interface. interface Action{ public bool Can( $word ); } All verbs must be able to tell what it 'Can' do. We'll pass in '$word2' into here to judge if it's capable. abstract class Verb implements Action{ protected $action; protected $objects; protected $preposition; public bool Can( $word ) { foreach( $i in $action ) { if( $word === $action ) { return true; } } foreach( $i in $object ) { if( $word === $object ) { return true; } } foreach( $i in $preposition ) { if( $word === $preposition ) { return true; } } } } So each verb now has the knowledge of which actions it can perform within itself. There is no reason anything else needs this globally available (like the switch statement would do). How can we now implements each individual verb to handle accordingly though.. In your switch statement all the words like 'exit', 'enter', 'crawl', etc can all perform simply actions, so we should have a class which each of these words inherit from also. For the sake of time I'll call it 'Movement' (even though 'exit' techincally fills this description, and doesn't have the same actions available so think of a better name ) class Movement extends Verb { protected $action; protected $objects; protected $preposition = array('above', 'across', 'after', 'near'); //all the other things in the switch statement public void Can( $word ) { if( parent::__Can( $word ) ) { // Any thing all verbs can do should be checked first (although I don't think there is anything..) return true; } //now loop through each '$action', '$objects', '$preposition' like 'Verb' does to make sure this specific Verb cannot do something an simple verb can do } } Now each verb that can do all the things in the preposition should be inherited from 'Movement', and now they can also have their own special cases. Lets say for example only 'Crawl' can do something like "CRAWL IN HOLE" (makes splitting the string more complicated, but makes for an easier example). class Crawl extends Movement { protected $action = array( 'in hole'; protected $objects; protected $prepositions; public bool Can( $word ) { if( parent::__Can( $word ) ) { return true; } // loop through possibilities for crawl specifically like the past 2 examples } } Anyway, I hope that gives a basic idea of how to go about that. Simply make generic classes, and slowly build up into more specific verbs which have their own specific cases. Now they code to check if something is possible can be represented as: $verbObj = new $verb(); if( $verbObj->Can( $word2 ) ) { // Probably should add a method 'Do()' into the Action interface so you can now do $verbObj->Do( $word2, $allWords ); //$allWords represents any word after the verb, and $word2 in the query }else{ die( "Invalid action for " . $verb . "." ); // fail more gracefully } Now you have a verb passing on responsibility to individual verb objects which can now know exactly what they are capable of without you having to build up a huge switch statement. Granted now you have to do something similar in order for '$verb->Do( $word2, $allWords );' in order for the proceeding words to now be able to take action based on that. I typed type all of this up purely in the forum so the chances of it being 100% correct are about 0%, but hopefully it gives you an idea of how to approach this. Also hope it didn't turn into a bunch of rambling. Edit: In some way you eventually have to check individual cases, but an OOP approach helps break it down into much more manageable pieces. For example if you decided that 'exit', 'walk', 'run', etc all should be able to do something new instead of wandering through the switch statement you can now just add the new action into "Movement", because you know all of those are movements. Or if you decide a certain movement needs it's own special case you can easily add it to it's own class also. Overall this is a more manageable approach, but doesn't eliminate the need to check if a verb can do a specific thing.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!