Making Games for a Good Cause: The Solar Games

Making Games for a Good Cause: The Solar Games

Hello everyone! Its been a couple of weeks since I last posted something on my blog. Today I'm happy to share a game project that I'm currently working on along with a group of talented people from the Orlando Area. This game project is called The Solar Games.

The Solar Games is a fast paced, solar-powered kart racing game being released for the mobile platform. The year is 2033. Global climate change efforts of the past 20 years have failed. The environmental apocalypse has arrived and it is causing strange mutations across the planet. The global community has one last hope by creating a race for change, an environmental Olympics... The Solar Games. A social impact video game that empowers players to create change in the world through a video game that provides energy solutions. 

The first in the series, Solar Racing is akin to Mario Kart meets Fallout. The game is set in a post-environmental-apocalyptic world where the landscape is now a surreal wasteland which has become commonplace around the planet. The gameplay is fast, intense with a dose of humor. Players will be able to race in multiple modes, from single to multiplayer across realistic tracks based on real world locations: initially based on Haiti.

The most amazing part of The Solar games is that any player can play and have fun while support a great cause: rural electrification in Haiti. Over 80% of Haitians are without electricity. Half of the game's profits will go to help create solar-powered energy for residents so they can see after the sun goes down, refrigerate their food and medicine, and power local facilities, such as schools, medical centers, and place of worship around the neighborhood. 

Here's how you can help:

We are trying to get the word out about The Solar Games so everyone can know about the project. We are launching a Kickstarter campaign running from August 5, 2013 to September 6, 2013 to raise the money we need to see the project to its completion.

Please forward this message or share our social media links to get the word out. And please donate on Kickstarter if you believe in the cause.

For more information about the game, you can look on the following links:

Website: www.thesolargames.com

Kickstarter: http://www.kickstarter.com/projects/thesolargames/the-solar-games

Facebook: www.facebook.com/thesolargames

Twitter: www.twitter.com/thesolargames

Youtube: www.youtube.com/thesolargamestv

Instagram: www.instagram.com/thesolargames

Pinterest: www.pinterest.com/thesolargames

The Role of the Producer in the Game Industry

The Role of the Producer in the Game Industry

  

     Today I'm going to share some important points in which will help some people have a better understanding of what is the Producers responsibility in the Game Industry. The points that I'm going to be sharing mainly come from an article from Gamasutra called "WTF Do Producers Do All Day?", written by Kain Shin on May 31, 2009. You can view the original article by clicking on this link. I figured that it was best to use the main points of this resource on my blog since it clearly summarizes the importance of the role of the producer in the Game Industry.

What do Producers Do?

• They lead the effort of getting the game finished on time and within budget.
• They can be the voice of reason that pushes to reduce the scope of the game if the design is too ambitious for the resources.
• They make schedules, minimizing chronological dependencies between tasks so that nobody is blocked and waiting on somebody else to finish their task.
• They make budgets, taking into account the salaries, application tools, and license fees that need to be paid for.
• They notice problems with workflow and come up with solutions in order to fix them.
• They are leaders, part of the management circle. A good producer can carry the team to victory, and a bad producer can cause the studio to shut down.
• They communicate the work process to the team.
• They make sure everybody knows what they should be working on at any one time.
• They adjust the schedule as needed, but also try to plan as much as they can early on so that little adjustment would be necessary.
• They can deal with the press by providing review copies and giving interviews that make people want to buy the game.
• They can be a liaison between the development team and anybody above, like the studio director or the publisher’s representative (the external producer).
• They may not necessarily solve every problem, but they do make sure that somebody is assigned to solve it.
• They may possibly pick up whatever leftover slack they can take using whatever skills they happen to have to help balance everyone’s plate (including their own) as best they can.
• They are in charge of ordering food for the team if the team needs to work late.
• They make sure there that documentation exists for tracking logistical issues such as equipment purchases and inventory status.

Technical Skills:

• Scheduling Software ( Examples: Microsoft Project and Hansoft). 
• MS Powerpoint (or OpenOffice) 
• MS Excel (or OpenOffice)
• Reading manuals and learning how to use new things. 

Good Producer Qualities:

• They keep meetings short and on track.
• Updates the schedule once a week or more.
• Communicates in a non-intrusive manner. 
• Good interviewing practices.
• Sees the big picture of any game project (salaries, financials statuses, studio strategies, etc). 
• Catches problems before they happen. 
• Knows a little bit about everything.
• Doesn't let things slide. 
• Turns everything into a time estimate.
• Stay as late as the team.
• Is a highly empathic people person with good social instincts. 
• Always trying to improve. 

Bad Producer Qualities:

• Makes the team stay late for crunch and then leaves at a normal time to enjoy a regular evening for themself.
• (Pertains mainly to large projects) Usurps ownership of Game Design authority. 
• Doesn’t write anything down.
• Downer Personality.
• Can’t separate talent from personality.
• Won’t fire anybody no matter how bad they are. 
• Promotes nepotism.
• Assumes that crunching is a normal part of the schedule. 
• Freaks the team out by constantly telling them how grim things are and leaves the team in “firefighting” mode instead of taking actions to prevent fires. 
• Says yes/no to everything. 
• Does Not Know The Product. 
• Focuses on the Blame Game. 
• Believes they have nothing more to learn.

Hope the main points of this article help you out. If interested to read the article in more detail, go to the following link.

Reference:

Shin, K. (May 31, 2009). WTF Do Producers Do All Day? Gamasutra. Retrieved from http://gamasutra.com/blogs/KainShin/20090531/84130/WTF_Do_Producers_Do_All_Day.php

Reus

Reus Usability Test Project

     Good day everyone! Time has passed since I last posted something on my blog. I'm happy to share an interesting project that I recently worked on. This particular project is a bit different from the previous ones because it is a game that I did not contributed on the design, production, nor programming. Along with a team of Usability Researchers, we specifically designed and conducted a Usability Test for the Tutorials of an Indie Game called Reus, which was developed by Abbey Games. We generated a Usability Report with the intention to help the developers to:

     1. Identify any confusing elements within the tutorials

     2. Gauge initial player reactions to the game's mechanics.

     3. Gauge initial player reactions to the games's graphics and sounds.

     4. Identify any other usability issues that could be observed through the tutorials.

What I liked about working on this game project was the satisfaction of helping other developers reach success with their current game. Abbey Games was so impressed with our detailed Usability Report that they officially added my Usability Team into their game's credits. Which is cool, since now I can officially say that this is my first shipped Indie Game.

About the game:

     Reus is a god game by Abbey Games in which players take control of nature through the hands of mighty giants. The players will posses imaginable powers over nature! But there is only one thing that they won't be able to control: mankind, with all their virtues and all their vices. Players can shape mankind's world, but not their will. It is the player's responsibility to maintain a balance in which man is not overpowered by nature, and nature does not fall under man's greed. 

Reus will launch, through Steam, on May 16, 2013. Some of the game features include:

     - Unique god game gameplay with several ancient giants at players' command
     - An interesting 2D art style form a perspective rarely found in god games.
     - Dynamic and immersive audio effects.
     - A powerful soundtrack that fits the theme.
     - Intricate gameplay, where humanity depends on player's power while challenging it at the same time.
     - Players' have full control of humanities fate.

Go visity the Reus' Website for more information about the game. Go spread the word to your friends. Hope everyone is interested to try out this game. Cheers!

NightBear

NIGHTBEAR PROJECT

     In the following post I'm going to share an interesting game that I created along with a group of talented students from Full Sail University, during the Global Game Jam 2013 (January 25-27, 2013). In this famous activity we had a total of 48 hours to design and create a game that uses "heartbeat" as a theme element.  During that time we came up with a 2D side-scrolling free runner game, using Unity 4 as our game engine. Although I'm listed as a programmer, my main role in this team was of a Technical Director/Producer. I was responsible of managing the responsibilities of the programming team; that is, making sure that all programmers were organized, facilitating the communication between the artists and the programmers, making sure that all programmers were working on their specific tasks, and help the programmers on the problem solving aspects of creating and implementing code in the game.    

     In "NightBear" you take the role of a Teddy Bear that is locked in the nightmare of his owner, Theo. You find yourself traversing through a deadly environment in order to somehow end this never ending nightmare. As the player, you will affect the heartbeat of Theo, which will increase/decrease the speed you run at. Player can also affect the heartbeat to perform other actions such as jumping. The level never ends, so players will be scored based on how long they can survive this nightmare. 

Gameplay Pictures:

Click here to play NightBear!

NightBear's Global Game Jam 2013 Website

Fire Fight

Fire Fight Project

     In the following post I'm going to share another interesting video game that I created along with my peers, Team Lazer Blazer, who are also taking the Masters Degree of Game Design, at Full Sail University. Different to "Knock Block" and "The Nightmare Before Game Jam", this particular game project was developed during the months of November to December of 2012 in order to accomplish certain homework' requirements from two particular courses of my Masters degree. During the month of November, our team designed and pitched the idea of creating an entertaining top-down action firefight game. After a hard work of pre-production, the team entered on production during the month of December in order to create a vertical slice of the game. Our game was built on Unity 4 engine. My primary role in the creation of this game was on programming. Specifically, I was responsible of implementing the music, sound effects, some of the game mechanics, the HUD, and the whole front-end of the game.  

     In this particular vertical slice game, players take the role of a rogue firefighter named Dirk, who is asked by his previous firefight department chief to help out on turning off the fires and rescuing the people from a local resident, since the whole firefight team is busy attending other fire emergencies that have been caused by a serial arson. The main goal of this game is to put out the fire in the building and save the residents. On the stage, players will encounter a burning building with flame rising up in each room. The players will need to put out the fire and find a way to progress to the next room. In the process of turning the fires off, the players will have to look for the residents of the building and interact with them in order to lead them out of the building. The game ends when players manage to turn off all the fires of the building and rescues at least one resident from the building. 

Click here to watch Gameplay Video!

The Nightmare Before Game Jam

The Nightmare Before Game Jam Project

     Hello everyone! In the following post I'm going to share a game that I created along with my peers that are also taking the Masters Degree of Game Design, at Full Sail University. Similar to "Knock Block" the game was created in less than 24 hours during a Game Jam session that was held at Full Sail University, on November 17, 2012. During that time we created a simple side-scrolling video game, using the Multimedia Fusion 2 software. In this particular game, I was responsible of programming all the main features as well as testing the game in order to make sure that it was quality assured. Since the game was well received by the majority of the other peers that participated in the Game Jam session, it manage to win the "Most Polished Game" award in the activity.  

     In the game, the player takes the role of a boy that falls asleep, while preparing himself for the next Game Jam. When he enters the dreamworld, his worst fears that he had as a kid start to appear and chase him around in order to eat him. Basically, the objective of the game is to simply survive each nightmare for a total of 30 seconds. Although players may think 30 seconds is enough to survive the nightmare, the nightmare will never be the same because every time the player fails to survive it, the platform of the nightmare changes completely. Therefore, since the player don't have control of the outcomes of the nightmare  players must improvise on how to run away effectively without falling from the platforms or being eaten by their worst fear.

Pictures of the Game:

Sleep overtakes you. Your own drawings begin to haunt you.

Everybody loves a clown...

You meet a hobo... he doesn't seem friendly.

You can't believe they bread raptors...

Your vision of the future are eerily accurate...

Click here to download and play the game!

Game Production Club: Game Jam Website

Knock Block

Knock Block Project

     In the following post I'm going to share a report that I had to make for one of my graduate classes that I took on Full Sail University. Basically the report talks about the modifications that I made to the first game project that I have participated along with a group of talented people that are also preparing themselves for the game industry. Some of the main Highlights of the game are the following:

- The game was created on a Click Jam session that was held on August 18, 2012, at Full Sail University.
- It was created using the Multimedia Fusion 2 software.
- My primary role on the project was Lead Producer/Designer, but I also help on some programming issues of the game.

Click here to download and play the game!

Now for more details about my experience of creating this game, I share with you the following report:

Introduction

     On August 18, 2012, our team Turtle Attack Interactive participated on the Click Jam session at Full Sail University. The team consisted of a total of seven members, four master students and three bachelor students. In less than 24 hours, the team created a strategic maze-based video game called Knock Block. Turtle Attack Interactive manage to implement before the Click Jam’s deadline the art work, the sound effects, the music, and the game mechanics. Despite the efforts, the game still had a lot of tune up in order to become a challenging, yet fun and complete game. For my individual project, I proposed to add the final pieces that Knock Block needed in order for it to become a complete game. In the following report, I will demonstrate the game’s progress, the final product and the reason why it was important for me to complete this game.

Knock Block: Game play objective and basic design

     Knock Block is a strategic maze-based video game developed by Turtle Attack Interactive team, on August 18, 2012, during the Click Jam session at Full Sail University. In the game, the player takes the role of a kindergarten kid called Bully which entertains himself by knocking the block structures of his fellow kindergarten peers. The purpose of the game is to knock a certain number of blocks before time runs out.

     The player must run over the block structures of the kindergarten kids in order to receive block points. While the player runs around the stage in order to knock the block structures, the kindergarten kids start building with blocks a tall tower of blocks. Depending on how tall the block structure is, the player will receive a certain amount of block points once is knocked down; in other words, the taller the block tower is the more block points the player receives. Consequently, the player must carefully plan his/her route in order to knock higher block structures before time runs out.

As the player progresses through the game, the player is exposed to more difficult mazes. The difficulty of the mazes is based on four main elements:

1. Mountain books: These are one of the obstacles that limit the player to move freely around the maze. In the first levels of the game, they act as walls that impede the player from being able to knock the blocks structures easily. But as the player progresses in the game, the mountain books tend to define the layout of the maze.
2. Teachers: They are the other obstacle that limits the player from moving around easily on the maze. Basically, the teacher impedes the player from being able to reach the number of block points needed in order to complete the maze. Every time the player collisions with the teacher, the player looses a total of five block points. The player has to carefully plan his/her route in order to knock certain number of blocks without having any contact with the teachers. In the first levels, there is only the presence of one or two teachers, but as the player progresses through the game the number of teachers increases from three to five.
3. Knock block objective: It establishes the number of blocks that need to be knock down in order to complete the maze. The number increases (60, 90, 120) as the player progresses through the mazes.
4. Time: The player has only a limited time to complete the knock block objective. In the final version of the game, with the exception of the last level, the player has only one minute to complete the knock block objective. In the last level, the player has only forty seconds.

The missing features and fixes of the game

On the Click Jam session, Turtle Attack Interactive manage to implement the basic elements that Knock Block needed in order for it to become a functional game. Unfortunately, the game was not completed because of the lack of certain features and fixes:

1. The game had some serious programming bug issues on the interaction of certain objects.
2. The game had no pause options; therefore, the player could not pause/continue, exit to the main title screen, or exit the game.
3. The game had neither maze levels nor winning/loosing transitions between levels.
4. The Option Screen’s art work design was not completed, plus settings were not working correctly.

These features should be added to the game so that it can at least be a complete game.

Progress of the added features and fixes

Bug issues on the interaction of certain objects

     One of my main concerns about the game was the interaction between Bully and the mountain of books. During the testing phase of the designed mazes I noticed that Bully seemed to walkthrough inside some of the mountain books. It was an odd situation because I noticed that in the first level maze that weird interaction between Bully and the mountain books was not happening at all; therefore, I knew that the problem could not be the code. After awhile, I noticed that the cause of that minor bug was the order of the insertion of objects on the maze. Since the creation of the mazes was based on the source code and display elements from the first maze, adding the additional mountain books cause them to have a higher hierarchy of display than the main character. Because of that hierarchy when there was a close contact between these two objects the mountain books displayed on top of Bully when it should have been the other way around. I managed to fix this problem by simply re-inserting Bully for each completed maze.

Pause Options: Keyboard based

     I decided that it was best to add some keyboard based options in the game rather than to create an additional scene that will represent the pause options. The first reason in which I stood by this decision was because I didn’t want to mess around too much with the code that was done by my teammates, especially when I was not the main programmer of my team (my main role in the team was being a producer/designer). During the process of adding the features that were missing, I accidently messed up the code that was done by my peers, which cause certain implemented features to stop working properly. This caused me to restart my work of adding the missing features a couple of times. The second reason why I stood by this decision was because it was a lot easier to implement in the game. Creating and implementing an option scene in the game was going to make the programming functions of the game scenes more complex; that is, adding more conditions between scenes. And since I was not clear on how to implement it correctly, I decided not to take any chances. In the end, I based my decision in order to avoid wasting time and messing to much with my teammate’s code.

     In order to let the player know how to pause/continue the game, return to the title screen, or completely exit the game, I created a Controls/Instructions screen so that it could appear before the player starts playing the game. In this screen the player will not only be informed of the mentioned features, but also will know which are the controls and the main objectives of the game.

Maze level designs and winning/loosing transitions between levels

     The main features that the game was missing were the maze levels and the winning/loosing transitions between levels. These were the main key elements that needed to be present so that Knock Block could be considered a complete game. For the Click Jam session, I only had the chance to create one complete level before the deadline. The advantage of completing this level was that our team managed to fix all the bugs and errors that were present in the code and art display before the presentation. Therefore, the first maze level became my template in order to create more maze levels for the game.
     For my individual project, I designed a total of seven maze levels for the game. I used as reference the theoretical bases of the Defensible Space theory in order to assure that the game had the elements of challenge and fun; that is, making sure that the game was neither to easy nor too hard to play and that players had fun while playing the game. What also helped me make sure that these elements were present in the game was the number of usability testing that I implemented. Not only did I test the game, but also I asked a couple of my peers and friends to participate in a brief think aloud sessions. I enjoyed working on these implemented sessions because not only did it confirm to me that the game had both the fun and challenge elements, but also it helped me figure out some bugs and errors that were still present in the game.

     Unfortunately, for the Click Jam session my team did not have the time to create the transitional scenes after either winning or failing a certain maze. Thus, it became my responsibility to create and add that feature in order to assure that the player was informed of their game play progress. They way on how I worked with the art of these scenes were by compiling the floor scenery that my artists’ team members used for the game play with two modified expressions of Bully. Once the scenes were completed, I added the necessary programming conditions so that these two scenes could appear based on the game play of the player.

The Option Screen

     The Option Screen was one of the only features that I could not fix completely. Back in the Click Jam session, my team didn’t have the time to add the art work design and the settings functionality. So for my individual project I intended to add those missing features. For the art work design I used the floor scenery of the maze, the kindergarten kids, and the block structures that were created by my artists’ team members for the game play. Similar to the winning/loosing scenes, I compiled these three objects in order to create an artistic Option Screen suited for the game. Once the art work was completed, I fixed some minor bugs in the programming related to the selection of the Master Volume and Back options. Unfortunately the only thing that I haven’t been able to put to work correctly is the Master Volume properties. Although the cursor can be moved to either the max or min sides of the Master Volume, the sound does neither increase nor lower its volume.

Importance of completing Knock Block

     Knock Block is one of the first games that I ever completed along with a group of talented people that are preparing themselves for the Game Industry life. Completing this product is one of the few projects that I could add up to my resume and future website in order to demonstrate to the Industry my different skill sets that I have developed during both Bachelors and Master program.

     Working on Knock Block clearly points out various skills sets that I have implemented in the game development process. First of all, it demonstrates my producer’s skills. During the Click Jam session my main role in the game development process was to manage the workload of my teammates, help with the communication between the different departments (art, programming, music, and design) and supervise the work done by my teammates in order to assure that the game had all the design requirements. Second, it demonstrates my game design abilities. Most of the design concepts in terms of the game’s theme, objectives, controls, and level design were ideas that were developed by my two producer team members and me.

     Third, it demonstrates my quality assurance abilities. During my Individual Project process I developed various think aloud sessions with my peers and friends in order to assure that Knock Block’s game play and features were working properly. Finally, it demonstrates my programming and art skills. Even though I was neither the main programmer nor artist in my team during the Click Jam session, in order to add the missing features and fixes of the game for my Individual Project, I needed to rely on these two skills. So in the end, I worked on various bugs and errors that had the game in its programming and created some additional art work for certain incomplete and missing scenes.

     Although Knock Block is not a large scale project, it still displays several of my skill sets during critical moments of the game development process. Because of that, it is important for me to add this game in my resume and future website as one of my personal projects during my academic life. That way I will assure that my skills are well presented, especially when applying for any work related to the Game Industry.