10 Ways to Improve Your Game Cameras

Game cameras can be some of the most tricky coding you do. That’s why when John Nesky’s 50 Common Game Camera Mistakes from GDC 2014 went live on youtube (The talk is embedded below), I immediately watched it! We can all benefit from these lessons from Nesky for refining our cameras!

When I first started watching Nesky’s talk I didn’t think he actually had 50 mistakes nor that he could actually get to all of them in an hour talk! But not only did he do both, I also realized that he was also right about these only being some of the issues we face. Which means we should keep the conversation going!

So here are my 10 Ways to Improve Your Game Cameras as takeaways from Nesky’s talk:

  1. Use a bigger FOV for heaven’s sake! 🙂
  2. If you can use a simple camera, do it!
  3. Player’s intent should supersede camera scripts
  4. Use the camera to give the player subtle hints, but don’t be overbearing.
  5. Don’t use quick camera transitions in place of cuts. Either cut, slow down the transition, or find an in-between.
  6. If rotating, camera shouldn’t rotate in place (on its own axes). Should rotate around avatar.
  7. WATCH FOR SIMULATION SICKNESS (SS). It’s a disconnect between movement you see and movement you feel. Any movement seen and not felt can cause SS. Have options to turn off extra movement if you want to leave it in the game.
  8. Avoid jerky camera movements and constant camera angle changes, especially during combat! It not only leads to SS, but can also be disorienting to players as controlling movement changes with camera angles. It also doesn’t look as pretty, ahem, as aesthetically pleasing.
  9. Allow players to invert controls. It’s a significant portion of players that want to invert (like me!). You’ll lose players otherwise.
  10. Implement, test, iterate, test, test, test! Repeat.
  11. Re-Watch John Nesky’s talk as needed. 😉

I just love GDC talks. There’s always so many of them at the event that you literally cannot attend all of them. So thanks to GDC for posting this treasure to the public. Thanks to John Nesky for being willing to share his own mistakes so the rest of us don’t have to suffer… as much! And for the rest of us I wish a big: Good luck!

Game Projects I: Week 17=Finals — Post Mortem

MAMT Post Mortem

What went wrong
There were way too many arguments.

It felt like many of the producers didn’t support the art and engineering teams. This is the first team I’ve had where the producers didn’t stay in the lab with the art and engineering team and support them while we  worked late. They also often argued with each other, and then with us about our decisions, and got in the way of work. They meant well, but it was frustrating and difficult to get work done with their constant problem pointing, and bickering.

 

What I learned
The design meeting was a Godsend
People see me as a leader. They listen to my ideas. I’m really good at listening to the ideas and suggestions of others an d sifting and combining them into what is best for the game.
I loved being lead engineer. I was nervous about it, but I believe I did a great job organizing the team.
I’ve become a better leader.
I like partner programming and I’m really good at helping engineers overcome their obstacles.
I love writing. I’m good at it. I had multiple people including faculty tell me I am an excellent writer.

I learned how good I am at Unity UI, partner programming, organization, game design, and writing. I wasn’t sure I was learning that much, but when it came down to the end of the semester and we were making the game and people needed help with their other classes (producers with their engineering class, writing class, engineers with their engineering clas), I was able to help them. When people asked for help I also made it a point to help them. I learned that I enjoy helping others and that as I stay organized and watch my time I do have time to help them.

 

What I would do differently
I would have initiated the design meetings much sooner. Also there were a couple miscommunications among the engineers, really just one big one between myself and one of them and what they said they had gotten done. She told me she’d gotten this huge chunk done, but I think she misunderstood the scope of what I had asked. Binoy had the great idea that we should do code reviews. So in the future I will have all the engineers commit whatever code they have been working on at the end of everyday and Binoy and myself will review it.

I should definitely continue writing regardless of where my career takes me. It makes my soul happy. As does game design, and being lead engineer. They were all roles I enjoyed playing this semester.

I want to be team lead. I have been team lead on several outside projects and they’ve all been amazing projects and have done well. I think if I am lead for this team I’ll be able to incorporate everyone’s ideas into something awesome that will make everyone happy.

I would also instantiate a veto and appeal process. The team often can’t come to decisions so the team lead (which we didn’t have one) needs to make an executive decision. The idea shouldn’t just be tossed out though. if someone feels strongly they should be able to go through an appeal process where they write up a one page defense for their idea, how it would benefit the game, a plan of action for implementing it, and it should address all the concerns and have a logical reason behind how their plan overcomes each of them,

Game Projects I: Week 16 — EAE Day

This was the week before EAE day. The engineering team worked really hard and I’m really proud of everything we accomplished. I’ll only discuss what we did after industry panel, but they worked just as hard before as they did after:

• I organized the engineers into projects: Binoy/myself did research on game engine, helped out with gameplay, and partner programmed as necessary with the other engineers and each other. Hailin was lead gameplay engineer and prototyper, and Dayna was AI lead. As engineers we wanted to explore multiple engines and what would be best for the game. This included the possibility of building our own game engine for the game so I did research into the binding C# and C++, sound and all other necessary libraries for building our own engine. When it became clear that we were making a 3D game we set aside the scratch engine idea to help create the 3D game. I helped out with the gameplay, version management (doing nearly all of the merging, and all where there were conflicts), taught Dayna and Hailin Unity Asset Server version control, helped Dayna with the AI and Unity, did partner programming with all the engineers as necessary, did all of the dialog UI and partner programmed the splash and ending screens with Binoy. I was instrumental in resolving scaling bugs in the UI (so you could see and interact with all the thoughts on the screen), and also did the builds for Windows 8 tablets. I also worked with the writing team in coming up with a story and the instantiated the design meeting which was crucial for the engineering team. With it I was able to divvy up the necessary tasks amongst us and create the game.
• Binoy was basically an assistant lead engineer doing all around engineering: helping out with gameplay, builds (he did all the research and builds for the android, and if we’d had an ipad he’d figured out how to build to that as well), did some research into the graphics for the scratch engine, and figured out XML read in (for thoughts and dialog) within Unity and created a demo (which he emailed out to the team), he also helped with the splash and end screen for the game, and helped where needed. In particular, Binoy was able to help Hailin get the thoughts rotating and dragging and dropping them back and forth into the inventory. He also worked on fixing the player movement script/camera controller. It proved difficult (as the camera always does) and because of time constraints and too many edge cases to deal with in a timely manner, was set aside for the next iteration. No way the game would have been finished without all his hard work and willingness to help wherever needed and to stay as late as necessary.
• Dayna was Lead AI. Without her working on that project practically solo (I only gave some input to the game design of the AI along with Sean, and helped out with some minor bugs), the rest of us wouldn’t have been able to focus so much on gameplay. She came up with a detailed plan for building a dynamic AI system and wrote personality scripts for the characters. She also learned Unity and got to play around with planes in 3D space. Not an easy task! Unfortunately because of other bugs (nothing to do with her scripts) we weren’t able to get the personality scripts on the AI, but that is first on the list for the next sprint. Dayna also participated with the writing team and in on design meetings with me and had excellent feedback, creative ideas, and suggestions.
• Hailin was our gameplay and prototype lead – she programmed in multiple camera angles and perspectives allowing us to quickly test and discard and choose the camera types we wanted to use. She got the game running in 2D in Unity and then 3D. She and Binoy did the programming behind the thoughts and rotating them, and dragging and dropping them back and forth into the inventory, and was all around awesome. She got all the animations playing and was even able to get a thought trigger reaction, but because of a bug on her computer with the Unity Asset Server we weren’t able to get it in the build for EAE day. But that would also go into the next sprint. She was all around awesome.

We were able to deliver nearly all the tech mechanics behind the game design doc that came from that meeting by EAE day. Unfortnately the design meeting didn’t happen soon enough for our team to really deliver as it was on the Thursday BEFORE EAE day. Some things just missed it, but are right on the cusp of being accomplished and will go into the next iteration

I also received lots of positive feedback for the game and really good ideas. I know others received negative feedback, but I think we all got the type of feedback we were looking for. In particular, I had a lot of people mention to me how they loved the 3D gameplay and the camera movement.

Game Projects I: Week 15 — New Design Meetings!

We got a playable point-click in 3D. The producers started to argue about the camera, but I suggested we just prototype some different ones and see what was best rather than waste time arguing. That stopped the argument, at least from happening around me. Hailin was able to quickly make the camera prototypes and we were able to play test them. After giving them all a go we decided to go with an angled camera that was Diablo-like: it followed the characters position, but never rotated (like a third person camera is always rotates when the character does, ours just followed the positon of the character, never rotating).

When I noticed that things weren’t moving along in design and story and even from art in a way that I needed as lead engineer because there was no unified vision, I talked with my friend Brenton Walker about the issues we were facing. He told me how his team was organized and how they do a 30 minute design meeting every class period right after stand up. That’s were tey come up with their list of to dos and pass then allow the leads to pass on tasks to their teams.

I thought that was an excellent idea so I proposed it to the team and they all agreed. And so on Thursday we had our first ever design meeting. It helped us nail down so many of the issues and come up with a unified design to move forward with. This design meeting was critical for us to be able to make the game.

This was a key point in turning our idea into a working demo. Without the design doc there was nothing firm that we could focus our efforts on. Everyone was working hard, but a lot of it was on long term efforts, some of it on extraneous tasks, and the short term goal for EAE day was going to be missed.

With the design doc created and updated from the meeting I was able to divvy out all the work that needed to be done to all the engineers and to our artists so we had everything we needed.

Game Projects I: Week 14 — A Blur

So much is going on right now in this semester! This week is a bit of a blur and it just happened! Here’s what I remember…

Dayna, Sean and I had an AI design meeting. We discussed the properties the AI should have, how we would design their reactions, and how to make it a dynamic AI system so that the narrative would be more f an immergent rather than a branching narrative. it was a really cool discussion. I left it to Dayna as lead AI and Sean as lead design to manage the recording and implementation of our meeting.

I did a lot of partner programming this week helping Hailin and Dayna with what they were doing. Binoy was doing research into reading in from xml and came up with a demo and I discussed the issues with doing that with him. I also took Hailin’s prototype and built it to Windows 8 tablet, which is not as simple as it seems. It took us two hours to get it worked out as we couldn’t quite remember how to do it. It took Me, Hailin, and Binoy to get it.

Roger came in and gave us some feedback about our story. What it needed was a topical hook. Two of the producers took this as our story sucked and a two-hour argument broke out. All the writers agreeing that all that needed to be done was to come up with a hook, and the two producers arguing that the story had to change. It really put a hamper in my work. This wasn’t uncommon actually. Arguments like this happened a lot among the producers. The engineers mostly didn’t know about them though because I mitigated all the arguments and then just passed on the feedback/direction that I got from these discussions so that they could focus on their work.

Bob talked with the engineers about what was new as he wanted to make sure we had something new we could show. We had a new story, new engine. Yes, yes he nodded to that but what else? We’re going to demo the game on tablets. Okay he said. Get to it.

Sold!

 

Game Projects I: Week 13 — Engine, AI, Story

I organized the engineering team and gave them their roles, or rather defined the roles within what they wanted to do. Binoy and myself were the game engine engineers. I was lead and he was assistant lead. We would do any necessary partner programming and fill in wherever necessary. I also managed version control. Hailin was lead gameplay programmer, and Dayna lead AI.

Engineering team go together and we had what was basically a mini design meeting. We broke up the work and research that we would need to do the engine (more below), AI, and gameplay. We came up with our second prototyping plan: choosing between thoughts popping up or having to click, and a 3D camera. Hailin was in charge of this. I and Binoy partnered with her as necessary.

Binoy and I really wanted to explore multiple options on the game engine which included the possibility of making our own. I was never able to get full support from the producers on this effort despite the research that Binoy and I were able to do that showed we should have been able to do it if we were making a simple 2D point-click game.

I explored bindings between c# and c++, outside libraries like SFML, we could use to improve our engine quickly. I also did research for fmod and wise for sound and their c++ “plugins”.

We also had our writing meeting and came up with a story that we all agreed on. We pitched the idea to the whole team later and the professors and they all agreed on the idea and the professors told us we could move forward with it. We came up with the characters as well. It’s a really fun story!