GDS210 – Week 11

Breakdown

So this site got taken down for a while, I lost all of my work, that has caused some delays in releasing blogs, hopefully I can catch up with these last couple now with an extra long blog post.

I realise, coming to the end of the project, that I have had serious issues with scoping. I designed a game that had lots of mechanics and things to do, it wasn’t just tappers as I had originally planned, there was a serious feature creep. I had planned on having around 20 ingredients to use, being able to mix those ingredients to make cocktails or have them individually as single drink experiences (wine, beer etc.), there was also the type of glass you used and how vigorously you shook the drinks to add to complexity. All of these things added up to a ridiculous number of recipe’s that could be randomly chosen for a player to make which meant the difficulty could be ramped waay up if I needed to. The fatal flaw, however, was that it wasn’t more fun. VR is all about making fundamentally fun experiences, things that are just interesting to do with your actual hands and not interesting, complicated mental work. I made a really interesting game, but not a fun VR experience. I have dramatically rescoped now.

Now there are 18 ingredients, you have to choose which bottle or tap to pour from, which kind of glass to use, and get the drinks to the customer as quickly as possible.

This is a much more fun and interesting experience with much more room for entertainment, being able (and almost encouraged) to throw the completed drinks at the customers, rushing through a number of strewn bottles to find the right drink and waiting, painfully for the glass to fill up. The taps work nicely and the effects look nice (for what we are doing) and the drinks are pretty cool, now I just need to complete my animation and finish the game.

Goals

The last things I need to do before the game is officially completed at the end of this week are: Finish making all of the bottles (I have Sarsaparilla and Soda water to go), finish rigging (aaargh!!) the horse model and add an idle animation, make sure the timer is working and test the game properly to make sure other people find it fun. A busy week ahead, but I can finally see the light and I feel like I am moving through the air again, rather than wading through water like I have been. I have tried to keep up with everything, but there are some things that got left behind, hopefully people like the work we have put into everything.

GSD210 – Week 9

Breakdown

I feel like I have barely got anything done, the physics based shader is coming along, it wobbles according to acceleration and angular velocity now, but it doesn’t look quite right. The drinks have mechanics that allow them to be mixed, but I’m not sure how I will go about doing that, I thought about particle effects, but that might be too hard on the graphics component, the easy way would just be to raycast down from the bottle being poured, but I’m not sure if that will be very good. I feel like I may need to use particles anyway, for the visuals, so hopefully I can get that to work together, two birds one bottle of Gin.

The group didn’t exactly organise themselves as I thought they would, Isaac has been doing well making his mini-game, but he won’t talk to Jon, who is busy making different weapons to use when Isaac doesn’t want to use anything other than pistols, both are fine, they just need to coordinate between them. The Throwing minigame has some issues, as Blake has spent most of his time working on greyboxing the saloon, something necessary, but not critical yet, where the time might have been better spent getting something testable together sooner.

We had a Trello board that was really poorly organised before, but Ken make a new one that has each of our sections and what we need to do, so that looks really good. I had to step in to try and get people talking a couple of times, but I’m trying to keep out of it mostly, I feel really burnt out this cycle, the amount of work just seems to keep mounting up. Looking forward to getting this all done with.

Goals

Next week I need to get the pouring effect done and start making glasses and bottles properly to use. I need to have actual gameplay ready for testing to see what is fun or not. I will put the liquid effect on the backburner and will try to get all the important stuff done now. I also need some rest, I have had events or activities on almost everyday, including weekends, and next week looks more busy. Going to be an exhausting few weeks left, can’t wait for the holidays.

GDS210 – Week 8

Breakdown

We received the new brief, and it is pretty exciting, I haven’t used much VR before, but I know I have enjoyed it every time. We came up with ideas over the study break and settled on Wild West themed, with some minor details being decided still. We have 3 mini-games to make, I am in charge of a Salon Server mini-game, serving drinks to eager patrons. It is a little daunting, as I want to put allot into the game, but I’m not sure how my scope will be and I have been so exhausted recently, that I really shouldn’t put too much on myself.

I found a really awesome shader to use, just need to change how the mechanics of it works, at the moment it uses a sin wave to simulate wobbling, but that just won’t cut it.

Goals

I need to get my scope and design sorted before anything else, the biggest obstacle is knowing where to start here. We spent some of this week making documentation, so we have most of the core elements out of the way, but I still need to make sure I know what my specifics will be. I tried not to be in too much of a leadership position, I am exhausted enough as it is, but being in charge of too much would be worse. I will believe in Josh and Ken to manage people, I know they will do a good enough job at it. I had to step in at one point to get people to organise themselves, but I am sure that they will get used to organising people soon, and even if they don’t, the group is good and they shouldn’t need too much help.

GDS210 – Week 6

Breakdown

We submitted the game this week. I am happy that it is completed and upset that it is not finished. We did not manage to get nearly as much testing done as I wanted, I went into this hoping to do as much as possible and really get some good feedback we could base our changes on, but things just seemed to keep getting away from us this week. I think we may have suffered some burnout after racing to get everything done; the game has 3 game modes, asteroids, UFO’s, 5 ships, beautiful graphics (in my totally unbiased opinion) and some really fun gameplay. We kept working until the end, but we just didn’t seem to have any time to do some proper testing, or rather, I felt much more rushed to get everything done and didn’t manage to push the team to do some testing.

Despite that, I am extremely pleased with how the game turned out, as I said, it looks awesome and it seems to be really fun. It is easy enough to pick up and play, but it has a high level of difficulty and the dodging mechanic and speed of the asteroids (plus the view space) gives the game a much higher skill ceiling than I first thought it would. The 3d ships look really cool, although I never really got a hang of getting the bloom to work with the emissive layers, it seemed to just blow out all light colours on the screen regardless of light emission.

Goals

Same as this time last cycle, there is not much for me to say for next week, we will get our next assignment (and start looking at VR which is exciting), I do know I want to look into the technology we will be using before we get to the next assignment, but other than that there’s not much else I can do to prepare, and not much I can say here that will really matter before I know exactly what we will be doing.

My main goal for next week is to have a good start on the next assignment and learn something I haven’t used before, and maybe actually manage to test the games we will be making. I want to focus on being a good team member. I would like to be on the other side of the scrum for once and allow someone else to take the reins and responsibilities of leading, hopefully I can learn something by watching what they do, or just make a new experience for myself.

Knowledge

I have used Scriptable Objects before, but I have not written about them yet this term, so I thought this would be a good time. I used SO’s to make the player options stick between scenes and be essentially static for each controller (allows settings to be saved and not changed while in game). This is just one of the amazing uses SO’s have, the ability to be essentially static classes, but still be used in the editor and have as many different versions as you need to. Scriptable Objects are great for a number of reasons; the face that they receive few updates, while still being serialisable, it’s ability to maintain changes made to it during runtime editing, allowing you to keep the changes you make and not need to worry about remembering everything after you leave. They also help keep things modular and clean, if we had used this for more, we may not have needed so many things in the Preload scene and could have had all our main variables kept in an SO to keep outside of the scene change cleaning. It is also a much cleaner way of handling static variables; when you can share a single scriptable object and have each class referencing the same one, you know it is a reference, not a copy.

GDS210 – Week 5

Breakdown

Last week the goals were to get the game to minimum viable product, I believed we smashed that out of the park (apart from the full game loop). By the end of the week, we were able to fly a spaceship around, shoot and destroy asteroids and even the scoring system and lives you had were tracked. Everyone had their own scene to work in so we managed to avoid issues until we were all together and one person combined their contribution at a time, until it was one cohesive, running system. I am very happy with how much progress we made, we did not get all of the games functionality complete, so next week will have to have some more work done before testing can really commence, but I am confident in how much we have done in the time we have had.

I was a little concerned with Isaac during the planning stage, last week he had some concerns that were hard to allay about the game choices and he can’t seem to stop questioning most of what the team does, it isn’t a huge deal, just makes the working environment a bit more stressful and means we have to explain the reasons for most of what we are doing a few times to keep going, but he has done good work with the character controller despite all that. Laurence has been good to work with, he understands the content well and has made good progress with the UI, which looks really good. Ken has got the asteroids looking good and although he is a bit quiet he has really good questions and insightful comments when he does talk to me. I feel like I haven’t done as much work as everyone else, the game managing component simply isn’t as visible as everything else, its still needed, but it doesn’t really matter how well it has been done, so I have simply been trying to keep everyone on track and making sure everyone knows what they can do next once they finish whatever task they are on.

We have managed to gain the support of Raine van Dyle, a third trimester audio student, to make some awesome music for us, which we’ll hear next week. She does some great stuff with ambiance and older music styles, so she should be able to make some really cool stuff.

Goals

For next week, we need to have finished the Game; we need to have tested the controls out on unwitting participants and make sure that everything works as it should under a variety of tests (we need to try and break it basically). My main goals are to get the game cycle finished as soon as possible and get polished and respond to any of the testing we get complete. One thing I really want to do for next week is to make sure everyone has been on the same page and that all the pieces fit well together.

Knowledge

I haven’t learnt much this week, mostly I’ve just been using what I know in slightly different ways, I set up a music mixer and audio manager to allow any of the sounds to be made with a function call, I have snapshots to transition between the menu and the main game, and I used a SetFloat to define the volume of the intensity music (music that matches the bpm and duration of the main track and cycles in when the game is more intense, in this case as the total lives decrease).

This week, for me, has been mostly spent making sure everything works, doing the tedious little things and modeling/texturing anything that needed it, including two of the ships and the title screen. I used substance painter for the texures, which was amazing, the most useful program I have used so far. Most programs used for texturing (mudbox, zbrush etc.) allow you to paint colours onto a texture, then those colours represent different things; base colour, roughness (how much it diffuses light), metallic (how sharply it reflects light), normals (the light reflection direction in x, y and z connected to the red, green and blue), emission (the same as base colour, but the texture produces that light rather than showing it), and more possible layers I don’t normally use. What is so amazing about substance painter, is that it allows you to paint a material onto a model; something that combines each of the different layers and allows them to be made into one combined resource and applied to a surface. It takes so much of the guess work out of texturing, so much of the tedium and allows you to design a texture and tile it as it should look, rather than making each texture one at a time and painting them on.

GDS210 – Week 4

Breakdown

We were assigned the topic of old arcade games to make new and 3D with multiplayer components, we were tossing up between a bunch of different topics, from 3D PacMan, probably well overdone by now, Space invaders, Gattaca, or Shooter games like Metal Slug or other games like that. We ended up on Gyro and Asteroids, as these both were easier to manage the 3D art for (not many moving parts on spaceships, therefore no rigging or animating really required) and they both have a unique gameplay element that would make them either work really well in 3D, or be extremely interesting to play with 4 players. We had to make a presentation again for both of these, Monday to Thursday to plan both, always a pain to try and remember everything we need to have in there. I put myself forward as the group leader again, I am glad to get more experience with different people this time, and I feel that each time I try I get a little bit better with the organisation and planning side of things.

The presentation went well, we are making Asteroids and have set up the Trello, Slack, Google Drive and GitHub spaces to work in and have made most of the Game Design Documentation to follow, not sure how useful it will be, we didn’t refer too much to it last time, having only really a single week to make most of the content and keeping to a document is harder when you don’t have everything planned out yet, but it’s still good practice and will help us in making the Trello page.

Goals

For next week we need to do a decent chunk of the project, to leave the last week for polish. We have to get the minimum viable product done; Player controls for both single and multiple players (I’m making a script to set up 4 controllers inputs, to allow for easy use by all the other scripts that need it and Isaac is making the players and controllers for them), we need to make the script to control the asteroids and some basic models for those (Ken is working on that now), some basic UI, so you can start the game and know when it has/will be ending, for a full game loop (Laurence is getting that done). We all have to do some 3D modeling, so I proposed we each make a ship, that way we have more ships and we all have at least one model each, then we can split up making the asteroids and anything else that needs to be done as we go, but we all have the minimum.

Knowledge

I have just made a multiple controller input for the XBox controllers, so this week I will be going through the difficulties I had in building that and what I could have used to save myself a tonne of pain and time. I messed around to start with, just trying different things, I noticed there was not really any conclusive way to see exactly what the controllers inputs would be, there are a number of different sites that explain what they are for specific devices, but it turns out that different systems and different controllers use different button tags. I then spent a good number of hours trying to find out which of the many many axes referred to the second third and fourth controllers, until I finally realised that there was a selector at the bottom of the input window that defined which controller it would get the inputs for.

That was the first headache. The second was setting up the input manager. This is where I could have saved myself a decent amount of time, as I did not realise that XInput helped so much in setting all of these systems up, so by the time I realised this, it was too late to turn back, and I just had to keep going. I ended up accessing the input manager through a text editor (Notepad++ actually) and just used one for each in there and changing the values that were needed, the ability to copy and paste and change locations made things much nicer.

So where I went wrong: XInput is a .net system that plugs into unity scripting to allow for a much cleaner and easier interface to your controllers, there is a small amount of work needed in getting it set up, putting it in the right places etc. and making sure the end product has a copy of the .net files, but after that, it allows you to check for each (up to four) players controller state; each of their button presses, trigger usages, it even allows you to control the controller vibration. All in all, I should have saved myself some time and effort by using XInput, but at least now I have learnt how to manually use the inputManagers controller interface, as painful as it was to use, maybe I will end up extending my script to edit the input manager script to set up all the controls automatically… a job for another time though.

References

Harvey, Drew 2017. Washington Courses. Accessed from http://courses.washington.edu/css385/2017.Spring/FAQ/UnityHelp/XInput.NET_for_Unity.txt

GDS210 – Week 3

Breakdown

This was the last week for thew first cycle of game prototyping, and with it Sub-Urbal came to an end. As with all the games I have made so far, I’m glad and disappointing in the ending, glad that it is over and I can focus on new things, I enjoy the beginning of the development process much more than the end, and disappointing as the project is never really finished when it’s done. It is over now though, and I am looking forward to starting the next project.

We went through the process of getting feedback, with google sheets and everything (most of the feedback was in person, but we got some people to put their responses in writing). It was really useful for figuring out exactly where we needed to make changes to get the game working the way we wanted it to. It was also eye opening, in that, it reminded me that we need to nail down exactly what we want the game to be before we make it. I always jump into the creation process without really thinking about how the game is supposed to feel, but just trying to make the game itself and worry about the rest later. We need to plan the underlying reason for making the game, as well as planning the content of the game itself, something I hope to learn more about as this trimester continues and I’m sure I will be talking about planning game-feel at some point here.

Goals

There aren’t much in the way of goals for next week, I know things will get crazy again soon, but I’m going to be relaxing for a couple of days and worrying about Monday when it gets here. Of course there are the obvious, next week we make groups come up with ideas and plan accordingly, so that is what we will need to accomplish, but I like starting these with an open mind and seeing how the group goes all together before coming up with a solid strategy for moving forwards.

My biggest goal for the next week will be to get more experience organising and managing people, I want to be able to fill all of the roles in a game dev team and, while it would be nice to sit back and let someone else manage, I really want to learn more about how to get people working together well. That will be another topic here, Management Strategies and methodologies, should be an interesting one, I’m going to have to start keeping track of all these topics soon, might make another section with brainstorm ideas, would be something cool to add to the site.

Knowledge

This week I have been focused on feedback and game testing, so that will be the topic I go into here. I got some basic question concepts from Shawn Patton, the Principal Designer from Schell Games (Patton, 2017), the concepts were in the form of some keywords to base the questions off of; Frustrating, Favourite, Wanted, Wand, Doing, Describe. Weird set of words, but the principle is that you ask what the players found frustrating, which tend to be things which will break them out of zones like immersion and flow, and either slow down the experience, or make it less enjoyable. Favourite, fairly self explanatory, what did they like about the game. Wanted, what are things they wish were in the game, what did they feel was lacking? Wand, this one stumped me for a bit until I read the explanation, basically how were the controls, how did they feel, how did they function and are there places improvements can be made. Doing, basically describe the content of the game, see if there was anything missed or if things need to be made clearer. Finally Describe, what would you tell people about this game? What were the stand out features (good and bad) and why?

This basis was pretty interesting and each question may have similar answers, but I think the way they can be phrased can change how the tester responds and can give you some unique insights to the game you’re making. Things the player might not realise are pertinent come out with these questions, if the game is frustrating, that might mean there were some skills or strategies that were not made clear, or that the ramping of difficulty might be breaking the pacing. Asking about how they feel controlling the game might not be something they would have thought to mention, or thought was an issue until you ask about it, how things feel to control can be some of the most important pieces of making a game fun and if there is something small holding it back, it’s important to find out as soon as you can.

References

Patton, S. (2017). The Definitive Guide to Playtest Questions. Retrieved from https://www.schellgames.com/blog/insights/the-definitive-guide-to-playtest-questions

GDS210 – Week 2

Breakdown

This past week has been a long one, in amongst trying to find references to find a game that has some ideological basis and uses semiotics, we had an Unreal and Tech Art presentation which, while fascinating, finishing after 9:30 meant I resigned myself for very little sleep the last half of this week. It did help give me a topic for this weeks info section though, which is nice.

On to the important stuff, my group and I had some issues this week, I feel that we fell down again in regards to communication, I have sent message after message with no real response and feel that they would be leaving this until the last minute to work on if I wasn’t already annoying them with trying to get them to do work. Frustrating, but I honestly don’t know what else to do, I have been trying to get the game ready for Monday to begin testing, but it is hard to keep working by myself on all of the coding when I have to also make some music and while I did make a couple of images, I would like to have more of a hand in that aspect also. The game is mostly ready for testing, which was my goal from last week (other than getting the group to work together), other than a couple of sections, we have a full game loop, you can start, upgrade, go through the mini games and fly, to go back to the upgrades again, so that is a success at least.

Goals

My goals for next week are to have the game completed, we mostly have polish and testing from here on out, Josh will be working on the UI Experience, as my forte is function, not aesthetics (the UI I made is ugly) and John will be making more obstacles as assets. I need to work on getting my audio made and fixing up any issues that come up in testing. The game is due Friday, which means we need to have this nailed by Wednesday and ask any questions we can on Thursdays class and upload shortly after.

Knowledge

This week I have been looking at Shaders. Dangerous rabbit hole, but really interesting, especially after the Tech Art Presentation. I have been looking at interesting maths that have a much weirder use than I thought, specifically looking at making blurry screens (as that is what I need to make for this assignment), but also learning more overall about shaders in the process. I have started using Shadergraph, for the ease of testing interesting designs, but I have found some limitations, one is that the nodes are often hard to understand and there is not a great deal of support for the specific functionality I have been looking for (specifically about sampling pixels from a texture). My basic maths for making the gaussian blur has been to essentially average each pixel with a block of surrounding pixels. If you have a 2d array of pixels you can take one point and add each pixel in a square called the Kernel, add them together and divide them by the number of samples and that is the initial pixels colour. I have been unable to do this specifically, so instead, I have shifted and averaged the texture 6 times; positive and negative on the x and y plane and positive and negative on a diagonal axis. This is a similar effect, however more mechanical in nature, which means there is a definite loss of precision and some edges still show up through this when I would like the whole thing to be blurry. I followed other examples of creating a blur which said to downsample and then stretch the image, so I have combined these two, using a render texture to downsample and the nature of rendering a render texture back into a camera to stretch the image with the faux gaussian in the background helping remove the hard edges.

GSD210 – Week 1

This will be a developer blog following the 3 main games I (and my teams) will be creating over the next 13 weeks, and my thoughts and interesting experiences throughout. This first blog will be a little setup and introduction as well as the main content.

I will be keeping to a similar structure, to see how that works, most of my blogs to this point have been fairly off the cuff and random, but I have found that a small amount of planning and structure may make making these somewhat easier (not to mention probably easier to read). I will have an intro called the Breakdown, where I go through the weeks progress and development (what worked and what didn’t, things learnt etc.). There will be a section about Goals at the end, of what I hope to accomplish by this time next week (I will try to post each Sunday). The final section will be a bit of a breakdown about something interesting I learnt about this past week, there is a saying I have kept pretty close throughout this past year and that is “There is no useless knowledge or skill for a game designer”, I have no idea who said it first, but something like this has been in most of the design books I have read so far and it is something that I have always lived with, without really knowing why.

Breakdown

Week 1 gone and wow was it a quick start,  already we have presented a presentation, been ‘greenlit’ and completed a decent section of the first game prototype for the trimester. I am team lead, with a programmer and artist, so far communication has been a little bit difficult, but I feel that the first week after holidays seem to always be hard to shake off, so I am giving them a little leeway until we really crackdown next week. I hope we can work together, but if all else fails I at least have confidence we can work through the project together. The game we will be making is a 2D arcade app about 2 kids making a pretend rocket ship in their backyard. It has 3 mini-games and a strategic element, first you have a tapping refuel mini-game where the goal is to keep a fuel gauge needle in the center of a bar. The second is a timing game where you need to flick three switches at the appropriate times to get boosts for the last mini game which is a flying game to avoid obstacles as you get higher into the atmosphere. The higher you go without hitting obstacles or running out of fuel, the higher your score and more coins you get to upgrade your ship, allowing for higher fly times, with the eventual goal of reaching space.

As I mentioned, we had to present our idea in class, which went well, as we didn’t have to make any changes to the plan, although the scope was touch and go as to whether or not we were trying to do too much. We have now made our Game Design Document and I have started some preliminary scripting, mostly making sure I can get the Gyroscope and Touch inputs working, which, at this point, has been very successful.

Goals

My main goals for this coming week are to get the game ready for testing by Thursday and make sure the team is communicating and coordinating as we need to be. By this time next week, I hope to have had some testing done in class on the tablets and be ready to make some changes as needed. I will need to figure out exactly how much the tablets can take in terms of processing power requirements for some of the more interesting ideas I have, but other than that, I am confident (as long as I can get the team to work together) that we can get it done as well as I would like it to be.

Knowledge

This week I have been learning about Gyro’s in tablets; how they can be used, their issues and benefits. I found a great read on the unity forums, about Accelerometers and Gyroscopes (Jjules, 2017) which was a really fascinating read and put me onto the method I am now using to take my gyroscope readings. While the traditional method of using a gyroscope calls for using the ‘Attitude’ or the raw rotational value, which is incredibly useful in mapping camera rotations in applications like AR and VR, what I need is to take a specific rotational value (rotation along the Y-Axis) to set a force to push the spaceship across the screen. After trying to use the pure rotational values, I found out there was an issue, when the rotation passes 0 into the negatives, it shifts up to 360 instead, meaning I would have to do some nuisance math and if statements that would only work sometimes and unnecessarily complicated. I then found another function within Jjules guide to emulate Accelerometer, essentially taking a delta rotation (in RotationRate) which meant I could keep track of a separate Vector3 and add these values to keep relative rotational values and then use them to calculate my forces. This seems to work, with some minor issues where if the screen moves too fast it can break how much rotation force is being applied, however I have a script where if you touch the ship it resets your rotation values, meaning if there are any issues, all you need to do is touch the screen and it should be working as good as new.

All in all, gyro’s have been much easier to work with than I thought they would be, but with some issues in my own limited experience, still something fun to work with and something new to learn.

References:

Jjules. (2017). Unity, and the Accelerometer vs. the Gyroscope: A Complete Guide. Retrieved from https://forum.unity.com/threads/unity-and-the-accelerometer-vs-the-gyroscope-a-complete-guide.451496/