Games, Web Apps, Business Intelligence

For my Legends of Dhashar PBBG, I decided to go with a hex-based map for maximum flexibility of character movement. These types of maps were the foundation of wargames that I played many years ago and they still appeal to me.

The map is divided into regions, each region being the size of one screen. When the character moves off the edge of the screen, a new region loads and the movement continues. The map starts with a simple map text file. There is a separate text file for each region which makes it a breeze to add new regions. Each file holds all of the data for a particular region. The first line lists the region ID numbers for all adjacent regions. The next eight lines are a grid of numbers representing the terrain for each hexagon in the region. The last line describes the sole town in that region. The current game only supports one town per region, but this can easily be changed to support any number.

Sample map text file:

Elandria
000,003,002,000
0,2,2,2,2,2,1,1,1,1
0,2,2,2,2,1,1,1,1,1
0,2,2,2,1,1,1,1,1,1
0,1,1,1,1,1,1,1,1,1
0,1,1,1,3,3,1,1,1,1
0,3,3,3,3,3,1,1,1,1
0,3,3,3,3,0,0,1,1,1
0,0,0,0,0,0,0,0,0,0
Bartertown,town,6,2,1.1,.8,weapons,armor,potions

The first step is to load a region. This is done with a Region class that I have already written. It stores the entire region map into an array which is a simple thing since the map is only 10 hexes wide by 8 hexes high. Once loaded, I can now draw the region. To do this, I run a nested loop to cover each row and column of the map. At each iteration of the loop, we "echo" [PHP] an <img> tag where we display the proper map tile based on the terrain number saved in the map array.

Remember, hexagons are a little more difficult than squares - each column must be offset from the one before, so they take on a staggered appearence.

After the map is drawn it is a simple thing to add characters and monsters and anything else you want, which we will cover later.

Object-oriented programming capabilities in PHP have come a long way and allow for functional and efficient code. I have seen many scripts that take advantage of OOP and many are done well. However, it seems to me that some people tend to over-do it on the classes.

Code should be functional. It should be efficient. And equally important, it should be easy to read. I can't understand why so many programmers feel the need to write long and complex code to perform simple tasks. You don't need a class to convert a date format - a simple function will do the job. Why write 50 lines of code when you can accomplish the same task in ten lines? Is it to prove how skilled they are by the complexity of the code? The real skill is getting the size of code as small as possible - that's called efficiency.

There is a need for OOP when designing large systems that will be maintained by multiple developers. The strict structure of well-written classes will keep sloppy programmers from creating many errors.

In order to know if you should use classes in your program, ask yourself a couple of simple questions.

1. Is there an actual object that I need to model? If you are developing a website that sells used cars, then you may need a Car class to manage the data of each car.
2. Does the size of this project justify the extra time required to develop foolproof classes? If you're going to write a class, you'll want to make it as robust as possible; otherwise, what's the point?
3. Does the task really require the functionality of a class, or can I accomplish the same thing with a function?

My Legends of Dhashar PBBG relies on classes to manage characters, monsters, and the map. This was a decision I made based on the scope of the game, the fact that I'm modelling concrete objects, and the possibility that I might allow other developers to work on the codebase. The classes make the code easy to read and to modify.

Classes in PHP make for very powerful and efficient code, but be careful not to waste your energy writing unneccesary classes to perform simple tasks. Overly complex code is not a sign of a great programmer, but that of an inefficient amateur with something to prove.