Showing posts with label game dev diaries. Show all posts
Showing posts with label game dev diaries. Show all posts

Friday, May 12, 2017

Game Prototyping in Unity, Part 3: Character Controller

This is a continuation of my blog post series about a tutorial I made called Game Prototyping in Unity available on Pluralsight. If you haven't read the previous entries, check out Part 1 on whiteboxing and Part 2 on art and sound integration.

There are many times when you don't need to make a character controller from scratch - a lot of simple first-person games use Unity's default first-person controller. You may also have a game where a character controller is not needed at all, such as a top-down strategy or puzzle game. Unity also has a third-person controller, which can work well in some circumstances. However, if you know the kind of behavior your want from your character controller, it is sometimes easier to make it yourself rather than trying to find one that suits your needs.

When designing a character controller, I like to first imagine how I want the player to see the world and the character. Do I want the player to be up close to the environment, seeing things first-hand?



Or do I want the player to see the character they are playing, see that character's animations and how that character interacts with the world?


For this game we will make a third-person character controller.

The next decision to make is deciding what the player's input will be to move the character. In some third-person games, the player clicks a point for the character to move there. In other games the player uses WASD or the controller joystick to move the character. There are also cases where the character moves automatically based on the context of the world - ie. moving toward an NPC to talk to them.

Since we want to offer controller support for this game, it makes the most sense to use WASD since that has a direct mapping to the controller joystick.

We also need to ask ourselves "Can the player control the camera?"

In some third-person games the camera automatically follows the character with no input from the user. In other games, the user controls the camera with the mouse or with the right joystick. We will use the latter option.

For this character controller I've decided to use Unity's NavMesh because it automatically handles keeping the player on the ground and smooth gradual movement. The NavMesh allows you to determine if objects in the scene are "walkable" - meaning the top of the object is a surface the player can walk on - or "not walkable" - meaning that object is an obstacle or in some way inaccessible. Once you'd baked the NavMesh you can see what areas the player can walk on as a blue surface.


The scripting part is fairly simple, we just need to attach a NavMeshAgent component to our character and then tell it which was to move.


Unity also comes with a "Smooth Follow" script which can be attached to the camera and set to target the character, that was the camera moves when the character moves. We can also use Unity's "Simple Mouse Rotator" script to give the player control of the camera direction.


The final step is going to be giving the player a ranged attack. A ranged attack can be anything that is fired from a distance such as a gun or a spell. I think a spell would work better in the kind of world I am creating, so I will make a projectile object with a particle effect like a spell, and put it in a folder called "Resources" (it's important this one is spelled correctly, because this is the only folder Unity can load from at runtime).


Then we need to instantiate that projectile when the player fires.


Then on the projectile itself we want to tell it to move forward on every frame (since we are instantiating it facing the direction we want it to move, it should only ever move forward).


And that's it! Now we have a third-person character controller that moves with WASD and uses the mouse to look around, and can cast a spell at enemies.


Check out the full video tutorial on Pluralsight! Section 4 will cover scripted interactions.


Wednesday, October 19, 2016

IndieCade Festival

Over the weekend I had the fantastic opportunity to hang out at the IndieCade Festival for Independent Game Developers. IndieCade is one of my favorite game dev events because it is really focused on Indies - it showcases the best indie games in development (or recently released), it offers indie devs a chance to network with each other and with potential publishers, and it has a great lineup of talks targeting the most useful information for development as an indie studio.

There were four talks I found particularly useful - the first was called "So you want to start a game company? Corporate Formation and IP Strategy" and was led by Jonathan Pearce. I've been operating Astire Games as a Sole Proprietor with a DBA (I hope...), but I have run into some limiting factors by not being incorporated (most notably I've been trying to become a Sony developer, and as far as I can tell you need confirmation of your corporate entity). Anyway, I've had a lot of concerns and questions about forming an LLC versus an Inc, issues with IP and with paying employees (or offering rev share), the potential for incorporating in a different state, and deep-seated fears about legal issues arising in my entrepreneurial endeavors. Jonathan's talk was both inspiring and informative, and laid to rest some of my biggest concerns, though I still have some more decisions to make - I am completely on-the-fence about what state to incorporate in.

The second talk I attended was actually a workshop called "Paper Prototyping" and was run by several experienced educators, one of whom I spent some time talking to - Michael Annetta (sadly I do not recall the names of the others involved). This two-hour session took us on the ins and outs of developing a game idea from scratch, and although a lot of it was stuff I already knew, it was awesome to see it from a new perspective and it gave me some great ideas for better ways to teach design and prototyping (as you know, I teach level design, UI design, and rapid prototyping at the Art Institute). This workshop was also very active and I made some new friends that I continued to see throughout the rest of the festival.

On the second day I finally ended up at a VR talk called "Non Photoreal VR" about the visual design side of VR, dealing with performance issues, and tricks for making an environment feel "more 3D" using parallax, lighting, and fog.

The last talk I attended was by a friend of mine - Chris DeLeon (@ChrisDeLeon) - called "Starting Meetups that Make Games." In his talk, Chris gave some background on his experience running several different game developer meetups/clubs where participants would form teams and create and publish games in their spare time (often either students or folks working in a non-game field, or game developers who want to try a different discipline outside of their normal job). Two of the biggest problems facing game dev students when they graduate are 1.) not having a shipped title and 2.) not having experience working in a cross-discipline team. As we learned in this talk, a game dev meetup can help solve both of these problems.

I was inspired by Chris' talk to set into motion something I have been considering for a while - I want to give my students at the Art Institute (as well as students at the other colleges in Austin) a chance to get some hands-on work in an interdisciplinary group on a game that will ship. This is now one of my top-most priorities - I have always been passionate about the idea of improving education, and now here is something very tangible that I am very capable of contributing.

Aside from the four fabulous talks, IndieCade also offered me one other tremendous opportunity. IndieXChange (one of the IndieCade tracks) offers something called "Speed Dating" where developers get five minutes to meet with a publisher and pitch their idea, then can follow up afterward with those publishers. I was lucky enough to get to meet with reps from Sony and a rep from Oculus, and discuss my VR project Sundown Arcadia. It was an exhilarating experience - I always love an opportunity to talk up my games, and having an avid audience of publishers listening was quite thrilling.

One of the best parts about IndieCade, in my opinion, is the quality of the connections being made. At your average game dev conference you walk away with a big stack of business cards of people you are probable not going to contact. I left IndieCade with just seven business cards, but I have a very specific follow-up email for each one of them.

Between the superb talks, the phenomenal pitch opportunity, and the unique networking connection, I would call my IndieCade experience a success!

Friday, June 10, 2016

Oculus Launch Pad

Last month I had the opportunity to attend an event at Facebook Headquarters called Oculus Launch Pad. This event was intended to promote diversity in the field of VR, and it met those intentions quite well. The program hosted 100 people for a day-long boot camp as a deep dive into developing games, apps, and film for virtual reality. I, along with 99 others who all came from diverse backgrounds and varying ages, genders, races, ethnicities, orientations, etc, spent a fantastic day learning about the technical side of putting a game on the GearVR, tips and tricks for designing "comfortable" VR content, how to keep a project on track and finish on time, and the importance of story and immersion in the VR world. The day concluded with a Q&A with Palmer Lucky and a networking mixer for all of the participants to get to know each other and learn about everyone's interests and projects.

On the technical side, it was great to have an opportunity to go through the process of getting an application from Unity onto the GearVR. I'm outlining the process here for anyone else who may be interested in making something for GearVR:

1. Get the latest version of Unity, and during the initial download be sure to check the box for "Android" from the list of development platforms (if you already downloaded Unity and don't have the Android package you will need to go back to the Unity downloader to get it).

2. Visit the Oculus developer website and download the Oculus SDK and Oculus Unity Utilities, and import the Oculus Unity Utilities package to your Unity project

3. Download and install the Android SDK. It will launch a download manager where you can select different versions. you can download as many versions as you like, but you will at least need API level 19. When you select download, you will need to agree to the terms and whatnot, but it is not super clear from the prompt you need to select "agree" for each of the download items in your selected list, so if you have two items selected you will need to scroll to the bottom to "agree" for the second one.

4. Create an OSIG for your device. This one is a little complicated, here are the details

  • Put your Android Galaxy device into debug mode (go to settings > device and tap the build number a bunch of times)
  • On your Android device go to Developer Settings and check the box for "USB Debugging" then plug it in to your computer
  • Open Command Prompt (or Terminal on a Mac)
  • d. Navigate to the Android SDK Tools folder (use 'cd' to change directories, 'cd ..' takes you up a directory, 'cd Directory_Name' takes you down into specified directory)
  • Use the command 'adb devices' and it will give you a list of IDs for connected devices (you will probably only have one) - if you have trouble with this step you may need to update the drivers on your computer
  • Copy your device ID, then go to developer.oculus.com/osig and enter the ID
  • Download the osig file generated by the Oculus website and copy it into the following directory inside your Unity project - Assets/pluggins/Android/assets
  •  Note that you will need a separate OSIG file for each device you want to test on; you can have as many OSIG files in the assets directory as needed

5. In Unity go to File > Build Settings. Be sure to add the scene you want to build to the list of scenes.

6. Select 'Android' from the list of platforms, then click "Player Settings" at the bottom. You can also hit "Build" right now to check if your SDK is setup properly, it will let you know if it cannot find the Android SDK (it may also prompt you to download the latest JDK which are also needed to run the Android SDK).

7. In the player settings panel which should have opened on the right side of the screen, scroll down to other settings and check the box "Enable VR", then scroll down to "Other Settings" and fill in the bundle identifier (you can use whatever company and product name you want but you need the company and product name at the top to match).

8. Sign your application - under "Publish Settings" check the box for "create new keystore" then click browse and name your keystore file, then give it a password (be sure to remember this password). Then set an alias and password for this keystore (it can be the same password or a different one).

9. Be sure your Android device is still plugged in and the screen is on, then hit "Build and Run" and the game will automatically deploy to the phone.

10. Unplug the phone from the computer. It should prompt you to put it in the GearVR, but if it does not then find your newly made build (it probably has the Unity logo right now) and run it, then when it prompts you put it in the GearVR.

I hope this is helpful to anyone trying to get started in GearVR development.  Feel free to respond with questions if you have any trouble with these steps :)

Tuesday, May 3, 2016

The Making of Cat Cave

Cat Cave was my second self-published title, but it was actually a lot of first for me. It was my first endless runner. It was my first 2D game. It was the first time I formed a team to work on one of my ideas (I found an artist, a sound designer, and a second programmer). It was the first time I attempted a port to iOS. And the second release of Cat Cave was the first time I took promotion really seriously.

I've learned a lot from the games I have released so far, but I think the most valuable thing I have learned is you can never do too much work when it's something you care about. As a single cat mamma, I have no human children, and no husband (or wife) to take care of, so my games are really like my children - I look forward to leaving work in the evenings so I can go home and spend time with them. And I feel guilty any time I have a spare moment that I choose not to spend with them.

To some this may seem like an unhealthy obsession, but for me the things I make are the strongest justification for my existence.

In total, I estimate that I invested around 120 hours into the development of Cat Cave. I wish I had kept more thorough track, but I believe the breakdown went something like this:
  • First Release
    • Development - 30 hours
    • Project Management - 10 hours
    • Promotion - 10 hours
  • Second Release (Major Update)
    • iOS Port - 15 hours
    • Development - 15 hours
    • Project Management (including running beta test) - 10 hours
    • Promotion - 30 hours
Another valuable lesson I learned is the importance of building hype. Don't release your game the day it is finished. And don't wait until it is finished to start talking about it. Talk about it all the time while you are making it. Pick a tentative release date far in the future. When you finish your game, get everything confirmed, and get it approved by all of the powers that be, THEN confirm your release date at least several days in advance. Then you must WAIT. Don't do anything to break the game. Don't do anything to put it in jeopardy on whatever platform you publish to. Don't let your anxious fans convince you to release it early. Just wait. And keep talking about it.

Speaking of which, here are the download links for Cat Cave, which is now available on Google Play and iTunes!

iOS: https://itunes.apple.com/us/app/cat-cave/id1104696928?ls=1&mt=8
Android: https://play.google.com/store/apps/details?id=com.Astire.CatCave
PC: https://moarkitties.itch.io/cat-cave




Thanks for playing!