CAGD 470 - Video Game Production
Sprint Blog 6
We are getting very close to the end, with only one more sprint remaining after this one, and we are all working hard to make sure Glock, Paper, Scissors looks great. Our group is still working great together and although we are excited to be close to finishing our game, we are also slightly bummed that our time as a team is almost over.
My design work was simple this sprint, as there isn't much more that needs designing. I was able to help our producer with honing in on what tasks needed assigning to hopefully get the most important things done. I did have to design our final boss, as that was the final thing we wanted to add to our game. With the help of other group members, we decided on "The Rock", a large rock body with a face and 3 floating hands that show rock, paper, and scissors, and will have different attacks.
I had 12 tasks assigned, and while I was only able to complete 8, the work I did get done added a lot to our game. The things I completed include making the gun bob when moving, having the gun shoot on click instead of holding it down, bringing in the new enemies, new powerups, and new boss, making the boss and boss hands shootable, having a boss announcement, and giving level 5 a working nav mesh.
Unlike the others, this sprint did have a fair amount of issues that slowed my production and led to me not being able to complete all my tasks. The main obstacles were enemies fading on death and importing models and textures.
The first that came up was importing models and textures, which involved around half of my tasks for the sprint. Bringing in the models and making them functional took time but worked well and didn't have issues, however, the same can't be said for the textures. For two or three of the models, the textures would not look correct and ruin the look of the models. The solution was simple, as I had to work with our modeler to reupload models or textures and bring them in and that would be enough to fix the errors. I am not sure what exactly causes these texture problems, but I am glad that the fix is easy.
New Enemy Models
The only other big problem I faced was with an incomplete task, having enemies fade away when killed instead of instantly disappearing. This task showed no mercy and wasted a lot of my time, as I was simply unable to get this to work. Our other programmer has no experience with fading objects, so he was unable to help, and even after watching and following numerous tutorials, I was still unable to get enemies to fade away. The solution, sadly, was to push the task aside and focus my attention elsewhere, since spending this much time on something that isn't necessary for a good game was hurting us, as I could have spent that time completing other tasks. I do hope to go back and find a real solution to this problem, but for now we have to keep moving forward.
Boss and Boss Hand Models
For the next sprint, we are grinding to fix any issues and get everything working, and if we have time we will refine the game all the way until it is ready to submit. I will hopefully be able to work over our week break to make up for the incomplete tasks from this sprint, but we all still have high morale and because of the hard work we are able to stress less now and are instead more excited and eager to finish.
Sprint Blog 5
In this sprint, our main goal was to get all remaining features into the game for the next playtest to make sure everything works well. This will allow us to be more relaxed in the remaining sprints and focus mostly on refinement and bug fixing. Our teamwork and communication are as good as ever, with good friendships allowing for fun and efficient development. Toward the beginning of this project, some problems emerged due to a lack of communication, but now problems are tackled immediately and are solved before causing any real issues.
Due to our team pushing to add all features by the end of the sprint, I had a good amount of designer tasks to make sure everything looked and worked as it should. This mainly dealt with the new enemies, as both programmers (Shawn and I) worked hard to get all movements and functions of the enemies working. I also had to oversee and adjust the levels, as we now have 4 levels with different themes and props so we had to ensure they would work well with the gameplay. Lastly, I had to once again work with our producer to prioritize tasks and get a better idea of what we needed to get done in the next sprints to get the best possible game.
I was assigned 11 points of work in this sprint, and I was able to complete 10 of them, leaving one point in progress. Some of the things I got done include making a swoop attack for the new scissor enemy, baking nav meshes and lights for levels 1-3, a working portal on level 3, having the new bullet UI glow depending on what bullet you're on, making lava death and a bridge shake and drop for level 4, and making a credits screen.
Like with most sprints in this project, this one went smoothly, with no spirit-breaking problems, and only small ones with quick fixes. The only issues I came across in the two weeks were UI scaling, terrain scaling, and the bridge drop.
UI scaling was the first problem, as halfway into the sprint, we realized that most of us had the aspect scale on 4k UHD, which was way bigger than needed, and when set to a more normal 1920x1080, the UI was tiny and hard to read. Our simple solution was to go back and rescale the UI, then add a canvas scale component to ensure that the problem wouldn't come back.
Next was terrain scaling, as our levels were way too big when imported, but they are made of terrain pieces, and when we would try to scale them all, they would deform, as we had to scale each one individually with the terrain settings. The only solution was for me to go into each terrain piece, scale it down to a good size, line them back up, and scale down the rest of the scene and put it in place. It took time but now all levels look great.
The last obstacle was the bridge for level 4 and making it shake and fall when the player stood on it. The idea for the level is that the bridge will shake and fall, wait 10 seconds, then come back for the player to use again. This should have been a very simple feature to add, but the bridge would not move no matter what I did. I thought it wasn't recognizing the player, but the console messages worked. After about 30 minutes, I realized the bridge was set to static for light baking, so the box collider was moving but the mesh was not. Setting the bridge as not static fixed this issue, and everything else went well and I was able to make the perfect shake and fall with easily adjustable variables.
My groupmates also did great work, and we are pushing toward a complete game. If we do it right, we should be able to get everything we want done without any crunch. We are all very excited at how close we are getting and I can't wait to see how much we get done next sprint.
Sprint Blog 4
For this sprint, my group focused heavily on fixing issues that players had during our playtesting, as well as adding more content and visual feedback to the game. We are continuing to build stronger friendships with each other which not only allows for better communication but also improves our morale and makes working together a fun experience.
I had more designer work this sprint considering we had to consider the feedback we got from players and how to deal with the major problems we had. This first involved going through the responses and finding out exactly what issues the majority of players had. From this we found that the biggest problems with Glock, Paper, Scissors were fast enemies going through walls, slow bullet speeds, game difficulty, and lack of clarity with bullet types and resource bars (health and stamina). Some of the changes made based on the feedback included making bullets faster, slowing faster enemies down, and adding screen tint flashes when the player is hit or heals. While these changes were small, they greatly improved the quality and feel of our game.
The last remaining issue to solve is confusion with bullet types. Some things that will be done include adding a more clear bullet type UI element, better explanation in the tutorial, and refining bullet and enemy colors to make it as clear as possible which bullet hurts which enemy. Besides those changes, my other designer task was to help our developer determine what tasks we prioritize moving forward to make sure we get the best game possible at the end of the semester. More specifically, we went over how many more levels to make, the remaining enemies to make, a final boss, and quality tasks like audio and art. After that meeting, we now know exactly what needs to be done in the next sprints and how much work we’ll have to do.
Aside from designer tasks, I was also able to get a lot of programming done. Of 11 assigned tasks, I completed 10, including an in-game feedback form link, gun recoil, healing and hitting screen tints, the new paper enemy and it’s shield mechanic, importing the new bullet models, and complex enemy stand-ins until we get completed models. The only incomplete task was the new scissor enemy’s movement and dive bomb mechanic, which will get done early into the next sprint.
While I had tasks in multiple areas, there were still very few issues I ran into during the sprint. The main obstacles for me included gun recoil and having the player shoot our new bullet models. I have never attempted gun recoil, so it was easy to understand that it was one of my main issues. After watching a video explaining gun recoil, I was able to get our gun to lift up when you held a button down, and return to normal when you released the button. The issue was that guns don’t stay recoiled like that, and I wanted the recoil to only happen when a bullet came out of the gun. After some code searching, I found where bullets were instantiated, and tried to somehow work the recoil into that function. I tried many different things, but finally got it to work by having a float set to a recoil duration number whenever a bullet is shot, and having the gun recoil until that float counts down to 0. With this, I was able to play with the float until I had a quick and readable recoil.
The second and less troublesome obstacle was getting the player to correctly shoot our new bullet models. After bringing the bullets in, we noticed that they wouldn’t move, but would instead be stuck in midair. I talked with our other programmer, Shawn, and we realized the bullets didn’t yet have a rigid body, which was necessary to get the direction and movement. After that was solved, the bullets still didn’t hit enemies, but would simply go through them. I checked and double checked every collider and rigid body, until I finally was that each bullet was held by an empty object for orientation, and the colliders were on the empty and didn’t actually exist. We put colliders on the bullet object, and everything worked perfectly.
For the next sprint, we are mostly focusing on finishing the new enemies, making a 4th level, and refining/fixing anything that isn’t yet completed or working perfectly. Hopefully in the next 2 weeks we can make our gameplay smoother, more readable, and a lot more fun.
Sprint Blog 3
For the past two weeks, my group has been grinding away to get Glock, Paper, Scissors to a complete electronic prototype fit for playtesting. We did a lot of the more necessary tasks last sprint, so this one mostly involved adding all the little details that would make our game look more presentable and ready, as well as tying all loose ends.
Once again, my main tasks as a designer were mostly to answer any design questions my groupmates had and fully flesh out any details I hadn't yet thought of for certain features. We were able to get a complete prototype out for playtesting, which will be done mostly by classmates, but I was also able to grab two early playtests to get a head start. They yielded similar results as the paper prototype, such as with easy-to-learn rules and easy-to-use mechanics, however, as the paper prototype was a bit too easy, the electronic version was a bit too hard. It is also nice to mention that there was only one reported bug from the playtests so far, and the bug is known to us and easy to fix.
For my programming workload, I was assigned 11 points in tasks, completing 9 of them with 2 left in progress. Some of the tasks I completed this sprint include end portal activation, portal teleporting, portal spawn message, enemies flashing red when hit, having different speeds, and being able to jump off terrain, tutorial prompts to help the player, and scene transitions. I also did several small fixes throughout the sprint, but many weren't large enough to consider a real task, nonetheless, they all helped get our game looking much better for playtests. The only tasks I was not able to complete were UI effects for two of our powerups, and they should get done early in the next sprint.
This was another smooth sailing sprint, probably the least troublesome of the sprints so far, but there were still small issues I dealt with along the way. These obstacles included slow scene transitions and players unable to click buttons. There were small hiccups elsewhere in the sprint, but the bigger problems came from the menu screens. The first that came was players unable to click buttons on the menus. This was obviously an issue, as players had to be able to press buttons to retry levels, advance levels, and exit the game. Luckily, our second programmer, Shawn, had more experience with menus from previous projects and told me the one line of code to fix it, which basically confined the cursor to the screen to the player could use it. This also was an issue in that players couldn't see the cursor, but I was able to get that one on my own, simply turning on cursor visibility when entering a menu. Slow scene transitions came next, and this was a big issue as no player wants to wait 10-30 seconds every time they enter a new scene. Shawn also helped me with this one, as he explained that the Update function was what was messing things up, and I was able to make the scene transition its own function and which made everything run much faster.
I feel like with every sprint that goes by we are becoming a more and more cohesive team and growing as friends as well as group mates. I now look forward to this class, not just because I want to make my game, but because it is fun to work with my team. This next sprint involves more polishing and refining to get the game looking and feeling amazing, and I can't wait to get started.
Sprint Blog 2
In this sprint, we focused on getting as close to a complete electronic prototype for playtesting and we did very well at that, with only small bits missing that can easily be done in the next week. Along with that, our team has been adjusting to the new school year, and we are not only getting more comfortable with each other, but we are also working more efficiently and completing more work each week.
Nav Meshes
My designer tasks this week simply involved answering any questions my team had and helping with any confusion about how things should look. I also met with our producer to make sure all tasks needed to get an electronic prototype were assigned this sprint and that everyone knew which cards to prioritize. I was able to conduct 4 in-person playtests along with having 4 online playtests. The in-person tests allowed me to get better feedback and see how people play our game. The best things we learned from playtesting were that people found the game easy to learn, enjoyed the quick gameplay, and liked having a timer along with lives, so we plan to use this feedback in making our electronic prototype better. Other than that, I mostly focused on programming and getting my cards done early for this sprint.
I was assigned 9 points worth of tasks, with 8 being completed and 1 left in progress. The only task I was unable to complete was getting a pause menu working. This card was transferred to our other programmer, Shawn, as it seemed like a better fit for him. My tasks for the sprint included making a win and loss screen, making a crosshair, having enemies rotate to face the player, making enemies take and deal damage correctly, and converting the enemies and terrain to nav mesh. The biggest of these tasks were the ones involving nav mesh, as my previous movement script worked well enough but had many problems that could come down the line and seriously hold back development, such as enemies not being able to go up ramps. Nav meshes instantly solve all of these problems, was easy to set up, and gives us more control over the enemies.
All of these tasks went relatively smoothly, but there were a fair number of issues that came with it. The main obstacles I dealt with during this sprint included enemies facing the wrong way, pause menu problems, and nav meshes working on ramps.
Crosshair
When converting our enemies to nav mesh agents, their movement worked well, but they would all look 90 degrees to the left instead of straight towards the player. The solution was quick, as I was able to make each enemy the child of an empty object, and that would allow me to turn the enemies to face the right way. Next up were issues with the pause menu, as the text would show up, but you couldn't press the buttons to continue or quit the game. I was planning on researching a solution, but we decided to transfer this task over to our other programmer, as he has more experience with pause menus. The last problem I ran into was nav mesh agents being unable to go up ramps. Enemies would follow and face the player, and would correctly move around ramps, but not up them. The solution was found through researching nav meshes, as all I had to do was set each ramp to static and re-bake the nav mesh. After that, enemies were working perfectly and I didn't run into any more issues.
Win/Lose Screens
For the next sprint, I will mostly be setting up scene transitions and making sure we are able to play through the entire game. We are doing great as a team, communicating issues and solutions between each other, and simply working hard and getting things done. So far, we are making great progress and if we keep it up, our team will have no problem reaching production goals and making a great game. I am excited for this upcoming sprint and for the rest of the semester with this awesome team.
Sprint Blog 1
In this class, we will spend the entire semester developing a game in a team of 5. I am the designer for my group, and the game I designed is called "Glock, Paper, Scissors", a first-person shooter where you shoot rock, paper, and scissor enemies with corresponding bullets to survive and win. Along with this, I am also a programmer, so most of the tasks I will be doing during the semester are coding tasks.
During this sprint, we were focused on our paper prototype and planned on only starting Unity production. We flew passed this goal and got quite a bit further into Unity than we expected. In the two weeks, I was able to complete 7 points worth of tasks, involving the paper prototype or coding in Unity. Some of the tasks I did include making the rules and pieces for the paper prototype, adding placeholder enemies and bullets in Unity, making the enemy movement, and having enemies take damage from their respective bullets.
This sprint went very smoothly, with almost no issues with completing my tasks. Some of the only obstacles I faced were with getting enemies to move correctly, making the rules sheet, and with GitHub. When the sprint started, I assumed getting enemies to follow the player would be difficult, but I was able to get it rather quickly. The only problem was that enemies would be faster the farther they were from the player and slower the closer they were, making it so the players couldn't make space but wouldn't get touched, which wasn't fun. While I haven't fixed this yet, I was able to do research and I now have a much better way to make their movement, which I will also do at the beginning of this sprint.
The next issue was with the rules sheet, as I first thought we would be conducting playtests in class and I could bring pieces. I later learned players would need everything to play the games on their own, so I had to make printable pieces and adjust the rules sheet to aid gameplay. This involved telling players more about the pieces and converting the game to single-player for ease of play. This actually made the game better, as I preferred the new version over the original.
Lastly, we did have some issues with GitHub that slowed production at the start of the sprint. Most of my group had little to no GitHub experience, so everyone had to refresh their memory on how to use and navigate it. As well as this, we did have one issue merging, and it took some time to get everything working again. Our solution to this was taking time to get used to GitHub, and using branches to keep our work separate from each other. We are also communicating more to ensure that everyone knows what is being worked on and when.
The only task that I was assigned but unable to complete was having enemies rotate to face the player while moving. I did not have enough time to get this task, so it will be the first one I complete in the second sprint. Some of my other cards for the next sprint include giving enemies health and working on victory and lose screens.
Other than the small snags we had, this has been a very successful sprint and has allowed us to get comfortable with each other. We were able to test out how everything would work in the group, so we should be able to speed it up next sprint and get even more work done. So far this is a very fun project, not only meeting my teammates but building a game completely from scratch and slowly seeing my idea come to life. I am confident that things will continue to go well and I can't wait to see how we do.
Comments
Post a Comment