Alternate Reality X

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.

I have been very busy the last two weeks, working on alternate reality the remake. It has been mostly about debugging getting the code ready for testing.  I have created a logging system that can be turned on so during testing anybody can turn on the logging system and all the logs will be saved. To a file that can be passed on, that will be easier for me to debug the issue that's going on.  To turn on logging to a file is just a command paramter when starting.

As I was goning through eliminating bugs, I've come up with two things that I was not happy about.  One of the features I was not happy with was screen resolution, in the original version was "if statements" all over the code for different types of screen resolution to be able to know when to display this and that.  When I converted that to Java I made some enhancement, I created variables for screen resolutions for different drawings, those are all set at the start of the game, this allowed me to remove all those "if statements" throughout the code.  But still had all those variable and having to adjust them for each resolution.  I was never happy with that solution.  I rewrote a lot of the rendering of all the features of software, this time I let opengl do all the scaling so it does not matter what your screen resolution you use.  To opengl it's the same resolution every single time, so there's nothing in the code anymore for all the different sizes this will help out much better.  So the canvas for opengl is always the same thing no matter what the resolution.  This allows opengl to scale the pixel to a full screen to the small resolution of the canvas.

The second thing I found that was not going to make it easier to expand on, was the city and the dungeon was all hard-coded throughout the entire software. So I stripped out the city in the dungeon code from the game altogether. I turned each one of those into a module but the game will load at the start you tell which modules are available and it will be able to use those, that way when it's ready you just plug it in the module. this will allow easy future expansions without having to redownload everything it can just do it in you know modules you download and install.  Each module, chain control many aspects of the game like fix treasure, fixed and counters, weather, Random Encounters, and of course the map.  

With this new module system alternate reality the remake, is turning into just a RPG game engine. there are a couple big things that would require changes for this to be 100% true. A module would have to be able to alter by adding or deleting items, spells, encounters. This is not a priority for me, I will keep looking into this but not focus on it.

Right now my focus is going through each encounter one by one to verify their fighting and functionality is working correctly. The next step after that is going through each item and verify they function properly and then finally spells. Once I have a generally debugged these items the city will be ready for testing. There there is a couple minor things left for coating but it's about 98% code complete without the new features.

I was in the middle of debugging the encounter system.   I knew I added tons of new code to try and match the dungeon the best I could.  Like, parry, being knocked down, knocking down a monster, having your weapon knotted out of your hands or the encounter.  I spent a couple of months getting the encounter code working and adding in all the special monster code like the thief stealing, devourer sucking up your items.

As I was debugging I was also playing the dungeon and noticed that some times an encounter flees but the old ARX system.  Once a fight starts it is to the end and no encounter will flee.  So I started to look into the code to see why an encounter flees.  After I found the code and figured out what makes an ecounter flee,  my next step was when was this code called.   After researching that I locate default code of onLoad, onSurprise, onPreAttack and OnDeath code.  I have that many of these function have 1 - 6 different sections of codes based on the encounter.  Some encounter have thier own routines while most of them use a shared routine.  So I started coding all these routine into the game and that is where the flee came into on the onPreAttack code,  it has 6 different routine that is used and two of them have a check for flee in them.  So like a thief, he is more likely to flee after stealing from you or if he loses to many hit points.   There are a few that are designed to not flee at all,  fight to the death.

When I started I located a monster data where someone mapped out some of the variable of the monster.  So I've been able to map almost all of those variables and have implemented them into the ARX system. The encounter routine is very advanced.  Over the last couple of months, I've implemented parry, dodge, spell casting (you, encounter), drinking potions, knock down, being knocked down, loosing weapon, stunned and many more features.

Now the flee code is in the game with all the default code.

During this process, I found other areas of the game no FAQ gets correct.  You can lose alignment for several reason that is not mentioned.  Like,  stealing from encounter will cause you to lose alignment, but if you go ahead and kill that encounter and alignment of the encounter doesn't matter you will lose even mose alignment, or kill the encounter that belongs to a guild that you belong to, you will lose 2 mood points on top of the alignment lose.

As I write this and research what I'm writting I see that there are a few onLoad features that are missing.  Like no monsters has an alignment of 255 but in the binary file the Knight has a 255, but it is changed on the load routine to reflect what is going on with the game at the time.  Have to implement this code.

Getting to know all the ins-and-outs of the encounter routine.  Getting really close to having almost all aspects of it implemented in the ARX system.  The game is really starting to feel like playing AR the dungeon.  More like the Dungeon then the City.  The fight routine in the dungeon is so far better than the city so, I'm basing the entire fight routine on the Dungeon.