Dragon Basher: Enter City

  Prev 1 2 3 4 5 6 Next

Posted: 03‑10‑2017 17:49


QuaCzar


Fire Flipper
1803 posts
Since there is no scrolling, I assume up.pl, left.pl, right.pl, and down.pl will handle the boundaries appropriately.

A city screen will have 4 times the area of a normal screen (which is 1/4 of the view area.) I see three ways to handle this, one server-side, and two client-side:

The server-side approach would be to use t0 through t3 as usual, dividing the screen information into 4 parts, without sending scroll commands. z-positions would need to have two parts, since the screen number will be included. This would allow effects such as scrolling twice in the same direction to move to a connected city. No scroll= command will be needed. refresh.pl may be the only file that would need changing for this to work.

The client-side approaches would use something like a city=command that contains the screen codes.

One client-side approach would read the city= command and switch rendering modes to handle one large screen instead of 4 scrolling screens. z-positions would be numbered as if it was one large screen, as well.

Another client-side approach would be to handle that city= command by breaking it and subsequent z-positions into 4 screens and using the same rendering. This would also allow effects like the server-side approach.

-QuaCzar : SysOp | P2P Guide | Anarchy Leader | #1 Magic

 


Posted: 03‑10‑2017 19:14


Joe


Fire Flipper
1406 posts
Ugh - seems the further along we get the more complex is becomes.

Hindsight suggests the main map could be four times as large, I'm actually thinking that would be smarter. I wish I had hindsight when we started this.

We want server-side for sure, that much I know - the client should be as dumb as possible.

The only question mark I have is how will the individual server modules handle the differences in the z values??

-Joe

DevTeam Member

 


Posted: 03‑10‑2017 20:04


Joe


Fire Flipper
1406 posts
Okay - I've thought this out some.

We've already discussed how cities should use lower case letters, so A0 will teleport to Aa ... and A1 will goto Ab.

The Aa.txt map file will need to have all four screens, so the loadmap.pl routine will need to splice that into four somehow. Which means the tile editor module will need to do the same.

The token.pl routine will most likely need updating to keep the z-location correct depending if the player is in a city or not, which means we should make a $InCity variable set in the loadmap.pl to be true or false depending on if the player is in a city or not (seems logical).

In other words, the $player{'tz'} variable will depend on if the player is in a city or not - if the player is in a city, the {'tz'} will be based on the city map (Aa) whereas if the player is not in a city the {'tz'} will be set to which map the player is actually on (A0, A1, B0, or B1).

As you mentioned, the scroll modules will also need to be modified so that if the player is $InCity an exit.pl module can be called.

And finally, the question of dropping objects comes up ... I doubt there will be a problem with those routines, but we'll find out when we get all the other stuff in place.

Am I missing anything?? I'm sure we'll encounter some issues with all this.

-Joe

DevTeam Member

 


Posted: 03‑10‑2017 21:07


Joe


Fire Flipper
1406 posts
And the "Enter City" command itself can actually be a "teleport" command ... as that is essentially what it does.

So there really is no need for an enter city module, we can use make it part of the teleport.pl module.

-Joe

DevTeam Member

 


Posted: 03‑11‑2017 07:34


Joe


Fire Flipper
1406 posts

So there really is no need for an enter city module, we can use make it part of the teleport.pl module.




Actually, I believe the executed command would be static-city.pl (or however I have them formatted), which can then trigger a teleport command.

I've been thinking about the loadmap.pl part of this - the current maps are saved in a single line text file; the city maps can be saved with four lines, each line being one of the four tilesets.

Right now my computer is setup on my coffee table ... hopefully in the next few days I'll have it moved to a desk in my bedroom and then I'll be able to buckle down and get some of this code done. This will most likely take both of us, and I believe it to be the last hardest part of the core engine.

-Joe

DevTeam Member

 


Posted: 03‑19‑2017 11:06


QuaCzar


Fire Flipper
1803 posts

Joe said:

I've been thinking about the loadmap.pl part of this - the current maps are saved in a single line text file; the city maps can be saved with four lines, each line being one of the four tilesets.


That's probably better than splitting the string at certain positions. It makes it more like normal screens.

I had planned on a server-side approach when I made the client-side, and it actually seems to be working out better than I expected, though a little bumpy, there. Haha

-QuaCzar : SysOp | P2P Guide | Anarchy Leader | #1 Magic

 


  Prev 1 2 3 4 5 6 Next

Hunt food, smith weapons, and prepare for battle! Can you stop
the Evil Que from taking over the entire game? Browser based multi-player
fantasy role-playing game that requires no downloads or plug-ins! Free to play forever!

By being at queville.com, you agree to our Terms of Service.