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.
2013-04-24
2013-04-17
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 :)
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.
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.
2013-04-08
Weekly update MS04x16
I will write what was done last week shortly:
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:
- 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:
- Wall pieces are rendered.
- Doors are rendered on walls.
- 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).
- 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).
2013-04-03
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.
Subscribe to:
Posts (Atom)

