For the last month I have been trying to get the basic game mechanics up and running along with creating some interesting content for the game mechanics to take place in. Along the way I have learned quite a lot about the light mapping processes in Unity, using GUI frameworks such as the Daikon Forge GUI and have picked up a few solutions from the app store to assist with the development where I think it makes sense. As usual for the first few months, a lot of time is spent wandering around the new tools and toys and make sure they are used properly. There is no escaping this unless you just want to mash things together as quickly as possible just so that you can say that you created a game. I want to create a game I think would be interesting, different, challenging and fun to play. As far as assisting with the project development, I am looking into options of grants and other similar ways of funding. I am going to try and create some content for the Unity Asset store to sample the possibilities that are represented there as well.
I will need to create a corporate shell around me and what I intend to create. The legalities and procedures all need to be in place along with a very serious plan on how to actually distribute and sell the end product. Well, you will not get anyone to pay attention to you if you don’t really have anything but promises and vague ideas when you ask for their attention. If you have on the other hand something playable and impressive as you approach them, they will take you a lot more seriously and a lot more doors will open. Meaning, that you should have something to sell before you create the framework to sell it.
When I initially dove into this, what I had in mind was just to create something that I would manage to do within a certain time and withing a certain budget. I want to be in complete control of what I am doing. But as I look at the funding options and what might be possible, I see bigger and better things.
In a couple of weeks time, I will start to manage a developer log on a few indie developer forums to try and spark some interest along with looking at all the options I have for gathering some funds.
That should be interesting.
As I piece together more and more of the game mechanics, I start seeing downsides of the current camera controlling scheme. But those are just interaction details to make the utilities you hand to the players as easy to manage and control as possible, but still adhere to a certain theme.
A lot of this project is growing organically but I have come to a fairly solid grounding of what base set of mechanics I want and how to design around that. In essence, the game is not about robots. It is about programming and solving programming problems along with some other science related problems. You can control robots and various other machines that you enter. But you are not confined to a single machine.
Here is a small description of what I hope the game will be.
You are without a permanent body and can travel between digital hosts. This employs a base theme setting where a digital representation of a human psyche is wandering around in the connected machine, jumping between machines to solve puzzles by programming them and organizing them.
Restrictions come in the form that you are limited to the base set of utilities the current machine you are occupying gives you and the surroundings that you are in. Some machines have better access, better tools and can do things others can’t. Some can lift heavy objects and some can fly.
Other mechanics of interest is a time machine where you can send data back and forth through time. In short, there are no save games to speak of, there is a time line and a history. Your sentient program just grows in size and collects data. This timeline and history will be represented in the main screen.
When you first load up the game, it will tell you that you have x minutes to solve a problem. It is not possible for you to solve it at the beginning and you will fail. But you are armed with a time machine that will eventually allow you to solve this problem within the time allotted. Most of the game is played after you screwed up the main problem, but you need to progress and collect data and solutions to be able to go back in time and solve the main problem within the x minutes. Plus, maybe add some time related paradoxes to make your brain hurt.
One of the few UI elements you will see on screen is a timer. This timer just gives you the fictional time plus it holds indicators for other snapshots in time that you had taken as a warning that they are about to get overwritten.
But, as I mentioned before, this is all growing/shrinking organically. I like playing with avenues I don’t really see in computer games and trying something new.
Work is not getting any less in terms of the amount of hours I need to put in to this, and frankly, I don’t expect it to for the remainder of this project. I did run into issues with using Maya LT since it has so many things missing that otherwise come for free in packages such as Modo. This transition will create a few day offset for me to catch up and learn to use all the replacement tools for the solutions I had in Maya. But I am focusing on getting the base mechanics and software to behave as it needs to.
As for all the persistence data, I picked up a utility from the asset store to solve that for me so that I can persist some object state and various other data between runs of the application or loading new scenes.
There are still 8 days left of this month and I am still aiming for having something playable by the end of that time. Demo these mechanics and maybe allow some poor souls to break it all.
This will continue again tomorrow.
V 