Friday, December 9, 2011

How about what the game looks like?

Here's a small taste of what our game has to offer. We still have some temporary art so be nice!

Navigation at it's finest

One component of nearly any shooting game, especially when multiple players are involved, is a mini-map to inform the player of unit positions. This is something we felt was necessary for our game and was part of our recent developments. When rendering a mini-map, any information necessary needs to be re-rendered to the small portion of the screen that is meant for the map.

To do this, a simple algorithm is used to scale down unit positions for the mini-map. The algorithm is as follows:

x position = mini-map screen coordinate + unit x coordinate * (mini-map width / main map width)

You do this for both the x and y coordinates and then draw a small shape or texture to the screen at the location. This draws a nice indicator for the unit in correct screen space for the player to enjoy. You can also play with effects to get player attention. For instance, our end level objective pulses to ensure the player knows about this important location.

That's it for this post, check back for more development updates coming soon!

What made Donkey Kong Country look so attractive?

When making a 2D game you will be forced to either learn how to create sprite sheets or navigate the interwebs to find that one sprite sheet that fits your needs. When you usually find that sprite sheet, it's on some weird format or some terrible resolution.

This is how we went about creating animations for our game. It was basically the same steps that the people from Rare followed to create their assets when developing Donkey Kong Country. Take a 3d model and since we don't have the software to render animated 3d objects on our game, we can render it to a sprite sheet and use it on our engine.

Make your art in Autodesk 3Ds Max and then render at whatever resolution pleases your needs and you will have a high resolution, high quality animation that will impress. Thanks to a 3ds Max script written by Geoffrey Samuel, we were able to render from 3ds max to whatever resolution sprite sheet at whatever configuration we needed. It also helped with making alpha based sprite sheets.

CLICK FOR GIANT CRAB!
The final product
CLICK FOR GIANT CRAB!

Wednesday, November 30, 2011

This is my BOOM STICK! Quick and easy top-down shotgun effect.

Ahh, the shotgun. When the baddies are closing in, there isn't much else that will have the devastating affect on the target as a shotgun. In our game, the scout will be equipped with a shotgun. Combined with his sprint ability, the scout's best strategy will be to time the use of the sprint to get in, let off a few blast, and get out. For the shotgun blast to look like a shotgun blast, it must behave a bit differently from most of the other weapons in the game. Weapons like the pistol and machine gun will fire in a straight line, all the time, while the shotgun must have a spread.

I went through a few different ideas on how to accomplish this, but I couldn't get it quite right. Thanks to the help of John O'Leske, our course director, he was able to point me in the right direction and the shotgun now has proper blast. By adding one more step to the calculation, the effect can be achieved quite easily. Just like with the other guns, the first step is to find the vector between the player and his where the crosshair is aimed. Then, we find the angle of that vector. Then to change the trajectory of this piece of the shotgun blast, we rotate that vector a bit. Repeat for each piece of the shotgun blast, in our case 5 times, changing the vector a bit, and a simple, but effective shotgun blast is achieved.

Check back soon for more information about Medusa!

Tuesday, November 29, 2011

Networking Update - Single Player

Welcome back for an update on the network development for MEDUSA. Much of the network development initially has been centered around multiple client computers connecting to a single server computer. This communication is great for playing the game with multiple people, but supporting only a single player is essential as well.

In order to support a single player, we run the server and client game states alongside each other in one application. This means that the input, updates, and rendering to the screen is run from both states. A basic idea is the following:
  • Client sends input to the Server
  • Server reads the input and updates the game accordingly
  • Server sends all updated information to the Client
  • Client renders the newly updated objects to the screen
This process is the same for single player as with multiple players, with the key difference being the Client and Server are running in the same application on a single computer.

The end result of this method prevents us from writing a completely different set of logic specific to a single player. It allows the preexisting client/server communication logic to be used regardless of the player count. The networking is coming along nicely and will provide a great experience for the players.

That's all for now, but stay tuned for more updates on MEDUSA!

Monday, November 28, 2011

Class Preview: The Scout

The Scout is a very high mobility class and benefits from being able to easily gun and run. We wanted to preserve the mobility that is inherit to the class but give interesting choices as to how to approach enemies.

The Scout's shotgun fires a spray that becomes gradually less accurate the further away the Scout is from the target. This gives the Scout two options as to how to operate. The Scout can keep a safe distance from the enemy and do less damage with each shot. The risks here are that ammo is finite and it will be quiet easy to run out if you don't deal enough damage with what you pick up. The other option the Scout has is to get in the enemies faces and shoot at near point black range for maximum firepower. The risks here are obviously the player is also very close to getting hit and the Scout is a very fragile class, with the least health. A few missteps and the Scout may end up dead.

Now even a really good Scout that can effectively backup and shoot away from the enemy will run into a problem of the best possible path does not always lead them back to his allies. It will not be uncommon for a Scout to end up in a corner by themselves and be low on health or ammo. The Scout's special ability allows them to increase their movement speed and avoid death for a short period of time to be able to rejoin the group. We decided the Scout shouldn't be able to shoot during this invincible sprint because it could lead to issues where a Scout would end up using this defensive ability offensively and tank most of the damage for the team by standing in front.

We hope everyone will enjoy the Scout as it is the most aggressive and mobile of the 4 classes.

Saturday, November 26, 2011

Class Preview: The Medic

Early on we decided that we wanted a 4 person co-op shooter. Each player would be a different class and everyone agreed at least one of them should be able to heal.

Early designs had the medic similar to Team Fortress 2's medic with a medigun that literally shot health at targeted allies. We decided against this plan because we wanted a play experience that was fun for all team members. The least picked and most powerful class in TF2 is the Medic solely because his main objective is so vastly different than the rest of the team. In a first person shooter most players want to shoot enemies and rack up kills, not hide behind a larger character and heal him. We decided on a simple to learn, difficult to master approach with the medic's gun shooting like the other characters but if the bullets collided with an ally it would heal them for the amount of damage it would have done to an enemy. It allows the medic to actively participate in a fight gunning down enemies but in clutch moments able to support other teammates.

The Medic's special ability is a stun grenade. We wanted the medic to still feel like a support class and not be in the front lines but be able to continue to protect allies. The stun grenade pushes enemies back and stops them from moving for a short period of time. This allows the medic to get into a better position to shoot and heal damaged allies. This ability can also still be used very offensively to stop large mobs of weaker monsters from surrounding a team.

Friday, November 25, 2011

Making the use of tools

Over the course of the first sprint, it was my job to create the level editor for Medusa. To meet the requirements of our game, the editor had to be fairly robust. While most of the goals were met during the first sprint for the editor, I spent some of the first few days of the current sprint putting some finishing touches on the editor. I added things like the ability to click-and-drag the various triggers that are in our game so placement will be quick and painless. Adding this functionality will make the editor more user friendly and allow for changes to be made quickly.

During the course of this next sprint, my largest role will be to take this tool and start creating levels for the game. As the lead level designer, it will be up to me to make a tutorial level that will introduce new players to the game, as well as get some of the initial levels started. Here's where all the hard work the last few weeks should really pay off. Setting up things like the player spawn points, event triggers, enemy spawn points, collision boundaries, placing props, powerups, lights and various other things can be accomplished quickly with the tools provided by the editor. Check back soon to see some of the levels in action!

Thursday, November 24, 2011

Happy Thanksgiving!!!

Happy Thanksgiving

Everyone at Bottle Rocket wishes our lovely blog readers a happy thanksgiving!

As a team we'd like to give thanks to everyone that has supported us since we decided to come to Full Sail and the whole staff at Full Sail that's been there to help us out throughout the project.

Wednesday, November 23, 2011

Learning to Network

Hey everybody and welcome back for another development update on MEDUSA. In this post, I want to talk about networking and our experiences thus far. From the beginning of development we knew we wanted to achieve networking for MEDUSA to allow cooperative play with friends. A previously built prototype had 2 player cooperative play but only with with a single split-screen that greatly hindered field of view.

The major hurdle that our team had to clear was that no one had any experience with network programming. So myself and another programmer on the team, Luis Lairet, began researching on the subject to look for a starting point. Luis found a great website with articles written by Glenn Fiedler, a programmer in the industry for over 10 years and currently senior programmer at Sony Entertainment. You can find the link to his webpage at the bottom of this post and you should check it out for some some great articles on networking and physics programming. He does a great job at explaining the principles and basics while providing easy to follow tutorials.

Our Assistant Producer, Rob Martinez, also suggested that we seek the help of Darryl Malcomb, the Game Networking teacher here at Full Sail University. Our team sat down with Darryl and he was a great help in explaining some structural details for our network and the best methods of packet transfer for our needs. All of this help started us on our way and we have been making exciting progress ever since.

Today, we have our network set up with a Lobby system that is entered when players are ready to play. The Client Lobby state looks for active servers to connect to while the Server Lobby state listens for incoming connections to store. The packets of data that we send are constructed using basic structs that have a header to describe the message type and the Client that this message belongs to, along with any other information particular to that message. The basic running pattern of our game will be:
  • Client sends Input message to the Server
  • Server reads the message, using the input to compute positions and check for collisions between objects
  • Server sends a snapshot back to every connected Client with all updated object data like positions and player health/ammo
  • Client reads the snapshot message and draws all objects to the screen with the new data

The server will also send messages such as a 'Play Sound' message that the client will read and perform the proper action.

Currently, the Lobby states are connecting and allow the player to choose a character on the Client Lobby. The server also stores Client information so that if Player 2 disconnects, they will be reconnected as Player 2 again.

That's it for this post. The next step is for all objects in the game to be updated through the network and tweaks to the communication during gameplay. Stay tuned for more updates and thanks for reading!

Glenn Fiedler - Programming Website

Tuesday, November 22, 2011

Lighting System in MEDUSA

Hello everyone, so this is my first post for this blog. My name is Luis Lairet and I am one of the programmers that is working on developing MEDUSA. One of my most interesting goals for the initial development of MEDUSA during the first sprint was to find a way of incorporating lighting onto the game engine.

The first thing we tried was simply, manually rendering every sprite as a plane and applying shaders effects. It was beginning to get complicated because we would basically have to re-make DX9 SpriteLib to fit our needs. It was then that we realized that it would be better to have someone with more experience in graphics programming to help us evaluate the problem and guide us through the process.

We decided to get in contact with Lari Norri, the teacher that had recently taken over the DirectX course at Full Sail University. Our first meeting with him had us arguing about the problem and what we would have to overcome while developing our idea. It didn't take him long to think of a solution. The solution was to do lighting through post processing. Basically we would render the whole scene to a texture and then apply lighting to that texture through the shader. This opened a lot of possibilities for us and MEDUSA. I already had a system working where you could display lighting on sprites using shaders but it wasn't nearly as optimized as this method could be. So I decided to scrap what was already done and take up the challenge of researching rendering to textures, post processing and then how to incorporate those two concepts onto rendering lights to a scene.

The final product is this(rendering on our Map Editor):

The final product
You have up to 7 lights on a scene plus the ambient light at any given time. The engine will calculate which lights are currently used on the scene and send them to the shader for processing. The concept for this is:

Screen Space to Texture Space

- Loop through the lights that are in the scene
- If the light is on screen, then take it's position and radius from screen space to texture space.
- Upload the array onto the GPU's memory
- Render the final color of a pixel by seeing how much each light colors each pixel

It was a fun process researching this topic, I hope you enjoyed it.

Until next time,
Luis Lairet

Welcome!

 Welcome to the BottleRocket! development blog for our upcoming title, MEDUSA.  This is the team's first game and is being developed for the PC.  MEDUSA is a swarm-shooting game played from a top-down perspective and focused on cooperative gameplay.  A few key features include:
  • Play with your friends with up to 4-player Co-op gameplay.
  • Play as 4 different characters with unique special abilities for combat
  • Survive and destroy swarms of infected ocean-life as you navigate an underwater facility
Stay tuned for daily updates on all aspects of development!