When working in Unity, I found it useful to do as much as possible within C# scripts.
Having more experience with similar languages, I was more comfortable with that style.
Rather than worry about creating GameObjects and attaching MonoBehaviours to them, I could create simple objects and do as I wished.
Difficulties arose when trying to debug features. Objects created internally through scripts are not visible in Unity's editor. The only way to get information about them was to print to the debug log, which quickly became tedious.
For this reason, I converted several of my C# objects into MonoBehaviours. When the script would create an object of that type, it would instead create a GameObject and attach a MonoBehaviour to it.
Nothing is done with GameObjects, the script retains a reference to the MonoBehaviour. This allows the script to function normally, and for the object to appear in the editor at run-time.
The downside is that MonoBehaviours cannot have constructors. A MonoBehaviour is created by attaching it to a GameObject instead of being created through a constructor. This means that they are not completely initialized upon creation, and will need a separate initialization method.
Using GameObjects also allows the properties of the MonoBehaviour objects to be exposed in the editor. These can be changed at run-time. A practice I've adopted is to rename any property that I want to be visible in the editor with an "editor_" prefix to show that while it is public, other classes should not access it.
Sunday, 12 July 2015
Friday, 26 June 2015
Romanticism and What it Means for our Story
More of This |
In practice this means as few technical conversations as possible and if they're necessary they ought to be dealt with quickly and efficiently so as not to get in the way of characters and plot. It also means that there ought to be far more conversations about how the characters feel and why they feel that way with the hope of the player empathizing with and caring about what characters have to say and their role in the story.
Less of This |
Monday, 1 June 2015
Finding Distance on a Hexagon Grid
One problem we have to solve when we're working hex grids is to calculate the distance between two hexes.
On a square grid, there are a few ways of doing this. The most accurate method would be to apply Pythagoras' theorem to find the length of the diagonal between two squares.
But this leads to really messy numbers, so most games opt for something simpler. I've seen some where moving diagonal is simply not allowed. Others count diagonal distances as either one or two units, alternating.
On a square grid, there are a few ways of doing this. The most accurate method would be to apply Pythagoras' theorem to find the length of the diagonal between two squares.
But this leads to really messy numbers, so most games opt for something simpler. I've seen some where moving diagonal is simply not allowed. Others count diagonal distances as either one or two units, alternating.
Thursday, 7 May 2015
Intersecting Paths on a Hexagon Grid
In an earlier post, I discussed a co-ordinate system for a hexagon grid.
In this post, I will discuss a problem I worked on recently concerning such a system.
Essence of Glory is a game of formations and positioning. One way this manifests is in the system for close Assaults. These do not necessarily refer to hand to hand combat (although boarding parties are one possibility), but "close" engagements. Sort of how two airplanes coming within a mile of each other is a near miss.
The system we are using for Assault stipulates that an Assault occurs between two opposing wings of ships if they pass through each other during the Movement phase.
The question is, how do we determine when ships pass through each other?
There are two options, really. Either track ships as they move and report any collisions, or do some calculations based on their paths.
The first option isn't really useful, because we want Assaults to occur any time ships' paths cross.
We don't necessarily care if they are in the same space at the same time.
So we are better off looking at the movement paths as a whole. Remember the grid system?
A vector can describe either a position, or a change in position.
[2,0] may be the position to spaces to the right on the horizontal axis, or it may represent a movement of two units in that direction.
It would be possible to describe the movement of a unit with one vector, but it wouldn't be as useful. For example, a ship starting at [0,0] might move to [-2, 1], but did it pass through [-1, 0] or [-1,1]?
If we described that movement using only the vector [-2, 1], we would have no way of knowing.
Instead, we can store the movement of a ship with a series of unit vectors. Unit vectors are those with length one. Note that in hex co-ordinates, [-1, 1] is a unit vector, but [1,1] is not.
So, a ship starting at [0,0] and moving to [-2, 1] could have its movement described with the sequence of unit vectors {[-1,0], [-1, 1]} or with {[-1,1], [-1,0]}.
To find all the hexes through which a ship passed during the course of its movement, just add each of the unit vectors in its path to its starting position in turn.
Then, to find which ships will assault each other, find all hexes that all ships passed through during the movement phase, and then find those that are shared between opposing ships.
In this post, I will discuss a problem I worked on recently concerning such a system.
Essence of Glory is a game of formations and positioning. One way this manifests is in the system for close Assaults. These do not necessarily refer to hand to hand combat (although boarding parties are one possibility), but "close" engagements. Sort of how two airplanes coming within a mile of each other is a near miss.
The system we are using for Assault stipulates that an Assault occurs between two opposing wings of ships if they pass through each other during the Movement phase.
The question is, how do we determine when ships pass through each other?
There are two options, really. Either track ships as they move and report any collisions, or do some calculations based on their paths.
The first option isn't really useful, because we want Assaults to occur any time ships' paths cross.
We don't necessarily care if they are in the same space at the same time.
So we are better off looking at the movement paths as a whole. Remember the grid system?
[2,0] may be the position to spaces to the right on the horizontal axis, or it may represent a movement of two units in that direction.
It would be possible to describe the movement of a unit with one vector, but it wouldn't be as useful. For example, a ship starting at [0,0] might move to [-2, 1], but did it pass through [-1, 0] or [-1,1]?
If we described that movement using only the vector [-2, 1], we would have no way of knowing.
Instead, we can store the movement of a ship with a series of unit vectors. Unit vectors are those with length one. Note that in hex co-ordinates, [-1, 1] is a unit vector, but [1,1] is not.
So, a ship starting at [0,0] and moving to [-2, 1] could have its movement described with the sequence of unit vectors {[-1,0], [-1, 1]} or with {[-1,1], [-1,0]}.
To find all the hexes through which a ship passed during the course of its movement, just add each of the unit vectors in its path to its starting position in turn.
Then, to find which ships will assault each other, find all hexes that all ships passed through during the movement phase, and then find those that are shared between opposing ships.
Monday, 27 April 2015
No Aliens Allowed: Why Only Humans in "Essence of Glory"
Yeah, what he said. |
Don't you want to see the version with Germans? |
Tangent aside, my point is similar narrative goals can be acheived by both human and alien actors in a story. The question is really one of tone, aliens have a tendency to sterilize a plot point whereas with humans it feels that much more visceral.
Thursday, 19 March 2015
Ease of Unity
This is my first project at really using Unity, and in the game development community there is a saying that you don't need to know coding that well to make a game using it. It seems that is actually the case... to a certain extent.
It seems that although you COULD technically use only the built in libraries for Unity, and how it handles cameras, assets, and rendering; to make a game using 100% code, it is entirely possible to use just assets, and use the settings provided with each asset with a few scripts here and there to glue things together.
One plus side of Unity is that the community is really big, and if you need a certain asset, what you're looking for will probably be in the store. Even if you need a certain functionality with it, you could potentially find that also. Making changes in the game to be event driven is also taken care of nicely in the engine itself, and is able to be set through simple dropdown boxes when you add it to a certain scene. Even if you do need to write code for certain events, the libraries handle a large component of the groundwork already.
So for anyone with cool ideas for games, or is even an aspiring game developer. Unity is a great engine to experiment with, even if you're not from a coding background.
It seems that although you COULD technically use only the built in libraries for Unity, and how it handles cameras, assets, and rendering; to make a game using 100% code, it is entirely possible to use just assets, and use the settings provided with each asset with a few scripts here and there to glue things together.
One plus side of Unity is that the community is really big, and if you need a certain asset, what you're looking for will probably be in the store. Even if you need a certain functionality with it, you could potentially find that also. Making changes in the game to be event driven is also taken care of nicely in the engine itself, and is able to be set through simple dropdown boxes when you add it to a certain scene. Even if you do need to write code for certain events, the libraries handle a large component of the groundwork already.
So for anyone with cool ideas for games, or is even an aspiring game developer. Unity is a great engine to experiment with, even if you're not from a coding background.
Wednesday, 18 March 2015
Unity 5 + Progress + Planning
Unity 5 was released recently, and so we decided to go ahead and move the project to that.
It seems to contain many updates to the high-end graphical and animation side of things, which this project may not touch, but there's not much reason to continue developing for an older version.
The conversion process was straightforward. All that was necessary was to open the project in the new editor, and the upgrade was automatic. It did take a surprisingly long time, and seemed to hang, but others have reported encountering this problem.
Anyways, I've been working on the rules side of the game. Essence of Glory is a table-top game for two players. It features dice, orders tokens, models, and a grid to play on. But there is also that portion of the game that exists only within the player's heads. They need to keep track of what turn it is, who has to play, and what they're doing at this juncture. And it is that non-physical side of the game that I have been tackling recently.
The game engine needs to know what turn it is, what phase it is, and what's happening, and it needs to present this information to the player in a convenient way. It also needs to account for the different ways of playing the game. Players may face off against the AI, or they may play with their friends over the internet, or around the table. I've been spending time thinking about how to handle all this, and started putting those ideas into action.
Since there aren't any illustrative screenshots to show off yet, maybe it might be fun to try to figure out my notes? Find them below the fold.
Subscribe to:
Posts (Atom)