Medieval Story has finally been released on Steam (wohooo!). Many late nights and evenings have been put into making Medieval Story. All graphics, sounds, maps, programming, scripting, GUI, music, AI, dialogue writing, modelling and what not has finally come together into this small game with about 8-15 hours of gameplay time. It feels quite bizarre thinking of all the hours that have been put into the game over the years and then reading reviews about it. Sadly some people seem to have had quite high expectations, pointing out infantile (?) dialogue, horrible controls and bad characters. I don’t know… Never fun to read criticism when it is sort of rude.
If you consider buying the game I hope you enjoy it for what it is; a one man game project developed in spare time.
Thanks for reading!
It has been quite a while since my last blog post… as always. However, development has not ceased entirely… just continued in ever so small steps. =) Here are some of the changes and additions made in the last couple of months.
Exploration/event music added.
Created library for handling steam achievements.
More enemy types.
Work on demo has begun (almost finished).
Fixed a bug when shooting arrows on certain types of enemies.
Implemented a game launcher which displays news and announces game updates. Launcher will not be included in the steam release, I think that would be superfluous.
Added animation to an already present cutscene (this had actually been long overdue, it looked horrible).
I've also created a short trailer for the game. Steam requires all games to have a trailer in order to have it published. Luckily I just found out that Photoshop is able to edit videos I didn't even have to learn any video editing software. *yay*
Well, this one-man project is starting to shape up nicely I think =)
Now, with these latest changes (…and a ton of tweaks and fixes made earlier, too many to mention here) I felt it was time to submit the store page and game files for review by valve/steam. They say that the review process can take up to 2-3 days for the submission to complete. It feels strange to call Medieval Story *finished* but I have to call it sometime. I hope the game gets enough response/appreciation to warrant further development. However… I know that indie games rarely becomes successful so I have set my aims pretty low in that regard. If I was doing this for commercial success alone I think I would never had gotten as far as I have.
On a private note, our second daughter has been born which has led to my development time being even more limited.
As always, thank you for reading and for your support!
[font=arial]Be warned, this might not be your ordinary game development post.[/font]
[font=arial]The New Year has just settled in so I thought I would keep my record straight and at least post one journal update per year. Real life has begun to catch up on me and my game development time has almost shivered up and died. This might sound like a very depressing post but it is not, and all for the good reasons![/font]
[font=arial]You might ask how this came to pass. Well, first me and my girlfriend got a baby girl about a year ago =) and then I landed a new job which involves non-game programming. My old job offered lots of free time during weekdays - this was ideal for game development at home. Now I work 8-17 Monday through Friday so I'm only free on the weekends. This works excellent for my family, not so great for my own game development project(s).[/font]
[font=arial]How much time is left for game development then? Well, right now I'm on paternity leave until April. So when the kid is asleep I can get some alone time, this is around 3-6 hours per day at most. During this time I also need to fit in other things such as cleaning, bills, write journal entries etc.[/font]
However, I have not quit on Medieval Story and I have been at it for quite a while. My isometric game is coming together bit by bit. I had imagined beforehand that this game would be a huge undertaking for a single developer... nonetheless I had hoped to be done by now. My problem is that I haven't laid out the game's story properly so the game just keeps growing and new areas are created when needed. I need to call it done some time and that is a difficult thing to do. I am not much of a storywriter which this sort of game kind of requires. Well anyway, to end this post I thought people might be interested in some screens of the current state of the game. Not much have changed graphics wise.
You can now kill wolves!
Some graphics showing the inside of building.
[font=arial]Conversation with an NPC.[/font]
You can't ride horses in this game - but they exist!
The outside of a fort.
[font=arial]Pug the mastermind.[/font]
That is all for this time, thanks for reading!
Hello! Great news! Medieval Story has been greenlit! Since I don't update this journal as often as I should there might be readers wondering what Medieval Story is about. Well, here's a short summary...
Medieval Story is a single player game which features action, puzzle and RPG elements. It is played from an isometric view point which can be zoomed in and out.
There are no experience points to be earned (so no level grinding). Instead different equipment and potions make your character stronger. Players can follow the main story arch and finish the game more quickly, however it is encouraged to explore the world. The game will be episode based and the world will get larger as I release new episodes.
Medieval Story is currently in content creation phase, progress is pretty slow since I am making the game on my own. The last few weeks I have focused on script writing, dialogs and map making.
Scripting This is done using lua, a scripting language used in many other applications and games. I use it to control character dialogs, changing of maps, setting character and object properties among other things.
Dialogue The dialogue is displayed via a special a GUI window. Here you can follow the conversation and make critical choices for how the story will unfold. Alongside the conversation is a hand drawn character portrait for each NPC you meet.
Map making I have developed a level editor called Nimrod the Isometric editor. Nimrod (for short) is tightly connected to the game. It can place actors and objects, assign scripts and set animation behaviour among other things.
The game will be released on steam in the near future.
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.
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.
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 ([color=#0000ff]blue[/color]) is used when the player runs and the minimum ([color=#008000]green[/color]) when the player uses sneak.
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!
I've uploaded a new version of the alpha demo. I know there still are a few bugs and tweaks that need to get fixed... but things are moving in the right direction.
Here follows a change log since last version:
Renamed game back to Medieval Story (read previous post for details).
Added more anti-alias modes (2x - 8x).
The buttons in the options screen can be right clicked to go backward when cycling choices (resolution, anti-aliasing, quality etc.).
The bandits are better at chasing the player.
Added a knife as weapon. It can be found inside a chest at the beginning of the game.
There are now rats in Mosscroft. They are good for practice before taking on the bandits.
Fixed a bug that could occur when talking to Cedric.
Made the enemies near the end a little bit easier.
Fixed a bug that made the battle music play when it shouldn't.
Fixed a bug that caused OpenAL not to be initialized correctly.
The list of fixes could be longer but I felt that the name change had to be released as soon as possible.
Medieval Story is now also available on steam greenlight! If you like the game please vote for it:
You can find the new alpha on the indiegogo campaign site.
I've started designing the outside walls of the tower. I want it to look a little bit weathered but not too much. Here's a step-by-step animation that I've made while working on it.
The lighting is a mock-up since the rendering engine will calculate the lighting and shadows. I did a quick shade because fullbright textures look like crap most of the time. Now all that is left is the interior...
On another note, I have decided to change the name back to Medieval Story. There is an American restaurant franchise that goes by the name Medieval Times. So to prevent any trademark conflicts I'll use the old name. Although they belong to a different industry I better be on the safe side.
The alpha demo can be found at the indiegogo campaign. Please consider supporting if you like the game. =)
New levels are taking form. This is a large stone tower set along the sea side. It's the local wise man's residence. The protagonist must seek him out to solve a number of problems. I have drawn this sketch to get a general feel for how I want the location to look:
Since this is a rather complex building I want to be sure all pieces fit together nicely when building the tower. I have therefore prebuilt the base structure of the tower with only simple building blocks. This allows me to determine the size of each 2d texture block before I start to draw it. Here is an animation from the level editor. It shows the progress of the construction:
It also allows me to test whether a navigation mesh can be built. This is a very important step to do since I want the player to be able to walk around and up the different stairs cases. No passage should be so narrow that the player can't get through.
I will be posting an update when the tower gets nearer completion. Be sure to visit my indiegogo campaign if you like this project. Thanks for reading!
The Medieval Times Alpha demo is out! The alpha is released for demonstration purposes alongside the game's indiegogo campaign. You can find the campaign and alpha demo here.
[color=rgb(40,40,40)][font=helvetica]The alpha is a short introduction to the first episode and the protagonist. The game's plot is gradually revealed as you progress.[/font][/color] I am pretty certain there are a few bugs that are yet to be discovered but I hope you enjoy the game nonetheless.
Pitch video: [media][/media] The pitch also contains some video from Nimrod the isometric editor. I hope you enjoy the video and alpha demo!
I've been working on a cave map for the past few days and I thought it was time to post a journal update. The cave will be composed of many connecting passages and smaller rooms. I thought it would be interesting to see one of the cave's building blocks come to existence.
1. This first image is quite important as it must conform to my 3d tile size. This particular rock has a dimension of 4x2x4. In other words it is half as long as it is wide/high. This mounts to an image size of 192x224 pixels (a tile with a width/height/depth of 1x1x1 is 64x64 pixels). Other than that this image is just a clump of grey.
2. Here the first smaller stones are outlined. I try to imagine how big I want the rocks to be in the final image and I draw from that.
3. In this image I try to flesh out the shape of the rocks. I only use 2-3 colors as it is easiest to work with at this early stage. Intricate shapes are somewhat simplified.
4. More detailing work, still only using few colors. One rather dull grey and another a little bit darker.
5. Here I fill in the areas that I want highlighted with a brighter color. Trying to accentuate ridges and creases in the rock.
6. Up until now I have only used a rather big brush. Now I begin detailing with a smaller brush. This allow for finer details. Ridges and creases get a more rough look. I also deform parts of the original shape to make it stand out more.
7. I give the rock more contrast by filling in the shadows with a dark color.
8. I thought the rock was a little too bright so I brought down the overall intensity.
9. Here I have filled in the creases between each rock with a 1px size brush and a dark colour.
10. Adding moss and earth between and on top of some rocks.
11. Final adjustment to the rock and moss. I highlighted the rock edge against the moss, making the moss stand out more.
An animated GIF created from the different steps above. It took me around 45 minutes to paint the rock from scratch.
Office 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).
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.
Crowdfunding [color=#000000][font=Arial][background=transparent]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.[/background][/font][/color]
[color=#000000][font=Arial][background=transparent]That's all for now, I need to get back to it.[/background][/font][/color] T[color=#000000][font=Arial][background=transparent]hanks for reading![/background][/font][/color]
It turned out to be a little bit more involved to scale up the GUI than I first thought. Most of my connected GUI objects (frames, borders etc.) are composed of individual quads. One quad for the upper left corner, one for the upper right corner and so on. This works fine when scale is 1:1 but when the graphics gets enlarged this creates a problem. For instance; if a pixel is scaled by 1.7 it would mean that gaps begin to appear between the quads that are not intended. I thought I could round it to the nearest integer but it turned out that it was more work than actually stitching the intended quads together with a gl_triangle_strip.
On a side note, my day job has taken most of my time lately (6 out of 7 days) but I thought this GUI scaling business would have been finished faster.. in a night or two - This did not happen. However this upcoming week I will have more spare time on my hands, so hopefully I'll get more work done too.
To add something visual to this entry, here is a fight to the death with a wild beast!!!
I have bought a Microsoft surface pro to develop on during my vacation. I found out that the game graphics needs to be resized. At native resolution (1920x1080) it was hard to click the GUI buttons, texts were very small and hard to read. So the past few days I have been implementing a scale value to all GUI elements and game graphics. Tedious and boring work but will hopefully it will be worthwhile for the player.
The graphics gets blurrier as the resolution scales up but I think it is worth it. Maybe later I will replace some graphics for these high resolution monitors.
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.
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:
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.).
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
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.
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 ([s]screen shot of this to follow within a day[/s]).
Next up is fleshing out the game's story. Writing better dialogue and decide where the demo should end.
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.
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...
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.
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!
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!!
It has been a while since my last post but I have been keeping busy. Here are some of the things I have completed (sort of):
The journal - Journal entries can be added from script. As an example, the player is engaged in a conversation and accepts a task/mission... then a summary of what was said is written. Journal entries can also have an image associated with them such as a scribble/drawing for a puzzle. The journal font have also been customized to have a more handwriting feel to it.
NPC pathfinding - A system for determining when pathfinding is needed has been implemented. A homing capability is sufficient most of the time but when the NPC get stuck or is far away from its waypoint a pathfinding search is done.
NPC inventory - Until now the inventory for NPC have been added from script, this can become rather tedious after a while. The system is still in place but some enemies will have hard-coded inventory items. Skeletons will for example always have a weapon equipped. If there were many skeletons in one area I had to script each skeleton's equipment manually, no matter if they had exactly the same things on them.
Store - I have been working on a store system. The player can drag individual items between the store and their inventory to buy or sell items. It is also possible to mark several items and only buy/sell those in one click. I have not yet settled on an "economy system"... that is how items will increase or decrease in value when buying/selling.
Collision detection - I have been fiddling around, trying to find the best shape for the player collision shape. Right now I am using a compound shape consisting of a sphere and a capsule. It seems to play nice so far. I have to be careful and not build maps so the player can get stuck.
Particle system - NPC can now spawn different or no particles when hit. For example a rat would spawn blood when hit by a sword but not when only hit by fists. A skeleton would spawn small bone/splinters instead of blood.
There is more to tell but I have run out of time. The next post will hopefully have some nice images and/or a video showing some of these things. I am aiming for a small demo in the near future.
I've been playing around in blender from time to time... just to get my mind on something else. Now I have stumbled on to a work-in-progress tool that I like to shed a light on. It can be found in a blender branch from Nicholas Bishop (a blender developer), i.e. not an official build from the foundation. It's a sculpting tool called dynamic topology that hopefully makes it to the trunk in the near future. It works almost like the other excellent 3D tool called Sculptris. The tool lets you model/sculpt like you were working in clay. You can make areas more detailed or simplified as desired and the mesh will conform to the new shape, adding triangles or removing them on the fly.
I made this crude flat-shaded head in a couple of- hmm hours? I didn't keep track of time :-P You can see the different triangulation resolution on his forehead and shoulder compared to the more detailed areas around his eyes (the triangles have disappeared in size). Anyway... It's a pretty cool tool! If you are a blender user doing sculpting I would really recommend you to try it out!
I found a build at GraphicAll.org
Hope everyone had an excellent summer. Thanks for reading! =)