Project – Pins

Pins is a hyper causal game I made awhile ago. It revolves around trying to get all your pins stuck into a circling object above. The challenge comes in getting all the pins to stick, with out touching any of the other pins.

Here it is on both the iTunes and Google Play Store:

Here is a link to the Github repo: https://github.com/RedGhoul/Pins

Here are a few of the screen shoots:

 

Using Unreal Again

After taking a long hiatus from Unreal 4, cause I didn’t like blue prints (Unreal 4’s Visual Scripting Language) I preferred real programming (C++) . At which point there started to be a nice long 3 second compile time 😦

I switched to Blue Prints ! I bought my self a course and started going at it every day after work ( well … almost every day … West World doesn’t watch it’s self )  I made the final project in the course, plus some of my own additions (these additions mainly making the game look AAA, and adding UI) .

So this post is dedicated to saying “Hey look I made this cool thing 🙂 ! ” mostly by my self.

Its you basic point and click ARPG that only has one level, and uses alot of the Infinity Blade assets that Epic has given away for free. Here are some screen shots:

 

UPDATE: 2018-08-18:

I plan on adding a better AI to the game using Unreal’s Behavior Tree

Override, Virtual, and Super in C++

When you inherit from a class you have full access to it’s variables and methods. However what do you do when you would like to use one its methods, and then add to it ? Well you would try to override the method with your definition. This can be accomplished using the “Virtual” keyword on the function you want to override on the parent class. And then using the “Override” keyword on the function in the child class. After which you would then use the “Super” keyword to call the implementation of method found in the parent class.

A real world application of this is, when you want to override and add to the “BeginPlay” method.

Override_Super_virtual

Here we see that the TankPlayerController inherits from the APlayerController that inherits from the Actor class. The Actor class holds the initial implementation of the “BeginPlay” method.

 

Unreal 4 VS Unity

Over the last decade Unity has become the game engine of choose for a good chuck of game developer out there. This is due to many factors, the main factor being that it was designed as a product first. Whereas a number of other engines where brought into existence to make a game. In my opinion this is the key difference between the two engines.

Unreal was originally developed to facilitate the creation of one the most beloved FPS of all time “Unreal Tournament”. Unreal Tournament was designed to be a fast paced shooter, with high graphical fidelity and high performance networking. These things are the key features of the Unreal engine, which is why the engine has the cons and pros that it does.

In Unity’s case it was designed to be nothing but a game engine that would not limit game developers in what they could do, and eliminate the many bottle necks in the game development life cycle. It is simply a product built to make any game, not a particular game.

The differences between the two are seen in the usability of either one the engines. This is most prevalent in the languages that they use. Unity uses C# (aka Microsoft’s Java) whereas Unreal uses C++. For beginners and even intermediate programmers writing effective C++ code it very difficult. Since there is no memory abstraction layer and the syntax is not as initiative to understand. Another point of difference can also be see in the minimum computer specifications needed to effectively use the engines. Unity for the most part does not require much, it could probably run on a potato. Whereas Unreal requires a quad core (i7 preferably), 8GB of Ram (preferably more), and good video card (preferably anything greater then a GTX1060) .

The differences highlighted above also explain where the two engines are usually used. After a while Epic Games started to licences out their engine. The licences were very expensive so naturally the only people that bought it were other game studios, who then made AAA games. Unity on the other hand had a free tier and inexpensive (comparatively speaking)  which lead a lot of indie developers to adopt Unity. Indie developers are usually tiny teams working on shoe string budgets. And they are usually content with their profits if it is just enough to make another game.

The biggest difference has to be the community of either game engine. Unity has one the largest and helpful communities out there. There are a ton of forums, blogs, books, and video tutorials out there on Unity. And then there is the asset store, a market place that allows developers to sell anything and everything one would need to make a game, wither it be art work, scripts, or even music the asset store has it all. The Unreal engine has something simpler however it is  not as robust as  the Unity asset store.

It is in my opinion that if you want to make video games you should use what make your feel comfortable. If your a experienced C++ developer looking to code games and have a few art friends to make high rez 3D models, and you want this to be a PC only game choose Unreal. If your a one man developer that has some coding experience choose Unity.

 

 

Understanding Unity – Part 2

The primary language of Unity is C#, but you can also use JS and Boo (python). Most of the tutorials and assets out there use C#. In my opinion C# is just like JAVA so if you know that you should be just fine. When you create a script in Unity it automatically inherits from the class MonoBehaviour. If you do not inherit from MonoBehaviour your class becomes a regular old C# class.

MonoBehaviours have a number of methods that you can implement, that are called over the life time of the object. All the way from when the object first gets created to when it is destroyed.

These different methods are executed in a different stages and these stages happen in a certain order. Going from “Initialization” -> “Game Logic” -> “Decommissioning”. I am not including a few of the stages here because they are not fundamental for getting started with unity.

Then the break down of the most important methods in each stage would be as follows:

  • Initialization:
    • Awake()
      • This function is called the second that an object is created. “Created” in these sense just means the second that game engine acknowledges its existence.
    • Start()
      • Similar to Awake() this function is called right before the first frame that is being rendered. You can think of it like just before it appears on screen.
  • GameLogic:
    • Update()
      • The Update function holds all your game logic, and gets executed every frame
  • Decommissioning:
    • OnDestroy()
      • The OnDestory function gets called just before a object is destroyed. This can come in handy, when you want to say update the score after killing an enemy.

There are also event triggered functions, such as OnCollisionEnter2D that get executed under specific situations. In the next post I will go over these functions, and the 2D physics system in Unity.

 

Understanding Unity – Part 1

Introduction:

Unity is one of the most popular and easily accessible game engines to date. Which has lead it to become of the best documented and beginner friendly games engines. It can be used to create both 2D and 3D games, and uses C# as it’s main scripting language. And the best part is that every part of it is completely free. Combined with its robust asset store and plethora of free online tutorials it is the game engine to learn these days.

How Unity Works:

To understand Unity, you need to first understand the differences between a library and a engine. A library is something to that you use to build your application, whereas a engine is something that only calls your code.

Unity is an engine, it is something that you have to understand and use in your pursuit to make a game. You do not get to decide on how the physics engine works or how the lighting effects work. You are just given a number of ways to use the sub systems that were created for you.

When you create anything in unity your making a object. Every object in unity has certain properties attached to it, like its position and scale. You can add other components to it like a particle emitter or sprite render. The way you start coding your game is by way of using scripts that you attach to the object like any other component. Once the script is attached you can then start manipulating the different attributes your game object has.

In the second part of this series I am going to talk about the life cycle of a unity object.