Blog 2: Features and Code Environments
3/7/2023
Welcome back to the Integration Hell development blog.
Code - It was a challenge to get the environment set up but now I am ready to begin coding the game. I was able to get this test program running. I'm still new to the graphics library I'm using (SDL2), but I will get better with it as the IH gets made. Code adapted from this tutorial. This means there is now a "version" 0 of the game (although it's just tutorial code).
Game World - I've had some ideas on what to do with the game world. I would like it to be "infinite", meaning it the maximum size is either a 32 or 64 bit integer limit for world dimensions. More details on organization of this in the section labeled "Bypassing Infinity". For the resources, the simpler ones will have a higher probability of spawning closer to the player while more complicated ores will spawn further away from spawn. This will encourage the player to make factories that spread out.
World Organization - The game will keep track of the world by dividing it into 32 x 32 tile sectors. For disk storage, 4 x 4 groups of sectors will be stored in to dat files.Β
Bypassing Infinity - Nothing is truly infinite. However, I can still make an "infinite" world by making it sufficiently large. I have two current ideas to do so. The first would be absolute coordinates. This means to make the player coordinates in terms of a tile for the whole map (i.e. 100x 200y tiles from the origin of the map). This limits the world to be approximately 4,294,967,296 x 4,294,967,296 for 32 bit integer or 18,446,744,073,709,551,616 x 18,446,744,073,709,551,616 tiles for a 64 bit long coordinate system. Both of these are ridiculously large and the disk on the computer would probably fill up first. The second system would be coordinates using sector coordinates. Player coordinates would be within the sector and have another set of coordinates for which sector the player is in. The 32 bit and 64 bit world sizes would be the same number but would instead be for sectors instead, making the world 32 times larger in the x and y direction. Again, this is absurdly large and the game would have lots of other problems trying to run a fully generated world.
Engine & Graphics - I am going to keep these as separate things. This way, if I change graphics libraries I do not have to rewrite the game engine and vice versa. The diagram below is a simplification of what I mean. The graphics system handles user input and rendering the game. The game engine handles all the machines, player interactions, and other game mechanics. The graphics system will send commands to the game engine to request data to render and the game engine will give that data to the graphics system.
Future Plans - Before I do more graphics work, I want to make a simple version of the world generator to get something for the graphics system to show.
The Checklist:
Goals:
π Window/Graphics
π Game Rules/Gameplay
π Game Logic
Tasks:
βοΈ Get a window to open
π Put an image on the window
βοΈ Move the image with the keyboard
βοΈ Define the world
π Have the program make the world
π Load/Save world data to disk
π Create simple assets to use for the game