GameObject or C# Objects?

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.

Romanticism and What it Means for our Story

More of This

I've mentioned romanticism before but never fully explained what I mean by that or how it will be used in the game. Romanticism, at its core, is about having emotion rather than setting dictate the tone and aesthetic. In most fiction the setting is the impetus for aesthetics and emotional feel of the work. Star trek, for example, is entirely dictated by the setting, star-fleet uniforms are as an element of the setting rather than what will be emotionally resonant. A uniform in our setting is meant to evoke a certain feeling about the characters and their roles in the story. This is not to say one form of story telling is better than the other, merely different. Star trek is about scientific what if's, our game is about political and character what if's. Tangent aside that's essentially what romanticism is about, letting emotion, tone, and for lack of a better term: flavour dictate the setting and characters rather than the reverse.

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

From a less technical stand point this means the players experience should be one of joining the characters on an adventure and feeling something about each event. I want players to feel swept up in this galaxy changing story of empires rising and falling, the ambiguity of good and bad in complex political systems, the moral questions surrounding warfare, the questions of honor and what it means to be a soldier. In Essence of Glory problems aren't solved with technology, problems are solved by people doing what they feel is right and then allowing the story to explore the effects on the world and people through emotion.

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.

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.

No Aliens Allowed: Why Only Humans in "Essence of Glory"

Yeah, what he said.

I think we really didn't want to include aliens because they simply wouldn't add anything. At the end of the day essence of glory is about politics and the people they affect particularly those on the front lines. In this case aliens can add some interesting things to a sci fi story, especially for characters. The point here is for aliens to present different perspectives to the human characters. Prominently in the Mass Effect series, alien races have vastly different goals and systems of morality to the protagonist and humanity. An effective narrative tool but in the end that's just it, a narrative tool to present the player with different perspectives on their actions.

Don't you want to see the version with Germans?

At the end of the day I'm aiming to achieve a similar goal but simply with other human nation states. In fact to me, using humans rather than alien analogues is much more effective because it's not as hard to sympathize or be horrified by their actions(Although there is some great sci fi about people trying to sympathize). In classic Sci fi, extraterrestrials were sometimes used as manifestations of real political fears and crises. For example The War of the Worlds by H.G Wells is an example of British "invasion literature" in which Britain fears invasion from some outside force. The Battle of Dorking by Sir George Tomkyns is a novel with a similar plot and structure with the difference being the martians in war of the worlds are replaced with Germans (minus the armoured war tripods and heat rays).

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.

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.

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.

Dreaming Man Update 7

I've come up with a new flowchart and decided that I'll add as I write more. I've also come up with a bunch of key turning points where the player has options that affect the outcome of the story (standard VN dialogue options).

This is written pretty bare-bones for simplicity, as Matt and I will be the ones mainly using it. It's going to be added to as more is written and decided.

One of the options:

Protag Dialogue Choice
Asuka?	Good morning.
??? – Asuka… Who’s that? Were you dreaming about someone, or are you still asleep? You must mean your wife, Amelia. [put her name in bold]	How’s breakfast coming along? .... Amelia – Almost done! Amelia – Breakfast is almost done!

To do: Actually rite moar

Dreaming Man Update 6

Not much to post about this week. I'm currently just in the process of writing dialogue.

I believe Matt is looking into the aforementioned functions from the last post.

Events in Unity

Events are a useful tool for communicating between game objects, especially when you don't know which objects will be communicating with each other.

Say we have a Button. When the user clicks on the button, we want another Thing to do task X. Maybe the code would look like this:

void OnClick(){
     Thing.doX();
}

All very well. But what if we decide that actually, there's going to be a whole bunch of different Things in this scene, and they should all do X? What if those Things need more information to do X? What if the set of Things that should perform the task X is constantly changing?

If any of that is true, that means we'll have to change our code for the Button in order to change what and how Things do X. And all the while the button hasn't changed. It's still there, doing its thing, getting clicked by the user. So why should we have to change the Button, if the responsibilities of other objects have changed?

The answer is that we don't, if we use Events.

Events are a really handy construct. They can be thought of as a one-to-many relationship, where one object publishes or broadcasts events and a set of others receive and act on them. Just like a radio broadcaster doesn't know how many people are tuned in at any given time, the Event broadcaster doesn't know what objects are subscribed or even if any of them are.

So our button code would be changed to look something like this:

//This defines a delegate which is a little like a function pointer.

//It defines the kind of function that is needed to handle the event.

//In this case, a void function that takes an object is needed

//to properly handle this event. 

public delegate void ClickEventHandler(Object sender);

//This goes inside the Button class, and defines a delegate member of the ClicEventHandler type for that button.
//This is the event that other classes will listen to.
public event ClickEventHandler clickEvent;

 void OnClick(){
     //Now, when the button is clicked, all of the delegates subscribed to the event will trigger
    clickEvent(this);
}

public class Thing{
    public void handleButtonClick(Object sender){
        doX();
    }
}


Now, we can change the behaviour of the Thing without changing the button at all.

In Essence of Glory, events are used to update parts of the game engine about changes in other parts of it. For example, when a ship is moved in the Model, an event is raised that is received by the View, which then updates where that ship is displayed on the screen. Events can also be used for special effects that trigger under certain conditions.

More information about Events in C# can be found here and in Unity here.

Dreaming Man Update 5

This week I wrote out outlines of what is happening in the first two dreams of the game, as well as some dialogue for the first dream.

I also came up with some concepts to shoot through Matt regarding the system of the game. I was thinking of an elementary inventory system, as well as some stuff regarding the implementation of the dialogue that I write up.

Inventory

The idea on the table is of a basic inventory system that modifies the chance of failure with options later in the game. This way this system would work is more similar to old RPGs or Point-and-Clicks, in that there are descriptions of each item (assuming no illustration), and they can only really be used situationally, either saving the player with an easy-out, or modifying percentage chances. This would just be a Boolean value associated with certain dialogues. E.g. Player can choose: Option 1, Option 2, and (if "Tent" is True) Option 3.

Dialogue 

Legend:
Thoughts	Either brackets, or italics (italics preferred)
Speaking	Person speaking’s name + colour
Narration	No name + plain uncoloured text
Sound Effects	Goes between asterisks *bang*

Assuming text is colour coded by character, in my opinion it would be nice to add a property to each ‘character’ which holds the colour of their text for purposes of easily distinguishable dialogue. And if this were the case, I feel it would be a nice touch to allow the player to pick the colour of the protagonist’s text, as well as his name.

Things to do: Dialogue for dream 1 and 2.

Higher Elevation

---Foreword---
Blue House Games is heavily involved in the local gaming community. More that just enjoying the participation, what we learn from our time with local digital and tabletop games clubs influences and inspires us. Due to this sentiment, we thought it would follow with the spirit of our blog that we shared the perspective of some of these organizations, and what we learned with them.


Who are we?
"We" are the Carleton Ravens, similar to another sports team, except we represent our school across North America competing in League of Legends. I'm Jungroan "Jezie" Lin. I used to play somewhat professionally, but have since allowed the game to take a backseat to my studies. This blog series does not serve the purpose about giving deep insight into the game itself, nor into the individuals on the team; much of that information is already easily accessible. Instead it will take one person's perspective on how a League of Legends team can hope to "elevate its game", from each stage of proficiency on to the next.

Preface
The team was built off of the "legacy" from the previous year; an early exit in the Collegiate Starleague (CSL) playoffs and not much promise as far as talent nor commitment goes. Going into the 2014-2015 year, I had taken a personal hiatus from the game after dedicated 30 hour weeks to it as a freshman in university and saw this as an opportunity to enjoy myself with the game some more alongside good company. After an incredibly poorly organized tryout process, our team was finally formed, mostly at the discretion of myself and my top lane player.

"Scraps"
That's what we were - not much different from grabbing a random collection of 5 players from the playground to form a team to compete in a fairly competitive collegiate league, most of the teams comprised of players with at the very least, familiarity with each other. We did hold the edge of having some professional experience, alongside a lot of untapped potential. That word "potential" is really a piece of garbage though. One of my basketball coaches in early high school preached to me "hard work beats talent when talent fails to work hard". I understood that we wouldn't necessarily have the level of hard work needed to be a top tier team, but hoped to circumvent this problem by employing my own macro mastery of the game alongside designating conservative roles for my teammates.

Acceleration
And, we elevated our game as a team as such. Players were taught a very elementary standard of macro play, directed to generally take the most conservative route as individuals and follow shot-calling down to the letter. In one of our earliest matches against York (IIRC), we employed a 4v1 top-lane strategy that I had learned from one of my scrimmages against team Dignitas way back when. We used a composition of Jinx, Warwick, Xin, and some other champs I can't quite remember with the purpose of destroying structures at a rapid rate. We were able to get to the inhibitor turret before 5 minutes had even passed on the clock. Using this global gold lead alongside funneled farm and kills to our ADC, we used this objective based composition to quickly end the game, moving together as one cohesive unit that honestly looked LCS ready. While matches to follow didn't always employ such a volatile strategy, our opponents (generally fully-diamond composed) struggled to keep pace with us once we transitioned into the midgame and were constantly lagging behind our rotations.

Stagnation
So imagine, you're a mid-tier team with a washed up pro player and some talent, barely getting a couple hours of practice on a good week. Naturally, you're going to hit a roadblock; ours happened to come by the name of McMaster. They had a talented midlaner and really no weak points across the board. While League of Legends may have started out being more comparable to basketball, it has slowly crept towards becoming more like hockey. What I mean by this is one player has a much lower capacity to single-handedly carry a game, and you are instead limited by the weakest link on the team. Every NHL player can handle the puck reasonably, skate fairly quickly, and is a threat to shoot. Sometimes in the NBA, a highly valued player (all-star level even) such as Rajon Rondo shoots 30% from the free throw line and can't hit a 3-pointer to save his life. For myself, I was extremely frustrated in the bottom lane, feeling that I was consistently better than the enemy ADC but being limited to playing a farming game with my partner.

Towards Excellence
We failed to qualify for the NACC through CSL, and looked towards our next tournament. Leading up to it I had personally duo queued over 30 games with our support but things weren't quite clicking. I understood that the meta had shifted from what it was half a year ago, when essentially games were decided by who had a slightly better mid laner; it had become a derivative of the team's collective skill and effort instead. We decided that we needed a change-up in the roster and decided to move forward with a different support. Our recruitment was on the basis of skill, and each player since has been individually putting forth time to hone one's own skills. The team is re-initiating its approach to the game. All of us are working to become better friends with one another first, then sharpening our own talents to bring to the table, where we will hopefully make one last bid for the NACC. Now we also bring with ourselves the breadth of experience from the first run and are ready to take that knowledge with us into hopefully a new age. Eating 250 chicken nuggets among the team wasn't part of the plan, but who's going to say no to a 50 dollar feast?

Singleton Pattern for Unity + Update on Battle Engine

This post is a short description of the Singleton design pattern, and a brief update on the state of the Unity project.

The Dreaming Man: Neo-Hwarangs, Protagonist, Scene One

Source image taken from Naver for artist of men
dressed as Hwarangs. (Jake dropped out, so we
no longer have an artist)

Neo-Hwarangs

A large focus and inspiration behind this was the idea of a technologically advanced, "neo" version of the old Korean high caste the Hwarangs. Ergo, they are a large part of The Dreaming Man.

In the game's story, the people in South Korea who had enough money to be able to hole away and survive the nuclear apocalypse eventually emerged, and had the supplies to carry on their generation. In the modern timeline of the game, 200 years after the end of the world, the descendents of these people have taken residence in the former "Jinju Castle", in the very southern part former Korea on the coast of the Sea of Japan.

In their time, they have travelled across the pacific to discover technology in the US that wasn't present before the war, and they have taken it back to create fusion-cell motorcycles for quick travel through the many concrete ruins of former Korea. The residents of Jinju Castle have dubbed the people with money and social power who ride these bikes, "Neo-Hwarangs".

Source image for potential
design of spears wielded
by the Neo-Hwarangs.

Traditional swords. This is a source image taken from Naver
for the swords wielded by the Neo-Hwarang faction.

The design for these characters includes an iconic pistol and sword combination, with spears as a cavalry weapon on their motorcycles. They wear tight-fitting versions of the outfits in the source image provided, with the symbol "花" on them.

Scene One

At the beginning of the game the player meets two of such people: Kang, and Kim Junsu. To summarize, they are scouting the region around where the protagonist lives, and they see his home and decide to check in. Kang likes the protagonist's wife, and decides to take her with him. This is to mirror the fact that the protagonist's girlfriend leaves him in the very first scene, and is intended to show that his premonitions are not random.

Kim Junsu – Kim is young and ambitious, and he has been travelling with Kang for a while now. Kang is tall and big, while Kim is tall and lean. He hopes to learn a thing or two from travelling with Kang, and is wary to object to something Kang says.

Kang – Kang is the leader of the group, and earned the position through his skill, strength and size. He is leading a scouting mission past this farm, and lacking just enough morals, he decides to take the pretty wife that he finds in the dreaming man’s farmstead.

Protagonist

The protagonist of the game is a fairly average white male living in Japan. Source images are myself and Matt, who are average white males (kek). At the beginning of the game his girlfriend breaks up with him, and henceforth an analogue of her exists in his nightly dreams.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
Things in the immediate scope:
- Write up more dialogue for the actual scene itself to give to Matt to put in the game.

Essence of Glory Faction Concept : Aehrenthal Federation

The Aehrenthal Republic was a collection of blue collar manufacturing worlds on the edge of Empire space. Upset that they rarely received more than raw materials and production quotas for their tax dollars, the system level leadership of the soon to be Aehrenthal systems lobbied for greater autonomy and a lessening of the tax burden. The Empire, overextended, and with a bloated administration decided to grant the Aehrenthal systems a unified leader who would only answer to the Emperor. Intended as a symbolic gesture to placate the systems while maintaining control, the newly crowned King Aehrenthal (for whom the systems are now named) quickly dissolved his post, replacing it with an elected cabinet which he presided over. Aehrenthal created a democratic system under the pretext of liberty and giving people a say in their governance but imperial historians cast it as a move to provoke the Imperium in to a war that Aehrenthal knew he could win and with it win the independence of his new nation.

The war was surprisingly short with the highly organized industrial might of the new republic out doing the overly bureaucratic system of the empire which put eldest sons at the heads of factories rather than those qualified or educated. In battle the republic's troops (mostly drafted factory workers) usually proved to not have the stomach for protracted fights, creating the need for more nationalistic and inspiring social programs and incentives. The soldier class quickly developed in to one of the most influential and prestigious groups in the Republic with politicians commonly wearing their military uniforms rather than civilian dress.

The new mobilized society combined with their industrial prowess made short work of the outmoded Imperial navy, but the militarism of their war of independence never truly subsided, due in part because the war has never truly ended, with the border territories erupting in constant skirmishes but also because there has been little political will to tone down the military rhetoric.

The intent of this faction in the game is to highlight the problems of emerging democracies especially when faced with such aggressive neighbors. Taking hints of Starship Troopers in to a revolutionary France type of society where they are not only facing internal problems but also a massive outer enemy, the Republic faces a lot of difficult choices for itself and how it should interact with the other nations in the game.

From a writing standpoint it's interesting because of not only the political what ifs but also the personal ones within the society that'll be explored later. In the current build the writing is slightly rigid from a character perspective, it's difficult to have a lot of diversity (in terms of character background) in the imperial factions because of the nature of their society. In the Republic faction we'll see not only more diverse character backgrounds but also more diverse political beliefs that will play in to the greater story of the Republic.


       

More story updates

This week I finally managed to get a hold of the full version of the VN toolkit, probably going to have some fun with it with some side projects. This version has a few more quality of life features, like not having to type in all the variables you're going to use, and instead select them from a dropdown box.

Anyways, this week our characters take a day away from studying tactics and visit the bar... although to learn from experienced veterans. Don't mind the scene in the back, placeholders are a nice thing to have.

Unity and toolkit troubles, and more knowledge

Unity is great for many things, but this past week there has been some shortcomings with the platform. 

So I started looking into the code for the VN toolkit a bit to see what we can throw in there, and what we can gut out. For the most part, it's a fairly well structured piece of software with areas where we can eventually start molding to form something suitable for this game. This is fine and dandy, although there's not much documentation in the code, it's easy enough to navigate and modify. Edit some parts of the GUI here and there, change some colour schemes, etc. However, it seems that the built in code editor for unity has other plans.

What? how can there be so many issues with areas that weren't even touched? Well after a while looking around, it seems that the built in editor MonoDevelop doesn't support any version of C# higher than 3.5, which is what the toolkit is built on. 

It seems that the original developers were also not pleased with Unity's editor, and probably decided to use a third party editor. Doesn't seem too unreasonable, but Unity is an engine where anybody, even someone without much coding experience can make a game; so it's not too unreasonable to say their platform for writing code is outdated.

Anyways, looks like the toolkit will need to be edited some other time. For now though, here is a new scene with our friends once again studying, in a bigger library this time. Perhaps they will learn a bit more about actual tactics, and *ahem* mechanics pertaining to what they're doing.

Here is Tarah dispensing some knowledge, while we look to make some more progress next week.

Unity Project Check-In

Not much to report this week. A few minor changes were made to the project. The two most notable being a rudimentary camera control suitable for testing, and some placeholder art for ships. Hopefully, by next week we'll be able to have those ships moving around according to the game's rules.

More on visual novel tookit

This week I've been looking into more features of the VN toolkit. Mainly basic functionality to get a working modern visual novel.

Using existing crop-outs of art we had, I made a little scenario with our characters studying with each other.

I managed to get the basics of a VN covered this week. Dialogue, choices, characters popping in and out, voices, and a BGM. They were easy enough to put in the game, but a problem that might occur later is organizing all the different scenes and dialogues.

What we may want in the future is to have a flowchart like narrative, with decisions or actions in the game splitting into different paths, or multiple paths to have a common convergence point. Throughout the next week I'll probably be taking a look at how to make a neat way to organize all the different scenes we have. Currently the tookit has a tree-like structure for organizing splits in decisions; what I may code in the future is to add flags to certain points to make figuring out what events occur at what times easier.

We might not have a story as convoluted as this one, but even if it's simpler it'd still be nice something to make it easier to manage.

Visual Novel Toolkit

This week I've been working with a module for Unity referred to me by Tyler, called Visual Novel Toolkit.

It's a pretty neat little program, that allows you to make VN styled games at the drop of a hat, although of course, for the more complicated parts of a game such as math and combat, you'd need to do that by yourself.

Working with the module in Unity

The actual interface inside of the module's pretty easy to work with, and there's a few tutorial videos online made by the creators of the module, as well as community content, so it's not too hard to learn.

The view inside of Visual Novel Toolkit

The UI inside of the game needs to be worked with, and the sprites are a little clipped, but this is only something to do preliminary testing on, so that's not too bad. 

I'm using sprites and dialogue given to me from the other project, shout out to whoever made them, because the art  and dialogue for The Dreaming Man aren't entirely up to snuff yet, so this allows me to do some practice before they're ready.

Anyways, it's a decent little program, and this weeks project. Next week I'll look into some of the code-side stuff, and investigate what more can be done with Unity.

Model-View-Controller Design with Unity

This article will discuss the overall design architecture that will be used to create Essence of Glory in Unity. Since Essence of Glory is a tabletop game, we can compare it to other such games and think about how they would be designed in Unity.

Let's say you were going to implement a game like Jenga in Unity. How would you do it? Well, objects in Unity are modeled with GameObjects. These follow the Composite design pattern; every GameObject is a collection of GameObjects, and/or MonoBehaviors. If you are familiar with Entity-Component systems, you can think of GameObjects as Entitites and MonoBehaviors as Components.

Coming back to Jenga, you would probably have each block as a GameObject and attach the right MonoBehaviours to it to give it meshes, textures, shaders, physics collision and so on. Furthermore, you'd want to know when a block hit the ground. So you could add script, in the form of a MonoBehaviour, to each block that would trigger when it collides with the ground.

But Essence of Glory is not a game like Jenga. A better comparison might be chess.

What happens when, in a game of chess, a piece falls over? Unlike in Jenga, this occurrence has no bearing on the rules. You would simply pick up the piece and replace it.

But hold on, I just posted a picture of a game of chess, but that isn't what chess looks like.

This is a game of chess:

And so is this:

 Or even this:

"1. e4 c5 2. Nf3 d6 3. Bb5+ Bd7 4. Bxd7+ Qxd7 5. c4 Nc6 6. Nc3 Nf6 7. 0-0 g6 8. d4 cxd4 9. Nxd4 Bg7 10. Nde2 Qe6!? 11. Nd5 Qxe4 12. Nc7+ Kd7 13. Nxa8 Qxc4 14. Nb6+ axb6 15. Nc3 Ra8 16. a4 Ne4 17. Nxe4 Qxe4 18. Qb3 f5 19. Bg5 Qb4 20. Qf7 Be5 21. h3 Rxa4 22. Rxa4 Qxa4 23. Qxh7 Bxb2 24. Qxg6 Qe4 25. Qf7 Bd4 26. Qb3 f4 27. Qf7 Be5 28. h4 b5 29. h5 Qc4 30. Qf5+ Qe6 31. Qxe6+ Kxe6  32. g3 fxg3 33. fxg3 b4  34. Bf4 Bd4+ 35. Kh1! b3 36. g4 Kd5 37. g5 e6 38. h6 Ne7 39. Rd1 e5 40. Be3 Kc4 41. Bxd4 exd4 42. Kg2 b2 43. Kf3 Kc3 44. h7 Ng6 45. Ke4 Kc2 46. Rh1 d3  47. Kf5 b1=Q 48. Rxb1 Kxb1 49. Kxg6 d2 50. h8=Q d1=Q 51. Qh7 b5?! 52. Kf6+ Kb2 53. Qh2+ Ka1 54. Qf4 b4? 55. Qxb4 Qf3+ 56. Kg7 d5 57. Qd4+ Kb1 58. g6 Qe4 59. Qg1+ Kb2 60. Qf2+ Kc1 61. Kf6 d4 62. g7 1–0"

In fact, some people play chess blind-folded, or via mail.

What does this tell us? That the way a game of chess is visually represented is distinct from what constitutes the actual game. The game of chess is an abstract rules construct which is merely represented in some form or another to players. This is in contrast to the earlier example of Jenga, in which the pieces that players manipulate are also significant to the rules.

Furthermore, this indicates that chess (and Essence of Glory) is a good fit for the Model-View-Controller (MVC) software architecture pattern. In MVC, the software is divided into three areas of concern:

1. The Model - simulates the state of the system. For a game like ours, this would involve tracking the position of pieces, resolving the outcome of moves, rolling dice, and determining if a player has won. This can be implemented with plain-old-C# classes and need not involve Unity at all.
2. The View - represents the state of the system to the user. Everything that the user sees is part of the View, this includes any buttons or other interface elements. As such, the View will mostly be made up of Unity GameObjects. It is updated based on information received from either the Controller or directly from the Model.
3. The Controller - updates the Model based on user input. May also be responsible for updating the View based on changes in the Model. Often implements the Observer pattern with UI elements.

This provides separation of concerns. Each part can be updated relatively independently of the others. It doesn't matter if a ship being moved is being represented by temporary place-holder art or a finalized and polished high-def model, the state contained in the Model and the command issued by the Controller will be the same.

This also helps for input. Only the Controller is concerned about where input comes from. Whether a command is received from mouse, keyboard, touch, over the network or generated by the A.I., the change in the Model will be the same and so will its effect on the View.

Model-View-Controller does not seem to be common in Unity, this article was the only real source I found after a quick search. It's an informative read, though it references the no-longer-used NGUI library. The example project linked in the above article is a very good example of how MVC can work.

Morgan's Weekly Update 2: What Needs to Happen in a Scene

Whenever I write a scene, there are a number of questions I have to ask about it. Questions like: are the characters relatable enough? Are they even believable? Is the setting clear enough? Am I getting across what I want to be? The most important questions (and i may revisit the previous questions in later posts) are things like: Am I teaching the player what they want/need to know? Are they even enjoying it? These two questions are hands down the most important to a game like this, after all a large chunk of the game will be dialogue. My early scenes were pretty lackluster exposition dumps with each character droning on about how they feel about the "Federation" only inserting a modicum of character simply based on;

"I come from X background, thus I feel Y" 

"Ah character 1; I am different for, I am character 2 from background A and therefore, think B"

No fun for anyone.

GO FOR THE EYES BOO!

I then went back to my role playing background and realized characters aren't necessarily remembered for their contribution to the story, more likely we remember their quirks and the interaction with the player. Minsc isn't ingrained in RPG culture because of his relationship with Dynaheir, we remember and love Minsc because he was a burly barbarian who carried around a cute little hamster named Boo. Going forward These are the sorts of things I really need in my characters, not more dry stock characters droning. 

I have the structure laid out, now it's just a matter of filling it with enough life to keep the player interested and teaching them along the way. One of the things that needs to be overcome is the unorthodox nature of our game. There aren't many large scale naval combat games out there, let alone ones with the systems we're including. My goal then is to ease the player in to these things through the dialogue. One of my fears is players looking at the systems we've made an wondering why things are the way they are, why does a vee beat a line formation in assault? My hope is they'll have some of these questions but the dialogue will dispel some of that, especially if they choose to have those conversations with characters, and keep it interesting. 

Lot of work on the horizon for me, check back next week for more of my exciting adventures in writing.

Dreaming Man Update: 2015-01-19

We were planning on getting a lot of the writing and drawings done this weekend, but a friend of mine from Peterborough drove over here to run a Pathfinder campaign which absorbed most of the weekend.

Regarding the progress we did make, Jake currently has reference photos for the protagonist as well as a description to create the sprite for him. Matt figured out how to use text with different options, backgrounds, and sprites in Unity, and I laid out the general shell for each scene to make it easier for Matt and Jake to read what's happening with dialogue.

I intend on writing some scenarios and possibly creating a Morrow Project ongoing to inspire some ideas.


The work we intend to get done in coming days is thus:
- Write dialogue and determine backgrounds for the beginning scene.
- Determine a (narrowed-down) set cast for Jake to draw.
- Determine a (narrowed-down) list of backgrounds for Jake to draw.
- Create some dialogue and organization of backgrounds, sprites, and scenes for Matt to import into Unity.

The overall goal at this point is to have a simplistic working prototype. ^ㅈ^

Visual novels and tabletop games

No game's complete without some sort of narrative, and for Essence of Glory we decided to take an interesting route to deliver that.

Since we're using the Unity engine to develop the project, we have the benefit of being able to use many tools for development. What we're doing at the moment is messing around with the Visual novel toolkit by Sol-tribe.

Using a visual novel interface will be very easy to have our characters interact with each other. The end goal is to modify the interface provided by our friends at Sol-tribe, so that eventually we will have a tool suitable for our game that is visually appealing and easy to maintain.

I'm just playing around with this at the moment, trying to see how many things are editable in the free version (since we might not want to fully commit to this yet). This tool seems to be able to recreate most modern visual novels, but there are some options we don't need for Essence of Glory; such as the save and load button provided with this toolkit.

All of the other options are very nice, including special effect and scripting options. It seems pretty picky about the textures that's used for characters, it must be cropped and specifically sized for the toolkit.

There doesn't seem to be more interesting features about the free version of the toolkit, it seems this week is a good time to lurk on forums to see features for the full version. But other than removing features, this seems like a good way to accomplish what we eventually want to deliver the story.

First Steps with Unity - Hexagons

This is the first in a series of posts about the development of the electronic incarnation of Essence of Glory.

We are just beginning work on this game, and we're using the Unity engine. We chose Unity for its availability, ease-of-use, and wide variety of deployment platforms.

This week's post will mostly be about hexagons.

What's so great about hexagons? Well, as the logo at the top of the page may suggest they are a pretty significant part of a lot of tabletop and wargames. They provide a more accurate and natural way of moving game pieces around than a square grid. However, they are a little trickier to draw than a grid of squares.

Unity measures the position of game entities with a three-dimensional vector. Our game board will mostly be flat, so we can ignore the height dimension for now. That leaves us to consider position on a two-dimensional plane, like a cartesian co-ordinate plane.

Remember math class?

As you might imagine, it's rather easy to draw squares on such a grid. The grid is already based on squares! Just draw a square at every position (x,y) and there you have it.

But how do you draw a grid of hexagons?

Well, it might help to imagine them as a grid of squares where every second column (or row, depending on your perspective) is offset a little.

Notice how each tile has 6 neighbours touching it.

What we want is a way of numbering hexagon tiles so that we can easily determine where to draw them.

Seeing as a hexagon grid is analogous to a square grid with offset rows, it may be tempting to try to number it like a square grid. Depending on how this is done, the results may not be helpful.

If you try to keep the axes at 90 degrees to each other, you may end up with something like this.

x-axis in red, y-axis in blue

As you can see, the y-axis is really ugly. Converting from these co-ordinates to Unity's world co-ordinates is not too difficult, but the reverse is a bit of a pain. What we want is axes like this:

axes as above

Much better. Converting from these hex co-ordinates to world co-ordinates and back will use the same formula at every position.

Now, to implement this in Unity, I followed the approach described here. As a programmer, I am much more comfortable with creating and modifying game objects from scripts rather than using Unity's drag and drop features. I won't go into detail here, but I first created a HexManager script, which spawns new game objects and attaches the HexModel script to them. Ideally, I would like to create a prefab out of the hexagon objects, as the game board will likely be the same in every level, but this is a useful construct and will do for now.

So, we have a way of drawing hexagons where we want them, and a logical way of describing where that is. Next week, we will be working on adding some interactivity to this video game, getting something to happen when you click on these hexagons.

In addition the article linked above, I also found 'Hexagon grid: Generating the Grid' and 'Hexagon grids: coordinate systems and distance calculations' to be of the greatest help.

Painted Panzer-Grenadiers for our Upcoming Flames of War Tournament

Here's a big ol dump of the stuff I've been working on for the upcoming Late-war tournament but it's still only a very small part of my army. I'll be playing a Gerpanzerte PanzerGrenadierKompanie which basically means a mechanized force, that runs around in half-tracks, outmaneuvering the enemy. This doctrine is very similar to the doctrine used by our Vanguard faction in Essence of Glory, which will likely receive a post of their own soon.

Making an army for a tournament is interesting and relevant because it's really about building a balanced force that can handle any threat and minimize losses. In essence of glory taking casualties is inevitable but minimizing your own while inflicting more on your enemies is key and looking at systems that also emphasizes those kind of trade offs.

Morgan's Progress Report 1: Old School Romantic Edition

It's been an interesting week, four and a half hours of which was spent watching Gettysburg with Martin Sheen and Tom Berenger, why? Besides the fact it's an awesome film it also has some amazing romantic writing and examples of relationships between corps commanders, and generals. This is really the kind of tone I'm trying to strike; a corp commander comes to you and explains his failure or success, it's up to you how to react depending on who it is and how you think they'll react. This type of interaction will really affect their performance and the story going forward.

Next week I hope to put more of this dynamic in to the scenes but work wise, this week was focused on learning how to use unity and a visual novel engine. It didn't go amazingly well but now with a better grasp of the system I can hopefully have something more concrete next week as well as some examples of some old school romantic style admiral, commander dialogue.

Dev Update: (Working Title) 'The Dreaming Man'

 A general outline for the introduction is written.

 A rough storyboard is in place to match the introduction.

 The general outline for the stages is in place, however more detail is to be written on the setting.

Protagonist

The protagonist ('The Dreaming Man') is decided to be a white male programmer in Japan. He works for Sony as a programmer (details of such are to be decided, such as how we can't use "Sony"). The reason for this is for the protagonist to be relatable, and for the intrigue of the adversity of being a white person in Japan.

Rough Storyboard for the Introduction.

Introduction Stage

The game begins with opening logo "Blue House Games". It gives an option to start the game, which will then begin an animation of zooming in and entering the "blue house" in the logo.

The introduction will be frame by frame, of different drawings. This is illustrated in the story board (right); in each individual frame it is merely the protagonist being drawn in a different position on the same background.

The beginning introduction shows the Protagonist entering a crowded subway station after leaving work.

He checks the time just as it hits 5:30 and he boards the train home.

He walks in the front door and puts on the kettle to make some tea.

As he's relaxing with his tea, he receives a text.

   >anon, I'm not happy with the way things are going

   >I don't think I want to be with you anymore

   >It's not that I don't love you...

   >I just don't feel the same way as I used to.

   >Please don't reply...

Anon puts down his phone and rests his head on his hands.

The next scene is anon going to sleep.

End of intro; fade in game Title.

Begin Dream 1 stage.

Dream 1 Stage

This takes place a reasonable amount of time after the end of the world. Enough so that most people have forgotten about the world before. The location of this dream takes place in the prairies of Saskatchewan on a farm with a barn for cows and pigs, and fields upon fields of grain.

Cast: Father; Mother; Son; Daughter

Players’ viewpoint is from The Father. The Father wakes up and looks over at his wife. She is exaggeratedly loving so to represent the Dreaming Man's sad loss. They go through a pleasant morning until The Father goes outside to work. At this point the home is attacked, and the wife is inevitably taken away, completely beyond the Father's control.

At this point, Dreaming Man wakes, and begins his day yet again. This is to be written.

Neo-Hwarang wielding a Geom (검).

Dream 2 Stage

This is currently unwritten, however the setting itself is written. This will take place in a neo-Korea, approximately 250 years after the end of the world. The dream's cast will consist of a group of neo-Hwarangs, riding motorcycles, and using pistols with sword sidearm. This is a setting heavily influenced by the Three Kingdoms Era in Korea ('삼국시대'). Three countries have emerged in former Pyeongyang, Jinju, and Pohang.

Things to be Drawn (as of now)

Full Screen Images/Backgrounds:

- Stylized "Blue House" opening logo. House has door and window(s). This allows for the zoom into the door upon starting the game.

- "Dreaming Man" waking up in his bed from an intense dream. A "nightmare" per se.

Dream 1:

- The inside of a relaxed one-bedroom farm house during sunrise. The house has a double bed for the father and mother, and two single beds for the children, as well as basic necessities. It is the equivalent of an 1800's farmhouse without power, and with animals and hand tools for crops.

- Exterior of said house. Containing a barn for the animals (pigs, cows) and tools. Surrounded by differing crops for as far as the eye can see.