Today i chose to critique your last blog post for this course. I chose you the programmer in your team doesnt have a blog and you are the only one who has posted for the last blog. This is not to say your last blog post wasnt interesting!
I like how professional and finalised writing for this post is because it brings about a sense of completion to the reader. I really liked how you went into detail about the game and the difficulties you faced during production, and how the good and bad things came to a conclusion on your final work. This really excited me since it meant your group really worked well together to bring about a playable game in the end that didn’t have any major game breaking bugs.
Your motivation for how you determined the good and bad things from your project wasn’t very clear and i would have liked to hear more on that. Other things that could be improved is the fact that your an artist and i would have liked to hear your final thoughts from an artistic percpective and not from the gameplay (programming) side. Other than that i thought your post was well thought through and it came across in your writing, this provided value to people following your blog and i am sure the other readers are as happy with your post as i am. I really enjoyed it and i hope in the future to see more of your work.
Hi, today i will be discussing my final thoughts of my game’s development and what i have learned on this Journey together with my group.
This week was the final week for working on our games, the final day being today. I think this journey was a long one and interesting because this was the first time making a video game with a Game Design group. It was my first time as part of a group because since the beginning of the year i have been making games for my programming classes the games being: Number Guessing Game, Pong Game and Pac-Man. Of course, i have made games before entering this course but they were made with the programming language Java, which is a much harder language to use in game making.
Now in terms of the production of my team’s game, the development process went pretty smoothly with only a few hiccups due to me being sick and since i am the only programmer this put a grinding halt on production. However, this particular hiccup could have been avoided if my team had used some sort of version control instead of me implementing everything. My other thoughts are that even though my team had only 4 people, we really somehow have been on the same page and have jelled well together since the first time we met. I can’t really describe how it worked out that way but, it did and i am really glad that my team and i were put together by the lecturer.
Figure 1 shows a screen shot of my game’s first level, the first level being a tutorial type thing.
I am really happy with my team’s final product and things i have learned on this journey include: Working with a proper game engine, being Unity, whereas before i used custom engines (engines built by me or together with the lecturer). In terms of how i learned unity, it was mainly me messing around and trying stuff out and also going through unity’s tutorials i mainly did the 3d shooter and roll a ball tutorial which were excellent in teaching how to use 3d objects and make them look 2d (which is what our game was). Why i did this is because it is important to try stuff out and figure out things on the journey instead of trying to force yourself to learn unity’s tools at the beginning;
Programming in C# was different but i liked how similar it was to Java programming, but i don’t know why we learned c++ instead? Maybe for something else coming up in this course…haha. C# when inlcuded with unity isnt a hard language to learn and actually makes me lazy as a programmer because it is easy to make multiple scripts for different behaviours in unity and have it wokr perfectly fine, but it is hard to create proper state machines that work well within c# since we werent taught how to combine it with unity;
While working with a team i learned how to interact with others while programming a game and i also found i was more productive in this development project than in other projects i have done by myself. Usually as a lone programmer all the decision would rest on one person, you, so working with a team was a nice change and i could rely on teammates for decision with game design or mechanics etc. Why working with a team was great for me is because i got to interact with others and be more social, and with design decisions if done by one person the view of a game would be one sided so having a group allows for more diverse decisions and ideas;
Lastly i have to say i learned that i like working with a team of people instead of by myself and i feel like i have grown as a person (Game designer) and a programmer. Although i was a lone programmer in the group so implimentation of decisions was left up to me to complete. I cant wait for the Arcade games course because ill be in a much larger group with more programmers, which means i dont have to do just about everything myself and can rely on others in the programming department.
The end result of our game “Friendship Down”, concluded to a semi-side scroller shoot em up game. When i say semi-side scroller, its because the background would be static when being introduced to a new wave, and then on completion of the wave the background would move until you got to the next scene, this provided some sort of progression to the game. The game ended with having 3 types of enemies, enemy 1 was the smaller but more fiesty while the other 2 were larger and had different types of bullets, where one of the bullets would act like a homing missile towards the player’s Allies. We also had great music made by Robert Mumury, he is also a student at uppsala university but he was in a different course to us. The music he produced, made a big impression on players during gameplay and provided great feedback to the overall aesthetics of the game.
Some feedback and final thoughts are that the game was a fun and interesting game to play, playtesters words not mine, and in terms of things that could have been added to game, the functions we cut due to time and me being sick, would have made the game more interesting and interactive but, it involved unnecessary things that would have been nice to have and not an overall loss to gameplay.
Overall, my team learned a lot about working together and my artists learned how to keep the art styles the same which is important for a game because you don’t want different styles of art being used in 1 game because it would make the game look too messy. In the next game production coming up, i will be more prepared and i hope my new team and i will produce something even more amazing together.
Hi August,
I really liked reading your blog, it was easy to read and people from outside game design could understand what you were talking about.
I like how you start every blog post by saying that your group chose Umibuzu as your game. Normally people might get irritated about that kind if thing but, I liked it since anyone who hadn’t read your blog before could look at it and go… okay so that’s the game your talking about. This is good because you want your readers to understand your design decisions.
Now onto the content of your blog post. I feel like you really went into detail about how you went about doing your playtesting and I really liked how you guys went about doing it. This is because your survey really asked the right questions and got good feedback on specialised functions of the game. This type of feedback is important in order to create a game that people will enjoy and also provides feedback on any bugs you may have had in your game.
Overall, the only thing missing from your blog post was your motivations behind why you chose to conduct your playtest in that way. Which would give readers a clearer understanding on playtesting and the different ways of doing it. Otherwise, as us said before I really enjoyed reading your post and it really provided great value to people looking for ways of doing playtesting. I hope to read more of your posts in the future!
– Natasha Bianca Mangan.
Hi, today I will be discussing why playtesting is an important aspect of game development and how playtesting has affected my game.
Playtesting is the stage where a game developer tests a game for bugs and any design mishaps before releasing it to the public. Playtests can be run “open”, “closed”, “beta”, or otherwise. Open playtesting is usually open to anyone who wishes to participate, or it may involve game designers recruiting testers from outside (the public). Closed playtesting is done internally within the company and is a testing process not available to the public. Beta playtesting refers to the final stages of testing just prior to release of the product and is often run semi-open with a limited form of the game in order to find any last-minute problems.
Playtesting is an important part of game development since it provides the developers with useful feedback on some or all the functions of a game. Playtesters are usually the ones that will find any bugs that the developers didn’t think of testing for. Playtesting is also important since any developer busy developing the game will become too familiar with the gameplay and consequently won’t notice any bugs until it is too late. This does not mean that the developers are incapable of finding bugs, it’s just that it is more difficult for them.
Playtesting for us as student developers was performed internally and we have had Alpha and Beta playtesting so far. What i mean by the playtesting all done internally is that every group sets ups a couple of computers with the game on it and then everyone takes turns wondering around playing each other’s games. Of course, it wasn’t only first years wondering around since our second years (mainly our Scrum masters) had look and playtested are games as well. For more information on Scrum masters go see Scrum Masters. If you’d also like to know more about scrum and why we are using it for development, please see The Effects of Scrum on my Game’s Development.
Feedback for my game’s set up was done via Google forms. This was an easier platform to use since the playtesters, once satisfied that they have played the game enough, could simple press ALT + TAB to switch between the game and the questions posed on the google form.
Figure 1 shows some of the questions we posed to the playtestersFigure 2 shows the types of responses we received during playtesting.
Now in terms of how the playtesting affected my groups’s game development, for the alpha we didnt really look at the results in detail since we already new what we were going to fix and what we were going to implement for the Beta. This in a way meant that it didnt affect my game’s development at all and could have had reperccusions later on. However, this was not the case for the Beta playtesting. I had a hand in analysing the results from the playtest and according to what was said, i updated our game’s balance to more suit what the players expected from our game. This was important because game balancing can be difficult to achieve and is an important aspect of a game’s development process.
During the beta playtesting where we could use more of the feedback, the playtesters mentioned the fact that the allies felt more like scapegoats instead of teammates. To fix this we added dialog that would shared between the allies and the player, basically visual feedback in times of crisis or when the allies wanted to help you with something. Another thing playtesters mentioned, that we changed was the shield on/off timer as they felt it took too long to use the shield again. This involved some game balancing and we took this information and used it to check other things in the game that could use more game balancing. This informaiton was probably the most useful feedback we had in during our game’s development process so far and made our game more interesting to play.
At the end of the playtesting though i did feel like my team didnt really use the playtesting results as much as we probably should have and it would have made our game a bit better. Which meant that playtesting results didn’t really affect my game’s development as much as talking to people while they played our game did. However, we did achieve quite good feedback on the controls of our game where they weren’t optimal enough for our gameplay and we were able to rectify that. We also received good feedback on the general aspects of the game and we were quite satisfied that our game had a good impact on the playtesters. So, keeping that in mind for the final version of our game we only need to implement the rest of the animations, proceed to debug and polish the rest of the game.
I know i should probably comment on Clement’s blog since i am a programmer but since it’s your group i just couldn’t not comment on yours instead.
First off, i love the theme of your blog it is very dark and mysterious which makes your groups game “Depth” really shine through. I don’t know if you did that on purpose, but it is awesome! especially since it was my group that came up with the “Depth” concept.
Ok so enough about your theme, let’s take a look at your actual blog post. I like that when you describe what you’ve been working on, you give us a tad bit of your thought process when it comes to creating sprites and we can derive that you have a similar thought process for other sprites you have made. I also like that with all three of your concepts for your “death” sprite, you use the same brushes, this is good art practise because it links art pieces together with a specific theme and if having done different brushes the concepts would be too different and might look contextually weird.
The production process for the creation of your 3 sprites is very clearly described which makes the reader read your text more intuitively. Your motivation for your production process is also very good and i can really see why you chose to go with those specific colour schemes and scenes. This blog post really provides value to readers who are looking for motivations or ideas for creating sprites with a theme of death.
Lastly, in terms of can your post be improved, all i say is that in some places it feels like you just shoved in information where more information wasn’t necessary since in the next paragraph you end up talking about that subject anyways. You did this in here: “I was thinking about the “alarm-lights” coming on inside the submarine, hence why the windows glow red (in both the black, first version and in the yellow, broken, second version.)” The information in brackets wasn’t necessary in my opinion. Other than that, i really enjoyed this blog post, i also like your art style and can’t wait for the final version of your game!
Programming Games 