The game is up for voting by the general public (on Steam, that is):
If you have an active Steam account, please consider voting in favor of the game so that I can hopefully sell it on the largest digital game distribution network of the world.
Thanks!
Bad news first: I have suspended all work on In Charge! for now. Considering my budget constraints and many breakdowns over the last 9 months, I would not have been able to complete the game. However, I have not been sitting around idly since the last post. To get myself motivated, I had started a rather simple, but compelling prototype. Since the core mechanics of that game are much less complex, I feel confident that I can complete it until March when my budget ultimately runs out. And this is what it’s all about:
The basic premise is a shoot of a Hong Kong Blood Opera (a.k.a “Heroic Bloodshed”) style movie action sequence . The player chooses a music track as the background music for the scene. Based on that track, an environment is generated and populated with stuntmen and pyrotechnics. Additionally, the chosen track will be analysed for bass and drum cues. On such cues, the player presses displayed buttons to shoot their guns. In essence, it is a mash-up between the games Max Payne, Guitar Hero and a dash of Audiosurf.
Check out these screenshots to get an impression:
Gas Bottle Explosion
Fire Extinguisher Explosion
Squibs!
If you would like to try it with some of your favourite music (must be MP3 for now), head over to the cTool website’s “Games” category and check the download links (cTool). If you do not know the password for the download, please request it from me via the address provided on that page. Any feedback is appreciated!
Week number 26… half a year I have been working on this project. A lot has happened in that time, even though these past six months appeared to have flown by in an instant. I wish I could have worked more, or more efficiently. However, I realize that everyone has their limitations and I can be no different. I am clearly behind my own schedule but will not accept this as an inevitable failure. There is still a lot that I can and will accomplish.
As for the actual progress since the last update: I have re-designed the task system around conversations and a couple of jobs can now be functionally assigned to settlers. Watch the following clip to see it in action:
Settlers currently start out as gatherers by default. They will seek out and collect freely available resources and drop them off at a nearby storage. In the clip, I make one of the settlers a worker. His job is then to build whatever I had planned and restock any objects which require resources (e.g. the camp fire).
I intend to keep jobs at a high level of abstraction to take the burden of micro-management off the players. You should be more interested in the general well-being of settlers and their loyalty rather than a perfectly efficient economy. The game should take care of that for you.
Next, I am going to implement more of the jobs and rework the initial settlement quest to correctly reflect the system changes.
Thanks for reading!
This week, I have integrated an open source dialogue system component (Fungus) which has replaced my previous, rough implementation. Starting from my coarse flow chart of last week, I have created a more elaborate dialogue tree for NPC interactions:
WIP Conversation Flow Chart
Most of the blocks in the diagram above already have some (or a lot of) logic behind them. A conversation can be started and navigated but most of the actual NPC behavior is not yet triggered. The following screenshot shows a couple of options from the dialogue tree above:
Dialogue Example
The conversation UI’s look and feel is still set to the component’s default. Changing that has little priority at the moment, however.
I did not manage to connect the conversation results to actual behaviors, but I do plan to make that happen next week. It is about time for a new video clip, anyway…
Thanks for reading!
What a ride this last month has been… Sometimes, our lives just unravel in an instant. Priorities shift and we just need time to get our shit together. I will spare you the usual philosophical musings about misery, change and human resilience. Suffice to say, I got back to working, albeit only little, this week.
I started out re-visiting the gathering task issue: players must be able to instruct settlers to gather resources and drop them off at a suitable storage. First, I wanted to define a target area for gathering jobs and them somehow add a modifier for the target resource. I outlined the prototype interface for that in week 10. Here’s a look at the very rough implementation of a target area:
Area Targeting
However, when looking at the required programming effort I also took a step back and considered the players’ interaction with such a system (being a few weeks off a project provides a new perspective). I realized that it would be horrendously tedious to set up dozens of tasks this way. This also goes against the principle of indirect control which the entire game is supposed to be built upon.
So… where does that leave us? Basically, I will scrap the task system (certainly the UI part) in favor of a more intuitive and fuzzy way. Tasks will, at least in the early stages of settlements, be given directly to settlers via conversations. E.g. “I need you to build stuff I have planned and keep it repaired. Follow me to the area around which you are supposed to work. Ok, here we are and this is how much you will get to keep doing that. Alright?”. Later on, this should be delegated to taskmasters, i.e. dedicated staff under players’ control which automatically keep things running according to the parameters set out by the player in charge. This will also provide a layered hierarchy of loyalty, which players need to look out for. The guard captain, for example, might develop his own ambitions if he is given too much freedom in running things.
For now, I have done some work on the task definition system, from which I will try to salvage as much as possible. Additionally, I have drafted a rough flow chart for conversations which helps in the definition of the upcoming, more complex, conditional conversation trees.
Next week I will improve the conversation system and try to get some of that complexity into it. Lots of very specific state variables will be relevant, e.g. when should an NPC follow, what influences task rewards. I hope to be able to show some exemplary interactions in the next update.
Thank you for reading and until next week (for real!)
It was a slow week. I just could not stay focused. Some smaller issues have been resolved, though:
Animations are still somewhat borked:
Animation Fail
What is happening here is that some of the animations have movement and offsets encoded within them. If not properly compensated, it leads to flying dorks which are supposed to look around on the ground.
I will take another look at animations and add some more NPC behaviours. I would like to be able to assign generic gathering tasks to NPCs, combined with a drop-off at a storage pad.
Thanks for reading and I hope I will soon be able to show more stuff again…
My life just kind of imploded during the last two weeks. I had to take a few days off. Afterwards, I dug into a task which required my full attention, as a way of getting my mind off of any other issues…
So what did I work on, then? Merging coplanar triangles on terrain geometry.
Those of you who are familiar with 3D graphics will already know that all geometry in games is made from triangles of varying sizes and orientations (at least currently, there are approaches using mathematical boundary functions to define volumes of theoretically infinite precision). Triangles consist of three vertices, which hold some more information than just a three-dimensional position. One of the many bottlenecks in real-time graphical rendering is the amount of vertices which an application needs to display at any moment. Therefore, any approach which can reduce vertices at loading time will yield better performance at run time. It is best explained with an image:
Before and after shot of terrain geometry
In the image above you will recognize the fine-grained mesh on the left from one of my earlier posts when I explained how the terrain is built using pre-defined building blocks. This mesh contains lots of triangles which lie on the same plane and whose vertices hold exactly the same information as their neighbors, save for their position. On the right, only the minimally necessary amount of vertices and triangles are retained. No geometry detail was lost, but it is no longer possible to smooth normals around >=90° angles as before. Normals are shared along much further distances and the visual effect is rather unpleasant if I were to smooth them out.
The experts among you will wonder how I solved the problem of UV coordinates, since terrain is usually textured using a texture atlas and UVs would just get mangled and invalid during vertex merges. I completely avoided the issue by ignoring UVs altogether. Instead, the terrain shader now uses full tri-planar mapping based on world coordinates, which is totally fine for static geometry like terrain. The texture atlas tile index is simply encoded into the vertex colors, which the shader can interpret and apply.
Because I have not done a single thing I set out to do, please see the last post for my next tasks: http://incharge.ctool.ch/2016/07/22/week-16-recap/
Thanks for reading!
There is little to show this week, but fortunately not due to lack of progress. Most of the work I have done was under the hood or would make boring presentation material. The initial “quest” line for the game start has been expanded with two new steps. I have also added a stockpile building, which serves as a drop-off point for commonly used resources which can be accessed by anyone. The rest of my time has been spent on fixing or improving some minor aspects (some animations, more highlighting, showing proper labels for interactions instead of “activate”, fixing the floor display issues for good, zooming out when selecting targets, etc.).
While writing this, I have also finished a shoddy version of a jump and ledge grab move. No more reloading when you spawn in a pit on a new map! Yay! For reference, and for those who may find this interesting, here is the current animation graph:
Animation Graph
Since my backlog keeps growing, I will concentrate on whittling that down a little:
Also, here is a little concept shot of a log cabin at night under a full moon:
Cabin at night
As always, thanks for reading and until next week!
The recap is late, but I got everything done which I had planned last week. Building planning creates blueprints, which can be built manually or by tasking settlers with it. The following clip shows a construction-ready blueprint (only ground floor is shown at the beginning) being constructed piece by piece:
As you can see, the navigation is already updated while building and the NPC can find the next part to build (although somewhat insecurely at times…).
Next week I will concentrate on enhancing the start of the game and parts of the UI. The player’s starting task should include setting up a task to have the initial camp fire tended to and building a first dwelling. I might also wire up some animations to the characters. The current building process is jarringly abrupt. Also, the floor management and display still has some issues which I would like to iron out…
Thank you for reading and until next week!
Although last week was cut a bit short, I made some nice progress. All basic building elements are now working together nicely. The uConstruct component is excellently done, which facilitated all necessary modifications and extensions.
The most important addition to the building system was the concept of floors. The component was originally intended for a first-person perspective (as seen in e.g. Fallout 4 or Rust). From a top-down perspective, visibility of elements becomes an actual concern. Floors (or their elements) are now made transparent if they obstruct visibility for building or navigation. See the following clip for a demo of constructing and navigating a complex building:
Another important addition is the building interface, as seen in the clip, which is still quite raw but exposes the most important functions.
Next week I will take on the proper building finalization, i.e. saving a plan will create a blueprint. I also intend to implement the construction task for NPCs and player interactions to construct elements themselves. Whenever an element is finished, NPCs should also become aware of them for navigation purposes.
As always, thanks for reading!