Jump to content

Creating an online browser-based game; there has to be a better way to do this


Recommended Posts

I've been working on a multiplayer browser-based game for the past few days, and it's actually going surprisingly well.

 

One aspect of the game is a personal map, where you can build farms, cottages, and soon, many other things. Right now, the map is a 3x3 grid; each piece of the map has its own coordinate. In my database, I have these listed as AA, AB, AC, BA, BB, BC, CA, CB, and CC. These fields in the database contain what building is on each coordinate (like "browncottage" or "farm(corn)").

 

This appears to be working fine, and when I purchase buildings and put them on each unit, they show up fine. However, I really don't think that a separate row for each unit is very efficient. If I want to upgrade to a larger map (4x4, 5x5, etc.), I have to insert all new rows in the table, as well as other miscellaneous code in my pages that pertain to the map. Also, if I want to store other information (like, if the building is damaged, or time left for repairs, etc.) for each unit, all I can think of is to create even more rows in the same table.

 

If my question is confusing, I would be happy to explain more. There just has to be a better way to do this, though.

 

Thanks!

stickynote427

You can have a separate row for each user in table.maps_type

in your user table you can have a column for the map_type (3 cells,4 cells...etc.)

then have a separate table for each map_type

3 cell map table

userID

map_1

map_2

map_3

 

4 cell map table

userID

map_1

map_2

map_3

map_4

 

Store the map type in a session variable so you dont have to keep requesting that info from the DB. (Unless it changes frequently)

you can also store the map info in an session array once you pull it. again (Unless it changes frequently)

Okay, so something like this?

 

USER  | 3CELLS | 4CELLS
-----------------------
USER1 |        |
USER2 |        |
USER3 |        |

 

I'm confused as to what would go in the 3CELLS and 4CELLS columns, though. I'm also confused as to what the 3-cell and 4-cell map table would look like.

 

Sorry if I'm missing something obvious here.

I don't quite understand your problem but normal procedure is to have one gigantic map (5000x5000 for example) When a player registers he is assigned an x and y coordinate which act as the starting point of their land and each player is assigned the same number of tiles (20x20 for example)

 

For example I am a new player and your engine finds that at coordinates 192,687 their are 20x20 free tiles (which means that I can build units on 192-212,687-707

 

Every time I build a unit it will be somewhere between 192-212 and 687-707 and store these in the db:

 

player_id building_id coordinates build_date build_time upgrade_date upgrade_time upgrade_level
--------- ----------- ----------- ---------- ---------- ------------ ------------ -------------
1         1           193,689     22/4/10    0:10:5     NULL         NULL         1

 

build_date + build_time < now() = building finished

upgrade_date + upgrade_time < now() = upgrade finished (this is re-used on each upgrade)

But with that table there, how would multiple coordinates look? The table seems to make sense and looks nice, but what would it look like with multiple buildings? Would there just be duplicates in the player_id column with building_id and coordinate being different?

Good grief.

 

Since your map is a grid what you have is essentially rows and columns.  Let's say your map is 5x5 and you number rows and columns starting at zero.

 

    0,0    0,1    0,2    0,3    0,4
    1,0    1,1    1,2    1,3    1,4
    2,0    2,1    2,2    2,3    2,4
    3,0    3,1    3,2    3,3    3,4
    4,0    4,1    4,2    4,3    4,4

 

Now you can essentially replace those 2-int values with a 1-int value with the formula:

LOCATION = ROW * TABLE_ROWS + COL

 

Since this table is 5x5:

LOCATION = ROW * 5 + COL

 

Thus:

0,0 = 0*5 + 0 = 0

0,1 = 0*5 + 1 = 1

0,4 = 0*5 + 4 = 4

3,2 = 3*5 + 2 = 17

 

     0      1      2      3      4 
     5      6      7      8      9 
    10     11     12     13     14 
    15     16     17     18     19 
    20     21     22     23     24 

 

 

Now if you have the LOCATION value and you want the ROW and COL back:

ROW = floor( LOCATION / TABLE_ROWS )

COL = LOCATION % ROW

 

Since this is a 5x5 grid:

ROW = floor( LOCATION / 5 )

COL = LOCATION % ROW

 

So if LOCATION = 21:

ROW = floor( 21 / 5 ) = 4

COL = 21 % 4 = 1

 

So int 21 is really 4,1

 

Now your table to keep track of who has what where is:

player_id <int> | location <int> | widget_id <int> | widget_status_id <int>

35                          21                      32                        3

 

Let's say player_id 35 is Joe, widget_id 32 is Farm, and widget_status_id 3 is Constructing.  Then that row means:

Joe has a farm under construction at row 4, column 1.

 

If you later decide to change the size of the grid, you just write a simple program to recalculate all of the locations in the table.

Thank you; I think that your method was very helpful.

 

I just want to make sure that I am understanding this correctly so far: there will be duplicate IDs in the table, correct?

 

So, it might look something like this?

 

player_id | location | [...]
----------------------------
1         | 2        | [...]
1         | 18       | [...]
1         | 43       | [...]
2         | 8        | [...]
2         | 19       | [...]

You should have a unique index on player_id and location unless you want a player to have multiple things in the same location.

 

And if all players shared the same grid, you would have the unique id on location alone.

 

(And yes, your sample table is acceptable.)

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.