Jump to content

  • Log In with Google      Sign In   
  • Create Account

OddGames development journal

Sneaking and bows

Posted by , in Nimrord Editor, Medieval Story, Graphics, Programming 12 September 2014 - - - - - - · 625 views

Been a while since the last update. I’m still working on Medieval Story, my *long* running project. The engine is more robust and I have changed my windowing framework to the latest glfw-master branch from GitHub. I decided to switch from 3.0.4 in order to get the latest mouse cursor support. Previously I rendered a textured quad and used that as a cursor. With the new cursor support in glfw I get much better mouse response. It is especially noticeable when the frame rate is low.

In regards to gameplay I have also made improvements. Both the mouse and keyboard controls have gotten more precise after tweaking the physics engine. The player slides better along walls and climbs stairs more easily. This is achieved by modifying the friction of the object that the player collides against (bulletphysics only has one friction value for the entire rigid body). When an object is walked upon it has a high friction value, it is treated as a floor. If the player walks up against the same object the friction value changes to a low value, it gets treated as a wall. I know this could be done more elegantly by dividing the objects up by walls and floors… but this would mean the double amount of physics objects.

Posted Image

I guess this sort of problem is not so common in ordinary 3D engines when objects are not treated as a whole. My world objects can often be walked on top of and slide along or against.

The camera has also gotten smarter. Instead of just chasing the player the camera focuses on the area that is ahead of the player. However, when in battle it focuses on the player so it does not to miss any action.

I have come to realize I will have to cut down on the scope of the game. I begin to worry that I might not actually finish it. However… there still are a few mechanics I feel the game should benefit from. One such item are Bows, they can be used to pick off enemies from a distance (*duh*). I might implement more types of ranged weapons in the future (crossbows, magic stuff) but right now I feel they are quite sufficient.

Posted Image

Another of these items are the possibility to sneak around your enemies. I have adjusted the level editor to compensate for this. I can now adjust the awareness radius of an actor right inside the editor (this was hard coded until now). Each actor has a max and minimum radius from where he can spot the player. The maximum radius (blue) is used when the player runs and the minimum (green) when the player uses sneak.

Posted Image

Posted Image

I think this will allow for more intricate quests where you are unable or forbidden from just killing your enemies.

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

... Oh, on a last note. I hope you consider voting for Medieval Story on Steam greenlight!

Medieval Times, office, crowdfunding

Posted by , in Medieval Story, Programming 29 November 2013 - - - - - - · 945 views

Yes, it’s time to update the journal! For some time I have been thinking of moving into an office instead of working from home. I’ve had a good working morale when I’ve been working from home... but I think it can get even better. It would also feel more like a real job if I actually left home. So the last few weeks I’ve been in contact with a renter/landlord who rent out individual rooms, sort of like a hotel for businesses. I’ve rent a small office (around 9 m2).

Posted Image

Most of the other rooms on my floor are empty. There are two sales guys, a transportation/travel business and some sort of entrepreneur (don’t know what he does exactly). Everyone seem friendly and helpful so far.

Game progress
My progress on Medieval Times crawls on. Been replacing the textured mapped text in the game with a higher resolution texture. Now texts look more crisp on higher resolutions. Have also been trying to get the demo together, connecting different maps with quests and stuff like that. The demo will be around half an hour to one hour of gameplay, I guess it will depend on the playing style.

I have been pondering to start a crowdfunding campaign for Medieval Times. I live in Sweden so a Kickstarter campaign is not an option since they only allow UK/US projects. My other idea is to look into indiegogo but I have not made much research into it yet. I am a one guy team so I guess I will have a ton of work ahead of me in order for it to be successful.

That's all for now, I need to get back to it. Thanks for reading!

Navigation mesh picking

Posted by , in Programming 29 March 2013 - - - - - - · 993 views

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.

Posted Image

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..

Posted Image

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.

Posted Image

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

Posted by , in Graphics, Medieval Story, Programming 27 March 2013 - - - - - - · 1,021 views

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:

Posted Image

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!

Bugs, keys and splashes!

Posted by , in Medieval Story, Programming 31 January 2013 - - - - - - · 863 views

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:

Posted Image

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).

Posted Image

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!!

Recent Comments

Latest Visitors