Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411593 Posts in 69386 Topics- by 58444 Members - Latest Member: FightingFoxGame

May 07, 2024, 12:21:15 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Big map scrolling
Pages: [1]
Print
Author Topic: Big map scrolling  (Read 1309 times)
rejwan
Level 0
**


View Profile
« on: August 01, 2010, 07:42:11 AM »

Hello,
My name is Ron and I'm a small game developer.

Recently I've finished the 1st stage of my new game War Legends (http://www.warlegends.com) which the client was programmed in Flex 3.0.

Now basically the world is made out of hex tiles, and the player can move the map around either by clicking and dragging the map or clicking the minimap.

The coder I hired to write the map drawing component made it in a pretty non-scalable way (the entire map is drawn into a bitmap object and thrown on the appliaction) - this is fine for small maps, but for larger ones this causes a very long loading time (which even causes the loading to fail on older computers).

Now I obviously need to remake that component, question is, what is the best approach for this? Obviously the client doesn't need all the map if the player is only shown a small portion of the map - so I'm guessing it has something to do with that Smiley

Screenshot attached from the game.
Logged

nikki
Level 10
*****


View Profile
« Reply #1 on: August 01, 2010, 07:53:28 AM »

well the basics are laid already, you just load the (hex)tiles you need (only the truly different tiles), read the 'world' data (wich build the big worldmap with tiles) and show the right tiles in the right place.

at the end you can put the tiles together (drawn into a bitmap) and display them.


looks pretty by the way


Logged
Kekskiller
Guest
« Reply #2 on: August 01, 2010, 08:00:15 AM »

At first, never draw such a big scene in one whole bitmap. There seem to be so many repeating tiles that I'd say put all visible tiles on the stage/sprite you're using as the map part and remove them if they get out of the screen rect on the map. This is rather simple if rectangular tiles are used, but for hex tiles you'll probably create a bounding box for each and use this in the screen/tile overlapping test.
Logged
rejwan
Level 0
**


View Profile
« Reply #3 on: August 02, 2010, 04:02:35 AM »

Hi guys thanks for the reply, that's pretty much what I was thinking about doing, I just want to do it right this time (Plus I need to change lots of core issues, which is a big big change).

Each hex has the following information:
* Terrain type
* Is visible
* Cities + Units
* Resources & Radiation

What I currently plan on doing is this:
1. Load all zones into data objects
2. Create a DrawMap(X,Y) function - Goes through all the needed hexes to display and loads them up into visual objects and displays them on client
3. On drag - Client removes any hexes out of view and adds the needed zones to the new client vision
4. On minimap click - DrawMap is called to redraw entire vision

This seems like a good plan or can anyone think of anything more efficient?
Logged

bart_the_13th
Level 2
**


View Profile
« Reply #4 on: August 02, 2010, 04:41:31 AM »

If you want to use less memory, then I think you should stick with the previous idea.
But if you want more speed and have more memory to waste, maybe creating an empty large bitmapdata and put all the whole stuff in it at the 1st time run(like Flixel did with it's tile map)

But considering your game's genre is strategy game,I think you'll never need fast rendering speed, so maybe you should stick to the first idea
Logged
Kekskiller
Guest
« Reply #5 on: August 02, 2010, 04:47:43 AM »

Going through all maps might a bit bruteforcish for Flash. For small maps OK, but remember Flash isn't the fastest engine you might find a bottleneck there when making bigger maps.

My suggestion is to split one map into smaller ones and give each it's hextile list/array, so you can first check the big map parts for visibility and then an hex tiles inside the visible map parts. This way you can reduce the all-tiles-bruteforce dramatically.

The rest is pretty much like it's usually done, so stick with whatever extension you think is useful.
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #6 on: August 02, 2010, 10:37:00 AM »

This is probably more work that most users have credited. You have a minimap, which I'm guessing is literally a scaled down version of the full map bitmap. No matter how you code the main map to do less work, you are going to have to re-implement that minimap from scratch (to actually draw something small rather than work big and scale down).

Other than that, I'd recommend keeping a huge bitmap, but only updating the portion you need on a per tile basis. It's maybe not the best way, but it's likely the least work to refactor from what you've come from. This means you don't need worry about removing tiles/sprites - you can just every frame with screen motion redraw all visible tiles.
Logged
rejwan
Level 0
**


View Profile
« Reply #7 on: August 03, 2010, 06:23:39 AM »

The minimap is actually a prerendered file made by the map editor and saved as a small JPEG so no rework will have to be made there.

And I'm afraid I have to blit scroll everything and remake the entire map renderer from scratch.
Logged

Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic