Voi Has Been Released!
Some of you may remember a previous post of mine introducing Anomalia. To be developed with fellow students and friends, Pat, Jared and Jackson for our final project as a team we've coined vec1. Quite a lot has changed since then, I'll be covering off what I've been working on specifically and what our future plans are for the project. If you haven't already picked up on it, the obvious change is our new name. Voi, as our codename Anomalia was difficult for people to pronounce consistently. Keep in mind that when I refer to the duration of production or development, I am referring to the period from the beginning of production up to now. That is the trimester having just been for us as students, to have completed final project.
I made a post on my adventures implementing reflections around halfway through development, just before we changed focus from technical to content creation. In saying that, the majority of my contributions have chiefly remained technical. While I would like to have had more input, I found myself at a blank and decided not to force ideas prematurely. This did allow me to focus more on producing code, despite having limited time due to work and commitments from outside of my studies. I did make some additions earlier on regarding level creation and prototyping, all of which of course with either discarded or overhauled. The menu scene and hypercube are some of my remaining assets in our current release.
Development of Voi took place simultaneously on Windows and Linux. With both Jared and I having maintained separate Windows builds, using Visual Studio 2015 and 2013 respectively. The current x64 releases for Windows are builds deployed from my end, which I have made an effort to keep as stable as possible. Testing and fixing any issues that arise as soon as new code is pushed. Release of a 32-bit version for Windows is under way from Jared's end, with a native Linux version planned in the near future. The current release however, does indeed work under Wine. I will be upgrading to Visual Studio 2015 at some point myself, due to far better C++ 11 support than its older 2013 counterpart.
Two features originally started by Pat that I completed, are checkpoints and what we internally refer to as "Half-Life points". Checkpoints are similar to a quick save and may be placed anywhere throughout a level. In the event of falling, you are returned to where you left off when last passing through a checkpoint. "Half-Life points" were coined from the pause when switching between different chunks of level in one of my favourite games, Half-Life 1. They do exactly that, allow us to break up levels into scenes independent of one another. For both performance reasons and ease of editing levels. Aside from a subtle delay, the player is able to walk between scenes almost seamlessly.
One of the technical issues that we had for far too long were glitches when walking through portals, occurring as the player intersects with its clip plane on the way through. It was crucial for this transition to be seamless, otherwise it felt like a teleporter and took away from the player experience. Make no mistake, our lead programmer Pat did an exceptional job. These glitches were due to the limitations in the way that rendering is currently handled, so I set out in the final few days to come up with a fix. The complication was that both worlds on either side of a portal, could not be rendered simultaneously. This would require rewriting the way that portals work, which we didn't have time for this close to our deadline.
For a brief moment, the world on either side of a portal would disappear into a void that was most noticeable when walking through sideways. My solution was to prevent the player from being able to stand in the clip plane for too long. This was achieved by slightly nudging the player through the portal depending on the angle in which they entered, as it was less of a problem when facing straight ahead. Even if the clip plane sat behind the near clip plane of the camera, when facing forward what could be seen was the world as intended on the other side and not the portal edges. Rendering is also halted during the frame in which world layers are swapped, an ugly hack but one that was necessary and worked surprisingly well given the alternative.
Next up were minor changes to the player, primarily fixes such as an attempt to solve a double jumping bug that we had for an unsettling amount of time. Adding to that was camera shake that can be toggled or set to fade over a period of time as required. This is used for visual feedback whenever an interaction occurs, such as the activation of switches to open doors or bell ringing. Other updates I'd made were fullscreen support and various performance enhancements in particular with particles. What we arrived with at the end was a game engine that worked well enough technically and certainly acceptable for our first release.
Most of my time from that point on was spent testing and bug fixing in further preparation, as the game was to be distributed online and showcased in a student exhibition. The response that the project received after being released publicly, has been a refreshing experience to say the least. Fortunately during the latter half of production, we managed too move forward and shift back on track. This happened after scheduling issues, that led up to a rescope in order to meet our deadline. We had always planned to continue on with development, especially now given how well the response has been and produce a product that holds true to our vision.
As mentioned, the scope of the project did change and less prioritised features were cut. Like any developer, this is not something we wanted to do but did plan for it. Having an already clear understanding of how and where each feature fitted in, allowed us quickly identify those considered critical to the end experience. Contrary to those that were just desirables and could be scrapped with minimal effect, in order to still fulfil what design goals remained. Our plan short term is to continue improving existing content, carrying out bug fixes and engine refinement from input and issues reported both from within the team and by third party users.
There are sections that will eventually be rewritten to accommodate new ideas and overcome current limitations. The way in which our rendering manager works, severely limits the number of portals and mirrors that can occupy a scene at any given time for example. There are certainly improvements to be made here before new content is produced. I also plan on refactoring the reflections code along with the addition of streaming, allowing for a much larger number of mirrors to be present. Only those closest to you will get drawn, weighted by the angle that they are visible from.
Long term, we are currently going through an experimental stage to see what works and what doesn't. Trying out ideas that we hadn't previously had the chance to and wish to explore in depth, before taking production further. Above and below are a couple of preview shots from experimental maps, trailing ideas and getting a feel for different environments. The island is Pat's work and the city my own, built as a proof of concept and to hone my Blender skills. It will also prove to be an ideal test map when the time comes to rework reflections, given the large number of mirrored surfaces on the sides of buildings.
You may have noticed that the Voi engine does indeed support colours! But enough from me now, the first major version has been released on itch.io - go and check it out!
I made a post on my adventures implementing reflections around halfway through development, just before we changed focus from technical to content creation. In saying that, the majority of my contributions have chiefly remained technical. While I would like to have had more input, I found myself at a blank and decided not to force ideas prematurely. This did allow me to focus more on producing code, despite having limited time due to work and commitments from outside of my studies. I did make some additions earlier on regarding level creation and prototyping, all of which of course with either discarded or overhauled. The menu scene and hypercube are some of my remaining assets in our current release.
Development of Voi took place simultaneously on Windows and Linux. With both Jared and I having maintained separate Windows builds, using Visual Studio 2015 and 2013 respectively. The current x64 releases for Windows are builds deployed from my end, which I have made an effort to keep as stable as possible. Testing and fixing any issues that arise as soon as new code is pushed. Release of a 32-bit version for Windows is under way from Jared's end, with a native Linux version planned in the near future. The current release however, does indeed work under Wine. I will be upgrading to Visual Studio 2015 at some point myself, due to far better C++ 11 support than its older 2013 counterpart.
Two features originally started by Pat that I completed, are checkpoints and what we internally refer to as "Half-Life points". Checkpoints are similar to a quick save and may be placed anywhere throughout a level. In the event of falling, you are returned to where you left off when last passing through a checkpoint. "Half-Life points" were coined from the pause when switching between different chunks of level in one of my favourite games, Half-Life 1. They do exactly that, allow us to break up levels into scenes independent of one another. For both performance reasons and ease of editing levels. Aside from a subtle delay, the player is able to walk between scenes almost seamlessly.
One of the technical issues that we had for far too long were glitches when walking through portals, occurring as the player intersects with its clip plane on the way through. It was crucial for this transition to be seamless, otherwise it felt like a teleporter and took away from the player experience. Make no mistake, our lead programmer Pat did an exceptional job. These glitches were due to the limitations in the way that rendering is currently handled, so I set out in the final few days to come up with a fix. The complication was that both worlds on either side of a portal, could not be rendered simultaneously. This would require rewriting the way that portals work, which we didn't have time for this close to our deadline.
For a brief moment, the world on either side of a portal would disappear into a void that was most noticeable when walking through sideways. My solution was to prevent the player from being able to stand in the clip plane for too long. This was achieved by slightly nudging the player through the portal depending on the angle in which they entered, as it was less of a problem when facing straight ahead. Even if the clip plane sat behind the near clip plane of the camera, when facing forward what could be seen was the world as intended on the other side and not the portal edges. Rendering is also halted during the frame in which world layers are swapped, an ugly hack but one that was necessary and worked surprisingly well given the alternative.
Next up were minor changes to the player, primarily fixes such as an attempt to solve a double jumping bug that we had for an unsettling amount of time. Adding to that was camera shake that can be toggled or set to fade over a period of time as required. This is used for visual feedback whenever an interaction occurs, such as the activation of switches to open doors or bell ringing. Other updates I'd made were fullscreen support and various performance enhancements in particular with particles. What we arrived with at the end was a game engine that worked well enough technically and certainly acceptable for our first release.
Most of my time from that point on was spent testing and bug fixing in further preparation, as the game was to be distributed online and showcased in a student exhibition. The response that the project received after being released publicly, has been a refreshing experience to say the least. Fortunately during the latter half of production, we managed too move forward and shift back on track. This happened after scheduling issues, that led up to a rescope in order to meet our deadline. We had always planned to continue on with development, especially now given how well the response has been and produce a product that holds true to our vision.
As mentioned, the scope of the project did change and less prioritised features were cut. Like any developer, this is not something we wanted to do but did plan for it. Having an already clear understanding of how and where each feature fitted in, allowed us quickly identify those considered critical to the end experience. Contrary to those that were just desirables and could be scrapped with minimal effect, in order to still fulfil what design goals remained. Our plan short term is to continue improving existing content, carrying out bug fixes and engine refinement from input and issues reported both from within the team and by third party users.
There are sections that will eventually be rewritten to accommodate new ideas and overcome current limitations. The way in which our rendering manager works, severely limits the number of portals and mirrors that can occupy a scene at any given time for example. There are certainly improvements to be made here before new content is produced. I also plan on refactoring the reflections code along with the addition of streaming, allowing for a much larger number of mirrors to be present. Only those closest to you will get drawn, weighted by the angle that they are visible from.
Long term, we are currently going through an experimental stage to see what works and what doesn't. Trying out ideas that we hadn't previously had the chance to and wish to explore in depth, before taking production further. Above and below are a couple of preview shots from experimental maps, trailing ideas and getting a feel for different environments. The island is Pat's work and the city my own, built as a proof of concept and to hone my Blender skills. It will also prove to be an ideal test map when the time comes to rework reflections, given the large number of mirrored surfaces on the sides of buildings.
You may have noticed that the Voi engine does indeed support colours! But enough from me now, the first major version has been released on itch.io - go and check it out!
Comments
Post a Comment