AEONPHYXIUS

“Fight across two battlefields at once in the comic book-styled Shoot’em Up that mixes puzzles and combat with dimensional teleportation! – PC/ Mac / Linux and consoles”

(continue reading…)

The original idea of this game was to develop a cross-platform game (Android and Iphone / Ipad). The idea was to develop a multi-player game about piloting a hot air balloon. As you can see in the first video (link below), I prepared a basic level for single player as a demo, with no much care about graphic design.

With that demo, I had competed at  Ultramagic International Innovation Awards, being selected over 200 projects to be finalist. Finally we did not win the prize :(, but this highly encourage us to continue with this project. (continue reading…)

<—— Using Command pattern to handle input in Unity and C# Part I

In my previous post, I was just introducing how to apply the Command design pattern to handle our game’s input (in Unity and C#). At the end of part I we came up with a simple solution to handle it, but we were still missing a “way” to adapt our code to different game scenarios (menus, in-game, … ). For example in the code I wrote there, we were assigning the A button to the fire action. But what if we are in the main menu and we just want to assign this button to accept instead of Fire? In this second part, I will try to adapt the code we developed before in order to support different game scenarios.

Let’s then first modify the base class in order to “store” the method we are supposed to call. Yes, you probably wonder by now that I am referring to C# delegates / actions. Our Command base class now will include a new Action var:

    public abstract class Command
    {
        protected Action command;

        public Command(Action _command)
        {
            command = _command;
        }

        public abstract void Execute();
    }

Once we have modified our base class, we will have to create only 1 instance or unique type of controller (or create a few different implementations, but for this example with 1 is enough). So, lets include some logic in our InputAction class to call the Action or Delegate its supposed to:

    public class InputAction : CommandBase
    {
        public InputAction(Action _command) : base(_command)
        {
        }

        public override void Execute()
        {            
            if (command != null)
            {
                command();
            }
            else
            {
                throw new NoMethodToExecute();
            }
        }
    }

As you can see in the code above, I am checking that the command variable (C# Action) is not null. This is a safety check that can be avoided to save improve performance, but of course we will need to be 100% sure it is always with a value (to avoid our game just crashing or having strange behaviours). One solution here could be to use the NullObject pattern (but this will come in some separate post). Also you can see that I am throwing a NoMethodToExecute exception. This is just a custom exception I made to handle when our command is null (source code in the github link I posted below).  So now we can create a lot of different InputActions just changing the method those ones will be calling when they will have to be executed. Let’s now modify our InputManger class to support this new functionality:

public class InputManager
{
	private Dictionary commandList;

	public InputManager()
	{            
		commandList = new Dictionary<string , InputAction>(();
	}

	public void AddControl(string _cmdName, Action _cmd)
	{
		if (commandList.ContainsKey(_cmdName))
		{
			commandList[_cmdName] = new InputAction(_cmd);
		}
		else
		{
			commandList.Add(_cmdName, new InputAction(_cmd));
		}
	}

	public void ResetControls()
	{
		commandList.Clear();
	}


	public void ExectueCmd(string _cmdName)
	{
		if (commandList.ContainsKey(_cmdName))
		{
			commandList[_cmdName].Execute();
		}
		else
		{
			throw new NoCommandToExecute();
		}

	}
}

As you can see above I am using a Dictionary (with a string as a key) to store all our events. This is not the most efficient way to store them, but for this example will do :). Basically I just create a new InputAction for all the Input we would like to handle. For example, following the 2 events we worked with in Part I (Jump and Fire) we will add them into our newly created InputManager as follows:

commandList.Add("jump", new InputAction( OnJump ));
commandList.Add("fire", new InputAction( OnFire ));

In the code above, “OnJump” and “OnFire” are the functions or methods that will handle the jump and fire logic (usually in some kind of player control).

And that’s all. With this simple implementation we will handle our game’s input using the command pattern. I will be writing part III sometime in the future as we will need an “Undo” operation in Dimension Drive. This type of operation is easily implemented with the Command pattern as well. It is also really good to save all the commands your game is handling so you can “easily” implement a “replay” or ghost mode. But let’s not spoil all the fun as probably that will have a big impact in Dimension Drive (the game I am working on right now). If you want to access the source code of this post so far (including a Unity example on how to use it), please see in my github public repository here.

Definitely Command is one of my favorites patterns. It is present in most of my games code-base. When used in the right place will help you to achieve encapsulation of your Input -> Action code.  Let’s see first how the “Gang of four” define this pattern:

Encapsulate a request as an object, thereby letting users parametrize clients with different requests, queue or log requests, and support undoable operations.

As you can see that definition is just … obscure? (I can’t find the right words for it). Well for all non-native English speakers (as myself) I would find that sentence a bit difficult to understand at first. “Encapsulate a request as an object” we all can agree that is referring to and object oriented encapsulation of callbacks (or at least kind of). With “Letting users parametrize clients with different request” we can assume that is referring to the ability to use the objects mentioned before to perform different actions. Then finally the rest is just a list of things you can do with this pattern.

Let’s now get down to business. In all games, or at least 99,9999% of them, there is a place where the code reads the user input (game pad, keyboard, touch screen, …). Once this input is received, translates this information into a game action, for our example let’s say jump and fire:

(continue reading…)

As some of you might know our first Kickstarter was “trolled” in the last hours. I will not write here much more about what happened, as a lot have already been said (Kotaku, Destructoid, Eurogamer, Polygon). Thanks to your support, we stand up and came back for more. This second time around there was no “more bumpy roads”, and we got funded !!!! If you want to know more about our second Kickstarter, you can find the project here.

I will never be grateful enough for all the support we received during those days. Really, it was all of you who help me / us to stand up again after what happened. Even now that few months has passed, I remember those days as probably the worst experience I ever had (gamedev related).

In other news I am working lately in some core features for Dimension Drive (I/O, audio, Steam integration, …). Sometimes I feel that the to-do list only grow and grow and grow 🙂 . If you want to download the latest public alpha (the newest versions are only available for backers and early access users) you can download it from here. If you want to follow how the development is going, you can check it our in our devlog.

Last, (but not least important) I am just writing some post about different topics (implementing game Input with Command pattern, some Unity – C# audio tricks, …).

Not much for now, if you have any question… just reply in the comments below (or use the contact form).

Hey folks !!!!

Sorry for being a bit absent for the last few months. At 2Awesome Studio we have been working like crazy to launch our crowd-funding campaign at Kickstarter. Finally last Tuesday we went live with our campaign and now crazy mode is ON. Crunch time every day, working from 8 AM till … 2-3AM again .. is exhausting but totally worth it 🙂

(continue reading…)

I have finally published UltraMagic Balloons Target in Google Play and the App Store. I have got the green light from UltraMagic at the beginning of June to go ahead to publish it. You can now download it for free in your Android & Apple devices using the links below. I will probably still add some new levels ( from 21 to 40 ) and  new features in the future. It has been a long way till I reached this stable version, but all the sleep-less nights, long week ends working on it now seem long gone while publishing it ( so proud of it ).

Just let me know if you like it and any other comments you might have 🙂 (any feedback will be more than welcome).

Download on Google Play

Download on App Store

I haven’t update the web for a while. I know… too much work is not excuse enough so here I am again, back on businesses. Developing 3 games on my spare time, working a full time job at the European Space Agency, and training for an Iron Man race is not easy. My days only have 24h … unfortunately. On top of all the development and training, a lot has happened lately, I attend 2 Indie Game Development conferences here in The Netherlands with my friend and now partner @Stilghar. Let me then summarize all news a bit in order, Ultramagic Balloons Target my first Android Game, then the 2 conferences we have attended, and a bit our future at 2Awesome. (continue reading…)