Alternate Reality "The Remake"

So for the last several week I have been working hard on getting bug fixes in the system. I've just been going through each section of the code making sure their bug free like the shops, Tavern, Smithy and Etc. Going through the guilds making sure they're working fine. It has been a daunting exercise and making sure every piece of the code is hit at least once. 

Starting to feel pretty good about it being ready for a beta testing.   I've gone through all of the loading and save routines for the player to make sure it's functioning properly. But one of the biggest things I came across was pausing of the game, that is such a huge issue, the way the original code was written it was hard to do with all the new enhancements. So I have ended up completely rewriting the Remake engine, now it has three processes during the game Loop. The first one is input then process and finally render. Luckily when I created the gui system for the Map Editor.  I managed to create that in a very generic window system and it was designed to seperate input from rendering. This window system is handled by a window manager to control all windows it can recognize a window is in focused or not in focused, transparency of windows.  Window moving, and multiple windows at one time... 

This system allows Windows to be drawn but not handle input this works out great with the splitting of the new engine. There is a render call and a input call so this works great with the new window management system it can see which window has focus in calls its input only for that one windowin focus and then for the  rest of the windows that are visible only get called for render.

So the game engine has five windows, there's a compass window, there's a mini-map window, stats window, a 3D window, and the biggest part of the game is the console window. The console window management actually has a stack allowing for multiple console Windows to be open only the top window that's in Focus actually gets the input called and drawn. This allows me to make the game not blocking on any part of the code. Previous c++ version, every input was a blocking call. this made development very difficult because in between each blocking call you had to do all kinds of checks and calls to functions, to keep the game going properly.  There were hundreds of these while loops that preventing the game from updating and each while loop had to be handled to cause the game to update. Otherwise it would be stuck in a tight Loop, that basically paused the game. Now if you going to the drop menu (drop a weapon) and you start doing the drop of an item, this code does not block the ability for encounter to happen.  The Encounter can still  happen, also curses, dieseases and such nor update during any menus. So what would happen is that you're just stuck in this Loop the game does nothing until you get out of this Loop and then it will check for an encounter. Now the game Loop is constantly being processed all the time no matter where you're at in the game so if you're in the middle of dropping items, the game can still comes up with an encounter and then counter menu system will pop up and you would go through the encounter. Once the encounters done that menu closes and then the next menu in the stack becomes active, you would continue where you left off. This has caused me to touch almost every part of the software to fix it to handle the new coding-style. Everything needs to be able to have at least 2 call, one for render and one for input. The original code was never designed this way, it was designed with just one call that handled input processing and rendering. So the game Loop would do all this in one call and then just sleep, the new game Loop does a call for input, does a call for processing and keeps calling the processing input until the end of the frame update and then renders. So I had to convert every console screen into a menu system that will handle one call for input one call for render.  Not all menus actually get calls like the compass menu, mini map menu which never need a call for input. All of the consule menus need both calls and render. This make all the menus  a asynchronous call, this made a challenge for programming.

This makes it a little challenging to write menus. You don't just call for an get input, and that call is not return until the user does ithe input. Now that call will returns instantly and just popups a window for the user to enter whatever it needs to enter. So the menu systems needed to be converted to a state system so it knows what state it's at, and then wait for that input to be completed before you continue on. So for the last couple weeks I have been converting all input screens into menu systems, turning them into State systems. It has been a lot of work but I think it is well worth it because now the game runs all the time there is no blocking routine but stop the game from updating. This new system will make for faster development in the future, with all those blocking calls gone every time I make a change I do not have to go into hundreds and hundreds of Loops to make sure they have the new update processing the game. Now there is only one process for the entire game. For an example, the thing that got the biggest improvement is the weather system. Now if you go into a shop the system will keep processing the weather but not render it, in the past it was all one section, process updates and process render. So now in the process mode it can process weather but not have to render it. This allows the weather to keep changing and updating even when you're in a shop for long periods of time versus it just paused and then wait for you to get out of shop. the sound effects of the weather are still processed and you can hear him depending on the Storm level so you can hear the rain inside of shop or thundering outside. It will not be as loud inside of a shop and render the sound much softer because you are in a building.

Right now I'm going to the encounter system make sure the encounter system works with the new code-style.   What was hard, was the  code was a tight loop,  to turn that into a state system to know where you're at in the encounter so the system still processes the encounter,  was quite challenging.  In the scheme of things it is so much nicer. It does make the encounter system a little more difficult, in the past if you drop an item, used an item, casted a spell, the game would be paused until you finished your selection. Now the game runs in real time, so if you're dropping an item and take too long, your opponent will do their attack so you need to watch out and be prepared for fights. Digging through your inventory to find a potion might get you attacked because you took too long, giving your opponent time to attack you. The only call that is blocking an encounter system is when you make an offer to an opponent. The opponent will wait for you offer determine what their action will be. I have not spent any time figuring out how much more difficult this will cause a fight routines. Especially when you are casting spells using Scrolls and Potions having to dig through inventory which can slow you down and give your opponent time to attack. Alternate reality the city, was a very hard game to get anywhere on the fight routines, I hope  that the fell of  the dungeon was much easier fight routines, but harder because they just threw more at you. Instead of fighting one creature you would fight 8 creatures. and on top of that you would have creatures that would regenerate, use potions to heal themselves, or call more creatures in to fight with them. Sometimes in the dungeon it would take a very long time to get through a battle scene, the encounters just kept calling more and more people. As soon as you got down to one or two, they would end up calling for more . You would end up fighting for 20-30 minutes just in one encounter.  You would only  fight one creature in the city at a time, but the ability for that creature to call for more creatures are part of the city not just the dungeon.

 

I have also took the time to test out 3D models inside the game. Thinking about this being the alternative Graphics enhancement. You will have a 8bit style graphics, the 16-bit style graphics and then enhanced graphics. For the enhanced graphics I am thinking about 3D models. I have a test case proving concept that the 3D models work with alternate reality, my biggest concern about using 3D models is making sure that the look and feel of the game are not altered in any form. I think one of the biggest parts of alternate Reality is it look and feel. The last the last thing that I want to do is take away in the field and turn it into seems like another came in today's era. The enhanced Graphics will not be pleased with the beta version. I have the walls, doors, Palace pillars all done in 3D models. The game looks pretty neat in 3D models, keeping the overall feel of the original style of the game.

 

This is a quick update to the Alternate Reality Editor.  I ended up creating this as it was need to be able to debug quickly.   Sometime the special effect of an item was not working and digging through data files to figure out what it should be doing was to much work.  So right now you can Edit and look at the entire map system.  It has tons of data that you can see about each cell or each zone.

You can alter Encounter Weapons, and Dungeon Items and Spells. 

I just wanted to do a quick update on what I've been doing for the week. So I was going through the code, to update Zone information inside the dungeon. Part of the update was to make sure that the temperature of each zone in the dungeon matched the remake. There's a website on the internet that shows the dungeon maps of all the different levels, with detailed information about description for each spot. If that spot is a fixed encounter fixed treasure, and etc.  It also has information about zones.  I was using this information to determine zones data to look up in the assembly code for detail. after wasting about 2 days on this I determined that part of the code on the guy's website is just completely wrong, I could not make sense of anything he was saying. So I started digging through the assembly code and figure it out that that is not zones. That is Zone definitions it's an array of five bites and that 5th byte tells it which zone you are in.  So it's just a list of different sections to determine that section belongs to a certain zone.  I have had to do this many times with what people published on the internet about alternate reality then digging through the code to find out it's it's a little off.  

In the meantime, instead of having to look at data files for maps to determine spots.  I have created a map editor, this map editor will load a module and display it on the screen.  The visual part of the map is based on the mini-map that the the ARX had inside of its code. It has been expanded since then to become a map editor. you can hit a key and it will display all the zones highlight each Zone in different colors. you can click on a spot it tells you information about that spot like description XY location if it's a special spot what kind of special spot if it's a fixed weapon then it tells you what weapon it is.

I'm working on the editor to be an actual editor, right now you only can view everything about the map. I have to put in the gooey to be able to create input fields and stuff like that. My plan is to use this map editor to be able to create expansions. The plan for the map editor is to be able to create an entire module not just the math but weapons spells and etc....

There is one thing I can think is left out in the remske, but is only related to the dungeon. That is if a spot has a special effect or dangerous effect,  there is nothing in the code to handle this.  I have not found this section in the disassembly code to determine what those effects do, I am still looking for this code to determine what they do.  I still need to locate this code and added to the remake.