Why Should I Care?

Cpl. Mason G. Kemp
Pvt. Earl C. Chadwick
Pvt. Carl W. Perkins
Pvt. Godon K. Stykes

Who are these names and why should you care about them? These are just a small sampling of the men of Vermont who died in World War One.  My team's game does not intend to hide from the pointlessness of the First World War but do we need to include a litany of the dead as a preface to our game? No we don't, but a list of names isn't necessarily a litany of the dead of a pointless war. It is an accusation, a reminder that you do not know these men, you cannot know these men. It is a condemnation of the human habit of creating the categories of Like and Other.

I do not have the courage or ability to join the military, I don't know if I would even if I did have the courage or physical ability, but the people who make up our military are human being just like you or me. The military often gets demonized for the current war, it becomes a polarizing subject. Either you are For the War! or you don't support the troops, this polarization dehumanizes and segregates the men and women in the military. After all, you aren't part of "the troops", it's those guys over there, away from you. We often forget or avoid thinking about how "the troops" are just people like us, with hopes and dreams and hates and fears.

The Great War, The War to End All Wars, The First World War, The Great Conflagration, The Forgotten War, it started just over one hundred and one years ago on July 28 1914. The American Civil War Ended just over one hundred and fifty years ago. There are still a couple of Great War veterans alive, the war ended within the vaunted now standard human lifespan of a hundred year. And yet, somehow in American schools, The War to End All Wars is a footnote, especially compared to The Civil War which is no longer within the realm of a human lifespan. American schools can't be bothered to explore one of the most fascinating, human, alien, repeatable, regrettable, relate-able  experiences that war can share.

History is the why, the when, the how, but most importantly, history is the who of humanity. And yet, you ask, why should I care? after all, this war killed millions over a hundred years ago, it doesn't matter to me. And you shouldn't, you don't have room in your primate brain to genuinely care about the millions of fathers, sons, daughters and mothers that died or gave their lives for a cause or a reason that you don't know, or even on occasion for no reason at all. We are tribal people, we can conceptualize a few people, up to the low hundreds, but any further than that and we have to start cutting people from our memory banks. Human beings simply don't have the mental storage space to care about the soldiers of The Great War as more than numbers. So how do you honor the millions who died? and they do deserve honor or at the very least, remembrance.  I don't know, but it certainly isn't by ignoring the monuments we erect in our town squares and halls to remind us of the losses.

In Syria today, along the Northern border lies the Kurdish Semi-Autonomous region of Rojava, though it is a state in all but name just as Syria is a State in name only. When the people of Rojava take up arms, do they think about the pointlessness of war? do they worry about their own death? do they want to protect their family, people and country? I don't know and assuming that they can only pick one or even that they have to reason beyond wanting to fight for fighting's sake strikes me as self-absorbed and self-justifying.

So there we are, I don't know why you should care, but I do  know that not caring at the very least about the history of the world is lazy, disgusting and useless. A person is enriched and the world made more beautiful and rewarding when they begin to explore their history, the history of the world.

Week 11 - Why I made a Mech game for three months

Senior Team Week 10 (11/9-11/15)

First off, our game finally has a name! Our Mech game is now called Korku, the Turkish word for fear. I'm not one hundred percent sold on the name but it does sound cool and not everything can be Tommy Falcon Hoverboard Simulator 2015.

A suprise challenge under our belt, we didn't find out until Friday whether or not we'd passed. The presentation suffered from a lack of preparation since we started it on Friday but we had finally hit the nail on the head with regards to content. With most of the work on the presentation occuring between Friday and Monday we hurried forward with game.

The most frustrating part of this week was the number of bugs that sprang into view just as we set about preparing to show off our game. Many of these bugs were low priority issues earlier in the semester that had slid under the radar as the team concentrated on implementing features and practicing presentations. This week we implemented something approaching a test plan which exposed many of these bugs.  For each night spent tracking down and fixing a bug another night was spent speeding through the unexpectedly simple refining of a system or feature. All in all it was a good if stressful week.

Up to this point, my reflections have been on how my team has been doing and how I've felt about that. With the end of the semester and the project approaching quickly, perhaps a look back and a deeper examination of the whys of this project is in order.  When we chose which game to go forward with we knew that none of our game ideas was going to be easy going forward with. I had wanted to go forward with The Finnish game because I dearly wanted to share my love of history and explore a mostly forgotten and unknown section of history. One of the things that the teachers at Champlain look for in our games is innovation and potential uses outside of gaming for fun.

Our vote was deadlocked when it came to which game to go forward with, two votes for the Finnish game and two for Korku, our designer ended up being the deciding vote.  Both of the votes against going forward with Korku came from the Mech enthusiasts in the team.  I had many reasons for voting against Korku. The ones that stand out to me were my worry about the scope of the project and that we would get halfway done with the game and I would hate it because it wasn't a good Mech game. 

A FPS Mech game is nothing new in the game industry, but its also not a genre that is over saturated with games. Each game in the genre is noteworthy and offers something different.  Mechwarrior 4 and it's expansions explored the brutality that comes with all civil wars and the cycle of violence inherent in war. Multiplayer Mech games such as Mechwarrior Online and Hawken don't offer such a in depth look at humanity but they provide a place for people who enjoy the same sort of game to get together and have fun.  Korku is trying to combine the ability to explore complex issues and stories of single player Mech games with the sense of community and ability to hang out with friends of multiplayer games. To top this all off Korku puts a spotlight on one of the lesser known battles of World War One (to Americans) and exposes gamers to something more than the well-tread battles of the Second World War.

*Warning* Major Biases Ahead *Warning*
Somehow despite the common saying about how those who don't know their history are doomed to repeat it few people put any real effort into learning even their own history. Everyone knows that the Nazis were horrible and about as close to evil as you can get in a subjective world, but in many ways the First World War falls through the cracks. Especially in America the main concern in high school history books is to let the student know that without America the war would have gone on much longer and that the end of the war set up the Second World War.  Time changes how we view events, even written records change and are revised.  Games are no more permanent than paper but they are interactive and just as practice is more effective than memorization, games can stick in your memory more than other forms of media.
*Warning* End Major Biases * Warning*

Outside of history Korku is a co-op game, focused on cooperation between the two players. The role of the second player is intended to encourage non-gamers to still themselves while hanging out with a gamer friend instead of hanging around being bored or resenting the game for intruding on time together.

Games have the potential to be an important teaching tool, getting students involved in the topics they are studying rather than repeating by rote the datum from their textbooks.  Korku would not be an appropriate game to use to teach anybody younger than high schoolers. A World War One game that completely sanitized the brutality of the war would be doing a major disservice to it's players and students. Korku should be asking the player to explore the idea of good guys and bad guys in war. Was Gavrilo Princep a hero, a fool, a monster or a young man?

Week 10 - Slouching and Suprise

Senior Team Week 10 (11/2-11/8)

At this point in the semester we knew that we were going to need to challenge every week to be able to be guaranteed a place at the senior show. Work continued this week but I don't think that we truly felt the urgency outside of the presentations. Looking back on this week we did not get nearly enough done even though we dealt with many of the things we needed to.

We really tried to take note of the lessons of our previous challenge attempts when we set about creating our presentation for this week. We finished the initial slides by Wednesday and revised them every meeting afterwards. We also set about scheduling Discipline reviews with various teachers for the final two weeks of the project. However we ran into one major snag on this aspect of our week, Michael and I forgot until Wednesday to contact any of the programming teachers while Kody was completely unable to contact any of the art teachers. This very nearly lead to our not having a programming discipline review and did lead to us not having an art discipline review. We expected that we would not be able to challenge because of this and the initial response from the teachers seemed to support this, but when class rolled around we were allowed to challenge the milestone. This week was stressful on the meeting front for me, I felt uncomfortable with my slides, I nearly failed to get my discipline review done and I thought we would be unable to challenge at the next class.

This week I realized that Tuesdays were not good work days for me this semester. Throughout the semester I tended to do less work on Tuesdays and would often be rather directionless. I took steps this week to counteract this by seeking out suggestions from other group members on Tuesday so I couldn't just decide things were done for the night and go home. I also made sure that I was eating enough and was full right before I started working so that I wouldn't end up in the distracted hunger state that I sometimes find myself in. We made good progress this week, many of the more persistant issues in the build were fixed and we polished menu and AI a good deal however I don't feel that we moved forward enough programmatically. Art wise, Kody churned out great assets at a rate that continues to astound me, I honestly don't think I know another artist who creates nearly so much quality work. Design work has always been an area that I struggled to keep track of and I think this was one of those weeks where knowing exactly where the designer was at and what the progress was looking like would really have helped. I felt that several of our group meetings this week were weak, we did not accomplish as much as we normally did during our work meetings.

That all said, during this week I felt the least stressed that I have ever felt during what is essentially the run up to finals week. I think that this is partly the environment of the team,  every single one of them is a good friend and a great worker. We all work well together and I enjoy working with them. I really hope that we succeed in passing the remaining stages and continuing on to next semester together. The other part is that I genuinely enjoy this game, more so and more easily than any other group project I've worked on.

Week 9 - Reassesment and Research

Senior Team Week 9 (10/26-11/1)

 We failed our attempt to challenge out of the Deep Dive stage, this was largely because we failed to convey the research we had done and how that had affected our design process. I do wish that Wilhelm had hurried the previous group a bit rather than simply my team off halfway through each slide of our presentation. Once we had taken a step back and looked at our presentation again we decided to make the most of our extended Deep Dive.

We had failed to show our research, this was easily rectified, in went the slides. We found that we hadn't finalized sound design or exactly what technology our weird war one was using and fixing these was much harder. Sound did not in fact get nailed down this week as the team shifted in opinion from meeting to meeting and I didn't keep track well enough or get everyone else to stick with one position. While we felt we had done enough research previously, the team decided that more research wasn't going to hurt the project.

My research this week focused on The Battle of Gallipoli itself and the conditions in the Ottoman Empire that enabled it to win the battle. One particular point that I was eager to determine was the exact reasons behind the battle (though not directly relevant to the game, it was a point of debate between team members which I hoped to win). Overall a decent amount of new information came up including a very interesting and helpful examination of how the terrain of the peninsula affected the battle, which would be useful for both art and level design.

Progress on the build this week consisted mostly of tightening up controls and networking. One point that we were particularly determined to deal with was getting the weapons to fire directly at the mouse which up til now they had steadfastly refused to do. Michael was finally able to get the guns working correctly by the end of the week. During the Deep Dive presentation our build had crashed repeatedly and we were startled by the bug because it had never happened before. Our Producer insisted that we find the bug before we tested the game again but we never found the bug, and the bug never popped up again even when testing on the same two computers.

Week 8 - Deep Dive Prep

Senior Team Week 8 (10/19-10/25)

This last week felt right, the team was focused on both getting our documentation together for challenging the next stage at the start of the next week.  We each had prototype work to do as well, Kody with getting art assets into the game, Michael was busy fixing and refixing the aiming of the guns and Aiden was designing the level.  My responsibilities were to implement the sounds and get the in game menu to work.  I start getting nervous when a week goes by and I don’t feel like work got done on the game which did not happen this week, unlike the last time we were preparing to challenge.  I was able to strike a healthy balance between implementing sounds, creating the Audio Pipeline, adding the in game menu and writing/practicing my slide for the presentation.

The main letdown of the week was that we did not manage to set up a Discipline Review with Professor Eric Sample who teaches Audio Production classes and who we had hoped would help us iron out the our Audio plans.  The only other Discipline Review we had planned to do this week was with Professor Wehmeyer and it went very well, we went in looking to get a better handle on our aesthetic and to see if we could get any help with our research on the Ottoman Empire. Professor Wehmeyer was a great help in these regards and was very interested in where we had taken the game since we had last talked with him.

We were confident that when we challenged we would be able to pass easily. This was because we had been constantly communicating our research to each other and we had spent each meeting for the last 3 weeks exploring our mechanics, world and story trying to figure out the best way to do everything.  However we were unable to get everyone to create their slides before our Friday meeting and so were unable to practice our presentation then, undaunted we planned to finish our slides by Sunday and practice then. Calamity struck when I got news that one my cousins had died and her funeral was on Sunday, Aidan also found himself stranded outside the state when he missed the bus back to Vermont. The Sunday meeting and presentation practice was therefore very understaffed and what practice the group got did not include everyone.

Weeks 6 & 7

Senior Team Weeks 6-7 (10/5-10/18)

At the start of the sixth week, we decided that we would proceed as if we had passed succeeded at our challenge. We looked at where we were with our game and where we needed to be by the 18th so that we could challenge the next stage as soon as we got back from break. After a review of where the code base was and where we were in regards to the design of the game we bustled off to ready the game for testing.

I ended up working primarily on the networking for the game during these two weeks. Getting networking testable took a lot of fiddling and long nights. It turns out that people don't write all that many tutorials for Networking in Unity and that there are just enough differences in networking code between 4.5 and 5.2 that it is an adventure to code. I got networking up and running on Wednesday 10/14, four days after I had wanted to move on to other important issues. However with networking in place several other aspects of the game quickly fell into place, specifically the game loop got it's first draft and AI/player interaction.

We knew that we would have to nail down the backstory for our game quickly because it influenced so many of our other choices. Our first goal was to figure out exactly where and who we were fighting. We knew that we were making a Diesel Punk WW1 mech game but we didn't want to retread the western front. After several proposed locations we settled upon The Battle of Gallipoli in the Ottoman Empire or modern day Turkey. With our location decided we were able to limit our possible participants list down enough to choose whose side the character would be on. The decision was hotly contested and even brought up during QA and class, but eventually we settled upon the Ottoman Empire. In part we settled there because of our artist's love of the possible art styles but we also got feedback during discipline reviews that the Ottomans would make more sense to play as.

During the course of the first week we discovered that we had not actually passed the first stage and that to fully pass the first stage we would need to present three separate and distinct relationships between the pilot and the engineer roles. This focused us on resolving this thorny issue, if either of our roles wasn't as fun as the other our Co-op mech game would fall apart at the seems. The first two relationships were relatively easy to come up with as we had been wrestling with the relationship issue from the start of the project, but the third required a more imaginative approach. What Aiden eventually came up with was quite an interesting and distinct third option and it threw our previous notions of the best relationship out the window. Eventually we came to see that the novelty of third relationship was mostly just novelty but it did teach us some important lessons about player interaction.

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: