OddGames development journal

NPC Portrait 2

Wed, 29 May 2013 18:25:00 +0000

Work in progress. Character name "John"

More to come later :-)

NPC Portrait

Mon, 13 May 2013 19:33:00 +0000

Hello!

Been painting and not coding so much, I've decided to have bigger portraits of the game NPCs when in dialogue. The portrait will sit on top of the text window. I am sure you have seen such arrangements in previous RPG games (Japanese RPGs most notably).

Anyway, I thought it would be fun for you to see a progress-composite image. Showing the work flow so to say. Final picture can be found here.

(Warning long image)

Thanks for reading!

Female peasants and horse (video)

Fri, 12 Apr 2013 11:23:00 +0000

Would like to show two of the latest models; a female farmer and a horse. I have modelled, textured and rigged these in blender.

I'm glad that I've got a decent blender workflow going. My only concern is that it gets rather boring to wait for the rendering of the all different frames.

On the programming side I have been trying out different behaviours for the non critical NPCs (for example friendly peasants). They walk around in the town and do their daily business using preloaded paths. I can switch an NPCs current path with lua scripting.

When testing I noticed that it would be necessary to be able to grab and drag objects. Sometimes a chair or a crate would get stuck in a corner after I had pushed it around a while. I looked up the bullet physics constraint object and implemented a basic grab mechanism which works pretty well. This should enable some interesting puzzle problems in the final game.

A short video showing the new models and the new grab mechanism:

Thanks for reading!

Navigation mesh picking

Fri, 29 Mar 2013 19:40:00 +0000

My navigation mesh picking routine have been fairly straight forward up until now. I have shot a ray from the mouse cursor into the scene and selected the point that intersects the mesh closest to the camera. This works fine 90% of the time. Recently however a new and more complicated solution was needed.

As mentioned in the previous post I have started building maps with more than one floor. This raises a problem since my navigation mesh is not split up into different floors, its just one big mesh for the entire map.

In the above example the house has one main floor and a small loft. The loft floor and stairs are overlapping the ground mesh outside the building. If I used the closest intersection point on the ray selection the player would always walk to the stairs, this is not always desired. For instance if the player were behind or outside the building... then the roof would be visible and the stairs would be obscured. In that case I have reasoned it's more desirable to pick the intersection point that is obscured, in other words... the ground behind the building, not the closest point.

New solution with a problem
Now I figured that this was pretty easy to solve. Just select the point that is further away if the player is outside (not underneath a roof), else pick the closest point if the loft is visible (i.e. the player is underneath a roof).

This worked fine for the above case. Now come the next house..

As you can see.. this house has an even more complex navigation mesh. The entire second floor lay on top of the first floor making the new solution broken. The second floor's mesh would always be used because it would always be the closest. However, it would still be possible to walk behind the house if the player were outside the building.

Second try...
Well, now I came to understand that I needed to split the building into more "roofs" and detect exactly which roof the player was below. Sounds confusing? It was at first.

I figured I would need to know where the players feet were in order to fix this and luckily I already had that position. I also needed to know which roof the player was standing on. Well I knew that too because I had already done the fading of the different floors which used the same objects. Some bullet points to decide on the correct intersection point (the green point in the above picture):

Disregard points that are too far below the players feet but still underneath the roof object (makes it possible to click stairs going down).
Always use a point that is outside the roofs X/Y components if only a single hit is returned (the user clicked outside the building and wants to get out).
Select the point that is closest to the players feet z component if there are multiple hits.

There are still certain cases when the picking is a bit awkward. For instance when the player clicks an area of a second floor that borders the outside of the building. This will result in a intersection point outside the building due to that the navigation mesh is built to account for the player width. This width can be seen around the entire mesh as an offset from the walls. It only becomes a problem when the mesh borders nothing (for instance a second floor bordering air). When an intersection point lays on the ground plane or is inside a building this issue has been taken care of with another method.. I won't go into this now, I think this post is enough elaborate as it is.. ;)

The second picking routine might be a bit overkill as I easily could... and in most cases probably will use entirely new maps for the interiors of larger buildings and floors (think castles, dungeons etc.).

Well, that's all, thanks for reading again!

Characters and transparency

Wed, 27 Mar 2013 13:12:00 +0000

Hello, I like to thank you for still reading this journal despite it being rather sparse and only sporadically updated. Lately I have been focused on character modelling. I have a base model which I derive my characters from, I am not very happy with its animations but they will have to do for the time being. Here are a few of the models I have created:

As you can see there are no female models (yet). I hope to get around to do a base model for women too.

I have also been implementing transparency fading of items and npc when entering different floors of a building. Here is a youtube video showing the fading in action.

Oh, I almost forgot... I've started a twitter account for those who are interested in reading shorter snippets. ;-) @olofsson77

Thanks for reading!

Houses

Tue, 26 Feb 2013 21:39:00 +0000

At last I have gotten my Cintiq display. It works great! Drawing new graphics is a breeze. This should allow me to do some nice portraits for the game NPCs and such. The display takes up a large chunk of my table though.

Game development progress... I’m trying out some new building graphics together with multiple floors. The new house type has walls made out of wood planks. I think it makes the house look a little bit more sophisticated. I find that a mix of the two building types gives a village a bit more of natural feel, I like.

But all is not well; multiple floors have raised an issue with the pathfinder. The pathfinder uses a ray test when finding out where the player wants to go. Right now the ray test only returns the closest point on the nav mesh (to where the player clicked with the mouse). This results that only points on the top floor of the building are returned. This is bad if the player wants to go to a floor in the middle or in the bottom of the building. I need to find a point on the nav mesh which is on the same floor as the player. I am guessing this will require some work and tweaking to get right, stairs for instance… might get a bit tricky.

Some screens showing the new graphics:

Bugs, keys and splashes!

Thu, 31 Jan 2013 21:42:00 +0000

Hello again!

Yet another of those evenings with too little energy to do something productive. Well, in regards to programming that is. However; I can muster enough drive to write a journal entry! These past few days I have been able to get a lot of coding done. This is particularly good in light of my resent troubles with my pen and display/monitor (see previous entry). I have been bug-hunting and also implementing features that have been on my to-do-list for too long.

One of these features has been a key ring/chain. I noticed that I needed something like a key ring for quite some time ago, consider the following scenario:

The player picks up a key that can open a locked door which eventually leads to another level.
The player opens the door and closes it behind him.
The player then walks to the new level. When the new level has been loaded the previous level is visible in the world map as a fast-travel location.
The player drops the key and afterwards uses fast-travel to get to the previous map.
Arriving at the first map on the “inside”, the player now walks to the door which was previously locked. Now he can’t get back to the key and he can’t open the door.

Situations like this can easily occur if I allow fast-travel and key drop. The easiest solution I could come up with was to implement a key ring which can’t be dropped. The ring holds all keys ever received and as a bonus also saves some inventory space (I allow 16 inventory items and 4 equipped items, 20 items in total). I guess I could do some sort of path tracking to the new fast-travel location and check which doors needed opening… but that seemed like a too complicated system. The key ring can be found inside the inventory along side the other slots:

I have also dabbed with the rendering code. Previously transparent items couldn’t cast or receive any shadows, this is now possible. I haven’t done any benchmarking on this but I hope it hasn’t slowed down the frame time too much. Also water splashes are a little bit prettier (~~screen shot of this to follow within a day~~).

Next up is fleshing out the game’s story. Writing better dialogue and decide where the demo should end.

That’s all for now, thanks for reading!!

Ordering woes

Wed, 16 Jan 2013 17:57:00 +0000

Hello!

I've been caught up in rather depressing business. I draw quite a lot on my spare time. All of the graphics to Medieval Times and some other things. Most of the graphics I have drawn on my Wacom Intous tablet (rather old, the first version) so recently I decided to upgrade to a beefy Cintiq 24HD Touch pen and display.

http://www.wacom.eu/index2.asp?pid=7002&spid=1&lang=en

These things goes of at a whooping price tag of 33000 SEK (around $5070). I ordered the display 10 December 2012 and got it 7 January 2013. Quite a long delivery time if you ask me.... However, only to find out that I had received the wrong model - not the touch version. I can't comprehend how this is even possible for such an expensive product! However, I got my brains together and made an RMA to the reseller. I sent the wrong model I had received and waited for another week for the right display to arrive.

The new display arrived 15 January. Now the version was right, it had touch and everything. I drew some, well tried it out for a half a day when I noticed it was a defect product. The pen didn't register on a certain area of the display...

http://www.youtube.com/watch?v=lUvYF2hVQI4

A new phone call to the customer care center at the store, request a new RMA and then the whole procedure again. I am hoping to get a working product by the end of the next week but I am starting to lose hope that this matter will ever cross the finish line. The customer care operator even asked me if I wanted a refund considering the twists and turns.

Well, it would have been nice to show some new artwork made on this device but sadly it has not been possible. This business has also crippled the programming side of my game project. I haven't been able to concentrate on the different tasks with this whole matter in my head. Hopefully this next device will be up to par and I will be able to show some progress in the near future.

Thanks for reading!

Are we there yet? Are we there yet? Are we there yet? Are we ther...

Sun, 02 Dec 2012 02:16:00 +0000

I have been making good progress on the “demo” I’m planning on releasing. The demo won’t be very long or content heavy, just one or two quest and a few NPCs. What I have done is making the things around the gameplay work nice.

The player can change gear. Armor, weapon, helmet and shield. This can sound easy to implement on paper but when figuring out how to have different equipment showing on the player avatar things start to get hairy. Especially when having 2D sprites and not actual 3D models which sorts by them selves. I solved it by rendering the player sprite at runtime when the player changes equipment in the inventory screen. There are a few special cases where the sprite objects had to have some exceptions to the rendering order but most often I could just render the sword at the expected location. For instance if the player is walking to the left the sword would always be rendered behind the player, if walking to the right the sword would always be rendered in front of the player. A special case would be when the player swings the sword in front of him but he is facing left.

This seemed like the most efficient way... however, first I tired to render the player sprite with its different gear directly to the frame buffer. This was not very practical and did not look so good. I want the gear to blend nicely with the base sprite. It looked weird when I faded them in and out of view. The head would for example be partly visible through the helmet if the helmet started to fade out. I want NPCs to fade away to simulate that they are out of sight. Another benefit is that there are less texture bindings per frame when pre-rendering the sprite gear to a single texture. I could go on forever about this topic but I am sure you all would get bored eventually ;)

View world and local map. The world map is a rather straightforward, just one big image showing the game world. I will print out location names as the player discovers them.

The local map is on the other hand a little bit more complicated. The map is viewed top-down like any old map. I generate it after the map data has been loaded into memory. First I loop through the world objects, skipping the objects that I consider “ground objects”. These ground objects have the characteristic of being rather flat; wider and deeper than its height. If the object is not a ground object I render it onto my map texture. I use a simple codex to distinguish different items on the map. If the object is a door I render it red, if the object is a tree top I render it with a round shape and make it green and so on… This makes for a rather simple looking map, but I think it suffices. The player location will be marked with a cross or an arrow of some sort. This has yet to be implemented.

Writing and looking in the journal. Adding entries is accomplished by scripting. Quests, information, thoughts the avatar might have, etc… all are recorded inside the journal. The entries in the journal are stored in chronological order, there won’t be any way to sort or search the entries and there shouldn’t really be a need to either. I don’t want it to be too convoluted. Each journal entry can have an image associated with it. This image can be used to set the mood of an entry or it can contain vital information. How to solve a particular puzzle or some scribble of an important location. I have thought that I might make the images personal to the player and reflect what’s happening in the world, maybe some kind of mental state of the player avatar.

Hmm, well that’s what going on I guess. =) Time to get back to it!

Thanks for reading, take care until next time.

Testing testing testing

Tue, 30 Oct 2012 13:07:00 +0000

Hello again!

I have been doing a lot of play testing lately; finding bugs and things that aren’t supposed to behave like they are. Other times two features might collide and be in effect when I hadn’t thought they would. Much of the colliding features are due to my design choice of having two different control methods. I am beginning to realize that this was a rather brave and/or foolish choice. Well, I’ll just wait and see how it plays out in the end.

Most of my programming is done on my stationary computer at home. It runs an older graphics card (ATI Radeon 4850). When I am on holiday or some such I often take my laptop with me. It runs with a built in nvidia mobile graphics chip (GeForce 8600 M G). It’s a pretty poor graphics card that is really only capable of running fixed function OpenGL rendering. However it is a pretty good thing to be able to test my shaders on two different graphic implementations. I thought that I was well covered until I realized I wanted to try Medieval Story on my brothers computer, he runs a newer GeForce, I don’t know the exact version (GTX something I think). It did run pretty well, but I found out that some times the shader breaks and draws black pixels when it should render lit pixels. After some testing we found out that it was due to the material shininess being 0 and the specular components calculation. I fixed the issue with a “hack”, adding 0.001 to the shininess as a minimum value. After that we tested quite a bit more and found out that the game also could randomly crash, well seemingly randomly anyway. The bad thing is that the compiler didn’t go to the line where the fault was. It just closed the program (sad face). Later we found out this was something wrong with the compiler… not being able to go to debug mode when a runtime error occur. Back home I ran my game again trying to replicate the bug and I found a small bug that was connected to the health bar drawing. A modulo by zero could sometimes occur when the health was very low, below 1.0. This could result in a division by zero according to the internets. I have since then fixed these bugs and I am now continuing to hunt for new ones.

Along side this development I am trying to come up with a half decent story. I think this is actually going worse than programming right now. I’m afraid the demo story is going to be very generic and boring. Any articles in regards to game writing or story writing in general are much appreciated. Again, thanks for reading!!