| |
|
|
|
|
|
Finished Implementing Premade System and Thoughts on a Possibly Crazy Idea. |
Posted 8 months ago. |
So the main way the world chunks will be generated is first underground soil and rock will be generated below a level of grass, and sky will be generated above the grass. Next a terrain generator will go through and populate the top layer with hills, mountains, lakes, and rivers outside of the main world coordinates that contain the city. Within the world coordinates that denote the city region, roads and buildings will be generated. Currently I have finished the main system that handles taking a bunch of pre-made building objects, and converting them into actual world data. This will give me the flexibility to easily draw random premade buildings (with constraints ex: cityblocks dense with skyscrapers, marketplace districts, suburbs, farm buildings on the outskirts). I will also be able to easily rotate these buildings by 90 degree intervals and to specify special flags that might make a building completely unique. Now, while these buildings are all premade structures, their contents will be completely randomized with furniture, appliances, items, and even things from other player's worlds. This coupled with random orientation and a giant pool of premade buildings will make the city pretty damn unique every play through.
Now all of that stuff is either done or almost done.
Here is the crazy idea I think I might be doing. Make a traversable continent! With seeing how easy all of the random generation I have been doing so far is, I am actually considering doing something crazy and instead of generating only one large city with open wilderness around it, I might allow for the procedural generation of an entire continent that the player (painstakingly) could explore. This would include traveling between MANY cities. The only limit would be the size of a person's hard drive as level chunks will be loaded/unloaded and then saved as the player moves between them (ala Minecraft). The major hurdle I can see that would become apparent at implementation is just how I would be able to track when the generator should be creating each of the features like a city, or farmland, or sprawling mountains. My only thoughts on it so far is to start the player inside the initial city at coordinate 0,0 in "CONTINENT COORDINATES" and then make him hit ocean at say 36000 continent coordinates in any direction, and the player wouldn't be able to move past this limit. Cities and other specific landmarks will be generated within certain regions of the "CONTINENT PLANE" whilst everything else will be left to true randomization. Now a continent coordinate would be a single 128 x 126 x 64 chunk of the world, and since the 36000 is just a number off of the top of my head, this could be HUGE. However, I am no math wizard and I can already see that much data being stored on a hard drive will add up fast, and while I am completely happy with my current compression techniques, they might prove to not be enough in the future. When that time comes I might just have to do some reading! |
|
|
|
|
|
|
|
|
|
|
|
|
|
"Slightly" Shifting Focus |
Posted 8 months ago. |
I will be narrowing down my broad and loose game-play objective from "dwarf fortress clone" to a large-scale randomly generated city rogue-like within a sprawling metropolis. But of course it will be during an Apocalypse. There will be zombies. There will be vampires. There will be all sorts of game play elements I wouldn't mind playing with.
Then to top it off, I will be implementing some kind of multi-player mechanic where players won't be directly playing in each others worlds. But characters and terrain artifacts from other players worlds will be brought into newly generated portions of another player's world (If the players tick some checkbox allowing such connections). You might be able to find a decaying corpse of a guy called "Bob Loblaw" who was a small claims lawyer that didn't last long in this new world, and he left behind a can of beans. But the cool part will be that this was another player who met an unfortunate end and from your perspective you are to your knowledge the last survivor, and you are finding all of these people who didn't make it. Also I plan on integrating zombified/vampirified/etc players as special enemy characters in other players world just for that extra bit of flavor. I have no idea how the overhead of server upkeep will go in maintaining this much crossweaving but I'll find out soon enough.
The reason I am straying away from just implementing "my own dwarf fortress" is because I feel I won't be able to offer a deeper experience than Toady is constantly bringing with his game. The only improvements I bring to the table are multi-threaded pathfinding and (eventually) prettier graphics. So I want to take this game in a completely separate direction while also maintaining the majority of ideas I originally set out to accomplish. I am still sticking with the top down view because side-scrolling just removes a layer of depth to the game, and isometric game-play would heavily tax me on the graphics and engine side of things, whereas I just want to get straight the to gameplay. |
|
|
|
|
|
|
|
|
|
|
|
|
|
More Progress |
Posted 8 months ago. |
So pathfinding is now 100% complete. Characters have their own pathfinding rules but the default ones allow movement in all cardinal directions and up or down. Up and down movement is only allowed if there is ramps in the tiles above or below the character and walls also block movement. I also finished working on how to display visual segments of wall tiles so that they are better defined:
You can see from the screenshots that the mouse is supported, and I plan to fully integrate it into the game. The arrow tiles in the images are ramps, and how they will be displayed. Things like ramps and wall segments are actually overlays instead of tile images, this will cut the amount of images I need to make for tilesets so drastically that at the end of the day it was a no-brainer. You can also spot that you can see the details of a few z-levels below you! This feature does cost more cpu time during the rendering step, but it provides the user more information about the world and will definitely help to ease more users into this type of game. |
|
|
|
|
|
|
|
|
|
|
|
|
|
Corrupted Windows |
Posted 8 months ago. |
| Well, I took a nap with my computer on and woke up to find out that somehow the Windows installation became corrupted and I could no longer boot Windows. To add to the frustration, the manufacturer of my laptop gave me a Vista disc that only allows clean installation, and I would need to order a disc just to repair my current installation. So, I ended up just installing a clean one, and now I've spent 6+ hour sorting through all of the old files deciding what to drop and keep. Very frustrating. |
|
|
|
|
|
|
|
|
|
|
|
|
|
My map structure |
Posted 8 months ago. |
So here's how I'm currently storing my generated levels.
I have 3 dimensions which are used by the world generator to create the level. They are width, height, and depth. Right now I am playing around with levels which are 256x256x13 because I find them to be of adequate size, and the loading time is near instant. Down the road I plan to increase the z-levels after I do some optimizing, and finalize on a loading time I think is acceptable. The map is stored in different parts, currently I have the tiles themselves stored as shorts in a three dimensional array, and characters and items stored in their own ArrayLists.
The reason I chose to store tiles in a short instead of their own Class is to cut down on memory usage as I gradually increase level dimensions being loaded into memory. To store and retrieve data from the shorts about the tile, I simply bitmask and bitshift my desired bits. Here's how bits are currently being used.
0000 0000 0000 0000 Sign bit [0-1] (Java doesn't support unsigned numbers)
0000 0000 0000 0000 Tile Id [0-255] (The id of the tile, or what type it is.)
0000 0000 0000 0000 Water Depth [0-7] (The depth of the water on the tile, 0 means no water)
0000 0000 0000 0000 Ramp Info [0-3] (0 - no ramp, 1 - up ramp, 2 - down ramp, 3 - unused)
0000 0000 0000 0000 Mud Info [0-1] (0 - no mud, 1 - mud; used for growing food)
0000 0000 0000 0000 Visibility [0-1] (0 - not visible, 1 - visible) |
|
|
|
|
|
View Older Posts |
Email: fizzik@fizzikgames.com
|
