CAGD 470
Chicken Scramble - Sprint 6
Sprint 6 was mostly a sprint with not a lot to do. I basically had everyone finish up everything they needed to do on the project. Programmers always have stuff to do, but it was a little bit difficult thinking of things for the others to do, since there’s no time to fully implement a new level design and there’s not much of a point in adding new models. It was also time to start working on the marketing images, so I had a person on the team start on those. Since I’m the person who works on the UI, I thought it would be a good idea to begin working on making the menus look a little prettier. I bet players don’t want the default Unity UI in their game.
Figuring out things to do for the modeler and the texturer were somewhat difficult. We were able to find some textures that needed to be done that happened to have slipped through the cracks previously, which was good. But in the next sprint, there’s basically nothing to do. For the modeler, I had him mostly focus on getting the mazekeeper model completed with textures and animations. I understand it was quite a daunting task since modeling a humanoid is kind of difficult. He’s not an animator at all, so going to Mixamo seemed really scary for him, despite me trying to convince him that it was extremely easy to use it. It automatically rigs the model and you get to use a bunch of animations already made for you!
 |
| Mazekeeper Walking. |
I remember our level designer mentioning at the beginning of the semester that he was going for an art minor, so I thought it would be a good idea for him to start working on the marketing images. In this sprint he finished working on the poster and the title logo. I think the title logo looked pretty neat, but the poster could’ve still used some work. As a producer, I always feel stuck between sending something back to “in progress” or marking it as complete because I really don’t want anybody spending too much time on one task when they could be using it on something else. As long as the idea is conveyed, it’s good enough.
 |
| Marketing Poster |
In this sprint, I worked on making the start menu and the level select menu look more polished. I had a lot of fun messing around with funny fonts and adding nice looking backgrounds. I looked up royalty free textures online and edited them in Photoshop to be seamless so that they would repeat and not look weird in Unity. The start menu uses a leafy vibe and I was able to use the title logo to make it look even better! The level select menu uses a picnic-like vibe with the gingham behind the levels and the canvas texture for the background. Also, one thing I found out in Unity is that you can make the UI fit any aspect ratio if you select the Expand option in the Canvas settings. I remember when I was playing Frogs of Rage last year the UI getting cut off by the monitors really irked me, so I really wanted to avoid UI issues in this game.
 |
| Start Menu |
 |
| Level Select Menu |
Another thing I also did with the UI is attempt to change the resolution of the fullscreen mode according to the aspect ratio of the display the game was on. Previously, I had it set to 1920x1080 in both windowed and fullscreen mode. If you were playing on a monitor that wasn’t 16:9 (like on the classroom monitors), you’d see some ugly black bars on the sides, and the game may or may not look somewhat fuzzy. Essentially what I did was make the game find the aspect ratio of the display and then multiply it to get a resolution in fullscreen that doesn’t make it lag. Before I added the toggles for the fullscreen and windowed modes, the game would lag in an unplayable manner on fullscreen. In the next sprint, I’d like to be able to make it so the player can edit the resolution through the multiplier I used in case they aren’t happy with the current one.
Chicken Scramble - Sprint 5
For this sprint, I mainly focused on getting the build to work and did some more work on the UI. To be honest, I feel like the team’s output in this sprint was not too great. Although, that was probably only because the last sprint’s output was really great. I usually remind the team to get at least one thing completed on the board so it doesn’t look like they spent 5 days doing nothing. Because there was a class that was canceled, people aren’t going to use that time to focus on the project, so I was unable to approve any work for nearly a week. I don’t really like to bug people on that since I know everyone’s extremely busy, but it was really concerning to me. We were able to make it up in the second week of the sprint, but consistency is important.
In the last sprint blog, I talked about how the build was incredibly laggy, which would definitely have an impact on how a player would play the game. I looked at the Unity profiler, which told me that VSync was making it spike really hard. Weirdly enough, no matter what I did, the build kept lagging. I turned it off in the project, and it didn’t work. I messed with the 3D rendering settings of the graphics card and it still didn’t work. What I didn’t realize was that the build was lagging only on desktop computers, and it was because of the monitors. Usually, my teammates use powerful desktops with several monitors. When I first made the build, I tested it on the high-performance computer at the library, which resulted in lag. I asked a teammate to test it out to make sure and they also reported the lag issue on their desktop.
 |
| Lag in the build. |
In class, we tested it on their work laptops, and the game actually ran perfectly fine, which was really surprising to me. I was able to fix the lag issue in this sprint by adding in an option for the player to play in windowed mode or fullscreen mode. I set the resolution to 1920x1080, because anything higher would make it lag. There’s still a bit of screen tearing, but it’s not going to mess with the game. Although, now that that ‘s solved, we now need to focus on improving the performance of the game because I’m starting to see some actual spikes from our code in the profiler.
I improved the level selecting transitions a bit more since the way I previously had it was really rudimentary. I was rushing it near the end of the previous sprint, so it was just some spaghetti code that said “if this level is inactive, set the other level inactive”. This time, I made it so that all the levels are in a list and the level that’s selected is activated and the rest are made inactive. So, we can add in new levels without needing to change the code. But at this point, we won’t really be able to add in anything new, which is really unfortunate.
 |
| The code I wrote for enabling levels. |
Since the next sprint is the last sprint that we’ll have enough time to work on the game, I hope we are able to get everything in. We still have some textures to improve and we still need to add in a rating system so that players can see their previous times. I don’t think the team is going to slow down, but since we are nearing the end of the semester, work is going to ramp up from other classes and people need to spend time on those
Chicken Scramble - Sprint 4
For this sprint, the goal was to get a new level in. We have it in there, and you can play through it, but obviously it’s still unfinished. I spent the entire night before sprint review thinking that we needed to get it done right now, so I ended up rushing the programmer to fix a bug with the mazekeeper transitioning to the next level (which he did but he ended up forgetting to do some of his own homework that was due that day). I feel really bad about rushing him, but the act of putting together a new build actually turned out to be a good idea. When I tested the build out on the high performance computers in the library, the frame rate was absolutely terrible. It’s a good thing I saw this problem now and not later when we actually do need the build out.
At the moment, I’m not exactly sure what is causing the bad frame rate. In our game, we’re putting all the levels in one main scene so that we don’t have to mess with scene transitions when we want to switch to a new level. Just teleport the locations of the player and mazekeeper! At first, I thought it was the new level in the scene bogging down the performance, so I quickly cobbled together some spaghetti code to disable the currently unused level. That didn’t seem to do anything. Our modeler did mention that he’s made games with way more models and higher poly counts, and those did not have performance issues. I did a quick search on Google and people suggested turning off VSync, which also did not work. I’ll need to look at the Unity Profiler later as soon as I can.
Other than that, the main dev work I did in this sprint was getting the levels to transition correctly. The way we’re doing it is just teleporting the locations of the mazekeeper and the player. The levels also enable and disable depending on which level the player is currently on. I ended up rushing this part near the end of the sprint, but in the future I can make it better very easily. Creating the transitions was a little more difficult than expected because I thought I could use scriptable objects to hold all the info about the levels, but they won’t work with scene objects, so they were largely useless. Moving the player was very easy, but the mazekeeper kept getting stuck to the first level’s NavMesh when I tried to teleport it to the new one, so I had to ask a programmer to fix it as quickly as possible.
 |
| More Item Sprites |
I also improved the menus a bit and did some more art. The back buttons on every menu use the same back function, except for the victory screen to level select transition. The way I have it set up, the game manager only keeps track of the current menu open and the previous menu opened. Each time a menu is opened, the manager takes note of it and takes note of the previous menu opened. The options menu is accessible from the level select menu, which is accessed by the victory screen when you finish a level. You can click the level select menu button in the victory screen to open the menu, and go back, it’ll work. But if you access the options menu and go back to the level select menu, the back button in the level select menu won’t go back to the victory screen, because the previous menu recorded in the game manager is the level select menu.
Anyways, I’m quite proud of the work that the team did this sprint. The team did a lot and worked really hard!
For this sprint, the goal this sprint was to improve the mazekeeper AI and then add in items. From the playtest of our core gameplay prototype, we had learned a few things, mainly that the mazekeeper was way too aggressive. As for the dev work I did, I started work on creating the level select menu and sprites for the items that the player gets.
Players liked our prototype, which was great. They said it was very easy to understand. One critique was that the mazekeeper was way too aggressive. If it gets you near the spawn point, you’re essentially softlocked there since you’re always close enough to the mazekeeper for it to chase after you. The task of programming the AI was a more challenging and time consuming task, so instead of having it chase you if you are in its line of vision, it chases you if you are a certain distance away from it. Because I was rushing a bit to build the prototype, I inevitably ended up missing some things. One was that the mouse sensitivity was much too high. Luckily, I was able to fix that very easily and made it something that was adjustable through the options menu.
 |
| Mouse Sensitivity Check |
The other thing was that the player was able to jump way too high, so they could literally just skip through the entirety of the maze. In our playtest form, we put a question that asked the player what time they got playing the maze, but because of this jump ability, it pretty much rendered this question moot. Although, because the jump was so high, we decided that it would be a good idea to make it a powerup! But this time, you can only jump in place so you can use it to get a nice view of the maze and not skip the whole thing.
 |
| Jump Ability |
Creating the level select menu was a lot more difficult than I expected. The layout of the menu in the wireframe ended up being a bit more than I could chew, so I was unable to finish the entire thing within the sprint. I laid out all parts of the menu, but didn’t get all the functionality down. I was able to make it so that the levels could scroll infinitely through the menu, but I wasn’t able to make the selection arrows work correctly. I wanted to make them select a level and move the image for that level to the center, but the image wouldn’t move to the center. The buttons to go to the start menu and the “back” button don’t work yet since I ran out of time to make the start menu and program the connections. I was trying to make an all purpose back button function so that players could navigate to a menu and then go back to the previous menu accessed when they hit the back button, instead of a button that points to a specific menu. I had a bunch of trouble getting the logic correctly, so I was unable to finish that before the sprint ended.
 |
| Level Select Menu Scroll |
Making sprites for the items was something I had much more confidence in. They were very easy to think up and draw, but one thing I really don’t like is how small they always seem to look in the game view. This time I decided to make the size of the item views a bit bigger, but they still look like they've shrunk. I’m not really sure how to fix it without covering the player’s view of the maze, so I suppose I’ll have to leave it until the very end.
 |
| Invisibility and Wall Breaker Sprites |
As we get into the later half of the dev cycle, it’s going to be a bit difficult to assign modeling and texturing tasks, as well as level design. At this point, we’ve pretty much made most of the models that we’d probably need for the game. Designing more levels would probably take up too much time, seeing as the hexagonal maze that we wanted to make just wouldn’t work for some reason. The texturer told me that he would be ok if we needed to take on programming tasks (which we do always need), but programming is a very difficult job to take on and he hasn’t taken 380 unlike the programmers we do have. Our goal for the next sprint is to add in the rest of the planned items and allow players to access the second level.
Chicken Scramble - Sprint 2
For the second sprint, the goal was to make a level ready for the playtest. The development was quite turbulent as I feel that most of the work ended up getting rushed at the end, but we were able to meet the goal and have something ready. What I mainly did was design some more menus in the game and then combine everyone’s work in Unity so that we would have the level ready to playtest. I ended up staying up late making sure that there was everything needed to have the core game mechanic in the prototype.
For the UI menus, I created a pause menu and an options menu. The pause menu was fairly straightforward. All I put in there were continue, options, and back to level select buttons. Although, I saw that in one of my other teammates’ example menus, he included a restart button, so I’ll have to incorporate that in the future. We were planning on making the pause button be able to unpause while on the pause menu, but I wasn't able to get it working for some reason, so I suppose it might be something that will have to be cut or worked on in the last sprint.
 |
| Pause Menu |
For the options menu, I made it really colorful so that it has some style to it. I followed the wireframe and added options to toggle the gameplay HUD, change its controls, and remap controls. So far, the only functioning option in the menu is turning the HUD on and off. One thing I learned is that when you enable a menu in a scene, it will put itself over the menus that are currently enabled. I thought that it would stick to its place in the hierarchy, but you have to code that in when you enable it. Something I want to include in the future is a mouse sensitivity option. On my computer, I have my mouse a bit more sensitive than usual, so the camera moved so fast that a small movement was an entire rotation of the character.
 |
| Options Menu |
The main bulk of my work ended up being near the end of the sprint, when I took the duty of combining everyone’s work in Unity. The main reason for this is because I kept getting into the pitfall of “Oh no, I forgot about this! I need to include it right away.” I’d think at one point, I’d be finished with everything that’s needed, but nope, I forgot something! This has kind of been the mood for most of my planning since I know that I haven't gotten everything written in the backlog. And then when I assign tasks to people, I end up writing new things for them since I remember every single thing we need.
The first thing I noticed is that we didn't have a victory screen, so I went and cobbled it together. And from there, I also realized that we didn't implement keeping track of time in the maze, which was an important part of the mechanic. So I coded that really quickly. I also realized that the key collection wasn't connected to the gameplay UI, so I did that.
 |
| Victory Screen |
The mazekeeper was added near the end of the sprint since it took a while for the programmer to figure it out. I had forgotten to assign him the task to have the mazekeeper triggering you to start from the beginning of the level, so I had to take that task. It would have been really easy, but my computer didn’t seem to want to cooperate with Unity that day. I wanted to use an empty Game Object that the player would teleport to when it hit the mazekeeper, but Unity would corrupt the project if I did that for some reason, so for now, I had to make it teleport to a specific coordinate on the level.
As for the next sprint, I’ll be working on getting the level select menu and the start menu laid out. The level select menu will probably be a bit more fancier than what we’re used to creating since the wireframe shows a scrolling menu that you have to move through with clickable arrows, but it’s doable. I really hope that I can plan better for the next sprint so that combining everyone’s work for the prototype doesn’t end up being a last minute effort again.
Chicken Scramble - Sprint 1
To start off, this first sprint was kind of disorderly. Since we’re using a completely new project management tool with no prior experience, it took some time to get used to (and still getting used to it). I suppose for my other teammates it wasn’t a big deal but it was an added pound of stress to my shoulders as the producer. To add to that, there was some confusion between me and the designer as to what the whole game idea and aesthetic was.
My original idea for the game was a multiplayer maze in which the goal was for two players to compete to get to the other side of the maze. We could have ways for the players to mess around with each other, like using door switches to open and close doors. To clear up the confusion on what we were building, we set up a meeting to talk about it. To prepare, I made a design map of what I thought it should look like. (In the picture, the blue dots are door switches, yellow dots are checkpoints, and the red dot is where the enemy spawns. Blue lines are doors). I also asked the designer to draw up a map on what his vision of the game was like, but he didn’t do that (which was more than a little annoying).
 |
| Design Map of Original Idea |
The designer questioned if it was truly fun for a player to get to the other side of the maze. He argued for a more single player experience, and that it’d be better for players to start in the middle of the maze and escape. I decided to concede to that since most playtesters are most likely not going to be playing with someone else. Multiplayer would have to be a wish.
The mobile app is really non intuitive since it lacks a lot of the organization that’s in the website. A lot of the features of Jira are hidden which wastes a bunch of time that I could be using writing down user stories and making sure I have everything organized (which I still don’t feel like I do). For example, the “complete sprint” button wasn't in the default view of the board when I tried to end it and I couldn't edit the sprint, but when I changed to the enhanced view, it was there.
Comments
Post a Comment