I've quietly continued working on the save mechanisms, it's rather intricate to get working right... hence there has been no new journal entries for a while. Right now the inventory is acting up between maps (occasionally) but I think I am going in the right direction.
However, sometimes the inventory doesn't act up. This allows me to go down a cellar and beat some rats with a new found sword. Too bad they are immortal at the moment...
DIE RATS! DIE! *doh*
On the editor side I've implemented a raise and lower map function. By pressing either button the entire map is shifted in the desired direction. This allows for instance building cellars to buildings that I maybe didn't think of in the initial design of a map. I have been thinking of doing a X/Y offset to the total map also... but my UI-space is getting more and more crowded. Having X/Y offsets would probably be just as useful as the raise and lower feature. I need to make more room, move some UI elements around a bit (ugh).
Been drawing a lot lately. Especially forest graphics, there needs to be a good amount of variation in order for it to look natural. A bit tedious doing roughly the same things over and over. Here's what I have come up with so far...
It looks better animated, the pines going slightly back and forth. The player and NPCs are "see-through" when they are behind something. This can be toggled in the options but I would recommend leaving it on since it's pretty hard to fight or do something when the player or the target is obscured.
I made a few steps while I was drawing a tree stump for those who are interested.
Basic stump shape.
Some more work on the shape, still just a silhouette.
Filled with the base color.
Trying to draw some shape with darker and lighter colors.
Some detailing, ridges of bark.
More work on the bark, doing some pointy splinters on the top of the stump. Make it look like the tree has fallen by wind or something (not cut down with an axe).
More detailing, the bark has a ridge going down the trunk.
Making a mask for some moss.
... And done!
Here is a screenshot showing the stump together with a stray log. Hope you like! =)
Been thinking about how to present new things to the player and I've come to the conclusion that I need yet again redesign my "HUD" interface.
I don't want to frontload the player with a bunch of information at the very beginning of the game. I think it would be desirable to have most of the buttons hidden at game start. They only become visible when an event has taken place. For example; the map button doesn't need to be shown until the player has a new location to visit, the health meter is hidden until there is change in health, the inventory button is shown when the player has picked something up... the list goes on. The new buttons should be accompanied with a short descriptive text, something like a tool tip. Maybe a flash or animation when they first appear to alert the player of the new functionality.
For your amusement I have put together a picture showing the different HUDs I've tried.
The bottom most picture is the current iteration. The back frame in gold will expand as new buttons become visible. The health meter is outside the view, floating in the upper left corner. I've intentionally made the buttons rather big in the current version. They should be easy to click/select since there aren't that many buttons.
I've implemented an auto transition function in the editor. I have always thought that this would be a handy thing to have but thinking it would be too cumbersome to implement due to the nature of my data storage, I use linked lists instead of a two dimensional array. However, now its done and it is pretty sweet :-) I have even made a bad quality video showing it all in action. In the later part of the video you can also see some regular editing going on.
I have also implemented the animation system discussed in the previous post. Now I can edit how fast and how much an object should sway its vertices.
The last few days I have been working on updating the navigation mesh tool in the editor. This will then be a matter of copy and paste to get into the game.
The reason for this is that I found some strange bugs in certain areas when doing path-finding. The found path would sometimes lead to x0, y0, z0 which isn’t something I would ever want. I checked if there were any newer versions of recast & detour and surly there was. I went through the demo project source and didn’t notice any real big changes to the navigation mesh building phase but I decided to implement the new version anyway... Maybe there were bigger changes “beneath the hood”. When re-implementing the library I found that there was a variable named edge max error. I had overlooked this parameter setting in my own editor. It was just a hard-coded value in the source (a rather big and bad value at that). Now I’ve made a GUI element where I can adjust its value and after a few preliminary tests I haven’t noticed any paths leading to wrong places. So I am hoping this have fixed my problems once and for all…
I have also made some graphical changes to the game. Water and vegetation looked stiff and unnatural without any animation. Animating trees and smaller vegetation can be quite a big undertaking. To circumvent the issue I have thought about moving the vertices of the vegetation but I hadn’t gotten around to it yet. Now I had a few hours to spare so I thought I would try it out. I decided it would be sufficient to move the vertices of the treetops to begin with; the trunk (which is most often another object) could be still. Also it should only be needed to move the outer most vertices of the treetop. The reason for this is to simulate that the treetop is stiffer the closer it is to the trunk. To make things easy and get results more quickly I choose to implement this in the game itself, leaving out the editor (I might go back and incorporate this later).
I searched the resource name of the graphic. If the filename contained the word “plant” or “treetop” it would animate, simple as that. Then I just needed a random wind-seed-number and move it around using cos and sin. To my astonishment it looked quite good the first time around! :-) As a matter of fact it looked so good that I decided to go ahead and implement a similar routine to make the water go slightly up and down. This was a bit trickier as a water tile has to line-up with its neighbours. The illusion of a water surface disappears if there are gaps between each tile/wave. It’s hard to describe in words how mush it does for the vividness of the scene; Here's a small video showing it in action.
The animations are hard to see unless the 720p video is viewed. The water waves could still use some tweaking.