Not famliliar with that game, sorry. Generally speaking in the old days you would just have a graphics buffer, would draw land to it, would then destruct parts by removing some pixels etc. Simple stuff. These days the graphics buffer does not reliably exist after doing a Flip() of the double buffered display, so you have to redraw the whole visible area each frame.
To do that you obviously have to have all the graphics that you need stored somewhere. Generally speaking it has to be in images. YOu can try one big image but there is a limit of the maximum image size supported by any given graphics card so you would be better off splitting it up into say 256x256 size chunks, one image each. Even when that is the case, you would have to draw all the visible parts of the landscape, draw any new destruction or changes, then re-grab all image parts that changed so that next frame you are drawing the changes you kept. GrabImage is not always very quick.
What we need to know is is this a turn based game, do you want it to have lots of realtime action, is it going to be scrolling only in one direction, and do you intend to modify the landscape?
To do that you obviously have to have all the graphics that you need stored somewhere. Generally speaking it has to be in images. YOu can try one big image but there is a limit of the maximum image size supported by any given graphics card so you would be better off splitting it up into say 256x256 size chunks, one image each. Even when that is the case, you would have to draw all the visible parts of the landscape, draw any new destruction or changes, then re-grab all image parts that changed so that next frame you are drawing the changes you kept. GrabImage is not always very quick.
What we need to know is is this a turn based game, do you want it to have lots of realtime action, is it going to be scrolling only in one direction, and do you intend to modify the landscape?