Hi, my name is Paul Wortmann, welcome to my site. I am a hobby game programmer, exploring algorithms and code on an adventure in creating games.
This site showcases and shares my projects and ideas with the world.
I have an interest in programming in general, but mostly for games and robotics.
Due to work and life I am unfortunately not able to devote a lot of time to game development.
I am still actively developing games, just not spending as much time on them as I would like.
As I relocated to Japan a few years back, learning the local language also distracts from writing code.
When it comes to language learning, I enjoy the process of creating my own language learning resources, a few of which can be found in the Japanese section of my site.


Any software or source code created by myself, unless stated otherwise, is under the GNU GPL V3 license, or (at your option) any later version.

CC BY-SA 4.0

Any resource, other than the source code/application, created by myself, unless stated otherwise, is under the CC BY-SA 4.0 international license.


Github Youtube Twitter Twitter

PhysHex Games Back Online. (2017-04-24)

After a long period of being offline, the site should now be back up for the foreseeable future.
The reason being was a change in ISP which blocked access to my privately hosted website for about six months.
Unfortunately the ISP change was unavoidable, I will go back to my previous ISP next time I move. But fortunately after many days of effort and complaining, I have finally got the site back up.
So what has happened in the passed six months?
I have not had much free time in my personal life, mostly due to work and family.
But I have been working on a new rendering engine periodically and have rewritten large parts of the engine framework. My current focus is to continue working on the new graphics engine until it has the following:
  • Lighting and shadows.
  • Texture mapping.
  • Animated models.
While it is a short list, I plan to explore these topics quite thoroughly.
Below is a early test using forward rendering:


Nose to the Valgrind...stone. (2016-11-06)

In the futile pursuit of writing the perfect game engine, I wrote some test code for a more modular graphics engine.
I have recently started using GLFW instead of SDL for the creation of an OpenGL context. Don’t get me wrong, SDL is excellent, and I will probably use it again the future.
But at this moment in time GLFW is a better fit for my current project.
One reason being that GLFW is more lightweight, I do not need all the bells and whistles of SDL, I just need a cross-platform OpenGL context.
But the major reason for using GLFW over SDL is less memory leaks. Although on Linux, these memory leaks are usually related to X11, used SDL, I hope Wayland won’t be this bad!
My first time using GLFW was a great experience, it just worked. I ran it through Valgrind without issue, much to my delight.
But my recent experiment did not go as smoothly. I did the usual initialization, call the window creation function, and terminated as per the manual.
The application ran just fine, no compiler warnings and life was good.... Until I did a routine Valgrind run...
I spent the next four hours trying to figure out why Valgrind had reported an error.
The next day, as all programmers do, I turned to Google for help.
After Googling the error “Syscall param socketcall.sendto(msg) points to uninitialised byte(s)” I reworked the code numerous times, initializing anything and everything in sight, but to no avail.
At this point I was thoroughly enjoying the bug hunt, waiting for that all important eureka moment.
Work was busy for the next few days and the shiny bug was still hiding, waiting patiently for me to find it, probably hiding in plain sight as they often do. Today being my day off, I have now been given another pleasurable opportunity to enjoy the happy pursuit of resolving code issues.
I wrote the simplest and shortest possible amount of code that would still produce the error.

The error occurs when calling glfwCreateWindow(...), I tried everything that I could possible think of, but the error still persists.
While this is not a serious error, and ignoring it would probably be fine for all but most.
I am never happy ignoring errors and warnings even the slightest compiler warning needs to be addressed.
My next step was to hit the command line and try get more information from Valgrind.

Based on this I assume the fault is with the Nvidia driver, which I recently updated to the latest version.
Libglx is for x11....
My next step is to wait for a newer Nvidia driver and hope they fix this, or try AMD Radeon?.
For now I will put this issue on hold and get back to work, thank you Nvidia and X11.org....

PhysHex Games new home. (2016-02-09)

I have been wanting to move physhexgames.com from my home PC to a dedicated PC for some time now.
I finally found a suitable home after looking at various such devices.
I ordered an Odroid XU4 from Hardkernel about a week ago, and it arrived this morning much to my surprise, I wasn't expecting it so soon.
As soon as I opened the box I immediately put it together and installed the necessary software, and then ate breakfast.
After about 8 hours of persistence I finally got i working correctly, the hardware and included Linux on the eMMC worked straight out of the box, no problem.
The reason it took me so long to get it working was my switch to ddclient, don't get me wrong ddclient is awesome, but getting it working with my dns provider and the settings that had to be changed from their defaults is where the inconspicuous problem did hide.
I even formatted and reloaded the Linux image in the eMMC 3 times and change all sorts of network / web server related settings before realizing where the sneaky error was camouflaged.
Learned a lot more about hosting websites on Linux today, good experience!
While I have many different single board computers in my collection, but the Odroid XU4 is by far the best such device I have ever used. :)


Jenkins, Continuous Intergration. (2016-02-06)

Jenkins: "An extendable open source automation server."

I set up a Jenkins server to automate builds using a git hook.
I have also been looking into having Jemkins automate Windows builds too.


RoboEngine design. (2016-01-02)

The initial design approach to RoboEngine was more of an interconnected approach with RoboEngine defining classed for each subsystem, and in turn having the game create instances of these classes.
Also having a central game loop defined as an abstract class and the game deriving this class populating the virtual functions of the class, some instances of the game engines defined class are also instantiated by the game engine.
This is a good approach for a game engine which offers less overhead and slightly higher frame rates that the new method, but also lacks in a few interesting features offered by the new game engine framework.

The new game engine framework defines each subsystem as a separate entity and instantiated by the game engine, each subsystem is a self contained module running in its own thread.
The game engine creates an instances of a message bus / event system and the individual subsystem threads use the message bus to communicate with each other.
While this approach is more complex it provides some benefits. Easier scripting, replay, powerful in game developer console, as well as allowing the graphics engine frame-rate to be unaffected by other processing.

Well that is the goal in mind, lets see how it turns out.


Architecting the game engine. (2015-12-29)

To the average user a game is about being immersed in a visual and/or audible experience effected by physical input devices. The inner workings of which are often of insignificance and often left without contemplation. However I am one of those that enjoys the adrenaline rush and thrill of knowing how things work and how to build them, more specifically how beautiful code intertwined in processing hardware transported about by electrons, pushed through the ravines of the processor's landscape results in the experience delivered as a game. Its more about these inner workings and optimizations that intrigue me, the myriad of possible features is only surpassed by the seemingly infinite possible implementation options that can be imagined. Creating the perfect universal game engine is apparently insurmountable, although the pursuit is no less rewarding.

Frost and Flame's engine grew out of the cleaned up spaghetti code that was Star.P.G., which in turn grew out of the butchered caucus of a previous game. Both of which were “complete” although flawed in the inexperienced code driving them. For me Frost and Flame has been about making the RPG I have always wanted to play, but at the same time gaining knowledge and experience in crafting games. Like many I could have chosen the path of using an existing engine, of which there are many excellent options available. I would have probably completed a few more games by now had I taken that approach, but I would never have been satisfied without rolling my own. There is an art to writing code, it is like a beautiful harmony of words placed in poetic phrases with a chorus of syntax painted on an artists easel, hidden from the user.

While there has not been a new build for Frost and Flame in quite some time, that is not how the story ends. Just like how code is hidden from a user, so is much of a games development. Since the last build I have rewritten the underlying game engine for Frost and Flame numerous times, at least four times this year alone. I have stopped pushing code to the Github repository as change in the repository has been so extreme and volatile. That is one excuse, and I have not had much time available to work on Frost and Flame this year. I will push more code in the future, when the code base matures and is more stable. I have, since the last public build of Frost and Flame acquired more game resources which are sure enrich the experience.

This year I separated the game engine code from the game code and have been developing multiple games using the same game engine. This is a good idea, but also a little more complex and time consuming, but well worth it. Unfortunately by nature I cannot just write a game engine and leave it be, it needs to evolve and grow as I gain more knowledge and experience. This is both a good and a bad thing, bad as there is no end insight and thus no game will ever be finished. And good as the quality of the games have and continual improve with each iteration of the engine. Another thing holding me back is I am a one man army (for most games), I like to do everything myself, thus find myself in solitude and progress at my own pace when I am not distracted by the variety of media reaching out to grab a hold of me. I have thus disabled some of my social media, but as one option is removed two more present themselves. I though streaming live online would be good motivation, until viewers ask so many questions I cannot concentrate or even continue on with the code. I have tried pushing commits on a daily basis to motivate myself into working on Frost and Flame, but then the quality of the commits decrease in order to adhere to schedule. I think daily commits are a good idea, but without a clear goal in mind and without a defined roadmap to follow, overall progress does not benefit greatly as time spent going back to rewrite parts that were rushed in the name of the daily commit stunt progress. Another possible idea would be to develop Frost and Flame as a team, this would drive me in a competitive manner to outperform my peers or to aim for perfection as not to disappoint. I seem to have wandered from the original purpose of this post, although not necessarily a bad thing.

My first iterations of the game engine were an intertwined mesh of functions and classes for specific tasks. The second iterations of the game engine were a less intertwined mesh of functions and classes for specific tasks abstracted away from the game to some degree. My current approach is far removed from earlier versions and differs substantially. I am working on separating all game engine subsystems and having a message bus for inter-system communication. As all systems will be separate they will be able to run in their own threads. The engine itself will also be totally separate from the game connected only via a message bus, no more direct function calling. This will add a slight overhead and affect performance negligibly but it will be well worth the effort. Having all systems accessed via a message bus will allow for other interesting features, like a user console, better debug logs and scripting. The graphics engine could run at 60 FPS without being affected by other subsystems which may dip slightly below 60FPS when under heavy load. All this hard work on engine improvement does come at a cost, that of an unplayable game without a build allowing others to work directly on the project. I have indeed written a similar game engine a few years back as an experiment, but without all the required subsystems implemented. It did indeed function well.

The message bus consists of a static array to implement the message pool, the hopeful benefit is better cache concurrency, although I have not yet optimized the memory with byte padding or looked at loop ordering, the compiler should actually do this.

Currently I am contemplating how the game initializes and the separate initiation of the engine. I will not rewrite the entire engine from scratch, only the underlying framework an then adapt and merge parts of the previous engine. One interesting issue is how to allow separate systems access to the same resources in memory, I am currently experimenting with sending pointer addresses through messages... Another issue is using an enum to define message types, this leads to each system having to define each enum if a switch statement is used. I could just use nested if statements, but this seems less elegant in design.

Just like a buildings foundation, a game engine provides a solid base to build on, and should not be rushed. It needs to be thought out and planned, if the foundation is unstable or does not support the architecture built upon it the whole building needs to be torn down and a new foundation built, this takes time and thus longer before the building is completed. The game assets are like the furniture, they can be reused, but they takes time to move about and reorganize.

Okay enough sleep deprived babbling…. Below is an early test of the new message bus using a log manager running in its own thread.

Robo Engine Progress. (2015-11-24)

Robo Engine Home
Frost and Flame Home
Project 0 Home
Was thinking about Robo Engine on my break this afternoon, pen and paper in hand.

Initializing the member initialization list. (2015-10-11)


I do enjoy a good bug hunt, and this was no exception.
At first glance it may appear obvious, but it took me over 30 minutes to squash this one.
I do know all about initialization lists, this was not as simple as it appears....
When I first started making games I would just ignore warnings and concentrate on adding features and making the game playable.
Looking back I am not sure if this was a good or a bad idea.
On one hand just completing a game is important for beginners, it provides them with a sense of accomplishment and desire to progress and learn.
On the other hand I have run into some crazy bugs that appear randomly and are hard for a novice to track down, usually memory related like pointers....
These days I am a little wiser, I treat all warnings as if they are errors, add code to check for errors and have more tools in my tool belt like GDB and Valgrind.
I have always enjoyed debugging the hard and obscure bugs, and this one was a fun challenge.

Parsing the XML. (2015-08-20)


Robo Engine can load and render OBJ model files, but OBJ models are very basic and do not allow for animation.
A player character would need to be animated, as well as other game objects, thus Robo Engine needs to support a model format that allows for animation.
After some research I decided on the COLLADA model file format, primarily due to:
  1. Animation support.
  2. XML based file format.
OBJ models use XML, but a very simple layout. COLLADA on the other hand makes full use of many XML features, unfortunately my old XML parser was too basic to fully parse COLLADA files.
And so begins my journey into the darkest depths of XML, don't get me wrong XML is awesome!
As you can see in the image above I can now transverse the basic structure of the XML tree, this after a lot of tweaking to my XML parser.
Next I need to store all the data in a data structure of some sort and find an easy way to access this data.
As with previous file parsers that I have written, I find it easier to debug the parser by writing a function to export the data structure from memory into a new XML file on disk. But I first need to get the data into a data structure..... a nested array of const char*s with an index at each level?

Robo Engine is born. (2015-08-19)


Since I started writing a new game engine for Frost and Flame, as well as writing a game engine for another project at the same time I decided to create a universal game engine that can be used by multiple games.
It is faster to write one universal engine than many specialized engines, as there is a fair bit of code needed for a game engine and reducing code reuse in multiple projects seams like a good idea.
Writing a generic engine also frees up time to work on more than one game, and can be used for future games too.
But since I am starting from zero, it will take some time before any promising results appear.
So far the new engine uses modern OpenGL, can load and render objects.
There is a lot of work to be done, best I get to it....

Does it blend? (2015-05-16)

Home Home Home
Home Home Home
Started working on a new game engine this year, OpenGL 3.3+
As I wish to move Frost and Flame to full 3D in the future I decided to make a few assets to test with.
I haven't used Blender in a while, but fortunately it is like riding a bicycle.
While the new game engine can import and render Wavefront object files ie. .OBJ, I noticed that while useful this file format is rather limited and does not support animations...
After looking at a few option, I settled on COLLADA, it is also an XML based file format, and supports among other interesting features, support for animation.
With added complexity in the model format, comes added complexity in the XML used to encode the data.
I have coded various XML parsers in the passed, but focused on basic data extraction for the data I was interested in, while this approach has served me well in the passed, it is not a universal approach, and fails on XML structure I had not yet implemented in the parser.
Thus my attention now shifts to rewriting the XML parser, but in a way as to parse any XML file, regardless of content.
Well best I get back to the code....

Japanese learning lists? (2015-04-17)


Chatting on IRC the other day about effective study methods, someone proposed keeping a list of words that one is currently trying to learn.
Whilst I have various lists on paper, the though of an application crossed my mind, and I couldn't resist. It still needs some work though.

JLPT Study application. (2015-03-20)


I have had reoccurring thoughts about making an application such as this for many years.
My initial interest was cultivated many years ago when I was just starting out on my Japanese language learning journey.
There are other such applications scattered about the internet, and I am not intending to compete at any level, merely creating an application for my personal enjoyment.
As this application may be beneficial to others, I have decided to make it flexible enough so that others may use it.
There is a simple XML file located with the application "questions.xml". It is human readable and you can modify it to suit your needs.
I may develop it further if there is sufficient interest, or as my requirements change.

Random map generation. (2015-02-19)

Started working on a random map generator to generate maps for an awesome open source game / engine.

Template based resource manager base class. (2014-12-31)


New resource manager for the new game engine I am working on.
Could do with a bit more work, like memory management and recource priority sorting?

Frost and Flame: Going 3D. (2014-07-04)


Frost and Flame goes 3D!
I think from when I first started on Frost and Flame I was already thinking about how awesome it would be if I had a 3D environment.
While I think 2D isometric RPGs are awesome, and I could probably make Frost and FLame into a full 2D RPG, I am more interested in how a 3D world works.
Its not only the cool visual effects, lights and shadows. For me Frost and Flame has never been about just making a cool game.
Its more about learning how to code better, figuring out how to implement specific ideas and algorithms.
Its more of a fun learning experience for me than a desire to create a game.
Although I would like to eventually finish this game, there are still so many challenges I wish to tackle, and awesome worlds I want to make.

OK, so what does it entail?
  1. First is the ground, or base floor. So basically a textured mesh to build on.
  2. OBJ -> 3D textured models, trees, cave walls etc...
  3. Light and shadow effects, campfire / torches etc...
  4. Randomly generated levels / worlds.
  5. MD2? Or the like -> NPC / Player character!.

Seems a long way off at this point....but it will be well worth it once completed!
I am as I write this wondering if I should first create a 3D hard body physics engine first? Easier said than done!
Maybe after the 3D world is complete I will look into a simple 3D physics engine?
I would like to be able to push objects about the world, rolling boulder perhaps? Well let me first spend a good few months creating a 3D environment first before I think too far ahead.....

3D Modeling. (2014-06-06)

3D models: FnF?
I have uploaded these to Open Game Art:
Rocky arch

New new game menu. (2014-05-22)


This month I revamped the new game menu a little. Still need to add the Player name box.
Also added a few more player portraits to choose from.
All the new portraits are by: Justin Nichol
They can be found here: Open Game Art I can't say for sure that they are permanent, but they do look good.

I also worked on the Windows build this month, it currently builds and runs on Windows again, had some great help with testing on Windows 7 from a new Frost and Flame fan, thanks Greg!

There are also some improvements to to map scrolling and buffered string textures too.
Not to mention I refurbished the event and io code, don't think anyone will notice though.
Got about another week till the V0.31 release, so will concentrate more on bug hunting and polish.
If I get some time I will work on the new 3D renderer.

Still haven't decided what features to work on next month, more graphics engine refinements and abstraction?

New Options menu. (2014-04-22)


I spend a fair bit of time clearing out the Frost and Flame git repository.
I also revamped the options menu.
A lot of it was background code, such as getting available resolutions from the system, building the data structures to hold the date etc...
While I was at it I started abstracting the graphics engine, there are now to render devices. The current OpenGL legacy renderer and the start of a new modern OpenGL 3.x+ renderer.
There is still a lot of work to be done to completely abstract the graphics engine, as there are snippets of OpenGL code floating around the code base.
Also the new OpenGL renderer is still along way from completion. I have added the base of the new renderer to the code base, but mostly I am developing it in a separate repository for now, and will merge it into Frost and Flame slowly as it matures.

Variety of item textures added. (2014-03-22)


Through March and also into April, I have deleted many old and low quality / scale textures from Frost and Flame. I have replaced many of them with nice new textures, many of which I rendered from 3D models using Blender. I can't take the credit for these wonderful pieces of art, and since there are so many, I can't list all the authors / links in this post, if you are curious, I have listed their names in the game guide file that is bundled with Frost and Flame. It is also available via the Frost and Flame github repo.

New spell book textures. (2014-02-22)


New spell book textures have been integrated into Frost and Flame.
Credit for these textures goes to: Piacenti
You can find them here: Open Game Art I think he did an amazing job, and there fit well into Frost and Flame.

Experimenting with walls. (2014-1-25)


As I wish to eventually create a 3D environment for Frost and Flame, I have been experimenting with some ideas. I think the first step will be to create various walls so that the current 2D maps can be replaced with 3D maps. Creating the actual model above was relatively easy, the textures on the other had seam to be a little more of a challenge. Next goal is to create a simple wall and incorporate that into frost and flame, one that has been achieved, then more complex and visually appealing models can be created.
  1. Simple "block" walls, brick texture probably, 2 piece, wall and corner, various textures can be applied.
  2. Cave walls.
  3. Castle walls.
  4. Various dungeon walls.
  5. More, variety!
At this point I think it best I rewrite the model OBJ loader and get some models in game, work on texturing the models and some lighting etc...

Frost and Flame V0.26. (2013-12-31)


V0.26 -> (2013-12-31) Happy new year!

UI -> Use 'h' key to generate a random RC cave map.
UI -> Use 'j' key to generate a random M1 dungeon map.
MAP -> Created new map data structure -> FMX.
MAP -> FMX map type to hold room data.
MAP -> FMX map type to hold extended tile attributes.
MAP -> FMX map type to only one collision array.
MAP -> Renamed tile / tileset defines for better code readability.
MAP -> Implemented new random dungeon generator algorithm -> M1 - Maze.
MAP -> Implemented new random dungeon generator algorithm -> RC - Based on random circles.
MAP -> Restructured map generation algorithms into different files.
MAP -> Placed different map gen algorithms in different files.
MAP -> Implemented room generation function/s.
MAP -> Implemented room interconnect function/s.
MAP -> Improved function to check map consistency.
CORE -> Found lingering SDL code/includes and converted to SDL2.
GFX -> Added Hammer_02 texture.
GFX -> Added stairs tileset for testing.
MAP -> Improved BSP generated room interconnects.
MAP -> Vastly improved flood fill based on a recursive algorithm.
UI -> Right click skills to equip them in vacant actionbar slots.
UI -> Enable spell icon overlays on the actionbar.
MAP -> Start of new recursive A* path finding algorithm.

LOC -> 26484

Maze generation. (2013-12-30)


So this week I decided to look into a different kind of procedural generated level, the maze!

I suppose I could just draw a bunch of lines with random length in random locations and come out with a sort of maze like level, but I doubt that would be an interesting maze....
My first attempt was to just use a single function with deeply nested if statements, this approach worked with some success.
But I was not pleased with such an implementation, it was more of a proof of concept than a final design.
So I set about creating a recursive function to call itself for each of its neighboring tiles who met the requirements, basically neighboring tiles that had not yet been explored, basically....
This approach is a lot faster to generate a maze, but at the expense of a little more memory, (during generation).

Next step is to add some rooms to the maze!
And then final integration into Frost and Flame.
Hope to have it done before next year!

Random Dungeon Part 3. (2013-12-07)


I decided to create a third random dungeon generating algorithm for Frost and Flame.
I feel that this generator produces some nice looking maps!
The main challenges were to connect the rooms in a meaningful manner and also to check for disjointed parts of the map. But overall I am rather pleased with the final outcome and look forward to playing maps based on this algorithm in the future.
Next I am thinking about using some path finding to add strategically located stairs to the maps.
Or to go back and improve my previously implemented BSP dungeon generator.

Flood fill. (2013-12-04)


As I have been busy at work on the random dungeon generation once again, I have started implementing a new dungeon generator. There will soon be three unique dungeon generators to choose from!
On of the challenges faces with when building a random dungeon generator is building dungeons that are connected, and fully accessible by the player character. Could you imagine a map with a disjointed room that is inaccessible to the player, it could spell catastrophe if the exit to the map is located in a disjointed room, or imagine the players frustration upon seeing glorious loot that was located in an inaccessible location.
Thus the need for some code to deal with making sure the map is accessible.
I decided to implement a flood fill algorithm to take care of this for me.
The first iteration worked, but was a bit more code and then I small moment of genius, and instantly thought of a better way to do it via a recursive function. The latest iteration uses a less code and is more efficient, I could even remove some of the code, such as the 'adjoining_tile' parts, which I think I will do....
This brings my goal of enjoyable, procedural y generated content maps one step closer.

Frost and Flame v0.25 released. (2013-11-30)


Quite a lot more work has gone into the UI again this release.
I focused more on The skill book and implementing the spell icons.
Whilst you are unable to currently cast spells in Frost and Flame, the UI side of things is for the most part complete. I am still considering what spells to incorporate and will add more spells in the future, also some of the current spells may be removed at a later stage.
A few more higher quality textures have been added, and I will remove the lower quality ones in time, once I have enough higher quality ones.

The UI is looking almost complete, and as such I will start shifting my attention to the actual game world in the near future.

Spells! (2013-11-15)


First spells have been implemented!
They can also be socketed with special gems, as well as slowly level up over time based on usage.
These are not the final spells to be implemented in Frost and Flame, as with everything else in the game they are subject to change. And they most likely will over time.
Once I have implemented some actual game play, then these can be balanced and changed to better fit the game.
But it is nice to finally have a visible and interactive skill book.
It took so long to get spells re-implemented due to all the underlying work that I was busy doing on the UI these past months.

Frost and Flame v0.24 released. (2013-10-31)


Time for a new release of Frost and Flame.
Frost and Flame V0.24 is a huge release, a lot of code changes and some of them being visible changes too.
Frost and Flame grew by almost 5000 lines of code this month!

I finally completed the drag and drop part of the UI.
With most of the UI completed and working, I decided to overhaul the text rendering side of Frost and Flame.
The visual improvements to the text are rather notable, as well as other non visible changes.
Text can be rendered to a texture and stored for future use, speeding up text rendering in some cases.
The code now allows for text to be rendered via a positioning flag passed to the texture manager.
Text / textures can be rendered from the left, centered, form the right, above or below a position, these flags can be combined to achieve text rendering such as bottom right, top left, etc...
Other changes in this release include a few UI item sounds, now moving items about the UI, items have their own unique sounds. (most of them at least, so far.)
A few more item icons have also been added. (gloves?)
Notable changes:
  1. New text rendering system.
  2. Completed the drag and drop implementation.
  3. Stack-able items, showing quantity.
  4. Item mouse overs.
  5. Item move sounds.
  6. A few new item icons.
  7. Random gems.
  8. Socket-able equipment!
  9. Randomly generated items.
  10. Re-rendered the potions at a higher image resolution.
A lot of work on the UI went into this release, the UI still needs a bit of work, such as spells. The last few months most of the work went into invisible parts of the game.
After refining the UI a little more I plan on working on a different part of Frost and Flame, the game world!
So Frost and Flame should be interesting to watch, might wait a month or two and work on the UI, items and spells for a little bit longer though. As always, it all depends on how much free time I have available.

A* Pathfinding. (2013-09-20)


I decided to take a break from UI work for a while, I have since been thinking more about implementing the A* path-finding algorithm in Frost and Flame.
After implementing this I can return to random map generation and implement things like optimal stair placement, or locked doors with user reachable keys, or strategically located loot or gangs of NPCs, etc...

This implementation will also prove useful later in development when implementing the player character and NPCs.

So far I have created a small console application to test different approaches to this algorithm, and also for optimization before integration into Frost and Flame.
I am not using the same map format as Frost and Flame during testing, I created a very light map format for testing. Although I am using a similar pointer based approach as found in the code for procedural map generating. I am also taking my own approach to this algorithm's implementation, I wont be creating separate lists of tiles, nor will I be using any specific memory for the tiles in order to determine paths between them.
I plan on having the map store a few extra variables for path-finding and reusing them each time a path needs to be found. This will also cut down on memory allocation / de-allocation for each path finding call.
With regards to performance Vs Memory, this approach should perform well with a possibly slightly larger memory usage than traditional approaches to the implementation of this algorithm.

I have since completed the final algorithm, and have thus started integration into Frost and Flame.
At this point the path is not yet returned, only calculated.

UI processing. (2013-08-25)


A few months back I started on a complete re-write on the UI system.
For the most part it is complete, uses less resources and is more responsive and flexible in design.
The first major hurdle was the creation of and management of a simple database of UI forms.
While this system is now in place and functioning correctly, it is possible that the render and processing systems are using the database incorrectly, as they both need to transverse the database from different angles.
Another and the primary issue at the moment is the processing of the UI forms themselves.
The current implementation handles the entire UI processing in a single function.
While this was a practical solution to begin with, its size and complexity has evolved into a difficult to manage function. Whilst thinking about it further this evening, I came to the logical conclusion that I have to break it down into smaller more manageable pieces in order to have code that is easily manageable in the future.
I am still contemplating the exact approach I will take. Either have the main processing function call smaller functions, or create "code blocks" within the function and label them appropriately.

Summer progress. (2013-07-21)


July has not been the most productive month for Frost and Flame. Some reasons being:
  • As it is July summer has arrived, and with that comes the summer holidays. This means I will be working for a few days away from home, and also without a computer.
  • But not only that I have also built myself a new computer. This is awesome, and I am now using Linux exclusively. The transition from one OS to another, and a new computer in general is time consuming. There is a lot of data to transfer and sort. Finding replacement applications, etc... But as can be seen from the picture above, Frost and Flame is now building in 6 seconds, definitely worth the upgrade!. Now developing on a 27" monitor, so I can see a whole lot more code at once which is very helpful. Even though I will be developing on Linux from now, I still plan on releasing Windows builds.
  • Life has also been busy recently.
What has happened this month with Frost and Flame is actually not much, the UI and Item manager are both in a state of change, with commented out code and half implemented ideas... It has been hard to find a moment to actually sit down and write some code this month. Hopefully next month I will have a week off work and some progress can be made.

Frost and Flame Version 0.20 release. (2013-06-30)


It is the end of the month and time for the release of the latest Frost and Flame build. Highlights this month:
  1. A lot of work went into the UI manager.
  2. Some work on the upcoming item manager.
While I don't feel a lot of progress was made this month on the game itself, I did a fair amount of thinking about how to implement the new item manager. Most of the work on the UI manager was to rewrite the actual UI manager itself, but no all the UI components that it uses. The new UI manager is more flexible and memory efficient. Although most of the work on the UI manager is completed, there are still a few lingering issues to tackle.
  • UI list sort has issues when the the window to sort is already at the top of the list and its neighbour is also active. I am pretty sure I will resolve this before the next release.
  • Item interaction is not yet implemented, mostly due to my plans to rewrite the item manager first.
After the UI manager has been completed, I plan to forge ahead on the new item manager and have it fully implemented soon, hopefully before the next release. After these tasks have been completed I may start looking into a 3D environment? But that is undecided and I best complete the current tasks first!

Item management. (2013-06-27)


The above image shows the current state of the item manager class.

I haven't written much code this last week, mostly due to life.
But I have a feeling that I might have some free time this weekend. I have been thinking a bit about the new UI manager and how it will affect items within the game. As the Item manager is a bit dated I feel that I will just delete it and write a new one. While is probably trivial to code, its the inter workings that need more thought. I could just have a static array of items referenced by Id, but then I am limited to a hard coded number of items. I could have a linked list of items and just add to it on the fly, which is probably the route I am going to take. While I am definitely planning the implementation of randomly generated items, they will be easy to add later.

But still questions and choices persist:
  1. Should I hard code some items like health potions? Or hard code all items? Or load some from file, or load all from file?
  2. Should I allow for unlimited item effects or sockets? Or hard code a maximum value?
  3. Should I allow for items to be modifiable during play, such as adding sockets, and / or effects?
  4. Should socket items be socketable? :O (Segfault waiting to happen!) Imagine placing a gem in to a gold nugget's socket,and then placing that in to a shield's socket...etc... (O_o)
  5. How would it be best for the UI manager and item manager to interact?
  6. How should I manage item effects? (O_o) Have a separate effects manager that works the same as the item manager? Or integrate them? Its not the complexity of the code that bothers me its the efficiency and extensibility of the code.
While there are definitely more questions on this topic, these are the current ones floating about in my head. Might have to whip out some paper and crack open my pencil case this weekend. I really should get myself a whiteboard!

Sorting the UI list. (2013-06-17)


With the creation of a new UI form management system, I went with a doubly linked list to hold the UI form data and pointers to the two adjacent UI forms in the list.
I initially decided I was going to sort the list by rearranging the pointers of the UI forms as I iterated through the list. This sounds easy in theory, but when it comes down to writing the code... well it is a bit more difficult.
I do like a challenge, and I could probably get it to work eventually. But when moving a lot of pointers about just to sort one item in the list, our good friend the segfault is sure to be lingering for those unsuspecting rare instances that only appear months after implementation.
I then decided to take the easy approach, instead of moving all those pointers I would just swap the data for each IU form about. Although this is way easier, I was trying to avoid this approach due to the amount of data I would be moving. But then I realised that I am not sorting the list on every frame, I am actually only sorting the list when the UI manager pushes an event to evoke a UI form sort, which is not very often.
At first glance I noticed that the data was not easily swappable, because of its fragmented nature within the UI form struct, so I made a sub struct in the UI form struct to hold all UI form data. This required around 7000 lines of code to be changed, I am really grateful for the "search and replace" function in Code::BLocks, without which it would have taken a whole day to complete the change.
Basically UI_form->foo now becomes UI_form->data.foo etc...
Having the data in a single struct makes it very easy to swap about, hence the very simple method in the picture above that shows the new list sorting algorithm. Thats like only 20 lines of code. :)
Well now with that piece of of the puzzle in place, it is getting the UI manager to push list sort events when appropriate, and then on to other more visually exciting ideas that are on the todo list.

This month I decided to do a little more work on the UI.
Initially I was only interested in completing the intra window drag and drop.
But as I tweaked the code and battled with the limitations of my implementation, I decided to delete my entire UI and code it from scratch. Good idea or Bad idea? I am still contemplating that thought.
Well the previous approach relied on two arrays, one massive array holding arrays of all the window and element data, and then another array holding ID's for the windows.
Whilst the first array was permanent and then referenced by the second array. The second array was then sorted according to the processing / rendering order of the windows, with recently accessed / activated windows bubbled to the top of the list. While this approach did work well, it had an issue of windows changing location whilst items were being dragged about, and then determining where the items came from and where they were destined to go became an issue.

So instead of working around the limitations of my previous implementation, I decided on a fresh approach which hopefully will solve some of the issues encountered in the previous implementation. I decided upon using just one doubly linked list. So each 'item' in the list holds a UI frame and it's accompanying elements, as well as two pointers. One pointer points to the next 'item' in the list and the other pointer points to the previous 'item' in the list. This approach allows for bidirectional transversal of the linked list. One application of this approach is that I may process the UI_frames in a forward order, but then render the UI_frames in the reverse order.

So far I have re-implemented the entire UI, except for the correct sorting of the stack and processing priority based on UI_frame positions relative to one another.
I should have this sorted out by the end of the month.

New UI_Manager. (2013-06-09)


This month I decided to do a little more work on the UI.
Initially I was only interested in completing the intra window drag and drop.
But as I tweaked the code and battled with the limitations of my implementation, I decided to delete my entire UI and code it from scratch. Good idea or Bad idea? I am still contemplating that thought.
Well the previous approach relied on two arrays, one massive array holding arrays of all the window and element data, and then another array holding ID's for the windows.
Whilst the first array was permanent and then referenced by the second array. The second array was then sorted according to the processing / rendering order of the windows, with recently accessed / activated windows bubbled to the top of the list. While this approach did work well, it had an issue of windows changing location whilst items were being dragged about, and then determining where the items came from and where they were destined to go became an issue.

So instead of working around the limitations of my previous implementation, I decided on a fresh approach which hopefully will solve some of the issues encountered in the previous implementation. I decided upon using just one doubly linked list. So each 'item' in the list holds a UI frame and it's accompanying elements, as well as two pointers. One pointer points to the next 'item' in the list and the other pointer points to the previous 'item' in the list. This approach allows for bidirectional transversal of the linked list. One application of this approach is that I may process the UI_frames in a forward order, but then render the UI_frames in the reverse order.

So far I have re-implemented the entire UI, except for the correct sorting of the stack and processing priority based on UI_frame positions relative to one another.
I should have this sorted out by the end of the month.

Frost and Flame V0.19 release. (2013-05-30)


As it is the end of the month, it is time for the release of the latest Frost and Flame build.
A lot for work went into this release, but mostly under the hood:
  1. Completed random dungeon generation. (use number keys in game to test)
  2. New Texture manager.
  3. New Sound manager.
  4. New Font manager.
  5. Added a command line parser.
  6. UI -> Initial item interaction.
With all the code changes this month, an added benefit is lower memory and CPU usage.
I think that over the last year or so not much has changed visually within Frost and Flame, there is actually less functionality and features in Frost and FLame now that that of a year ago.
But, the code base has undergone many overhauls and rewrites. Frost and Flame is now stable, and no more compiler warnings, I may have taken a step back to re-write and fix all those nasty bugs, but in the long run having a solid base to build on is far better than a game that crashes intermittently, and segfaults as it pleases.
I have also started using Travis CI - A hosted continuous integration service for the open source community.

Performance increase for V0.19. (2013-05-23)

After completing the new texture manager yesterday, I decided to use the same approach for the management of sounds and fonts in Frost and Flame.
So I started a new sound manager last night based on the new texture manager.
When I got home from work today I completed the new sound manager, and also implemented a font manager and integrated them both.
The performance gains are astonishing! Not only does Frost and Flame use about half the memory, it is also more CPU friendly too!
Under the hood I decided to go the route of using a simple linked list for a data structure. The linked list stores the data, and returns a pointer that is used by game elements to access the data.
If a game element tries to re-add the same data, the manager checks to see it is already in the list and returns the pointer that was previously assigned.
Even with this approach Frost and Flames loading time is decreased significantly.
The initial texture manager that I implemented in Frost and Flame used a large struct of variables defined for each resource....while this worked rather well, adding resources was tedious and inefficient.
The second approach I took to resource management was in the form of having each game manager / element manage its own resources, this led to a lot of duplicate resources being loaded.
The only advantage to this approach was that different game components could load resources on demand, but managing that process was also tiresome to implement.
So far the new resource managers seem to have solved many issues with regards to both complexity in their integration and use.

Frost and Flame V0.18
Frost and Flame V0.19
As you can see it took a lot of code changes.
But definitely worth it!

New texture manager. (2013-05-22)

Against my better judgment I went ahead with the creation of a new texture manager for Frost and Flame.
I have been thinking about implementing a new texture manager for some time now, and this week I had a good idea on how to implement it.
Only problem is that it is too close to the end of the month, and that being the date for the release of the next version.
I didn't really want to implement something of this scale without having enough time to iron out any bugs.
But as I am currently working on inter-window drag and drop, I need some items to test with.
With that goal in mind, I started to add a few items for testing purposes only to realise that the longer I postpone implementing the new texture manager the more code I will be adding to the game that will be in need of changing when it is finally implemented.
So I have gone ahead and implemented the new texture manager, it entailed a lot of code changes, and has unfortunately introduced some new bugs.
For the most part all systems are working well, almost the entire UI. Only when moving UI items is there an issue. But the biggest issue I have yet to resolve is the rendering of 2D maps.


Drag and drop. (2013-05-14)

Decided to make a short video to show some of what I am currently working on.

1. UI drag and drop integration:
Took a while to implement this due to unforeseen complexities within the new UI framework.
Currently drag and drop within a window works correctly, but there seems to be intermittent instances where drag and drop does not work correctly with regards to inter-window drag and drop, I expect to have this ironed out in the next release.
Further improvements and support for various item types is due for inclusion next. But I may improve the item manager first so as not to introduce a bunch of items that are incompatible with future code.
2. Random dungeon generation is also visible at the end of the video. I will include the test key bindings in the next release or to for further testing. Keys are 1,2,3,4.

Random Map Generation. (2013-05-06)

Looks like I have completed my goal of randomly generated maps.
They can be used with 2D tile based maps, and the underlying algorithms used to generate the maps may also be used in the future for 3D maps.
I will come back to random dungeon generation in the future, to improve maps with items and entrances and exits.
Maybe early next year? My reasoning being that I plan to write a path finding algorithm early next year, which will be used to place items strategically.
My focus has now shifted to getting drag and drop to work in the UI so that items can be implemented.