I mentioned in my last post that I had found new appreciate for the game design document. Our lack of one has certainly made this project difficult. With that in mind, I did some reading. One of the major reasons to have a GDD is documentation. You need to know what's supposed to happen and be able to keep track of everything in order to know what ought to be removed or redesigned. It also helps organize all the ideas and serves as a to-do list. It tells you what you're missing. This would have been a huge help earlier in development. The closest thing we have to a checklist is our Trello board, but there's no one place with all the information. The GDD helps to make sure everyone is on the same page. There's been a few times when I noticed our artist making sprites I wasn't sure when I was going to implement, or found out certain mechanics weren't intended to work as I had thought. On a shorter schedule, this could have been disastrous. It's also important to keep up to date, to make sure no one spends time on something unnecessary. Again, this could be disastrous on a shorter schedule, and even with our current schedule. I'll be keeping an eye on that Trello board. The article I read suggested creating it in stages. Unfortunately, we didn't really have time to plan in stages, and a lot of time was spent at the beginning working on the UI of all things. Suddenly we were in full production mode with little more than a pitch in slideshow form to tell us what to do. The article also suggests having one person in control but receiving feedback from other team members. This idea became a difficult situation for me, since as our previous deadline drew ever nearer and I still was unsure where to go with the mechanics, I was torn between making up whatever I could and following the intentions of our team lead. Thankfully, the introduction of a story script and updates on our mechanics document has helped to fix this. So, to summarize:
Citations:
“How (and Why) to Write a Great Game Design Document.” Game Development Envato Tuts , Tuts , 24 Apr. 2015, gamedevelopment.tutsplus.com/articles/how-and-why-to-write-a-great-game-design-document--cms-23545.
0 Comments
I've had two experiences making games with a team. Neither has been particularly ideal. Why? Time to find out. One of the most important things to do is to make it clear who's supposed to do what. This year, we've done that...sort of. We know who's doing the art, and who's doing the programming (me), but it took far too long to figure out who was supposed to do the other things that needed to get done. Two other important things are to set goals and communicate. Communication took awhile–over a week into the project, I still didn't know the mechanics of the game I was supposed to be programming, and even after making a document to lay everything out I still didn't have a clear outline. I'm beginning to appreciate just how useful GDDs are. We did set goals, and kept them organized on our Trello board, which had admittedly fallen behind. I made an effort today to update any cards pertaining to my work. Another piece of advice was to make decisions together. I tried to foster that. I've asked for input from my team lead and artist and have reigned in suggestions when I had to. I can't speak for anyone else here. More tips I read didn't seem to offer answers. I've heard that one should play to individual strengths and put people in roles that suit them. I didn't have much of a say in that, since team leads assigned roles, but seeing as I'm the team programmer, I think we accomplished that. I read that you should get to know each other and develop relationships outside of work. We've known each other for quite some time; this certainly isn't the problem. I read that team members should promote sharing–I did my best to do that. I set up the document and made requests for input. I've done what I could. I read more tips about setting ground rules to prevent arguments and controlling conversations, but a lot of this simply doesn't apply. Based on what I have read, the most obvious issue to me seems the communication and lack of planning. We didn't know what we were doing and who was doing it. That's been improved upon now, and I think we'll pull through. I hope this improves next time. So, to summarize:
Citations:
Mattson, Dave. “12 Tips for Fostering Teamwork.” Entrepreneur, Entrepreneur, 23 Mar. 2016, www.entrepreneur.com/article/270024. “Top Tips for Effective Teamwork.” Uplift Events Blog, Uplift Events, 19 Apr. 2018, www.upliftevents.com.au/blog/top-tips-effective-teamwork/. In the past week I have been working on developing the mechanics of our 2D game project, based on Maria's pitch for the sepsis simulator game. The plans are almost entirely complete. There has been difficulty determining how concepts such as the time system, location switching, and player symptoms are going to work due to lack of concrete detail in the game's plan (and lack of a GDD–I'm beginning to appreciate how important those are), but I have managed to come up with workable ideas, with input from our team artist, Shannon. The time system will function in terms of daylight–sunrise to sunset–and will progress continuously throughout the game. Symptoms will function as status effects and the player will be notified through Oregon Trail-style pop-ups as symptoms take effect. The player will be able to switch through static locations through a menu during the level. Unfortunately, since this is mostly planning at this point, I have no real graphic representation of my current progress. The Unity files are set up, but due to school cancellation from weather I don't have access at the moment. Starting Monday and throughout next week I will be implementing the mechanics and adding the graphics as they are created.
I decided to review Sara's game pitch for CPResponse, a CPR simulator that teaches the player to perform chest compressions on a variety of patients by pressing the spacebar. This seems like a good game concept because CPR is a very useful skill to have and could save someone's life, yet many people know little to nothing about it. I like that it addresses a variety of patients, including infants and dogs, since I've never seen this taken into consideration and had no idea there was a different procedure. I do think some improvement of the controls would be necessary, since pressing a spacebar won't teach you how much force to use or prepare you for how tiring this can get. I think a foam rectangle controller containing sensors like we discussed in class would be effective. I also wonder how much about hand position would get across even with such a controller. That seems like a complicated thing to design and a difficult thing to track in-game. A sensitive controller would be needed. This would not be a game students could make if such a controller were used, since we don't have the materials, but keeping with the spacebar idea, I think it would be. The problem would be making sure the medical information is correct, since misleading people could be dangerous in this case. Making sure the spacebar pressing lined up with the beat could also be frustrating. I think it would be possible with enough time, however. So, to summarize:
|
AuthorI'm moving on to my 4th (and final) year as a Game Art & Design student at Durham School of the Arts. I'd like to call myself an artist, but I'm a programmer at heart. Archives
February 2020
Categories
All
|