– LINKS AND SCREENSHOTS –
Project: https://koapush.github.io/project2/
Github: https://github.com/Koapush/project2
Screenshots:
– DOCUMENTATION –
https://docs.google.com/document/d/1G_1UNEc8uf9kAOriNEXdVEJ6epZKqb6PpfFYL9XYL-4/edit?ts=5f9179d7
10/16 afternoon:
Discuss the general idea. Review slides and searching for inspiration. Fail to come up with a satisfying idea for both.
10/22 lunchtime:
Based on what we have on the proposal, generating a new fundamental idea for the project. A little different from the previous one, but based on that: players click the landing positions for the ball and the ball will bounce from the clicked position. The goal is for the ball to collide with the object on the canvas to get scores.
10.25 afternoon
Update the idea. Generate the basic function of the project. Still remain the blocker at the bottom. The object can be a monster, who can be killed by the collision from the ball after colliding several times. And it also will attack the blocker and shorten it. So the goal for players is to kill the monster before the ball falling below the canvas.
10.27
Decided that the image of the monster/virus can be like: https://giphy.com/gifs/YPbrUhP9Ryhgi2psz3
10.29
Generated a basic virus monster using for-loop.
10.30
After talking to fellows we found that the directions of balls don’t actually change a lot even the player manages to keep the ball bouncing every time with the board. So we redesigned the launching platform like this: https://editor.p5js.org/tj1059/sketches/pfdo1ZUst
10.31
Finish the general model in p5.js: https://editor.p5js.org/tj1059/sketches/sO9dtntTs.
11.1 night
Realizing the difficulty that we should break down each state of the game separately, we decided to turn the code into an oop format so that it might be easier to call according to methods under each state.
11.2 User tests
Working on modifying the code in oop mainly to solve the bug that the ball can be continuously launched even after the virus is killed and the code runs again and again.
11.3 night
Focus on debugging. We created several classes so that the overall structure is much clearer and each state could run individually (and accordingly created separating js files suggested by fellows). We also modified the code referring to the feedback from the user test. We specifically designed the playing rules and added the interface design elements. One new problem we met now is that the code would not run once we add an audio source to it.
11.4 In Class User-test
Referring to the feedback from classmates, added a Restart function; Figure out the problem of applying audio sources.
11.5 night – Last update:((
Change the playing rule that the virus can increase its blood if it’s not hit, which increases the playability and playing time. Modify the front page and changed the font.
11.6 Presentation
– REFLECTION – Coding –
Generally speaking, I’m personally pretty satisfied with our project and very much appreciate working with my partner, Cara.
As for the overall process of making this project, it goes mostly as we expected (and somehow even beyond my expectation to be honest). When first being inspired by the brick-breaking game, we intended to design a similarly interactive game (i.e, with simple design yet playable interactions). During our later process of realizing the basic model, both we ourselves came up with various new ideas through brainstorming and we were inspired by other suggestions. Though we did suffer much struggles during the whole process and for now even have any further ideas to be realized, I am more than proud to have what we have right now as our group project.
To be more specific, as for the coding part, I think we’ve mostly achieved what we expected and realized some more chilling effect that goes far beyond my original expectation. When first realizing the bouncing ball model in p5.js, we saw part of the whole picture of the difficulties that we should be able to separate each game state individually. Facing with such struggle, we then tried to modify what we had at that time into an object-oriented programming format, which was a huge challenge for us. Thanks to the help from our professor Steele, learning assistant Linda and fellows, we finally tidied up our basic logic within the code – creating different classes and methods, and defining different game states to call the according methods in order to run the game.
Things then became relatively easier to further develop our project in code, and since we’ve been constantly coming up with new ideas and hearing from others’ suggestions, we still made a lot of huge and tiny changes even after the user test. For example, we modified the visual style of our project by delicately designing the project name as well as the winning/losing page by applying one certain google font. What’s more, thanks to the cute stickers on jamboard, we added to the background music as well as the sounds for hitting effects and winning/losing page, therefore making it much more a pleasing game in any sense. As for the game itself, in order to enhance the playability within our capacity, me and Cara brainstormed for quite a long time and eventually came up with the idea of applying the blood bar and enabling it to restore automatically. The goal of the game was therefore to literally “kill” the virus before it recovers. (It was even one of my proudest development of our project:)
Other problems we met during the process of further modification include being unable to play the bgm automatically when entering the webpage (due to the settings for Chrome browser), unable to play the winning/losing sound only once in the draw() function, unable to set the canvas in the middle of the browser, etc. Every time when successfully solving a problem, say, a bug in code, I felt quite self-satisfied and large added to my pride in our project. All the problems were eventually solved, yet if I had more time, I might try to change the RESTART button into a keypress function so that it could somehow keep the coherence of the interactions. Anyway, I would say we realized what we set out to do and even achieved more than what we expected initially.
– REFLECTION – Idea –
- Did the process go as planned?
Cara and I actually changed our idea/plan several times. We started our idea from the inspiration of the game Brick Breaker and would like to make an interactive game with simple and clear UI and a relatively high degree of playability, like the game Brick Breaker. Since we did want to make something different, we first changed the bricks to a moving object, and to a virus monster. Having found that the tracks for the ball are actually easy to figure out, which decreased the playability, we removed the board using a launch platform instead. User test feedback also changed our plan. For example, to increase the duration of a single trail, we added a blood bar for the virus monster, which we never thought of as we design our game. We also added visual and audio effects, as well as a restart button after the user test.
- Did you achieve what you set out to do?
Yes. We are satisfied with our job of making an interaction game with exactly simple and clear UI but nice UX and playability.
- What (1) did you set out to do or learn, and did;
We set out to make a creative and interactive game with simple and clear UI but nice UX and playability, and we do think we did a good job on that.
(2) did you set out to do, but didn’t
We think we did all that we thought of.
(3) did you do or learn, and hadn’t originally intended to?
We actually didn’t have a clear idea of what we were going to do, so most of what we’ve had now is not intended originally. This is not bad because we won’t be limited by a single idea, and we are ready to change to a better idea at any time. For example, the blood bar of the virus is added right the eve before the final presentation. But we do learn that we might as well have a much clear idea framework on the first stage so that we could be more efficient instead of updating ideas and the coding again and again, which wasted a lot of time.
- What would you have done differently?
We would generate a much clearer frame idea before we actually start coding so that we can be more productive and efficient. We also find that working together is indeed important for a group project. Since Jyoti and I have different schedules for the midterm, in the first and second weeks we are kind of working separately, and it’s not convenient for idea updating and collaboration. So we would definitely spend more time working together and do communications timely.
Leave a Reply