Hello everyone! This is the first devblog of many for the just-started development of Pyco Mundi: Origins, the Pokemon Twilight spiritual successor/redesign thingamabob that I am making. Basically it's the original stuff from PT moved into a non-Pokemon universe. But that's not the point of these devblogs, these devblogs are going to cover whatever insane design/coding thing I'm currently thinking about. It's mostly a way for me to think about my plans out loud. Not everything I devblog about will end up in the game but a lot of it probably will in some shape or form. Anyway today we are talking about the very fundamentals of the overworld engine and how the game is displayed to the player. Back in the day I made an engine called OpenPokemon V2 which succeeding in recreating parts of a pokemon style overworld engine by storing most of the map information into a giant 2d array. It was a pretty complex problem for me to solve at the time but in the end it was seemingly more efficient than the PTV5 engine. Originally the plan was to use that engine for PTV6 but then PT became PM and as a final nail in the coffin of OPV2, Game Maker Studio 2 came out. I was now inspired to re-invent the wheel. The idea I'm currently working on is potentially similar to OPV2 in that it uses arrays but the similarities end there. What I'm going to do is first create a custom map editor because without it this entire project would be insane. The overworld map will for the most part be designed as one huge map, which will then be split into equally sized pieces and saved. This is similar to how Minecraft works, but 2d. This way, the game just loads all the nearby chunks into an array and then uses that data to dynamically create all the objects on the map. This will eliminate room switches from the overworld, so the only time you will need a fade to black is when you enter/exit a structure such as a building or cave. Obviously there will be a lot of complexity in managing the chunks, such as what happens when an npc wanders from one chunk to the next. My current plan is that NPCs will only be able to wander a maximum of 1 chunk away in any direction. If both chunks become far enough away from the player to be unloaded then the npc will be returned to their original position and they will be unloaded. Ultimately though, I think it will actually become surprisingly easy to manage once I have the map editor built. The big question is if this will run fast enough or if it will end up being a huge waste of time. Well that's enough about chunks themselves, let's move onto to some other related bits. My original plan for PTV6 called for a resolution I described as "widescreen DS" It is ultimately 192p, which is still pretty dang tiny although a nice step up from the old GBA resolution of PT. This entire concept of chunks came from the decision that I should probably make the resolution higher but not wanting to change the graphical style. The game will still use 16x16 graphics but it will have a default resolution higher than 192p, maybe 240p or 360p. I'm undecided on this. But it will be resizable to very large sizes, not just by zooming in on the sprites either. I don't know the maximum amount of map that will become visible at once but it could be pretty huge. This will of course also depend on what kind of FPS my insane chunk system ends up getting at bigger sizes. My thinking is that there will be 2 options, zoom level and view area. View area might max out at like 720p or something but then you could do 2x zoom to fit 1440p or 3x for 4k resolution. This will allow you to choose whether you want big easy to see sprites or a huge amount of surrounding area or a middle ground. Or you could just play windowed at 480p or something. I think this is an ideal solution both for gameplay and for supporting lets players, which is something I have become very aware of when trying to play games with dumb resolution choices. Now you probably haven't thought about this but a tiny house might look a bit silly surrounded by 90% of the screen being black. I have 2 thoughts on how to solve this. The first is that I could just make it so buildings are automatically zoomed based on the resolution you are playing at and how they compare to it. The second is that when you enter the building it will appear as a sort of GUI window with the main map still in the background. This could look a bit strange though since the inside of buildings are so much larger than the outside. Ultimately it might end up being a combination of the 2. I'll have to see how it looks. Anyway I think this is enough of my ridiculously long overly technical stuff that nobody really cares about. Next time I'll try to talk about something a bit less complicated =p