GDD and Fred the Shark, Mike Moore, Week 6 Journal 14MAY17
Snippet of the video: This is Fred the shark, Fred the shark now has bones and controllers that make him chomp and swim… you’re welcome world. Fred says wish your mother a happy Mother’s Day.
On another super exciting note, the project managers banged out a rough GDD… 30 pages… woot woot. It is nice to have all the information in one place. Code, art, anim, and production departments are all moving forward to bigger and harder challenges… here is to an awesome game.
Thanks to the Art Dept the Anim Dept is starting to crank out idle, and attack scenes for the underwater level enemies. Main characters are now being fitted into there own rigs.
Positive: Enemies and characters are being rigged and animated. GDD is now a living and breathing small novel.
Negative: Figuring out the rigging and parenting of controllers can be quite the time consuming effort. Ran into some grouping issues while having different controllers for the rigs. Bless the Game Gods for youtube.
This week was all about creating character and background art, sending it to Syd to be vectorized, and making sure it’s formatted correctly for rigging. Wednesday the group looked at the current character designs and shared what they liked, didn’t like, and wanted from them. The goal became to make the sister seem fun-loving, and maybe a little scruffy, but still mature enough to be read as an older sister. In iterating her design, I got rid of some of her asymmetry, since that would make her sprite for moving left different from moving right. She has some scratches and patches to vary things up, but nothing major. Now she has game ready art from a profile view, and lines for an idle pose coming up. We decided to wait and see how the animation for the sister goes before making final art for the brother, but he does have iterated art now. He’s a combination of the last two designs, taking the baggy top, expression, and backpack from the second and the rest of his design from the first. He’s also been stylized to match the sister. As a smaller task, I also altered the tail for the shark enemy, so that it looks more like it’s heading straight for the player.
After receiving a blueprint for different environment zones and platform locations for level design, I also began working on background art. It’s only first iteration art, but it was received well enough to be vectorized and prepared to be put into the game. After seeing what works and doesn’t work about it, that art can be remade.
This week’s process went pretty smoothly, it mostly involved me drawing, making sure people liked what was being put out, and then changing things upon request. Drawing the background was a little weird because the blueprint and size requirements were 4096 x 46989, but it should be able to scale down nicely now.
It’s the end of the first week of development. While the art team was working on laying out the concept for story and character design, the programming team worked on a quick prototype of the game mechanics.
I was in charge of getting a movement system setup, along with controller support for the two players. I had some old code from a previous 2D platformer project so I used that as a base. Since this game will have two players, I had to decide how the camera would function. Since the brother is the slower of the two characters, I had the camera follow him exclusively. The sister’s position in the game has no affect on the camera. I added restraints to the sides of the screen so that the sister can’t wander off where the camera won’t see her.
Controller support was some work. The process behind setting it up isn’t too difficult once you know what you’re doing. But before you do understand the process, it’s a bit obtuse. Unity has a list of input settings to toy with, but the setting names don’t always convey what they actually do. For example, I made a setting that mapped jumping to a button on Player 1’s controller. I edited the setting to “Controller 1”, which I thought would keep that button to Player 1’s controls. However in testing, jumping with that setting caused Player 2 to jump too. Turns out setting “Controller 1” only works for certain situations, and otherwise you have to name the button according the the controller you want to use. Once I figured that out it was easy, but it was annoying getting there.
Lastly I took the code from the other coders and added it to what I had. Unfortunately not all of it worked, so I had to cut down or dummy down some of the features we would have liked to have for our prototype. Next week though we’ll be having a meeting on how to better share our code.
Week 1 had a pretty tight schedule and I didn’t get any sleep tonight, but at least the demo’s finished.
Syd and I further discussed the features we wanted to see in the game’s main characters, and then we threw a couple different sketches back and forth to explain visually. Eventually we ended up with two possible directions for the big sister and two for the younger brother. Each sketch has a preliminary color palette, but they’re nowhere near final. Both the sketch and the colors are to be iterated on according to how the group responds in our next meeting.
We tackled the enemy concepts with a similar approach, deciding on what some light enemies could be, what the final boss might be, and then talked about shark being the likely heavy enemies. Both of those have sketches and color now too.
One key to any successful group undertaking is organization. In every sense of the word. This, of course, takes the form of our various technologies and setups to keep our team on the same page — Trello, Discord, Google Drive, and the like. But this was prefaced by an even more broad discussion: that of who would take on what responsibilities. Completely by chance, we wound up with a pretty balanced team: of the eight of us, four were interested and able to handle coding; the rest were ready to cover 2D art, modeling, and/or animation; enough people were interested in taking on some aspect of project management that we would be sufficiently covered in that regard as well. At the end of our first discussion, our team organization looked like this:
The entire group met for a few hours and pitched ideas and concepts. We ended up settling on a side scrolling co-op game and began a discussion on the overall concepts we’d like to address in the game. With a possible focus on the fellowship aspect of a co-op game, we brought up the idea of two siblings walking home and creating their environment with their imagination.
Erin Truesdell, Chris Lucas, Kane Fitzgerald, Sydney Oswald, Tom Dragna, Mike Moore, Noah Nam, and John Harvey.
It’s the first week of development for us.
Class and the assignment were on Monday. We held our first meeting on Wednesday, where we discussed individual strengths and spent two hours pitching ideas, discussed, and voted until we had selected our final concept: a forced-coop side-scroller featuring the fantasy adventures of a big sister and a little brother on their way home from school.
Friday was our next team meeting. We set up this site for production journals, set up a team Google Drive, and a team Trello. Communication-wise, we’ve set up a Facebook group chat and a Discord channel. And, of course, we selected a team name. Sydney took on setting up our sprint records, and tasks were assigned to team members according to their abilities.