Returning to Projects

Returning to our home way back in September the projects were put on hold.  Reviewing the projects to reload the whole thing. 

Down Time

All work on the game is on hold for about a week.  Thanks

USAF Space Command Closed Beta

A game is of no use if you can't share it with others.  One of the most important parts of any software is getting eyes on it.  A fresh set of eyes can find errors and provide a different perspective.  Obviously if you select  too many people the perspectives and ideas can get uncontrollable.  There is no perfect outcome just the best you can do at your level of knowledge. 

However, all perspectives have value. To that end I will be inviting people from a variety of sources to participate in this first beta test.  The game is not in its final form and the ideas the testers provide may already touch on items that are known to be issues.  That doesn't matter. 

Critique is the most important thing you will provide and I expect it to be as detailed as you wish to be.  I thank you in advance.

Getting Ready for Closed Beta

A milestone has been reached.  The game now has a name and is now undergoing review for Closed Beta testing.  I will warn you...it still has plenty of work left....but it is closer. I will keep you updated.

A Quick Guide to Mazes

A maze is nothing more than an open loop.  To get out of any maze place your right hand, or in the case of a platform maze your feet, on one wall and never take it off as you move through the maze.  This is not the fastest way through a maze, but it will get you out.

In a game a maze will have obstacles that are intended to make you go a certain way.  This may or may not be a good thing for the player.  That is where they player has to make decisions based on what they have learned about you. 

Never assume.  A wall might be a wall, or it might actually be the only way out.  How you handle the puzzle is part of the fun.

What is a Game Engine and Why Use One?

My first exposure to actual programming began when I was about 10.  My father had bought me an electronics kit.  With it I was able to build an analog computer circuit known as a logic gate.  Without killing you with the highly technical uses of a logic gate, it was basically an on off switch that had rules. 

I continued to be fascinated with the logical way in which a computer program is able to use information.  That is not to say that the answers the logic provided was always correct, but the logic was always...logical. Logic is a huge misnomer. You can think of something logically and still get the wrong answer. I am getting into the weeds on this one, so I will just leave it there.  For now.

In the early 1980s I bought my first digital computer, the Commodore Vic 20.  By today's standard you probably have a wristwatch with more computing power. The Vic 20 opened the door to learning the importance of managing memory in order to create a useful program.  The Vic 20 was quickly followed by the Commodore 64, a Tandy (forgot which one), and a Packard Bell.  With each machine I began to learn Machine Language, how to use memory maps, Pascal, Visual Basic, C++, Java, HTML, JavaScript, and an entire host of other languages. 

Many of the things I would program in my spare time were simulations.  Things like a ball dropping and bouncing, or a ball flying through the air. This all required that I build an environment that took all of the properties of physics into account.  To do this required a great deal of programming which in turn made the process of building a game even more of a challenge.  I did manage to make a few game-like simulations, but nothing that was astounding.

Game Engines remove some of the tedious aspects of building an environment that seems realistic by providing a framework that includes the physics required for many game routines.  Game Engines also provide the framework for getting user input, translating that input into graphical output, and handling the many sub-routines that a programmer had to put together from scratch.  The question becomes, can you do what a Game Engine does from scratch?  Of course you can.  You can also build your own Operating System, but why?

There are many Game Engines on the market.  I have chosen Unity for two reasons.  Reason one...Until I make $100k with Unit, it is free....reason 2...see reason 1.

Art

Art for me is a real challenge.  This means that I will need to make use of art that others have done, as well as my own. Is this wrong?  No.  It is the same as if I hired someone to create the art. That is the key.  Any art that I use from others will have to follow the rules they specify for its use.  I'm good with that.  At the same time it allows me to work on the part of the artwork that I am good at.  Making the game as visually appealing as possible.  This post will focus on the Art work and the workflow that is involved.

Game art requires a great deal of work.  Games are not static so the artwork is not static.  As with all art it starts with a model.  Below is a model of "Ellen".  Ellen is the player character that comes with the 2D Game Kit, which is a free asset from Unity.  The idea was to make Ellen a United States Air Force Security Police/Forces Airman. 

To make Ellen into an SP was easy.  I just had to add a beret.  That sounds easy, it is not actually that easy.  I had to add the beret to over 100 different images of Ellen.  The goal when you have to do so many changes is to reduce the amount of work as possible.  To that end I was able to draw the beret on one model of Ellen.  Then paste it as a new layer on most of the still images that made up the model of Ellen.  I now present Erica.

Of course I couldn't leave that alone.  To make the player character mine, or at least mostly mine, I had to try to create my own "Ellen Like" character.  So here is Chuck.

Chuck needs work.  But he is a good model for future use.

Now for the question concerning copyright and the work of others.  Ellen is free.  Free from copyright, but I can not call Ellen mine.  Even if I were to plop a beret on her.  I'm good with that.  What I can call mine are some of the background art that I have added that are my creations.  Here are my additions.

The short of it...if it is a plant..I created it. 

Until next time....

Sound

Sound.

Just as we use visual clues to understand the world around us, sound is very important to establishing an immersive effect in games.  Since a game is about building tension and eventually releasing that tension from the user sound goes a long way toward that goal.  

This is an example of background music that may be used in the development of Project Erica.

Background Music Example

Project Erica

Project Erica

Project Erica is a new venture for me.  It is a 2D Platformer game built with the Unity Engine. At present the game has entered into the end stages of prototyping.  With that in mind I will track my progress, or lack thereof, here. 

Erica (The proposed Player Object)

Organization of this type of project is important.  Mainly due to the many parts involved.  For instance, I must consider the flow of the game, the rules, art, and code to make the game function.  In latter stages, there is the feedback from technical and non-technical users.  This will improve the overall usefulness of the program.  To that end this post will deal with the organization of the work flow.

Step 1

Create some fundamental rule sets.  These include those that affect coding and game play. For instance, Naming Conventions are important to know the difference between an Object called "PlayerIdle" and a variable called "playerIdle".  It may seem silly, but as your code becomes more complex this difference matters.  Knowing at a glance that your code is referencing "PlayerIdle" lets you know that this is an object. It saves time and heartache.

Step 2

Create on paper the actual flow of the game.  Before you write a single line of code, or draw a single character you must define the game environment.  Storyboards, or just plain text can help you define what you will need further down the line. It allows you the opportunity to work out the major flaws in the overall logic of the game.

Step 3

Do you start with the art, or start with the code?  Since this is a game, the art is what a user sees.  From the games perspective, the art is important, but so is the code that allows the user to interact with the art. I personally begin with the pseudo code.  Placeholder art, the stage I am in now, will allow you to work out the overall mechanics of the game. Of course you will be tweaking it all throughout the process.

Step 4

This is where the rubber hits the road.  As your game mechanics are being tweaked you can start to add finished (or mostly finished) artwork.  There is a lot of testing, editing, and retesting during this part of the process.  This will include creating forms of the game that can be tested by others.  Choose wisely who you allow to help with testing.  Accept all ideas you receive. 

Step 5

Finalizing the project can be the hardest part.  If, like me, you have come up with new ideas you will need to decide, can those new ideas wait until later?  Upgrades and modifications to a game are to be expected, but too many become a pain for the user.  Continual testing is a requirement.

Summary

That's it for now....more to follow.