Dragontorc MS4

Although few things I'd like to change, I decided to close MS4.

In this milestone I created new rendering system (using SDL surfaces), room interior generation (more on that later) and simple travel system.

All graphics is temporary - programmer's art. And looks awful :)

As I decided to switch to C++, it may take some time until I convert everything to C++. And I have no idea how long this will take. And...

I'd like to try something else for some short time, experiment a little bit with procedural generation. I am not that happy with what I have now for room generation and as I'd like to make it proper and to use procedural generation for much more things, I will try something else (to not fall into same mistakes) and I will be updating here to show results.

Weekly update MS04x35

I couldn't do too much during last week (weekend was "lost") but I still did few things that I am really happy about. Of course those were related to porting to c++ as I was sucked in by creating basic systems to be able to port whole code to c++. But boy, it was fun!

I have arrays and lists. I have some concurrency mechanisms, own thread management (threads without affinity masks set up), own immediate job queue system - I have immediate jobs queue and I want to add async job queue and a helper class that will support multiple queues with priorities. I'd like to make it work on as many cores as possible with basic separation into:

• main thread (responsible for adding tasks for other threads, that will also do single threaded immediate jobs and all other immediate jobs)
• rendering thread (will only do rendering and maybe some immediate jobs and/or background loading)
• background tasks thread (will do background tasks and will load things in background, and do immediate jobs if nothing else to do)
• immediate jobs threads

With such approach, I will have one thread doing rendering. One thread for single threaded immediate jobs (all physical activity that can't happen at the same time as other systems). One thread reserved for background tasks (it shouldn't happen very often and loading should go there, but on more cores I could have more background task threads and separate background loading thread(s)) and all other threads for immediate jobs (AI/logic, animation system, particles). And I want to pack everything together, so at any time there won't be any idle thread. I need to come up with list of jobs (basing on what I wrote above) and priorities for all threads.

And of course I want to make it possible to run on single thread too, as it will be easier to debug stuff and some computers may have just one core.

When creating code in vala I was already thinking about parallelization and I made clear separations in as many places as possible. With vala I could still do same things but it would be slower (in execution), it would be much harder to debug and I would have to add mechanisms that vala doesn't support by default and would introduce some mess into the code (there's no easy way to do pooled objects, not as easy as in c++).

For now I would still like to do missing bits (async job queue, job execution class) but I am switching back to vala to add things that are missing for this milestone.

Weekly update MS04x34

The plan was to finish MS04 and then start porting to C++ but on the weekend with few hours to spare I started to implement some stuff (and reuse those that I've already written few years ago) that I will need for C++ version. Then of course I will spent at least few weeks to port everything. But you have to believe me how much difference there is between writing code in notepad++ and in Visual Studio. And to debug it. And now I even have stuff to detect memory leaks which should be handy to keep an eye on what's going on in the code. I could spend lots of money to have proper Visual Studio (not Express Edition) and Visual Assist X but now I can live without them. Although I tend to try to open file with alt+shift+O, go to definition with alt+G and try to do few other things that are so obvious and natural to me now. When I think of writing code, compiling at command line and wait for it to compile few minutes... No. And of course with some fundamental changes in C++ I may wait a lot too, but just minor changes should be quick.

I still want to do few things (implement pool, list, xml loading) and that should be enough for now and I'll get back to Dragontorc - now, with my recent hook I renamed it, but as I am still not sure about new name, I will keep on calling this game Dragontorc - have no worries, there is still wizard, servant, items and magic. 

Weekly update MS04x33

Or rather lack of updates. There are lots of things happening at the moment and while Dragontorc is on top of activities that I don't have (or really want) to do, this means, that for last 3 weeks I haven't done almost anything except things that I had to do. Well, few times I watched something on TV. Once it was polish edition of "Whose line is it anyway" which was quite good and I also watched something else that I don't remember. Oh, and I played Tau Ceti for 5 minutes. Those were extra things that I really didn't have to do neither I really wanted :)

But back to Dragontorc. I am considering quitting my current job at some time in future (not until current project is finished) to focus on Dragontorc (and probably something based on it, as I won't make much money on remake of forgotten game. probably). First, I'd like to save some money to make it possible for my family to live for at least one year without any worries.

Weekly update MS04x32

Even if I have crunch, I decided to do something every day. And I did. But stopped at weekend and during this week I have to focus on refitting kitchen (because we want to do this before baby comes to the world). Anyway it was a little bit crazy, 10-11 hours at work, couple of other things happening and then working on Dragontorc 1 to 3 hours until 2 or 3 o'clock in the morning, but I did some very important improvements to room generation. There are now priorities for links/connectors so it is easier to decide how bigger spaces are filled with pieces. There are attractor anchors that should help with placement of doors and some pieces on the grid. Why?

I was looking at original Dragontorc and trying to figure out how forest and stone henges were done and then I realised that every graphic piece has same width, but while pieces in my game can be liked that, doors are added on top of the pieces in any place so with my current system I was not able to generate forests or stone henges similar to original ones. But then I thought that I can place doors only in certain points - in the centre of existing pieces. And to not have trees on pathways, I can place trees afterwards as additional decoration. That I had in my plans, to have additional pieces as final decoration - pictures on walls, pegs sticking out, bushes, etc. I also did some improvements for displaying pieces and started to add forest, but I still need to test decoration pieces for floor and ceiling. This can be great to have vertical doors placed above skins laying on floor, holes in floor aling with cracks.

Probably without crunch and when refitting is over I should be able to speed up things. And word about crunch. I agree that it is exhausting but when I read that some game devs resigned from work after they had to crunch for less than a month for 10 hours during weekdays, I have no idea what to think about them. I crunched many times. Sometimes it was 10 hours a day Monday to Friday for week or two. Sometimes it was Easter spent at work (except for Sunday). Sometimes it was 30 hours straight. Sometimes it was more than 12 hours a day Monday to Friday and 10 hours on Saturday for 3 or more months (and then game didn't sell all that great but wasn't flop either). Sometimes it was because someone miscalculated how much time we need or things were changing but to hell with that. Crunch happens. If I will be going to release my own game and I will want to have that final push to polish things out, I will crunch. And crunch bonds team. But if it is possible, people should not crunch, because many times it is due to fact that someone made wrong decisions. But sometimes it is better to crunch for two weeks once in 3 or 4 months than to have one long big crunch period.

Alright, now let's get back to Dragontroc. What I have and what I miss? I have forest without proper trees. I have travel without moving obstacles. And that's what I still want to do. And I will do it as quickly as I will be able.

Weekly update MS04x31

I'm back!

I was thinking a lot about what I want to do in the game and how. And I came up with story lines/scenarios and dialogs. Yes, I'd like to add some (rather simple) dialogs to enhance story in game or rather, how players experience the game.

And just after coming back I did a little bit for travel system. Simple travelling is almost done. I only need to add option to harm player (although I'd like to avoid that, leave travel as just travel that takes some time but is only a break between segments of game) and some obstacles. I'll leave other bits that I want to have in simple travel for later.

What's next besides that? I want to add few things for room generation to make it possible to generate forests. And that should be last thing for this Milestone. Afterwards I will port it to C++ to allow faster iteration and debugging (and make it more portable).

Other plan is to do at least a little bit of work every single day.

Okay, let's do this!

Weekly update MS04x30

I decided to push a little and for three days I was working on Dragontorc for 2-3 hours starting at midnight. I'd rather not do that, especially that I had to wake up in the morning and be at work at 8-9 o'clock, but I really wanted to push travel system forwards. And I did. And it took more time than actually needed due to lack of debugger. Catching random crashes with logging tool, when each compile takes so long is annoying me more and more. And I can't wait when I finish this milestone and I start porting to C++. Yes, this will mean that for some time there will be no new things. But this will eventually speed up development greatly.

And when I took a look and my MS plan, I realised that main features of game are planned for 8 milestones. Which means that with his MS complete I will be half way through! And systems that are left are not so time taking as those in MS3 and MS4. There of course will be still actual game left to do, but that should be a little bit more relaxing.

I am writing this on Friday, as tomorrow we are going to wedding and on Monday to seaside. Travelling for few hours. And as we will be travelling, here you have screenshot of Maroc.

We'll be there for two weeks and as I will have very limited Internet access (on my phone), I won't be posting anything here for two weeks.

See you.

Weekly update MS04x29

Instead of doing actual travel, I focused on some work behind it, that will be needed anyway. I simplified and unified few things. I didn't do more, or at least that what I wanted - looking for hospital, dance lessons, shopping for vacation, arranging kitchen refitment.

And on Monday we're going to seaside. To the same place as last year - without electricity. I will do some designing, maybe define some quests and check what do I need to implement them.

Weekly update MS04x28

No update.

Well, I was working on digitally signing documents that I wanted to do for our book-keeping app. And all I can say is that solution for that is unnecessarily overengineered. Why?

1. XAdES is a way to have digital singature of any xml document. Fine with that. It protects against modifying data in sent document, timestamp, signature itself etc. If you modify (almost) anything in document to be sent, it will fail veritifaction. So that's good, right? Well... It doesn't give any extra security and as documents that are sent are just info about tax being paid and such stuff, no one may care about it that much. Timestamp? (that is part of XAdES BES, not pure XAdES) What for? You can put anything you want there and only if someone would like to modify it, it would be impossible. But in the end, only thing that matters is when it came to the system.
2. My second issue related to XAdES is that it is standard, right? And there is no easy out-of-the-box solution for it. There are classes in .NET that allow signing documents but they are dead end and what you really want, is to go through XAdES documentation, learn a little bit about crypting and write your own implementation. For something that should already have open source, available to anyone implementation. Why do I think so? Because lots of people will waste their time on doing exactly same thing. There are strict rules that you have to follow. Input and output are defined (well, without some omitable details, like form of some "id" tags) and everyone that will be implementing that, will waste their time. Even if that would be just one hour. It took my few hours, but I haven't done anything like that before. It would work as a charm if only...
3. Actual digital signatures. I knew a little bit about RSA keys and cryptography in general. And I though that if you have proper certificate installed on your machine, there are tools, libraries and stuff to make it possible to use that key/certificate to sign any data. Without accessing any data inside that key/certificate. To make key/certificate work as kind of service and make it harder to abuse it. Right? No. Keys and certificates that you can access using simple methods are useless in real world according to some people. Just having RSA key generated is not enough and I'm partially right about that. You can easily copy private key and abuse it. That's why private keys are stored on devices (like you wouldn't be able to copy it from there) or on other computers and you only send data there to be signed. That's fine right? But what about implementing all those various solutions? From what I could find withing given time frame - there is no information how that can be done or even if it should be done like that. I really thought that there is some API that is part of OS, that you tell to sign some data and it is done by stuff installed to OS. And maybe there is something like that, but I couldn't find it. Diversity is good but when it is controlled a little bit, when there is common ground and you don't have to handle everything separately. Then it may be disastrous.
4. And most annoying thing about that is after initial boom for digital signature, our government decided to make it easier for people to sign their tax forms and more of them can be signed using data from previous years. You just put at the end of document information about how much have you paid one or two years ago. Why did they do that? I'd say that they've seen that there are more problems with current system (XAdES + various solutions to compute signature) than benefits. I'd say that they could centralise signing system but then someone (well I know exactly which company that would be) would win the contract and we would have to wait couple of years for it to work properly. On the other hand, digital signature market is not so open, as you have to be certified and you need to comply to various requirements. And... some companies are withdrawing now from providing digital signature.

That's it. I will continue working on digital signature quite soon, although I'd like to do sending invoices in PDF format by e-mail, but now I want to do few things for Dragontorc. Finish simple travel system and finish this milestone. And start porting to C++.

Weekly update MS04x27

Alright! Many new ideas. Big and small ones that I write down every day.

I did some more work on travel system - I added hubs and "empty" travel. I wanted to do simple travel last week but during weekend I haven't done anything (well I worked a little bit on book-keeping app and idea of creating standard and requiring everyone to implement same thing, instead of providing general solution as open source code is just something that I will never understand). And before weekend I added filling rectangles for foreground/background/horizon planes. Now, even though they share same pieces, by using different colour forest and castle look and feel different. I also fixed few minor things.

Tomorrow I am going to court and I thought about doing some coding today, but I'd prefer to relax now.

What are my plans? Create simple travel and do everything that is required to be able to add forest. And then add forest itself. After that I should finish this Milestone. Then I will start porting to C++. This may take some time but as I already wrote, this will speed up things and give more options in future. And I will be able to fix some things - rename some, reorganise, etc. Why? Because I just can't have too many "event" things ;) And there are few more. And some spelling mistakes.

Weekly update MS04x26

I implemented travel system, but I want to change few things within it. At the moment there are travel regions with places inside. Each place contains rooms. Any room may have travel links. And travel links connect to other travel links by means of travel routes. I first wanted to keep it this way and add extra functionality if there are more travel routes for one travel link, but decided to keep it more flexible and add travel hubs. This is plan for next week. As well as adding simple travel (based on original games). Somewhere in future I'd like to add cutscenes, tunnel travel (with rendering similar to one that was in Narco Police) and few other travel systems.

What else have I done during past week?

Finally there is player class that handles input and rendering and I want to remove all "debug" methods that are now used to handle input. Player class is also connected to how adventure is advanced, allowing just one place to be advanced at same time (which will change to advance other places sometimes, less and less and then stop advancing them at all).

I also reorganised few things within modules, as there was some mess and projectile modules were initiated in different manner that object (actor/item/servant) ones.

And I had few other things that were drawing me away from this. Last weekend I was writing down transcripts from video that I plan to use in court. Which means that next weekend I will be preparing myself for And this weekend I will be preparing for trial.

Weekly update MS04x25

I started to work on travel system, although big part of that time was spent on thinking what do I need and how to organise things. But as everything I wanted, I have designed, I am going to implement one variant of travel (similar to one used in original game) without UI that might be optional and more useful in other variants.

Travel system might be also used for streaming or on-fly generation of world. But this is some optional future feature.

Ok, this is going slowly sometimes, but still - every day I write something for Dragontorc, I realise that I am working on it for more than two years and I still want to work on it and finish it. And every, even smallest thing, makes me closer. Yes, there are some things that were unforeseen, but most of them are just details.

Weekly update MS04x24

I've finished working on vertical doors today. I couldn't do much in last two weeks and most of work was done during this weekend. And few hours I spend on finding some crashes and asserts. And it makes me want to switch to C++ more and more.

Word about vertical doors. At the moment I haven't done doors that open and I probably won't as just holes in ground is enough. One huge improvement from original games is that it isn't enough to touch hole to fall into it. As soon as character stops over hole, it will be sucked into it and slowly move down for a while. This should help to prevent situations in which someone didn't plan to enter hole. And it works fine now.

For this milestone I planned travel system but before I do that, I want to add some shadows first.

But before I do that, I have to do few things with other app that are in my backlog for way too long :/

Weekly update MS04x23

Prague is a beatiful place.

I was coding there, a little bit. But instead of doing something useful, I was fixing few bugs that I run into when compiled under Linux. And it made me think about few things. While vala is nice language and probably amazing when doing stuff with GTK, it might not be proper language for what I do. I was considering switching to C++ at some point. Mostly to make it possible to release game on more platforms. And while it was some distant point in future, after spending way too much time on finding bugs mostly because instead of using proper debugger I have to use gradma's logger, I decided to do this after I finish this MS.

This should help a little bit. Debugging, faster iteration. On my netbook, that I brought with myself to Prague, compilation time was almost 3 minutes and there's no incremental compilation. I could seperate everything into libs but I would still be missing debugger. I heard that someone managed to make GDB to work with vala but that was some time ago and support for it was dropped. Visual Studio feels to be great choice to work quickly. Then, if it all works, I might try GCC and then linux builds and other platforms (luckily or maybe thanks to experience mine and other people, all my code that requires specific platform is kept in one place).

Other things - I have some nice ideas for Dragontorc and also for my next project that will use same engine.

And more news - after I started to work at new place, I decided that I really need to push Dragontorc and plan is to finish features I really want to have and try to get demo version by the end of this year. It will be shorter game and probably free. And it should present most of engine features I want to have in game.

Weekly update MS04x22

Last week was full of random events and some of them I shouldn't write about here or anywhere else. Most important thing that I can write about though, was me starting new job. Well, technically it was this Monday but as I shift sometimes and write those updates on Wednesday or anytime else, I will be trying to write about everything that happened since previous update.

This change also made me think, what I am good at, what will be my future, near and far. I realised that I have quite good knowledge about game engines and various subsystems and with that realisation, came another. Whenever I go, I will be working with similar people (talented game enthusiasts, programmers and artists, writers and designers) on similar stuff (animation and gameplay). And that's it. My other options is to do games on my own or to do something completely else (like programming, but not games). But then - I really enjoy what I do and I am happy with changing my job, even my first days always make me feel not right. That was always happening, whenever I changed job.

And back to Dragontorc. That was another, more important and bigger relevation. I really want to finish it and release it. As I enjoy working on big games, "it's all the same" feel is quite strong, even if game is completely different, engine is different (but shares many ideas), etc. Hell, even my own engine that I write for Dragontorc is very similar, although it is small 2D game.

And as I played "War Thunder" yesterday to relax, I also realised that it isn't as relaxing as it used to be. Now I am frustrated with fighting outnumbered against better planes. This of course is partially my fault as I often go straight ahead, bashing right into enemies, but it isn't always happening and fighting against better planes is ok, if you got killed few times in a row, but not 7. Not by the same type of plane. And in longer run, playing "War Thunder" may make me quite qualified pilot of WWII planes. With some stories to talk about that maybe few people may care to listen.

That's why I really need and want to work on Dragontorc more.

Even if it would be just few minutes a day. I always have some small tasks to do. Sometimes it might be even doing some graphics, scripting AI, etc.

Last week didn't bring much. Really small changes and couple of ideas - one of them being ability to bind spells that were used. It might be mostly useful for spells that could be easily wasted, all missile-like spells, but also maybe "energize"? That I haven't decided yet, but I know that whatever it might be used for, it should be as simple as possible, operated with one key/button and it should always work, but if you want to speed it up/use less energy, you should be able to. While I want to make hardcore retro gamers happy, I also want to write game for me that would be fun adventure with challenge but without frustration. I might be too old to die 100 times while trying to finish that one single level ;)

Weekly update MS04x21

I had some troubles related to other planes (foreground, background) when I added generation of them. Well, generation itself revealed couple of issues that I solved immediately and added few features - most minor, but one - blocking other connectors if one is chosen - works now pretty well and allows more freedom when designing pieces for generation.

But the biggest issue was how to move other planes in relation to main plane - room's interior. First I added something obvious, that was based on how perspective works. If character/camera moved to bottom, which is closer wall of room, it was just like camera would go to ground. User could see elements in foreground and in background. It looked quite ok, but problem arose when I moved character/camera to top - further wall of room. Then foreground moved further away and disappeared below edge of screen (just like in original), but top did same thing. After little bit of thinking I decided to do something that may feel weird when you start to think about it (but you can also rationalise it) - when camera is at bottom, foreground elements are in line with closer edge of room and you almost can't see background, but when camera is at top, background elemenst come closer to further edge of room, while foreground goes away.

There are some minor things that I'd like to do here, but they may wait a little bit. I want to focus now on vertical doors and then on travel system.

And why two weeks? I had few busy days as I changed job. I'll be still doing same thing (well, almost) but somewhere else :) I wonder how it will turn out, but in case it would be horrible, I can still go back. I hope ;)

Weekly update MS04x20

Alright, I started to work on foreground generation and got distracted with room types.

One of things that I really want to have in Dragontorc is ease of adding new content by random people. If someone wants to add new type of wall for castle rooms, they should only need to define that particular piece, give info about it and game should learn about it, where it should be used and use it only there. That's why I have tag system and tag conditions. With them, you can define room types (or regions, more on that later) that they are described as "medieval castle" (two tags, "medieval" "castle") and that that room type accepts pieces that have both of these tags. Actually tag condition can be used in more advanced way, making it possible to write "(darkage or medieval) castle". And with "disallow" tag condition it can avoid using fantasy elements (put "fantasy" in right place and all pieces tagged as fantasy won't be used).

And pieces may define kind of rooms. For example bookshelf may tell that it should be in "library" and new room will be defined that tells what "library" is. And if user wants, they may define "library" with given room type.

Stop. Room type? Kind of room? That's what is my problem here that naming is quite problematic. I will probably change it, but for now it is:

1. Region Type - region is area of similar graphics/mood in game. It might be castle, forest, village, stone henge and so on. It contains room of different types (kitchen, corridor, clearing, etc). Is defined with tags, collects pieces of similar tags
2. Room Type - I am considering to rename it to Room Template. It might be more general description of room, kitchen, library, that is not dependent on region (so it might be kitchen in castle or in space base).
3. Room (Kind) - I have no idea how to name it, it is just plain name of kind of room - kitchen, corridor, clearing and it used to differentiate various rooms within Region Type.
4. Room Pieces - various room pieces that are building blocks of each room. They may define Room (Kinds) within Room Type.

This sounds complicated when I try to write it quickly and some documentation will be required to describe it properly. But on the other hand, with examples (xml files with graphics) it should be very easy to understand and to use.

By the way, yes I am using lots of xml files and at the moment I have no need for editor but I'd like to see one being done in future - maybe even not by me :) This will of course require some tools to test stuff that could be run from commandline or integrated into actual editor, but that should not be complicated thing to do (not the commandline version).

Weekly update MS04x19

I had one week where I couldn't do anything.

But I did few things last week. Floor generation mostly that showed how many problems there are (well, were) with room generation. Were, because I fixed them this week, but I'll write about that here.

Room generation now creates walls, doors and floor (which was not present in original game). There are two ways to generate floor:

1. Start with boundary pieces, attached to walls, then fill rest with "tiles".
2. Fill everything with "tiles".

Tiles are not actual tiles, they are just pieces as anything else, so they don't have actually to tile :) This looks simple as an idea, but I really couldn't decide what to do with this, as I wanted to have floor connected to walls but at the same time, I wanted to have lots of pieces filling floor. Solution now seems obvious but it wasn't few weeks ago.

There are also starting pieces that land right in the middle of line closest to camera in the room that can limit tiles in nice way. I still need to add code not to clip them, so they can extend down in nice way.

And now bad things: when I run it (and it finally worked, as there were few minor issues, one of them related to my incorrect use of vala :( with c++ I would not do such thing in first place and I am more and more tempted to switch to c++) it took more than half a minute to generate 7 rooms. More than half a minute. That's way too long. I was logging a lot, so I cut some logs to be optional and it was still too long. I compiled without logging and debug info and it turned out to generate in less than a second (I didn't even try to measure it).

Why it was taking so long? I don't exactly know. I know that I did lots of things completely unnecessary. When room generator added new piece, its location was updated and then madness was beginning. Every piece was disconnected from each other and then reconnected basing on their location. And everything was checked if it intersects with each other. And while for walls and doors there were maybe 20 elements top, with floor it started to be 60 and most of checks were done against each other. Twice (because I was too lazy to do it properly in first place). I changed it to only do most of that stuff for last element added.

I did that to properly rebuild connections when something is removed and for removing pieces it still goes through that madness. But here's why. Some of connectors might be closed due to state of other connectors and while they are being closed when something is added, it seems to be fine, but when something is removed, it is much more trivial to disconnect everything and rebuild it. Of course it isn't right way and if I find room generation working too slow, I might decide to change that. But as it works now and there's no need to do anything more complex, I'd rather keep it as simple as possible.

What's for next (well, this) week? I'd like to add foreground and background generation and introduce subtypes for rooms. For now, without properly choosing them for map - this will have to wait for next milestone.

I hoped to do more during last few days but: a) I started to get addicted from War Thunder and already spend 30 hours flying - which is great way to relax and round time that lasts up to 30 minutes seems to be better choice to spend limited amount of time than coding, as this can easily extend to few hours. But then, after each round I have "one more" issue :( b) I actually didn't spend too much time next to computer, and when I did, I had other stuff to code (book-keeping app that recently made it possible for us to get rid of mortgage but as we want to keep some money just-in-any-case and maybe start a little business, we still have mortgage) c) we were going to restaurants almost every day last week and it was great :D and we should do this now, as soon we're going to have baby and with such small fellow we won't be able to go to few places for some time.

Weekly update MS04x18

This week I want to write few things about doing stuff properly. Mostly because update is quite small (just added floor pieces, added place in code for generation). Last week and probably following weeks I might be occupied a little bit with my balcony and court matters.

There are some proffesions that require lots of thinking but even within them, there are certain rules that should not be broken. For example, in programming, you should never allow memory to leak. Never. There are some rules that are just guides, but in some projects they might be crucial requirements. To use, or not to use certain techniques or solutions. For example, multithreading application without any mutexes or semaphores (or at least, in as few places as possible, preferrably when there is not much going on). Games follow both those examples (memory leaks lead to crash when game is running for a certain time, mutexes and semaphores slow down application so much that multithreading doesn't give boost it could give). And there are many more rules. And there are other professions that require experience and knowledge and yet, they have certain rules not to be broken.

When you build something, you use materials provided by manufacturer with information how it should be used to function as desired. When there is information that given layer should be at least 2mm thick, then you can't assume that it will work fine when it is 1mm thick and hope for the best. If manufacturer said that you need to apply it at least two times, each time increasing thickness by 1mm, then you can't just assume that you applied it two times and it is thick enough. How to check if it is thick enough? You can do two things: cut piece and measure it, but then you broke layer. Or follow usage information: 1,4kg of powder per 1m2 for 1mm. If you have 10m2 then you should use 14kg to get 1mm of layer. 28kg to get required 2mm. If you used less, then you didn't do it properly. It's that simple. And there are more rules that every kid could understand. You really don't have to study anything to get them. And yet, there are experts that allow to bend those rules "because nothing really bad hasn't happened yet". Until something really bad happens and then everyone points and everyone else and no one's guilty.

Weekly update MS04x17

Week 17... Well, I hoped that it will be done by this time, but then, I wasn't working as much as I wanted. And now back to update.

This week was sponsored by letter D, D for Doors :)

• door pieces are chosen to match actual door as close as possible - it is now possible to have wooden door and two differently looking holes on each side of door (one could be enterior of castle, second: a cave)
• added blocking that may prevent pieces to be placed in that place (window can block anything to be placed in front of it, I have no plans to block only pieces of given type but I might consider doing this)
• added default occupy calculated for door basing on size of hole - this works with blocking system telling it how much space does door require
• added smarter generation for doors - they check where on given wall they could be placed (by subtracting from available space every place that is blocked by something) and try to fit there
• some other minor stuff done (mostly related to room generation)

Here's gif that shows what happens if there is no blocking and there is something on wall that requires space not to be obstructed.

In plans there are decoration objects that will change flow a little bit: they will be placed after doors are placed on walls. But this blocking thing still should be used for windows/holes/pillars other such objects. And blocking system will also be used for decorations, but then doors will be blocking decorative items.

You can also notice all those small differences in walls and door placement that come from procedural generation (although now it is quite random still and number of pieces is very limited).

And I finally decided how to handle floors and this is my next top priority thing to be done.

One of the things that I overlook are doors in floors and ceilings. If I'd be doing this letsdothisasquicklyaspossibleandnotcareaboutextendibilityandmodders then I would just add object that on contact plays animation on player's character and teleports it to another room. But I don't want that. I want proper door in floor, that can be opened, closed. That any character can move into but also can change its mind and move out from it. Doors in ceilings will have no other functionality than just an entrance to room (well, maybe just something to be drawn on floor). But I will still think about this while working on floor generation, which will also modify and tidy up room generation a little bit.

Weekly update MS04x16

I will write what was done last week shortly:

• custom room type scales for different planes which will allow close plane to appear closer or further from camera/player
• auto adding room pieces to room type which will allow moders to add new pieces to already existing room types and should also make it much easier to add new pieces in general (because I missed adding new piece to room type few times already and with this in place, this should no longer happen)
• fixed bug with using default anchor

And now, what I promised some time ago. Here's how rendering works at the moment in Dragontorc:

Delays on things that are not visible are omitted although they are now "rendered" (they are queued but as they are not on screen, they are not actually rendered). Simplified list of what's going on in that gif:

1. Wall pieces are rendered.
2. Doors are rendered on walls.
3. Bits inside holes are rendered (and then whole hole is rendered, so it is a litle bit different than what you see here, as things inside holes are rendered offscreen). You can notice part of wizard being rendered (one pixel width).
4. Everything inside room is rendered in appropriate order (based not just on depth but on BSP).

Servant is not green in that gif but it doesn't matter as everything else is just grayscale anyway :) (and I need to find some tool to create animated gifs easily).

Weekly update MS04x15

Though I've been sick and Easter coming, I managed to do few minor changes to renderer. Doors are now properly rendered when closed. I also added little bit of code to make it easier creating custom pieces. I was thinking a lot about generation of floor (and generation of other things in general) and decided to first keep it simple and then add some extra bits.

Weekly update MS04x14

Bad news. I got sick and I still am sick. Because of that, I did only some minor things and just wrote more info about implementation for stuff I want to do next.

When this will happen? Problem is that now I have few things on my mind: my current job, book-keeping app and Dragontorc. And of course there is my wife, my dogs, dancing lessons and at the moment there is also that thing with balcony that I'd like to end as soon as possible. And I'd like to have some fun from time to time which is not obligatory but helps :) Out of those things Dragontorc unfortunatelly has lowest priority which means that if I have lots of things to do, they may occupy me too much and Dragontorc stops sometimes or just barely moves forward.

If there won't be any weekly updates, then it is because of such pause but I will try to do even something small every week. Just to keep things alive :)

Weekly update MS04x13

Important thing was done and part of it was working at first attempt (I love when such thing happens, you write not too small piece of code, compile it and it just works as expected) and it was bunch of changes in rendering.

I now use BSP (which stand for binary space partition) to render sprites that intersect each other or to render objects going through doors. I already tested it on wizard going through door and it works fine - although result is almost not visible, on the other hand, without it, it was right in your eyes.

I hoped that I will have some graphics for doors but I don't :( And because of that, no screenshot this week, but in incoming updates I'd like to show how scene is rendered bit(map) after bit(map). I already have tool to do that and need to find nice example and turn it into gif.

For time being, I will keep gray background.

Ok, so what next?
1. Graphics for doors definitely.
2. More advanced door placement (to avoid placing them where they should not be).
3. Floor generation.
4. Generation of items on different planes.

Given more time, this should be task for couple of days maybe, but this may once again turn into weeks :( But step after step it is getting there.

Weekly update MS04x12

Another busy week and this one might be not better.

There were couple of minor things related to room generation. I added temporary door generation, so at least there are some doors now visible. I also fixed, and I hope that it is final solution, pixel alignment, so objects inside room, room pieces and other elements are properly aligned now.

And final, probably post important thing, that was done last week is support for rendering masked objects. This is what I need to render objects going through doors (or that are on other side of door). Current solution is not optimized (but marked with TODO marker and description what should be done) and is quite simple. Render target is created that bases on graphics for door hole (source). All objects should be rendered then on that render target. Then alpha channel is copied from source (door hole) and finally result is rendered where hole should be rendered. Well, it will be so, as at the moment it was just tested without proper placement of objects and hole.

When I do rendering of door holes, I will add doors and I will focus on something that I hoped to avoid. To  be honest I also thought at some point that I will be able to avoid this door hole rendering but even without doors I noticed that wizard sometimes is rendered on wall although it should go through hole. And second problem seemed also like something that most users won't notice but I know that it will look bad unless I do something. I thought that I will find some easy, maybe even hacky solution for rendering objects inside room. For normal objects there is no problem but when it comes to door wings it starts to get trickier. I decided to stick with simplest solution and use BSP (binary space partition) to properly render objects behind and in front door wings.

And one screenshot to show progress. I used grey background to test alpha blending (well, not blending, as now it is used just for masking) and it resulted in quite nice look. Of course door hole look strange like that as shadow seems to leak out from them. You may also notice that right door hole is not aligned to wall (it is rendered 1 pixel left to where it is supposed to be). I want to fix it, but if I don't, I think that nothing bad will happen, as proper graphics should not have such visible issues). How I would fix it? Add info about alignment, in this case, this camera angle, it should be 2 pixels and all doors should have locations aligned using this value. But for now, I will leave it, as it is.

I hope that during next update, I will show you not only door holes, but fully working doors - but maybe without proper ordering method.

Weekly update MS04x11

I did just some minor changes in the begining of the week. And I was occupied with other stuff during weekend :( But I plan to code at least one hour each day in the evening. I still sometimes go to bed around 1 or 2 am and get up around 7 am, so streamlining few things should not affect my health too much.

Other news. I started wiki, using  dokuwiki on my server, but mostly to check how does it work. I copied few bits from my internal documentation and just take a look at various xml files that define stuff and I realised that it already is not so small as I thought it is. I will try to write documentation, at least to have general ideas on wiki, but I know that at one point I will have to spend lots of time to document everything and create tutorials.

But now, let's go through room generation and do some travelling between further locations!

Weekly update MS04x10

I started working on doors but got a little bit distracted by both not Dragontorc and Dragontorc related things. One of distractions was finally locating and fixing crash that was happening on one of machines I work on. And I think that it was good idea to do so (few computers with different OSes installed). Strange thing is that it should happen on every machine but on this particular one there was 100% repro. But that crash is fixed and that was only one that I am aware of and it was caused by pretty dumb thing I did (for any programmers, especially vala programmers, owned object was created and stored in weak pointer and I have no idea why I made it weak anyway).

Another thing that distracted me was handling of logs and screenshots (I have no idea why I didn't do that earlier) and adding "dev tools". First one is to export templates for door graphics.

And other things I did were related to doors and to room generation but nothing new to be shown yet. I hope that during weekend I will finish doors.

Thing that worried me a little is that I want to add many more things and while I am tempted to do them immediately, I am not going to do so. Unless of course I feel/think that I need something already. Otherwise I just take strategy of small steps. I have clearly specified goals and I am getting there with small steps. Some of the things I refactor while I work on them but some I leave for future.

There's one more thing I'd like to cover now.

I am starting to consider releasing builds, so people can test them but as some of the things are already functioning but they are just pieces that are not exactly glued together, it could be quite disappointing experience for some of people expecting playable game. And that keeps me from releasing such builds. I am not worried about leaking, using them as early game, as this ain't game yet, but probably I will still add some simple mechanism to allow playing just in specific framework of time and release new build every month or so. And on the bright side, I'd love to see what some of the people would do with modding system, even without any documentation - but I think that I should write manual anyway, at least for some of the things (AI BASIC for example).

Any suggestion about tools/solutions for doing that? This is something that is not taken straight from code and I am not even thinking about creating separate documentation for source code (although I try to comment as much as possible and many things have ideas and processes described anyway, so that's covered). I am talking about manual for modders. Wiki?

Weekly update MS04x09

I was sick for a week and occupied with few other things and I'm sorry for that.

Recently I added room generator that takes various pieces and puts them together to form a room. At the moment there are just pieces for corners and walls. There are no doors visible and this is next thing on my to do list. Doors will be a little bit tricky, as they are holes in walls with object going through them - even if actors move to different room when they haven't even passed the door line, they sometimes still should appear partially obstructed by walls. But actors aren't biggest problem and for now I will just ignore that issue. Bigger problem are wings of doors. I don't want users end up with creating same graphics for animated doors on left, back and right side walls. And there are also hinges and doors opening into and out the room which would just end up doing enormous amount of graphics. What I thought is that it might be easier to create graphics for door frame, hole and wing of door separately. Why frame and hole separately? Because of the way I want to display objects on other side of door. Things should be rendered in this order:

1. Walls.
2. Door frames.
3. Door holes with objects that are going through them or are on the other side of them.
4. Objects inside room.

There are many more planes/layers and it might seem strange to have them separated this way but this gives more control over what is rendered first and what next.

Anyway, this is just a plan for next couple of days which will also include type for door, code to handle various door types.

And here's a screenshot of how does it look now, mind that all graphics are just test stuff (taken from original one or done quickly to test various functionalities).

Rooms are quite tall, the ceiling should be not too much higher than the books on the wall. But for some odd reason I decided to have walls this tall. Well, temporary graphics.

Weekly update MS04x08

Not too much happened last week, again. I moved parts of code here and there to have it cleaner and more organised.

And I started to add room generator that should put all room pieces together to create a room. User should be able to add any piece, describe how does it connect to other pieces and program will use it when generating room. I plan for future to add user-defined blocks of pieces that can be used together with single pieces.

I also tested plane to display objects in foreground and used different scaling values for both axes. In original Dragontorc I think that there was single scale which resulted in objects in foreground going too low when Maroc moved further into room. Now it looks better I think. As soon as I finish room generator and add few custom pieces, I will provide video.

And while we're here with different planes, there is also background plane that can add perspective in "rooms" that are open spaces - forests, deserts, etc.
I only need to allow users to modify scaling for different regions.

And I added debug rendering that will be useful both for me and for users creating custom content. And I already solved a bug with it related to projectiles hitting objects.

Weekly update MS04x07

Well, it didn't turn out as I hoped it will. But on the other hand we spent lot of time together. Mostly watching all series of "Pitbull" (around 25 hours in total, but over three days).

Only thing that I did in code, was to tidy up loading global settings. Now they are loaded before everything else happens, which means that now resolution can be set with settings file and pixel size might be use as a value when reading stuff from file (for example instead of telling that something is 1.5 units wide, it can be specified that it is 32 pixels wide - it should really help if someone would decide to change size of pixel, for any reason - but of course if every value would be given pixel-based, then it won't matter).

I also had some thoughts about walls and have an idea that should make it easy to specify pieces for walls, doors, etc. I hope that I will do that during this week and I will be able to show some video or screenshots of how new render system looks like - but don't expect anything spectacular, I haven't done any graphics that will go into final game. Not yet.

Weekly update MS04x06

Well, I did just one thing this week, but it was not so small one. I finally have proper render system and it works (gathers data abound objects in room and displays them in right order). I also have mouse input working.

I write this post on Wednesday of following week. I could do much during weekend and for half of this week as my wife's got sick (and both dogs too) and now I take care of them. And do some other stuff too - one that gives me some money and that has to be done at some point. I thought that while I have some time between going to one doctor, doing some housework, etc. I could use it to write Dragontorc or to do all the stuff that I have to do till end of January and then, when I'm done with it, I can go back to Dragontorc. I still have Thursday and Friday and Saturday and guess what more? Sunday! I know that I won't do much on Thursday as I need to finish the thing I am occupied with right now and I also have minor surgery on Thursday that may leave me in pain for few following hours (I had similar thing year and a half ago and painkillers helped but didn't obliterate pain).

Back to Dragontorc. Plan is to create descriptions of rooms and doors, some basic graphics and put that into render system and that is a little bit tricky, but I will explain it, when I will be presenting that stuff working.

Weekly update MS04x05

I'm back!

I started to work on moving from GLFW to SDL and to create proper system handling classes and renderer. Before it was just calling GLFW functions directly, rendering everything by going through all objects. And because I switched to purely 2D graphics, I had to order all visible objects and that's why I came up with renderer that gathers all data - code still goes through all objects in a room, but instead of drawing them immediately, it just stores, what and where should be drawn. This also means that it is now possible to gather data and process next frame, while current one is being rendered on separate thread. With 2D graphics this may sound as overkill but:

1. I didn't do that yet. It runs on one thread.
2. I want to keep all code clean and rendering functionality should be with rendering stuff.
3. Switching in future to different graphics (voxels, 3D models) should be less problematic.
4. It is modular.
5. I had to solve issue of holes in doors. I want users to be able to create custom/new graphics and to make it easier for them. And as it is 2D graphics, I need some ordering of objects and drawing objects that are partially beyond the door.

And as for switching from GLFW to SDL. SDL provides all modules I need (although some need extra stuff to be done), it also handles any size of graphics, not only of power of 2. And finally, system classes are held in one place and if I ever feel that I should use other solution, I will just have to do it in one place.

Only thing I did since beginning of year up to last Sunday were commenting out old functionality, compiling libraries I need (sdl, sdl-image) and creating base for system classes. My mistake was to try to use sdl2 and I managed to modify sdl-image to compile with it and then prepare vapi for such sdl-image (I named it sdl2-image) and then... I realised that I really don't want to prepare vapi for sdl2. It is enough that I have to modify vapi for sdl to add functions that I find missing (SDL_SoftStretch, SDL_DisplayFormatAlpha).

Don't worry, this week I will make greater progress. I still need to think about how to represent graphics for walls/doors, well, regions in general, but that's separate issue.