Week 5 - Actually Challenging

Senior Team Week 5 (9/28-10/5)

This week was very important because this was the last chance to challenge the first stage before the break. Missing this deadline would have left us with 5 weeks to complete the rest of the game we chose. Knowing this we focused ourselves on hitting every item we had failed to finish for last week, we also improved our prototypes.

The feeling of this week was mostly paperwork and dialogue. I spent some time revising TRAs and other documentation based on feedback from the practice presentation we did in class last week. The main issue was the suggestion that Isometric cameras were easier to do in Unity than I had previously believed. After researching the matter I discovered Unity's built in system for creating a Isometric camera, however my research did not turn up a solution to the issues caused by the Isometric camera.

I also made the GIFs of the Plant game for the presentation, this was an interesting and sometimes frustrating experience.  Learning how to make GIFs and how to use fraps was simple but figuring out the little eccentricities was an annoying task. In the end though I came away with enough good gameplay footage to make two satsifying GIFs.

The decision for which game we would go forward with was the hardest decision we had to make so far. We each made our case for our currently favored game, we were just barely in favor of the Mech game. The next step we took was to formally cast our votes in light of the previous cases we had made. It came down to a 2-2 split between the Mech game and the Finnish game, Aidan was the deciding vote. In the end we went forward with the Mech game.

Also Kody made an amazing piece of concept art for the Mech game.

Week 4 - Challenge Prep

Senior Team Week 4 (9/21-9/27)

This week was both momentous and a letdown. On the one hand we got a lot of details that had been resisting actualization for a while, and we made a lot of progress with our documentation. On the other hand it didn't feel like we made much progress with the demos. During our meetings it felt like we were on fire, outside of our meetings, tasks were easily accomplished and then it felt like I was stumped for what to do next.

For Senior Team projects, each team has to convince their teachers that they have gone far enough with their game to continue to the next stage. It is a combination of test and assignment. If we don't understand and haven't worked on our own project enough then it does not go forward. Each team has to complete all the stages over the course of the semester to be eligible to present at the end of the semester and potentially continue on to the next semester.

We had initially hoped to challenge the first stage of the semester on the 28th but we fell shy of our goal.  Early in the week we determined where each of our prototypes stood and what other materials we needed to complete to successfully challenge. For me it was writing the initial Technical Risk Analysis for the Plant game and the Finnish game. For the group in general it was prepping for the presentation. The TRAs were a good and simple exercise that helped me understand how I was seeing the projects and their risks. As a group however we all got so caught up in our individual tasks that we completely forgot to prep for the presentation. This group failure was a part of why we decided not to challenge the first stage on the 28th.

Weeks 2 & 3 - Exploration

Senior Team Weeks 2 and 3 (9/7-9/20)

At the beginning of this sprint we decided which three games we were going to carry forward. We decided on a plant themed 2D side-scroller, a twist on the mech* genre where two players pilot the same mech and The Escaped Finnish Slave. The group decided that the Finnish game would make more sense to prove as a paper prototype, this would also allow us to feel out how the game would play before we committed ourselves in code. We decided that to make the best use of our two programmers we should each focus on one of the remaining games. Splitting our efforts allowed us to work more efficiently but reduced our communication. I think that the plan has worked out but it could easily have gone the other way. That one of my ideas made it to this stage helped pull me into the group. I still didn't always voice my opinions during the first week, but I found my footing in the end.

Plant Game:

A 2D side-scrolling, platforming adventure game where the player has a gun in each hand that the player can fire. The player can only aim one gun at a time.

This idea baffled me at first. Initial details had been light and I did not understand what differentiated the game from it's inspirations. As the newest member of the group I had thought that the ideas that the team had thought up during their summer brainstorm had been more fleshed out. I felt like I was feeling my way in the dark beyond the base mechanics. I did get input and help from the rest of the team when I needed it. We were also struggling with the art direction for this game which left me feeling rather isolated. For the first week I didn't even have any idea what the main character was. During our meeting on 9/14, I brought these problems up. We were able to settle on a general art direction and soon after I knew what the main character was and what he/she were fighting. After we started to get a feel for the art, the rest of the game started to fall into place. The movement system has proved to be difficult to nail down. Movement had already changed once by the end of the first week. After consulting with Micheal** I came up with a third system that felt much better. This third method has so far worked together with other mechanics in a simpler manner.

When we presented our game ideas during our Discipline meetings this game was generally thought to be the most in scope. We did get another important piece of feedback from the faculty though. Platformers, especially side-scrolling platformers have been done to death as senior games. If we go with this idea we will have to get the mechanics perfect or we will likely fail to continue on to the next semester.

The Mech Game:

A 1st(ish) person mech game where the mech is operated by a pilot and an engineer. This game started as a multiplayer battle arena game and is currently a coop mission based game.

The group unanimously voted to make this one of our three game ideas. Despite our shared enthusiasm for this project we were told during our Discipline meetings that this game was wildly out of scope. I have had less involvement in the coding side of this game so far. The main idea that we have been iterating within this game was the role of the second player. A crucial aspect of this game is making both roles fun, neither role should be the role everyone wants to play. When we started we loaded the second player down with a bunch of puzzle and action mechanics. After reviewing the roles we realized we had to have the second player commit to either the puzzle aspect or action aspect. The direction we went with depended on the feel of the rest of the game. One option was making puzzles central to the entire game by abstracting some of the activities of the game into puzzles. The other option was to fully commit to the first person action side. We decided that the game we wanted to make was more traditional and went with the first person action side of the mechanics.

The Finnish Game:

Too many puns. A survival game about a young escaped Finnish slave making the journey back home through a foreign land in 1100AD. Emphasis is on your isolation from the people surrounding you. 

When I come up with a game concept, it often has more story than mechanics. This was true here, but in this case the story ended up furnishing us with flavorful mechanics. We decided on a paper prototype for this game. When we started work on each of the games this one felt too large to make a good initial sale with. Early on we did not feel like we had a solid hold of the mechanics of the game. Every time we talked about the Finnish game we solidified and constrained it. This game is the most fun for me to work on because I love the history behind it and I love sharing that history with others. My initial worry was that the scale of the journey would be impossible to do in one map. I was also worried that problems would crop up trying to populate the sheer amount of space in the game. We solved these issues by breaking the game up into a linear series of incidents. In each of these incidents the player has a sandbox of choices of how to deal with the incident. An example of an incident is coming across a river that the character can't ford and having to find a way across.

*A Mech is a fictional humanoid tank usually operated by one person.

**The other programmer, and the original programmer for the team

Week 1 - Ideattion

Senior Team* Week One (8/31-9/6)

This last week I spent more concentrated time on my couple of ideas than I ever had previously and I think I came away with a better system for planning out projects than I had previously used. I started by spending an hour just spewing out ideas on my own, at the end I was left with about ten nuggets. over the next couple of days, whenever I had an hour or two free I would spend worrying away at one or another of the nuggets, thinking about what made it interesting and unique. On 9/4 my senior team had a meeting to decide on which ideas we liked and would present to the class on 9/7, of my nuggets, two were chosen and I picked my favorite of the remaining eight to be my third idea. I took these three nuggets and delved into them, by 9/7 I had grown each of them into a solid game idea.

This process took a lot of the pressure out of coming up with the ideas. Instead of each idea having to stand on it's own right out of the gate, I could churn out several stories looking for mechanics or mechanics looking for stories. By allowing the two parts to be separate I was able to develop the nuggets first and discover the parts I liked and disliked about each nugget. By the time of the team meeting I'd already dismissed three of the ten nuggets because of flaws that overshadowed their strengths.

Once the nuggets started growing I had a better idea of where each was headed, such as one of the nuggets the team ended up settling on, The Escaped Finnish Slave**. The initial nugget was based on the Farcry series and an article I found online about the Baltic slave trade in the Middle Ages. As I nurtured the nugget it became clear to me that the game didn't want to be the murder-fest that Farcry games tend to be, but rather it wanted to be a game about survival against the odds where living from day to day meant avoiding fights rather than picking them.

*Senior Team is the first semester of a year long graduation game project
** You play as a Finnish slave who has escaped his captures and is fleeing home, also not the final title of the game

Britannia Post Moterm

 Britannia

The second project I pursued this semester was to create a faithful adaptation of the board game Britannia by Fantasy Flight Games, in XNA.  The project consisted of three milestones, each three weeks long.  In order to faithfully adapt Britannia I needed to create a visual representation of the board that could easily detect mouse clicks. To this end I worked towards creating a color map of Britannia’s board. A color map is a copy of the image you are using that divides the image into sections; each section being a different color. Since each section of a color map is a separate color, it is easy to tell what section was clicked by comparing the color at the position clicked to a list of sections and their colors. The map is not displayed but does cover the image it is a color map of.  color maps are very useful for any game which uses 2d-esque surfaces with selectable irregular sections.

            Creating a color map is was an easy but extended task. My first order of business was to scan the board and create an image to display. Finding a scanner large enough to fit the entire board at once proved impossible so I had to scan the board in sections. The scanner I used resulted in about 6 sections. Once the sections were scanned I combined them into a single image.  I had expected to display the resultant image and also to use it as the basis for the color map, however XNA cannot handle an image with over 4000 pixels on a side. I hadn’t realized it but the default settings for the scanner and Photoshop had resulted in a combined image that was around 9000 pixels tall and 6000 pixels wide.  I had to split up the board back into 4 individual parts because the scanned images for the bottom third of the board were incomplete on their own. This resulted in the final display board.

            The final step of creating a color map is to take a copy of the display board and replace each of its sections with a color.  Each color has to be unique otherwise the map will not work correctly.  Each color-section pair must also be recorded so that the game can tell which section was clicked on.  For my project I had to create 4 sub sections of a single larger color map, additional sections did not increase the complexity of creating the map but did take longer to do than a single map would have. I used Photoshop for this process and I used layers to my advantage. First I would select the section using the lasso tool and cut it to a new layer, next I would color the section and finally I would turn off the visibility of that layer until I was done with the color map. This process allowed me to more quickly change the sections because each section was in a lower layer than the previous section and any differences were decided by the section with the highest layer. 

            The process of scanning the board and creating the color map left me with a very large and detailed board of Britannia which made playing the game very difficult.  To resolve this issue I decided to allow the player to zoom in and out from the board.  Scaling sprites in in XNA is a relatively simple process because you have to determine what percentage to scale the sprite by, and then while drawing the sprite include the scale in the Draw function call.  The difficulties arose when the scale of the color map and the position of units on the board had to scale with the board sprite.  The scale of the color map was simple since it was also being drawn, after setting the alpha to transparent. Scaling the positions of the units was a problem that I did not manage to solve by the end of the project.

            Britannia was a very self-driven project, and I learned about my work habits and how I work without an assignment driving me.  Three weeks doesn’t sound like a long time for a milestone but I found that with so many other projects that were not self-driven Britannia often went to the bottom of the priority heap until the last week of a milestone.  Long milestones can be good if you are only working on one project but when you have to balance multiple projects at the same time. It would have been better to shorten my milestones so that the project remained in my mind more.  Britannia was a large project at the start, it was over scoped and I did not plan it out well enough. When I realized exactly how large it was I froze a bit which made the problem worse. It is hard not to get freaked out when you realize you’ve set far too ambitious goals for yourself, but it’s important to press on in spite of that.

Fully finishing the color map took an entire milestone and was ended up eating a larger amount of time than it should have.  This problem happened because my tools for making the map were in 3 separate locations and each was several minutes away from each other.  Keeping my essential tools together would have made completing the color map much quicker and simpler. When I discovered that my initial scans of the board had missed the bottom center section I had to go home get the physical board and wait for the school library to be open so that I could scan the board.

Despite all the difficulties I really enjoyed working on this project and intend to continue working on it during the summer.  Figuring out how to make and use a color map was interesting and useful, before I would have struggled to make an interface that was not at least a little boxy but now that I know how to make a color map I can make selectable UI elements that are not squares or circles.

This is the current build:
https://www.dropbox.com/s/pj44gxd35lzj090/Britannia.ccgame?dl=0

Screenshots:

Color Map:

Tanks A Lot Android Game

Tanks A Lot Ver 1.0

     The goal of this project was to make a basic Artillery/Tank game, in the genre of such games as Pocket tanks and Worms.  I had three weeks to program the game before the project was over however I was only able to use two of those weeks due to issues with Android Studio. 

     Tank games are one of my favorite types of games, and having a chance to work on one even one as basic as this turned out to be was a great experience.  Figuring out solutions to the many issues that come up when you are putting together a tank game was cool because I’d go to other tank games I enjoyed and see how they dealt with it.

     Working with Android Studio again was a fun experience, though I am less experienced with Java and Android programming than with C++, I had an easier time with bugs and understanding how everything fit together in my project.  This was my first time exploring anything like a game loop on the Android and figuring out how to implement that was a great learning experience.  Balancing when to have the world update and when to draw the screen was an interesting conundrum and resolving it was a good way to gain understanding on how other programs update and draw. This game definitely challenged my math skills more than most projects at Champlain College which was valuable for refreshing those skills.

     I learned a couple of lessons from this project about work priority that I intend to carry forward.  I would start with the update loop rather than leave it to the middle of the project where it ended up causing me some worry about how long it was taking to implement correctly.  The other thing that I would prioritize differently is math, correctly calculating angles and power and then converting them to a unified movement took far more time than I anticipated.

You can check out the  game on Android here: https://www.dropbox.com/s/lwzw1o0lff457hm/app-release.apk?dl=0

Screenshots:

Rampaging Connections

            King Arthur’s Gold is a multiplayer only game where players build castles, tools and vehicles of war before setting to hacking each other apart.  Gameplay is divided into two parts, during the first players are restricted to their half of the map and are able to mine and build to their hearts content. The second part of gameplay releases the players from their isolation and commences the hacking and slashing, however the players are still able to mine and build.  The ability to build and use explosives adds another level of interaction to the game since all terrain is destructible.  There are a variety of game modes but all of them pit two teams against each other.

King Arthur’s Gold uses UDP for game connections and communicating with clients, however it uses TCP for automatic updates, API server communication and remote administration.  The distinction between running a server while playing which uses UDP and remote administration which uses TCP is something I find interesting, since remote administration consists of running a server but not playing on it.  The networking model for King Arthur’s Gold is inspired by Quake 3, though it differs in its ability to handle the large and variable number of objects in King Arthur’s Gold.

King Arthur’s Gold does on occasion suffer lag, however it does not have a greater issue with lag than most other games do.  The lag that I have encountered while playing King Arthur’s Gold seems to be mostly due to local computer issues. Most reported instances of lag that are reported by the player base also seem to be due to local computer issues rather than connection protocols or game code issues.