Since I lack of time, have little energy and I also have a school project to do, I decided to focus on remaking a original Wizardry game clone for now. I tried to reuse most of the original game mechanics while trying to fix the issues the original game had. So I returned to the original races, attributes name, etc. Look at the game book section for the latest modification. I will use this website as a design document that evolves over time.

I tried to keep the mechanics simple, with not too much new features, while trying to make the game fun. I am trying to use the Sid Meiers technique: 33% old, 33% improved, 33% new mechanics. So far, the initiative system changed, there is now character flanks, there will be multi-classing to mix and match skills, permanent wounds, etc.

For the assets, I will use mostly DaveGH's textures and I decided to use Thalzon's monster assets for the enemies. I tried to pick up monsters art matching the most popular monsters in Wizardry and Dungeons and dragons. Thalzon's asset are very surrealist, so making a choice was sometimes complicated.

For the default adventure, I am not sure if I will use the Goblinoid Mountains idea since I have no assets for Orcs and Kobolts. Goblinoid mountain was designed based on the Wizardry bestiary, still, I have lot of goblins/gnomes like monster . I could try to retheme the adventure, by the way That adventure's map is drawn on paper. Else, I was thinking in reusing Wizardry 1 maze to create a new adventure. Like if it happened in the future and people returned to the maze. There would be more stuff to do than the original game, but you would get the nostalgia of the original maze.

My objective for the next release is to make the minimum necessary to make the game functional. In fact, it is possible that next release you only get a walk-able maze and no game play. Or just basic character management with no combat. I'll see. It would take a lot of work to get back in business, but once the new engines would be built, the rest will develop very easily.

Programming

I am currently using the divide and conquer strategy. The idea is to separate each portion of the project into an independent project of it's own to allow re usability for other projects including a commercial game. So far, I have separated the Maze engine with the editor from the base game. I will also be separating the user interface into a separate module. There are some advantages of separation like reducing coupling and I don't need to rebuild those modules every time I compile the game. Also some modules, like probably the User Interface, could be ported on other game libraries than Allegro. I could try to make an SDL port of the UI, but it is more complicate with the maze engine because I need 3D polygons projection which is lacking in SDL.

For Mapper, the maze engine, I will be adding the floor, ceilings and probably stop there for now. There could be maze markings. I would need to re-redesign the editor since one of the main problem is that I cannot use the UI of wizardry since they are separate projects. So either I make a custom UI for the editor, or I only blit the background of the editor that contains maps and data, with minimal editing functions, and reuse this code in the game editor. I am not sure yet how I will handle it as adventure editing requires both the adventure data and the maze file. The objective would be to focus only on the maze file, still some data like events, are closely tied to the maze.

I worked on a mini side project called F(X) Launcher that is basically a command line interpreter which launches business logic functions. The idea was to use this command line interface to test the game mechanics without any user interface. The project was fun and I made a command line calculator with it. The other interesting portion is that I managed to implement the Automated build system with Cmake and Gitlab CI. It allows me in 1 click to build 4 different version of the application. I even ended up cross-compiling the windows version from linux. You can find the latest binaries here:

http://lariennalibrary.com/extern/fxlauncher/

Simply run fxli,exe (on windows) for the interactive version of the program. This experience could help me build the continuous deployment system for Wizardry Legacy once the code will be ready allowing easier deployment. Now one thing I realized is that since I am using an SQL database, there would be a lot of boiler plate code to read the parameters of the commands invoked to create the necessary SQL queries. Also, most actions like creating a character, or curing a character is a multi-step process that demands to store the choices made by the user for each dialog and then launch the command. Storing those choices is also problematic and requires boiler plate code.

So this leads us to Glymmer, the user interface, which I have not yet created a separate repository. I did a consistent amount of work so far to display a stack of dialogs, but now I wanted to push thing further. Instead of trying to accumulate information to build a command, I would instead keep everything into the SQL database. Each game action would require a series of steps. And during each step a query will be run before, to display information, and afterwards to update the information. The idea is to avoid as much as possible any form of programming for the business logic. Most of the operations will be simple SQL commands tied to the user interface. An advantage is that I don't need to store answers anymore, and I will have little boiler plate code. It would make it easier to make changes or mod since the UI is data oriented. Player choices would be stored by marking records in the database.

That means that a new approach must be used, since the business logic occurs at each step. So the solution to make playtesting without a GUI would consist in using the text interface to list a series of choices and make a selection by typing the associated number. This would simulate the arrow cursor in the GUI. This way, I could playtest the UI without the graphic mode. I could probably have a form of automated testing, by storing a list of choices to make in the interface. A bit less convenient than just listing commands, but it could possibly work.

I still have to evaluate if making a text interface will really take a lot of time. I think on the long run it could help for debugging. It could also make Glymmer functional without using Allegro. Since managing records in C could require a lot of code, by keeping everything in the database, it could accelerate the development of the game. Only complex mechanics like combat resolution, would be done in C code. I would also be putting tons of constants into the database, in fact any information displayed to the user should be in the database to make the UI building easier.

So the next steps is either to work on the UI to test some business logic. Or add some features to the maze engine and try to make a more functional editor. Meanwhile, I would be managing some assets, and trying to define the data and mechanics of the game. You'll find them in the game book section.

Enjoy!

• News: Focusing on the original game (2021-10-06)
• News: Initial version of Mapper released (2021-07-04)
• News: Changing the direction of the project (2021-04-10)
• News: Teaser for the next release (2021-01-22)
• News: Version 0.6 is here! ... with not much new features!? (2018-01-18)
• News: I might finally put the source on a git server (2017-09-10)
• News: A new release for Wizardry Legacy (2015-02-01)
• News: Planning for another coding session (2014-10-28)
• News: Wizardry Legacy 0.4 is here! (2014-03-14)
• News: Wizardrying at, almost, full spin. (2014-01-17)
• News: Working on the Editor and taking a break (2013-05-27)
• News: Version 0.3 is now available (2013-04-16)
• News: Restarting to Program (2013-04-03)
• News: A new Website for Wizardry Legacy (2012-11-21)