Return to Gruedorf

The gruedorf site was down for like a week and without a timer to nag me I simply didn't care to update this thing. But that's all in the past.

Updates or not, plenty of progress has went down. In short summary the current build of the game lets 4 players connect together using a simple gui, walk around the map in a turn-based fashion, and chat.

That was completed weeks ago. More recently I have been churning out technical documentation for the battle system's mechanics and designing how the main game plays out. More recently I took ikaDB out of the attic, ripped out its dependencies on iked (since ika in general is now dead), renamed it to GameDB (I need a better name), and have begun to spruce it up a bit for this project.

The first improvement I've made is caching the GUI for models. More specifically: wxpython (or possibly the database itself) is really slow at generating the GUI for each model, so I added caching the generated model GUIs at start up so the interface is much snappier now. Unfortunately I couldn't make it cache modal pop-ups for add/editing sub-models due to how wx works, but those are used less frequently and they cache after the first instance so it's not too bad.

Next up is revising the GUI for its new standalone format, fixing up the bugs I encountered while working on Hydration 2, and trying to speed up the underlying DB access (presently it's too slow to use in real-time, you basically have to load the entire thing into your game at start-up, and that takes a few seconds. I hate this and want to fix it. I'm not sure of the underlying cause yet.) I'm toying with the idea of a public release of GameDB since it would be useful for virtually any game written in Python, but there's a lot of nasty gunk in it I'd want cleaned up before a public release.

aaaaaaa

Some design doc work was done. That was it! for reasons beyond my control.

Find Path

I got the beginning of pathfinding done but there's still additional work to be done on it. Then I realized my planning was insufficent to determine how to connect the dots so I went back and started expanding the design doc for the code. And I am still doing just that. A poor week.

Bugs, bugs, bugs

My goal for the week, after some soul searching, was to get sprites working. That goal has been mostly completed.

It's partially due to my inexperience with it but so far C++ is like working in sludge since virtually every additional piece of functionality I add gets a bug/flaw associated with it that takes an hour or more to fix before I can move on to the next thing (hello thar manual memory management). Hopefully that becomes less plentiful as I get used to it.

Questionable time allocation

So I swapped out CEGUI for MyGUI, which took a lengthy amount of time to do. I'm somewhat second guessing that decesion since it's even worse documented than CEGUI was, though it makes up for it with a better toolset and working in a way I prefer for the most part. I also brainstormed some means of dealing with sprites. I am not particularly pleased with this week's progress and I kind of wonder where my time even went. Such is the curse of a broken sleep schedule.

Untitled

-Messed around with the general architecture of the map engine to support multiple maps at once, among other things.
-Added mouse click detection (extra fun in iso) and various tile setting/coordinate converting utility functionality.
-Began making CEGUI and SFML cooperate. It's working fine! Just need to learn CEGUI now.

I was originally planning on offloading most of the game logic to python, but after looking in terror at the embedding guides I'm probably just going to write most of it in C++- though I may end up revisiting python integration to a lesser extent much later on.

land grouping screen display

I guess it's some isometric map engine written in C++ using SFML or something.



It has zoom functionality as well I suppose.

More details laaaaater.