The project has come to a close. We nailed our pitch and did the best we could for the playtesting session, but at the end of the day, Wands and Warheads was not chosen to go forward into the next semester. It's unfortunate. All that work we did to setup the game for success, and have it stopped before it can truly manifest. It was a long, fun trip, but it's one that ended before it was finished.
Wands and Warheads was originally made by accident. When the semester began our two potential games were a Guild Management Game and a Hardcore 2D Survival Game. As placeholder for the ranged weapons in the survival game our designer used a fireball effect, which was an unexpectedly huge hit in class. This led us to rethink our options and games, and from that came Wands and Warheads, which replaced the Guild Management Game.
For me this jump was a big switch. The Guild Management Game had been my piece of the conception phase, so it was hard to let go of. However, it would have been much harder to make work than Wands and Warheads, so it was ultimately the right decision, Once we chose Wands and Warheads to be our game going forward, I took over the map and navigation systems as my main focus, with little additions to other systems based on time and need. I also contributed to the art in the game in the form of spells and a few items.
Working on the map was an interesting graphical challenge. I had very few issues and bugs pop up that weren't graphical in nature, which is unfortunately my weakest area. I couldn't add a new feature to the map without the graphics bugging out in some way. It was also an interesting design challenge. I was left mostly alone to make the map as I please. As the game world was updated, so to was the map. However, I had to constantly reference John's plans to make sure I revealed enough info for the map to be useful, but not so much it was trivial to navigate and showed all the world's secrets. This eventually led to the balance of towns being marked while single houses were not. Since the map was so closely tied to John's work, I created the map with the intent of being easily adaptable. This worked well in the long run, since there was one week were the map was changed in some way almost everyday, and updating the map was simple since most it had handled most of it automatically.
There were certain key decisions we made this semester that pushed the game the direction it did. The biggest one was our decision to drop the Guild Manager and double down on the Survival Game with Wands and Warheads. Without that one decision, we would have ended up in a much different place, and I don't think the whole team would have been as happy with it as we are with Wands and Warheads. The next big decision is our switch from Fantasy Survival to Survival RPG. Originally Wands and Warheads was just a less punishing version of the Hardcore Survival Game with fantasy elements. This was a quick change in focus and a very easy one, but one that worked out very well and without it we could of had a very different game. It also helped differentiate the games and gave us a much more defined goal for Wands and Warheads. The last was our choice to move away from a most standard progression system and switch to an option based system. Instead of having certain weapons be better than others, they are balanced around specific playstyles. The high damage weapons carry much more risk compared to the lower damage weapons, in the form of resource use and how much you expose yourself to danger. This gave our combat a much more refined focus and made the game more fun. Being contained to a single level did make this choice easier and stronger weapons would have shown up down the line, but it would be sets of weapons instead of single ones, to keep that balance of playstyles.
Going forward into next semester, I've been placed on the team Superfluous Amounts of Spectacular. They're making Dan Shredder. While I plan to try and avoid the graphics side of things, I learned plenty about Unity shaders during the creation of my map that I could maybe apply to one of my tasks in the new team. I also learned plenty about working better with a team. We of Chimera Inc worked very well together, possibly the best team I've had in any production class, and as such I feel I learned more of what is the right way to work with others as opposed to other teams were I learned what not to do more than anything. I hope I can be a valuable asset to SAoS going forward and we make a damn good game.
Monday, December 14, 2015
Wednesday, November 18, 2015
Week 10: Final Progress
We have entered the final week. No more major changes are being added by the team to minimize risk. Everyone is focusing on polish and bug fixes, myself included.
To start off the week, I found a multitude of tracks for the team to pick from to replace our current game music. Our placeholder music has been replaced with something more official and rights free. Should we choose to do so in the future we can compose our own score, but this music will keep us from running into any legal trouble.
I made a few more fixes related to the marker system. The text on the markers is finally working, however a new bug has popped up related to the shader. It is incompatible with the text and only renders the text as a black box. Currently I have not been able to pinpoint a fix so the text is currently disabled. If a fix can be found before the final pitch then it shall be applied, but only if it does not break anything further.
I also worked on a quality of life change of being able to delete specific markers using the marker menu. I almost had a solution within the current system, but it would not find the markers it was supposed to. However, it is applicable under a new, marker specific system that can be done should our game go forward. The backend work required means this needs to be put on hold for now to minimize the risk at this point in development.
Should anything new pop up that is game breaking I shall work toward fixing it in these last few days, but for now all looks well from my end and I can lend more assistance to my team in their endeavors should they require it.
To start off the week, I found a multitude of tracks for the team to pick from to replace our current game music. Our placeholder music has been replaced with something more official and rights free. Should we choose to do so in the future we can compose our own score, but this music will keep us from running into any legal trouble.
I made a few more fixes related to the marker system. The text on the markers is finally working, however a new bug has popped up related to the shader. It is incompatible with the text and only renders the text as a black box. Currently I have not been able to pinpoint a fix so the text is currently disabled. If a fix can be found before the final pitch then it shall be applied, but only if it does not break anything further.
I also worked on a quality of life change of being able to delete specific markers using the marker menu. I almost had a solution within the current system, but it would not find the markers it was supposed to. However, it is applicable under a new, marker specific system that can be done should our game go forward. The backend work required means this needs to be put on hold for now to minimize the risk at this point in development.
Should anything new pop up that is game breaking I shall work toward fixing it in these last few days, but for now all looks well from my end and I can lend more assistance to my team in their endeavors should they require it.
Tuesday, November 10, 2015
Week 9: End in Sight
The game is starting to wrap up in preparation for our final pitch in a few weeks. We have brought together all our necessary features and the bugs are being squashed.
One particularly stubborn bug on my end, lighting showing up on the map, has finally been fixed. Last week I got a shader to remove the lighting, but it distorted the colors of various props. Nothing seemed to work. Fixing the colors caused the lighting to return while removing the lighting would just re-break the colors. At one point I had even removed some colors and rendered them as just white with a black outline. My final solution ended up being a simple one, instead of trying to keep the map's normal colors I applied a color filter to the whole thing. I gave it a sepia tone to look more like an old, faded paper map. The color issues were masked and the lighting was completely removed.
I also fixed another bugs related to entering buildings, where the mask applied to the player camera also applied to the map. My last change directly to the map was adding and removing specific structures from the map. This is to give the player something to find and keep track of with their markers.
Onto the markers themselves, I have completed their final iteration for the time being. I would have liked to do more, but fixing the maps bugs was more important since the markers at least worked as intended, they just lacked extra functionality. Some of my original goals are in place, but the rest has been put on hold. If was are chosen to continue development after our final pitch, I will give the markers the full functionality they deserve.
One particularly stubborn bug on my end, lighting showing up on the map, has finally been fixed. Last week I got a shader to remove the lighting, but it distorted the colors of various props. Nothing seemed to work. Fixing the colors caused the lighting to return while removing the lighting would just re-break the colors. At one point I had even removed some colors and rendered them as just white with a black outline. My final solution ended up being a simple one, instead of trying to keep the map's normal colors I applied a color filter to the whole thing. I gave it a sepia tone to look more like an old, faded paper map. The color issues were masked and the lighting was completely removed.
I also fixed another bugs related to entering buildings, where the mask applied to the player camera also applied to the map. My last change directly to the map was adding and removing specific structures from the map. This is to give the player something to find and keep track of with their markers.
Onto the markers themselves, I have completed their final iteration for the time being. I would have liked to do more, but fixing the maps bugs was more important since the markers at least worked as intended, they just lacked extra functionality. Some of my original goals are in place, but the rest has been put on hold. If was are chosen to continue development after our final pitch, I will give the markers the full functionality they deserve.
Tuesday, November 3, 2015
Week 8: Unity Documentation Woes
This week, I was pretty much going in blind for all my tasks. Having done very little with Unity's UI, I needed to learn a lot from scratch. What I couldn't have predicted is how little Unity 5 seems to have out there. I've spent up to an hour just to find the replacement for a method found in every Unity answer and tutorial. Others are so vague it takes incredibly specific searches to finally find that single answer that actually explains what is happening. Unity 5 seems to have shaken up more than I expected, and I lost a decent amount of time to searching in circles.
The marker system is finally resembling what I envisioned it as. Markers are limited on the map. They are given a unique color to be easily differentiated on the map. They still require names and I'm considering a warning popup to let the player know a marker is going to be removed when they hit the cap. Choosing which marker to remove would be the ideal situation, but this simpler system works for now.
Lighting bug is still a problem, though now for different reasons. I was able to get replacement shaders working, but all the ones I have tried so far distort the colors of the objects that are visible on the map. I've tried a few different edits to fix the colors but they make no difference, so I'm probably missing something in relation to how these shaders are working. As soon as I figure out the color issue I will probably use it to apply a "map" look. Just having them working as mostly intended is a great start though, and it can be easily tinkered with going forward.
Tuesday, October 27, 2015
Week 7: Adventures in Unity UI
A new week, a new task. This week the team decided it would be a good idea to add the finial systems and refine those we have already completed to be in a more complete state. I was to look back at the map and refine the markers system. The way they work now is a rough implementation, and it makes it too easy to navigate. The bug with lighting also needs to be removed so the player can no longer cheat with the flashlight to find their position on the map.
First, the markers. Current implementation lets you spam markers while also placing an infinite amount of them on the map. If you spam placed them while moving you can create a trail that lets you know the exact path between different points. You still have to remember the general landmarks along the path, but it's a power that can be abused. Under the new system, you would have a limit on the markers you can place, but the markers would be nameable so you know exactly what each was for. This requires a lot of UI work, something I'm not very good or familiar with. The marker keybind needs to open a menu instead of just placing the button. The menu will have the name of each marker with a second way to identify it on the map, probably by color. It will also have a button to add a new color and a box to enter the name for that marker. This is all new ground for me, and still requires a lot of work to complete.
Next, the lighting bug. I've looked around a lot, but something I did not anticipate was that almost all my searches would turn up outdated info. In the switch to Unity 5, Unity also made drastic changes to its shader system. None of the previous solutions exist in Unity 5, so I need to create my own solution. I have the advantage of not know shaders in previous versions of Unity so it's all new for me, but I still have a bit to learn and tinker with. If I can't come up with a working solution through shaders, I can fall back on the pre-render/post-render functions for the map's camera.
Going into next week I will continue working on these problems and have them complete in time for our next stage challenge.
First, the markers. Current implementation lets you spam markers while also placing an infinite amount of them on the map. If you spam placed them while moving you can create a trail that lets you know the exact path between different points. You still have to remember the general landmarks along the path, but it's a power that can be abused. Under the new system, you would have a limit on the markers you can place, but the markers would be nameable so you know exactly what each was for. This requires a lot of UI work, something I'm not very good or familiar with. The marker keybind needs to open a menu instead of just placing the button. The menu will have the name of each marker with a second way to identify it on the map, probably by color. It will also have a button to add a new color and a box to enter the name for that marker. This is all new ground for me, and still requires a lot of work to complete.
Next, the lighting bug. I've looked around a lot, but something I did not anticipate was that almost all my searches would turn up outdated info. In the switch to Unity 5, Unity also made drastic changes to its shader system. None of the previous solutions exist in Unity 5, so I need to create my own solution. I have the advantage of not know shaders in previous versions of Unity so it's all new for me, but I still have a bit to learn and tinker with. If I can't come up with a working solution through shaders, I can fall back on the pre-render/post-render functions for the map's camera.
Going into next week I will continue working on these problems and have them complete in time for our next stage challenge.
Tuesday, October 20, 2015
Week 6: Onto the Next Step
We have successfully completed our first stage and begun to work toward stage two. We have gone forward with out Magical, more RPG oriented survival game; Wizards and Warheads. The team is all incredibly excited to turn our full attention on this game. We have great plans and we can't wait to see them all implemented and functioning.
Last week I made a map. This week I made a better one. The previous map worked as a proof of concept, but was ultimately useless for what we wanted it to achieve. This new map is much more robust and adaptable to our level. It's easily editable by the designer as he makes changes to the overall map. It was done using the layer system in Unity, a system I have never used before and honestly did not know existed. By creating and setting layers, the camera used to display the map can ignore specific objects in the playspace that should not be shown on the map. The same applies to the player camera, map specific objects are ignored while the rest are displayed.
I added a marker system to the map to take advantage of the layer system. Players can place these on their map to mark important landmarks they might find along their travels. This can be used to help a player navigate the level and keep track of their target, the large boss monster terrorizing the towns. I had planned on using a different marking system that allowed the player to draw directly on the map, which would have made tracking the monster easier but much more fun as well. Unfortunately it was buggy, imprecise, and ultimately did not work with the way I was creating the map.
I also did some more rune art. Two runes made it in based on the style of the current fire rune, but I have decided to remake all the runes in a new style to work better with our magic system. The current rune style is not easily expandable beyond those we have now, but my new concepts will allow for a much greater number of spell runes.
Last week I made a map. This week I made a better one. The previous map worked as a proof of concept, but was ultimately useless for what we wanted it to achieve. This new map is much more robust and adaptable to our level. It's easily editable by the designer as he makes changes to the overall map. It was done using the layer system in Unity, a system I have never used before and honestly did not know existed. By creating and setting layers, the camera used to display the map can ignore specific objects in the playspace that should not be shown on the map. The same applies to the player camera, map specific objects are ignored while the rest are displayed.
I added a marker system to the map to take advantage of the layer system. Players can place these on their map to mark important landmarks they might find along their travels. This can be used to help a player navigate the level and keep track of their target, the large boss monster terrorizing the towns. I had planned on using a different marking system that allowed the player to draw directly on the map, which would have made tracking the monster easier but much more fun as well. Unfortunately it was buggy, imprecise, and ultimately did not work with the way I was creating the map.
I also did some more rune art. Two runes made it in based on the style of the current fire rune, but I have decided to remake all the runes in a new style to work better with our magic system. The current rune style is not easily expandable beyond those we have now, but my new concepts will allow for a much greater number of spell runes.
Tuesday, October 13, 2015
Week 5: Plans in Motion
The prototypes are finally coming together. We have completed our discipline reviews and are on track to enter the next stage of development with one of our games. The team is in full agreement on which we will take forward starting tomorrow as we bring in the finishing touches for both games.
This week I had a goal that seemed simple on the outside but in reality was much more complicated, especially in a 2D space. I was tasked with making a map for the player to reference during gameplay. The map itself was simple. However, the hard part comes with our secondary goal, making the map slowly reveal itself as you explore. For 3D games this is easy since you can use multiple layers and remove a mask using ray casting. In 2D this is not possible in the same way, though perhaps it can be done off screen using relative coordinates. This will be a goal for next week.
I've also volunteered my non-existent art skills to help with some assets for the game. Having no artist we have to work with what we have, and I'm confident enough in the little ability I have to make a few assets for the game.
I think we are finally not only on the right path but a unified one, and I can't wait to see where we will take our game in the coming weeks.
This week I had a goal that seemed simple on the outside but in reality was much more complicated, especially in a 2D space. I was tasked with making a map for the player to reference during gameplay. The map itself was simple. However, the hard part comes with our secondary goal, making the map slowly reveal itself as you explore. For 3D games this is easy since you can use multiple layers and remove a mask using ray casting. In 2D this is not possible in the same way, though perhaps it can be done off screen using relative coordinates. This will be a goal for next week.
I've also volunteered my non-existent art skills to help with some assets for the game. Having no artist we have to work with what we have, and I'm confident enough in the little ability I have to make a few assets for the game.
I think we are finally not only on the right path but a unified one, and I can't wait to see where we will take our game in the coming weeks.
Tuesday, October 6, 2015
Week 4: Switching Gears
The team has spoken, and the guild manager has been shelved. Progress was not moving along fast enough for any of us and we have decided to focus on a branch of the Survival Game for our second prototype.
This branch will contain magic. Various spells can be used at the cost of health and resources. It will be a more fantastical take on the survival game we already had. The other branch will continue along a more standard survival game path.
For me, I've spent most of my time becoming familiar with the prototype and learning how to change and add to it's systems. I'll be tweaking the systems and added some extra complexity to them as I learn where all the turning points are. We will soon be making our final decision on which branch to move forward with, so both must be in the best condition we can get them in.
Wednesday, September 30, 2015
Week 2 and 3: Delays and Complications
The game has gotten off to a rough start. None of this is the team's fault, this squarely falls on me and my troubles these past few weeks. Programming wise, what has been done in the game hasn't been too difficult. Marquee selection ended up being incredibly simple after I did all the necessary research and at that point selecting single units was a few extra lines of code. Swapping between scenes worked without a hitch. Much of the time spent wasn't even in the code, it was tweaking the camera speed and angle to best suit each scene and its controls.
Now, in to the issues the problems that have gotten this game off to a rough start. First would be communication. In week two this was a big issue because Andrew was unsure how to talk with me about what he should do on the project, and as such we lost any potential work he could have added programming wise. He did get all the documentation done though so not all was lost. We fixed this in week 3, starting with our first meeting where we outlined which pieces of the current project each person would work on, and during the week when we used our slack group to ask each other questions about the specific direction the game was going.
Second would be a mix of time management and life just getting in the way. Between work and classes, I have a fairly busy schedule week to week. As such, I try to set aside time to work on homework for class and on programming this game. Last week I was behind on both and with the class happening earlier in the week than the week two deadline, I put my attention on that first. All fine and dandy, except I was so tired from lack of sleep that I was unable to finish the work I had started on the game in time for the team's review. The next day I made sure everything was done and ready for our team meeting, but it was still technically late. This week was another monster all together. During the week my roommate seriously injured himself and needed to be taken to the Emergency Room. The time was 2 am. I did not sleep that night which was immediately followed by one of my most exhausting days at work yet. I fell asleep as soon as I got home and lost the entire day's worth of free time, time I had planned to use on the game.
Now, both these situations could have been mitigated is I set aside time earlier in the week. I need to work a lot on my time management in these coming weeks for not only this game but whichever we choose to go forward with. Right now it's not looking good for this one even though I personally feel it has a stronger and more manageable direction. By the end of next week though both games should be in the spot we want them and we will choose from there.
Now, in to the issues the problems that have gotten this game off to a rough start. First would be communication. In week two this was a big issue because Andrew was unsure how to talk with me about what he should do on the project, and as such we lost any potential work he could have added programming wise. He did get all the documentation done though so not all was lost. We fixed this in week 3, starting with our first meeting where we outlined which pieces of the current project each person would work on, and during the week when we used our slack group to ask each other questions about the specific direction the game was going.
Second would be a mix of time management and life just getting in the way. Between work and classes, I have a fairly busy schedule week to week. As such, I try to set aside time to work on homework for class and on programming this game. Last week I was behind on both and with the class happening earlier in the week than the week two deadline, I put my attention on that first. All fine and dandy, except I was so tired from lack of sleep that I was unable to finish the work I had started on the game in time for the team's review. The next day I made sure everything was done and ready for our team meeting, but it was still technically late. This week was another monster all together. During the week my roommate seriously injured himself and needed to be taken to the Emergency Room. The time was 2 am. I did not sleep that night which was immediately followed by one of my most exhausting days at work yet. I fell asleep as soon as I got home and lost the entire day's worth of free time, time I had planned to use on the game.
Now, both these situations could have been mitigated is I set aside time earlier in the week. I need to work a lot on my time management in these coming weeks for not only this game but whichever we choose to go forward with. Right now it's not looking good for this one even though I personally feel it has a stronger and more manageable direction. By the end of next week though both games should be in the spot we want them and we will choose from there.
Wednesday, September 16, 2015
Let the Games Begin: Ideation and Iteration
A new year. A new team. A new game to create.
When said like that it all seems so simple, yet game development rarely is. For a ragtag team of three programmers, a designer, and a producer, we have a blessing and a curse. We lack a dedicated artist. This means we are free to create what we want gameplay wise, but on the flipside we won't have any art to back it up if the gameplay alone falls flat. However, we have enough programming power to create something fairly complex and special, so we headed into the ideation phase with high hopes.
That's the thing about ideas though, they are cheap and anyone can make one. Many of our ideas fell into this category. Two stood above the rest when all was said and done, a 2D Survival Game and a Guild Management Simulator. We had also considered a form of Tower Defense, but some of the ideas were adapted into a potential direction for the Survival Game. Art wise, these games could be rough, but we plan on sticking to a simpler, almost pixel art style to keep the art load low but still presentable.
The Survival Game is fairly simple on the outside, survive the dangers present in the world around you. The complexity comes in with our potential design directions. The dominant choice right now is to have a city system. The player could enter the cities and interact with the townsfolk, but ultimately have to head back into the wild after and indeterminate amount of time. The cities themselves would change overtime as well, with some cities completely disappearing off the map due to some natural disaster. We have also considered having base building that must be defending from roaming enemies. Possible settings include post-apocalyptic for something closer to Earth or a Rim World for a more science fiction feel.
The Guild Management Simulator is the idea I am the most attached to and have contributed the most to design wise. Set in a Fantasy or Medieval setting, you are the Guild Master ad you must recruit adventurers to help you complete jobs and clear out dungeons to keep the guild running. It's a two part game. On the management side you send adventurers out to autonomously complete jobs given to you by Non-Player Characters(NPCs), maintain and build up the guild, as well as recruit new members. You can decide what rooms you want in the guild to best maximize your members effectiveness and where they are located. There will be a main hall in which you can choose a specialization that will help the guild attract more members, make more money, or somewhere in-between. This room can be customized as well which might have an effect on how effective your specialization is. On the other side is the combat missions. These take place in the Dungeon, a multi-tiered structure found in the city that is infested with monsters. The combat system will be a variation on the standard Real Time Strategy (RTS) style gameplay. Defeating a combat mission earns great rewards than those normally received from sending your guild members on jobs. It also unlocks the next floor of the Dungeon and allows you to send parties of adventurers to clear the defeated floors. This game would benefit from both a 2D or 3D style, and the one that is chosen will greatly influence how we design the game later on if we chose to go forward with it.
We hope to have both prototypes done by this time next week so we can make our decision on which game to move forward with. And then the real fun begins.
When said like that it all seems so simple, yet game development rarely is. For a ragtag team of three programmers, a designer, and a producer, we have a blessing and a curse. We lack a dedicated artist. This means we are free to create what we want gameplay wise, but on the flipside we won't have any art to back it up if the gameplay alone falls flat. However, we have enough programming power to create something fairly complex and special, so we headed into the ideation phase with high hopes.
That's the thing about ideas though, they are cheap and anyone can make one. Many of our ideas fell into this category. Two stood above the rest when all was said and done, a 2D Survival Game and a Guild Management Simulator. We had also considered a form of Tower Defense, but some of the ideas were adapted into a potential direction for the Survival Game. Art wise, these games could be rough, but we plan on sticking to a simpler, almost pixel art style to keep the art load low but still presentable.
The Survival Game is fairly simple on the outside, survive the dangers present in the world around you. The complexity comes in with our potential design directions. The dominant choice right now is to have a city system. The player could enter the cities and interact with the townsfolk, but ultimately have to head back into the wild after and indeterminate amount of time. The cities themselves would change overtime as well, with some cities completely disappearing off the map due to some natural disaster. We have also considered having base building that must be defending from roaming enemies. Possible settings include post-apocalyptic for something closer to Earth or a Rim World for a more science fiction feel.
The Guild Management Simulator is the idea I am the most attached to and have contributed the most to design wise. Set in a Fantasy or Medieval setting, you are the Guild Master ad you must recruit adventurers to help you complete jobs and clear out dungeons to keep the guild running. It's a two part game. On the management side you send adventurers out to autonomously complete jobs given to you by Non-Player Characters(NPCs), maintain and build up the guild, as well as recruit new members. You can decide what rooms you want in the guild to best maximize your members effectiveness and where they are located. There will be a main hall in which you can choose a specialization that will help the guild attract more members, make more money, or somewhere in-between. This room can be customized as well which might have an effect on how effective your specialization is. On the other side is the combat missions. These take place in the Dungeon, a multi-tiered structure found in the city that is infested with monsters. The combat system will be a variation on the standard Real Time Strategy (RTS) style gameplay. Defeating a combat mission earns great rewards than those normally received from sending your guild members on jobs. It also unlocks the next floor of the Dungeon and allows you to send parties of adventurers to clear the defeated floors. This game would benefit from both a 2D or 3D style, and the one that is chosen will greatly influence how we design the game later on if we chose to go forward with it.
We hope to have both prototypes done by this time next week so we can make our decision on which game to move forward with. And then the real fun begins.
Wednesday, April 29, 2015
Programming for the Oculus Rift
Virtual Reality has always been a dream of mine since I started playing video games. Imagine not just playing a game but living it. I couldn't hope for anything better. In today's world, that dream is starting to become a reality. The Oculus Rift might not be true virtual reality, but it certainly is a step in the right direction. It is a virtual reality headset, immersing the player in their game world and giving them control over the rotation of their frame of view by turning their head. It's the first piece of the VR puzzle, and this past month I was given a chance to develop a small game demo for one.
Now first time setup for an Oculus Rift is not an easy process, like any other new peripheral. This was made more difficult due to the age of the graphics card I use in my desktop, but once that hurdle was passed the rest fell into place easily. Once the Oculus was connected and working with the desktop I tested it in a few compatible games and demos. This confirmed that the device was in fact working and gave me a better idea of what sort of game would work best with the Oculus.
The first proto-type was going to be a simple First Person Role Playing Game (RPG). The player was easy and setup fairly quickly, but when I tried to add vehicles everything started to go wrong. The Unity plugin for the Oculus Rift does not deal with multiple camera sources very well. Trying to rename the cameras so they were easy to find just ended up with those cameras being ignored and new ones being created under the default name. Linking the camera's directly to a public variable instead of trying to find them dynamically didn't work much better. Now at this point I could have just scrapped the vehicles and gone forward with the RPG, but they were and important part of my game's design. I had also been recently inspired by Elite: Dangerous to try a Space Simulator, so I decided to save all the usable code and changed up the prototype.
My second and final prototype is a simple Space Sim Demo. 6 Stars and one planet make up this small star system. The player can fly around all of them looking for 7 spaceships. these ships can be destroyed with your laser. It takes 5 shots to kill a ship and currently they just circle around their spawn point. I considered making both an aggressive and passive AI, but I didn't have time to tune the them so they were left out for now. The aggressive AI was too good at killing the player and the passive AI wasn't compelling to chase down.
In the end, I ended up with a nice little prototype that can easily be expanded to include more planets, more star types, and better AI. I also learned how to setup a game for use with the Oculus Rift, which was my main goal going into this. If I ever need to make a game for the Oculus again in the future I will be prepared to do so.
Now first time setup for an Oculus Rift is not an easy process, like any other new peripheral. This was made more difficult due to the age of the graphics card I use in my desktop, but once that hurdle was passed the rest fell into place easily. Once the Oculus was connected and working with the desktop I tested it in a few compatible games and demos. This confirmed that the device was in fact working and gave me a better idea of what sort of game would work best with the Oculus.
The first proto-type was going to be a simple First Person Role Playing Game (RPG). The player was easy and setup fairly quickly, but when I tried to add vehicles everything started to go wrong. The Unity plugin for the Oculus Rift does not deal with multiple camera sources very well. Trying to rename the cameras so they were easy to find just ended up with those cameras being ignored and new ones being created under the default name. Linking the camera's directly to a public variable instead of trying to find them dynamically didn't work much better. Now at this point I could have just scrapped the vehicles and gone forward with the RPG, but they were and important part of my game's design. I had also been recently inspired by Elite: Dangerous to try a Space Simulator, so I decided to save all the usable code and changed up the prototype.
My second and final prototype is a simple Space Sim Demo. 6 Stars and one planet make up this small star system. The player can fly around all of them looking for 7 spaceships. these ships can be destroyed with your laser. It takes 5 shots to kill a ship and currently they just circle around their spawn point. I considered making both an aggressive and passive AI, but I didn't have time to tune the them so they were left out for now. The aggressive AI was too good at killing the player and the passive AI wasn't compelling to chase down.
Revisiting Multi-threading
Last year I took on a project to add multi-threading to a pathfinding AI simulation. While moderately successful, the simulation ran into problems with the number of threads created when I increased the counter in the function controlling their creation. With the goal of improving this functionality in mind, I took it upon myself to fix it and have a much more robust multi-threaded system.
The reason for the crashes was because the program had run out of memory, but I had thought I had accounted for that case within the program. Turns out my implementation was wrong and stemmed for one simple misunderstanding of how the threads were working. When I created the threads I would detach them until the counter hit max, and then wait for that one to join before detaching more. This is where everything went wrong.
I was assuming each of the detached threads would finish before the one I was trying to join. This was not the case. Detaching anymore than one thread before joining the next caused them to pile up faster than the system was ending their processes, burning through the available memory. Such a simple solution that had avoided me at the time due to my poor understanding of exactly how joining and detaching threads worked.
With my new found understanding of detaching and joining threads I relocated the thread creation and set them up in a better management function. This one allowed all the necessary threads to be created without running out of memory. Now my program could create as many threads as necessary without crashing.
The reason for the crashes was because the program had run out of memory, but I had thought I had accounted for that case within the program. Turns out my implementation was wrong and stemmed for one simple misunderstanding of how the threads were working. When I created the threads I would detach them until the counter hit max, and then wait for that one to join before detaching more. This is where everything went wrong.
I was assuming each of the detached threads would finish before the one I was trying to join. This was not the case. Detaching anymore than one thread before joining the next caused them to pile up faster than the system was ending their processes, burning through the available memory. Such a simple solution that had avoided me at the time due to my poor understanding of exactly how joining and detaching threads worked.
With my new found understanding of detaching and joining threads I relocated the thread creation and set them up in a better management function. This one allowed all the necessary threads to be created without running out of memory. Now my program could create as many threads as necessary without crashing.
Subscribe to:
Posts (Atom)