This week has been much more productive than those previous. I finally cracked the problem of a function I've been working on the past couple weeks. I stumbled a bit with forward declarations because I've rarely used them in previous projects. I usually just avoid situations were they are needed. I worked my way through it though and came to a working solution.
Then there are the quirks of Unreal. Unreal is not very consistent with how you access member variables, with some being behind a get function while others are just free to call directly. In blueprints these all look the same, further increasing my confusion. Once I figured them out though it was easy to slot all the pieces in where they belong.
I then moved on to the next unclaimed function that needed to be moved over to C++ from blueprints. Using my new found knowledge, this was much easier to go about and I completed it in short order, which the code necessary to expand it's functionality commented out until the necessary class was also moved into C++.
However, after all this was done, we have decided to scrap the C++ re-write. The team realized it would be a constant uphill battle to not only move over the current code base, but also keep up with the new features. It is better for everyone to go forward with what we have, optimize the game in other ways, and stick to blueprints and scripting.
Sunday, March 6, 2016
Thursday, February 25, 2016
Problems and Pause Menus
This week was an interesting one. I was tasked to make a pause menu. So far I had only edited existing menus, not made one from scratch, so it proved to be a fun application of what I had learned. The pause menu itself wasn't too difficult, but the logic to get it working and switch between menus was new ground. I was able to get it in and working as intended, but getting it to return the game to the main menu proved to be much more difficult. Not only that, but my second task interfered with this one, causing myself and my team mates to lose valuable time.
Now, my second task was to move one of the blueprint functions on out fretboard to the C++ class. I picked it up fairly quickly, but ran into trouble finding out how to retrieve the target enemy. After I was pointed into the right direction, I set about making the needed function to use it in the fretboard. It was at this time I was asked to make the pause menu return to the main menu instead of closing the game when you hit the quit button. Not seeing any errors in my build, I commented out the changes just in case and committed the build so I could pull the changes our designers made before changing the pause menu logic. I thought I had it figured out and went to build, only to run into a very vague and useless error message. Somehow during my commit or the merge, I'm still not sure which, this very nasty bug appeared. It completely broke the build for myself and others. We spent a couple hours trying to fix it, each of us who were effected testing where it could have appeared and possible solutions. Kyle was the one to finally figure it out and fix the issue, but by then the damage was done and we all lost a lot of valuable work time. Neither of my tasks were able to be completed for the new build, putting us behind when we are already trying to pull it all together in the C++ classes.
Fortunately there should not be much left to either task, so they can be completed quickly barring unforeseen issues. I'll have to work harder this coming week, and hopefully we will be ready to move onto new content by the end of next week.
Now, my second task was to move one of the blueprint functions on out fretboard to the C++ class. I picked it up fairly quickly, but ran into trouble finding out how to retrieve the target enemy. After I was pointed into the right direction, I set about making the needed function to use it in the fretboard. It was at this time I was asked to make the pause menu return to the main menu instead of closing the game when you hit the quit button. Not seeing any errors in my build, I commented out the changes just in case and committed the build so I could pull the changes our designers made before changing the pause menu logic. I thought I had it figured out and went to build, only to run into a very vague and useless error message. Somehow during my commit or the merge, I'm still not sure which, this very nasty bug appeared. It completely broke the build for myself and others. We spent a couple hours trying to fix it, each of us who were effected testing where it could have appeared and possible solutions. Kyle was the one to finally figure it out and fix the issue, but by then the damage was done and we all lost a lot of valuable work time. Neither of my tasks were able to be completed for the new build, putting us behind when we are already trying to pull it all together in the C++ classes.
Fortunately there should not be much left to either task, so they can be completed quickly barring unforeseen issues. I'll have to work harder this coming week, and hopefully we will be ready to move onto new content by the end of next week.
Friday, February 12, 2016
UI Shenanigans: Week Three
This week I had a change in focus. Being weak in Unreal I moved to a slightly easier task, changing over to the new UI assets and fixing any bugs that were there. For something so simple however, I had the hardest time just getting the assets in. Turns out I was going it the completely wrong way, so once I was set back on the right path it was easy to get everything in.
Now, in proper Unreal fashion, it couldn't be simply left at that. In Unreal's menu widgets, there is a display option for buttons called hover. When your hovering over a button it will change to a different asset, which we have so you know the button is selected. However, this only works with a mouse, and not the controller. The controller selection is not considered hovering, so another workaround is needed.
To do this, I had to manually change the default image to our selected image and back again when your on another button. This is done in blueprints with a function that breaks apart the button style and rebuilds it using the desired image. However, we ran into another couple problems. The first, and most important bug is that the game completely locks up due to the button constantly switching every frame. We need to either find an event that will rarely be fired, or set it up related to inputs. The other bug, is that it's not actually using the images correctly, and just setting the button back to default values. This is less important though because it doesn't break the game, like the previous bug.
Hopefully next week we will have these bugs squashed. I am also going to start trying to combine some of the separate menu widgets into one.
Friday, February 5, 2016
New Semester, New Game: Week One and Two
An new semester, and a new game. After the end of last semester, unfortunately the game my team was working on wasn't chosen to continue development and we were moved onto other teams. The team I ended up on was Legitimate Studios, and their game is Dan Shredder in Hellzone. It's a game that uses a Guitar Hero controller alongside a DDR Dance Pad to fight and defeat enemies. Fairly innovative and very fun, they chose to make the game in Unreal 4, an engine I had little experience with up until now.
The first week was very low key. We had our first couple official team meetings, where everyone got to meet each other and we began planning what we would need to do within our disciplines. Myself and the the other programmers decided the most important thing to do was to move all the blueprints into C++ classes. Blueprints are significantly slower and use up a lot of resources, so this switch would improve the game's performance by leaps and bounds. We also decided on the various roles each programmer would cover. Dan and Kyle would work on systems, Cody would work mainly on gameplay, and I would fill in where needed with a current focus on the gameplay side.
As I mentioned at the beginning, I had not worked much in Unreal 4 before joining the team. Much of my time these past few weeks has been learning not only about the systems in the project, but also learning how to use Unreal. My current two tasks are focused around the blueprints, which gives me ample time to learn how to use them and how to move the game away from relying solely on them. It hasn't been easy at first, but very rewarding. This is a great first step for myself and the team, and I cant wait to see where our efforts will take us.
The first week was very low key. We had our first couple official team meetings, where everyone got to meet each other and we began planning what we would need to do within our disciplines. Myself and the the other programmers decided the most important thing to do was to move all the blueprints into C++ classes. Blueprints are significantly slower and use up a lot of resources, so this switch would improve the game's performance by leaps and bounds. We also decided on the various roles each programmer would cover. Dan and Kyle would work on systems, Cody would work mainly on gameplay, and I would fill in where needed with a current focus on the gameplay side.
As I mentioned at the beginning, I had not worked much in Unreal 4 before joining the team. Much of my time these past few weeks has been learning not only about the systems in the project, but also learning how to use Unreal. My current two tasks are focused around the blueprints, which gives me ample time to learn how to use them and how to move the game away from relying solely on them. It hasn't been easy at first, but very rewarding. This is a great first step for myself and the team, and I cant wait to see where our efforts will take us.
Monday, December 14, 2015
Postmortem: Wands and Warheads
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.
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.
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.
Subscribe to:
Posts (Atom)