#inb379

3/6/2016

Mickey spoke on behalf of our team today to perform the final presentation.

I finalised making the slide with him and practised for a few hours last night. We arrived today an hour and a half early to practice a bit more and tune in to the 2 presentations before us.

They included some things in their presentations which were worrying us a bit beforehand. Things like having a trailer-style video, no gameplay picture walkthrough, non detailed consumer market sheet etc.

When we presented, I manned the computer to change the slides like we practised. We managed to time the slides pretty much perfectly, along with him speaking over our demo video without any big pauses or gaps. It was really tough trying to get the timing right as we did not have the ease of changing slides to match his speaking pace.

Laz seemed impressed and happy with how it went, as his feedback was relatively minimal. We have a lot of plans for next semester, and plan to work on it during the holidays so we can get more done in the 380 unit. It was a shame that the panel could not critique our game, as it would have been nice to get the perspective of outsiders also. It has been extremely useful having Laz (and Alex) to help give us feedback throughout the semester. I was afraid at the start that we would get a tutor who would have low standards and essentially leave it all to us, but fortunately Laz was honest and fair with what he said, which helped our development beyond what we could have achieved otherwise.

Really enjoyable class, good team, good tutors, and I look forward to working further on the game next semester.

Group photo after the presentation to end it all:

This semester has been a rollercoaster ride from start to finish in INB379, both in class and within my team. Overall, I’m proud of what we achieved and learned together and I think we’re well prepared to enter the next phase of development in INB380 next semester - after a mid-year break to reevaluate our prototype, our work practices and how we can get the most out of the allowed production time before user testing begins.

As seems to be the trend for my team throughout the semester, the presentation and compiling of our portfolio was a task left up until the eleventh hour - something that must be critically looked at if we’re to be successful in the next 6 months. Though this was easily the most stressful lead up to a presentation, I feel that our team leader was able to professionally present our final pitch without too much of a hitch. As often stated about our team, we again seemed to have pulled a rabbit out of the hat. Hopefully in future we don’t have to pull it out of anywhere.

Some notable and completely valid questions were asked after this presentation that I think are imperative to keep in mind when going forward. This was primarily regarding how we can truly capture the subversion of expectations element that was so highly referenced in the presentation, which for a while now has been a personal concern, and likely one in the minds of each member of the team. 

Well, we just had our final presentation. It was originally supposed to be a practise this week, but things happened that caused it to be moved forward. Not the best reception we have had given the viability presentation, and some of the desk critiques, which I haven't mentioned a lot since actually being able to do programming work. Partially because the work was my focus and easier to post on, and partially that the desk critiques were generally the same, so to speak. The feedback was relevant to every week, but each week came down to various levels of “You have done well/good/not quite enough” combined with “You need to/haven't seemed to consider this aspect/design choice/etc.”.

About the presentation. Things went mostly well. Our video was too much trailer and not enough game play demonstration. Our presenter focused to much on his personal opinion on where our game would sit on the market and not enough on research and figures. And we didn't have much, if any, reference to where we were headed in the future with the game.

It is a little disappointing to do the final presentation and be getting some serious feedback, which are all things we could have worked on for it if this had been the practise and we had another week before the final. I think it almost goes without saying that I feel that our group could have nailed the final presentation 100% if that were the case. Unfortunately not, but fortunately the marker is taking that fact into consideration when marking them.

That said, I still think we did well. I am proud to be on this team, working on this game. When I was looking at the groups that were presenting their ideas in first week and say that the first one up was called Ringfort I thought “this could either be a really cliché game idea, or a cool and original one”. Then when I saw that it was already a group of three I thought “I probably don't want to join up with these guys anyway, because they probably already have a rapport and integrating into the group might be difficult”. Very fortunately I found the game idea cool and original enough to get me to at least email Daniel straight after the presentation, and all three of them were easy to get along with guys who were happy to welcome another programmer on board. And I haven't regretted the decision once. Sure, there have been other game ideas that looked cool and I thought “I would play that” or “that might be interesting to work on” but none of them resonated with me like Ringfort did, and I only hope that as we continue this game into the next semester that I can do it justice.

This will be my last post of this semester, but I hope to be able to continue it into next semester (assume that isn't a requirement) provided that I am not so busy making the game that I can't share it with whoever actually reads these posts.

So we are very rapidly approaching the end of the semester and there are still things that haven't been implemented, even in a rudimentary way. By things I am referring to the morale system and beastfolk interactions (not sure if I mentioned in an earlier post or not, but we decided to call the units in the game beastfolk rather than beastmen. Beastmen just made me think of Gurren Lagann, where as beastfolk has a much more fantasy feel to it in my opinion). So while we do not have these we now have everything else to a greater or lesser extent. We have buildings, units, resources, and even quests. Yes, we now have questing in the game, even if it is a very basic form.

Initially, there was one quest that appeared on the second day (so the player had to end day once) and then completed automatically on the day after that, giving the player some wood as a reward. This was mostly to test that we could successfully create quests, a notification button for them, and have them dispense rewards when done. Then we went a step further and added unit assignment to the quest (this was thanks to Patrick and Michael as they had already done something similar with assigning units to buildings). The quest was then altered to only finish the turn after it had at least one unit assigned to it. This is were I left questing for the time being as there is other assessment to work on, but Daniel and Mitchell are working on small number of better fleshed out quests with proper descriptive text and all, that we are hoping to have present in the final prototype.

In an earlier blog post, I mentioned that the building preview turned red in places that it wasn't allowed to be placed. This worked fine for showing that you couldn't place a building on a tiles that already has a building or some terrain. But there are other restrictions on buildings, such as lumber yards needing to built built adjacent to at least one tile with trees, or a rabbit house needing to be adjacent to a shrine. So to do this I had to do further research into hex grids and their coordinates. This website was really helpful (http://www.redblobgames.com/grids/hexagons/implementation.html). It describes different coordinate systems as well as pseudo-code for each system on how to do many things, most importantly to us, finding a range of tiles within a given radius of a given tile. However, it is only pseudo-code and it only finds within range of the centre tile in the grid. I needed to write a C# implementation of this but also generalise it for any given tile, not just the central one. Below are images of all the math work trying to debug the original implementation before I realised that I would need to mathematically work out some limits for the alogrithm to work as intended

As we head forward with the prototype, it became very quickly apparent that placing buildings was difficult without some sort of preview as to which tile you were building on. So I made it my job to make a transparent building preview that appeared on the tile a building would be placed, which would also highlight red when hovering the mouse over a tile that was an invalid place to build.

Sometime after we also wanted a tool tip next to the building buttons to tell the player what the building is, what is cost to build, and a (very) brief description of what it does. This is because we wanted to move to buttons that Weren't just words, but images of the building, which I think is a choice that really fits the style we are going for in the game's art.

Here is a video one of the other group members made which demonstrates the building preview and tooltip:

(This reflection covers the third week of semester, from Monday May 23rd to Sunday May 29th 2016)

While this final week of production was meant to include a massive combined group effort in order to reach a suitable place for our final desk crit, I personally feel as if I did not contribute as much as really should have. Despite knowing that the work here should come first before anything given in other units, I had been putting off a large final piece of assessment in other weeks, and thus my part in the team’s final week faltered.

Throughout this week, as a programmer I essentially only worked on a rudimentary system for wall transparency, which allows the player to see their avatar when behind walls in game. As the team’s lead sound designer, I implemented a game over sound to signify the player’s death, and a healing sound effect to signify the player successfully using an Orb of Honey item. Both of these sound effects will need to be tweaked in future, but are suitable for our current needs.

Whilst my own efforts were weak, the rest of the team pulled through immensely. Our two artists should be absolutely commended on their work as they stayed up late the night before our desk crit to greatly overhaul how our terrain works, giving the prototype a much needed leap in visuals and polish. As stated by the tutor, we had essentially “pulled a rabbit out of the hat,” even though that rabbit was still small. 

During the debrief that took place after our desk crit, I took the time to apologize for my weak performance throughout the week. While not everyone was aware of this (our team leader even went as far as to say that he didn’t notice an issue), the honesty proved to be beneficial, with some conversation starting around how the art and programming teams this week were disjointed, and even our lead programmer admitting that he believed his effort this week was not satisfactory.