Jump to content

Recap on Assoc MultiDim. Arrays


Klyx99

Recommended Posts

Im playing with some old gaming code and looking to clean it up.

Every year I learn something new that helps.

Right now only interested in learning beter way to handle assoc arrays and assigning them a little more efficient

 

The following is scattered throughout the code - and seems very klunky if not messy. It works fine, but I don't like how it looks. what can I do to clean this up a smidgen:

         $mob = $_SESSION['mob'];
        
        $_SESSION['player']['level']++;
        $_SESSION['player']['hpmax']         += $mob['hp_buff'];        
        $_SESSION['player']['strmax']        += $mob['str_buff'];
        $_SESSION['player']['defmax']        += $mob['def_buff'];
        $_SESSION['player']['strength']      =  $_SESSION['player']['strmax'];
        $_SESSION['player']['hp']            =  $_SESSION['player']['hpmax'];
        $_SESSION['player']['def']           =  $_SESSION['player']['defmax'];
        $_SESSION['round']  = $round;
        $_SESSION['player']['seen_master'] = 1;
        updatePlayer();

What is the best way to clean this up. I really haven't found many tuts on something like this. I know I may end up finding away to pass the player around but this seems the best way. I am not dealing with OOP, (for the time being - still learning about that) so please keep any tips to procedural.

 

The above player "sheet" has 50+ fields. I have done things like $p = $_SESSION['player'] ... do something.... then back to $_SESSION['player'] = $p

 

For the curious, I have always used games to learn a language, as I feel a game seems to encompass many facets of any given language.

 

So a couple questions

  1.  when assigning values to a field, can you do calculations? 'hp' => += $mob['hp']
  2. is there a more efficient way of assigning the above instead of doing a repetitive - I really love the DRY method whenever I can do it.
  3. is there something better than session var for passing a player around the website?

I do use a custom MVC I created - procedural, not OOP (did not see one out there that was very good - so wrote one myself - no arrays, as is shown by many who try it), If anyone is interested in what a procedural one looks like, i'd be happy to show it. many I have found are really over done, this one is very simple (sorry digressed).

 

Link to comment
Share on other sites

1. Aren't you already doing that? I see one ++ and three +=.

2. You are using custom logic in there. I don't see a way to clean it up - you'll just add more complexity for little gain.

3. Sessions are the way.

 

I wouldn't expect you could remove or modify any of that logic, but you could go OOP and modularize it. By that I mean something like

 

class Player implements Serializable {

	public $id; // presumably you have one

	public $level;
	public $hpmax;
	public $strmax;
	public $defmax;
	public $strength;
	public $hp;
	public $def;
	public $seen_master;

	// ...

	public function notSureWhatThatCodeRepresents(Mob $mob) {
		$this->level++;
		$this->hpmax += $mob->hp_buff;
		$this->strmax += $mob->str_buff;
		$this->defmax += $mob->def_buff;
		$this->strength = $this->strmax;
		$this->hp = $this->hpmax;
		$this->def = $this->defmax;
		$this->seen_master = true;
		$this->updatePlayer();
	}

}
class Mob implements Serializable {

	public $hp_buff;
	public $str_buff;
	public $def_buff;

	// ...

}
$_SESSION["player"]->notSureWhatThatCodeRepresents($_SESSION["mob"]);
$_SESSION["round"] = $round;
The logic is the same but you've contained it in one place, and the code that uses the session only needs to call methods to do what it needs.

 

 

There is a caveat with storing objects in the session: all properties are serialized, so if you change your code then sessions could break.

The good news is that you can get the benefit of having objects in the session without the downside by modifying how the objects are serialized:

// Player::
public function serialize() {
	return $this->id;
}

public function unserialize ($id) {
	// populate $this from data from... wherever you get the data from
}
That only stores the ID in the session, so as long as IDs don't change the unserialization will always work.

 

 

And advice that may not apply: don't use the session as a way to shuffle data between specific pages that you expect the user to follow along. For example, say the user triggers a battle between their player and some particular mob. This takes them from page A (list of mobs) to page B (fight). The player can go in the session because it's a global concept that you'll likely need everywhere. Don't put the mob in there because (a) it's only useful for page B and (b) it requires the user go from A to B without stopping anywhere else. The latter is the bigger issue because if the user does not make that transition, even if your site makes it more-or-less automatic, then you have stale data in the session and that data may cause interesting side effects on some other page C. Worse, if you have page C to pick a pet to train and page D to do the training, if the player goes from C to B then they might accidentally fight their pet, or weirder page A to D might "train" a mob. (An unlikely example but the point still stands.)

Link to comment
Share on other sites

Im an old goat that is too stubborn to move to OOP (I will eventually - but  grew up in the days of single letter vars and spaghetti code written in 1K to 16K of RAM - TIMEX SINCLAIR? COCO I,II,III ?? ANYONE??). Out of necessity of php/mysql I have had to become quite adept at separating logic code from presentation code - even procedural - since exe programing is completely different. If one takes their time and look at the big picture, it is quite simple to do w/o the need to move to OOP.

 

to shed a little light on the code - there is a training mode and a RNG mob encounter mode(players just grinding) - this is determined else where and once they are set - it is turned into mob[] var. The mob var goes to the attack method until the battle is won, then it splits accordingly to who won (training mob won - level up, training mob lost - put your head down and leave LOL) and if it is a mob, either player is dead or gain xp and some gold :-) then it too branches back to their separate entities.

 

there is a updateplayer() module that adjust anything that changes via a loop (foreach player as field=>data)

 

while I thought it would be a very simple text rpg, it is becoming quite the beast :-)

what I was hoping to do as mentioned above, was simplify the assignment of array vars, and moving this data back and forth. I only chose session vars because constant reading of db would be a waste - even if it is a small player base, and reading/writing ini files or xml files I fear, would have the same cumbersome results - unless (why I am here asking the pro's) there is a more efficent ways of handling player info.

 

I did read your example of A to B, however, after certain sequences are done (finished battle for instance) that session is unset. (unset($_SESSION['mob']) until it is needed to be called again. That prevents (hopefully) your scenario mentioned. the only live session var at all times is player. (which can be destroyed on AFK too long).

 

Thanks for the input, seems I am on the right track.. I'll keep an eye out for anyone else that has some more ideas.

Edited by Klyx99
Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.