World Map UPDATE

Here is the updated world map. I added texturing to the background, placed a few flames around, and darkened the overall image.

New Logo

Here's the new logo.

Before:

After:

Animation List

The animation listing is up on the google drive now. You can find it here.

World Map

The world map is finished....I think. It looks simple, but I think it gets the job done.

Red Lantern Outpost Updated

The Red Lantern Outpost sprite sheet has been updated to include more tiles, such as the spotlight lighting up more tiles and vertical streets.

Audio Update

Just finished making the background music and the ambient sounds loopable in Ableton. Audio should be in good shape now.

The Tox Sprite Sheet Finished

The Tox sprite sheet is finished for the time being. Here is an example of how it'd look like assembled together.

PW Aspect of the MQP

I've been slacking too much on the Professional Writing portion of my MQP and it's starting to catch up to me. The next few weeks, I'm going to have to really bust my hump in order to get it to where it should be by the end of B term.

That being said, however, it is still part of the MQP and I believe its completion will help me write a better story that engages the player on a deeper level than it would otherwise.

My PW aspect is essentially a study dedicated to determining how to create an emotional connection between the player and the narrative within the framing of a strategy game. While there have been numerous studies on action games and RPGs in terms of emotional affect, the field of research within strategy games is mainly barren. Some would argue that strategy games, by their natural inclination to openness and appeals to logic as opposed to emotion, can't support complex and rich narratives, but I believe that to be false. Especially since I've been on the receiving end of games for a long time and have encountered plenty of strategy games able to create interesting stories and narratives.

By answering this question of how to create emotional connection between player and narrative, I believe the MQP will be that much more enjoyable for it. For the time being then, I think I will put my primary focus on successfully developing the methodology and literature review so that I can be a more effective storywriter in terms of creating engaging and interesting situations for the player, which will help our entire project as a whole in the long run.

Audio Update

The victory fanfare has been transposed to sound more masculine, and the three music pieces have been looped. I've cut each of them down into smaller sections in Ableton so that they can be placed together for as long as needed.

Prologue Cutscene Dialogue Set

The cutscene dialogue for all the cutscenes in the prologue are written according to Tim's cutscene parser format. It can be found in Scripts>Cutscenes>CutsceneDialogue>Prologue. There are 4 cutscenes in total, with three different backdrops being used.

Start Menu

The start menu, in terms of general design, is pretty much done. Just need to see what kinda options we'll include on the screen.

Archdrake Manor Backdrop Finished

The Archdrake Manor backdrop is finished for the time being. Again, it's clean, but I'll have to hold that off until the bare minimum is reached.

Quick Alpha Demo

This is just a quick video showing us going from Start Menu  to Cutscene to Battle. A lot of the art is not in yet but will be soon. Read the below posts to see what technical details are in so far.

Sorry for quality (Will upload to youtube next time)

Editor Plugins!

Rather than laying out all our scenes by hand, I wrote a plugin for Unity that allows us to take in a description of the level and then places everything correctly. The level file describes things like the width and height of the level, the tile sheet for the ground, where players and enemies are, and more. Then, we provide the plugin with this file, the sprite sheet, some other dimensions and the scene that will follow the scene we are generating. Then, we press the button and get a scene with everything setup the way our scripts require.

This is what results from generating the map from the picture above:

The level is generated (which saves us from having to do it at runtime), all players are placed with their correct stats; likewise for the enemies and their stats and AI. The terrain and status objects are also added to their correct position to influence the way the map plays out. All in all, this just makes it much easier to setup a scene and removes a number of things that we used to do at runtime.

Archdrake Manor Sprite Sheet Completed

The sprite sheet for the Archdrake Manor is now finished. Now moving onto the Archdrake Manor backdrop.

Basteon Level Set Up

Basteon level is set up basically how I want it to. I've got a few things to discuss though and Ill bring them up at core hours tomorrow when I can use the level as a visual aid in conjunction with explaining what I mean.

The numbering for the sprite sheet seems to be a little off. Some of the numbers didn't match up to the sprites I expected them to. Something to note.

Once we get the next level's tileset into the folder, I can begin working on the next map.

I think tomorrow or Thursday we will finally be able to start playtesting with people outside our group.

AI and Parsing Data Files

This post is long overdue. For most of the past month I've been working on getting the AI from random attack to something coordinated and useful (in addition to other things).

The AI system is composed of a series of packages attached to a unit. Each package is composed of a number of conditions and actions. A condition is a simple query about the state of the game. Things like "are there enemies in the area?" or "am I wounded?" and many more are all available as conditions. In order for a package to be able to run, all conditions must evaluate to true. An action is a single thing that a unit might do. Something like finding a target, moving somewhere, or attacking something are all covered. Actions are run in order.

Each unit has a number of these packages as well as a package that does nothing (so that there is always a package that can be run). When the AI system goes to run for a unit, the packages are evaluated in order (so they need to be specified in a certain order). When a package is found that is capable of running (all conditions evaluate to true), then it is run. The last package (the one that does nothing) has no conditions and so it can always run and will be chosen if nothing more specific can run. When running a package, each action is evaluated in turn, in the order they are specified. Usually, a simple package will involve finding a target to attack based on various criteria, moving towards that target and then if able to attack (if the unit is next to the target and had the AP), the unit will attack.

A sample AI system for a unit would look something like this:

AI
    Range 3
    Name BasicEnemyR4
    Package
        Conditions
            PlayersInArea 1
        Actions
            GetNearest
            GetLowestHealth
            GetRandom
            GetDestination
            MoveTo
            Attack
    Package
        Conditions
            HasPreviousTarget
        Actions
            GetPreviousTarget
            MoveTo

This describes an AI system where the unit has a range (which controls how far a unit can look to find an enemy) of 3 with two packages. The first package is conditioned that there is at least one player with the area defined by the range. If there is, then that package will be chosen. It first gets the nearest enemy. If there are multiple enemies at the same distance, then it will narrow that list based on the remaining health of the enemies. If there is still a tie a target is chosen at random. Once there is a target, the unit will find the closest open point next to the target, move there (it might not make it if there it doesn't have enough AP), and then, if possible, it will attack the target. If there are no targets available, then the second package is checked. This is conditioned that the unit previously had a target. This means that the unit must have had a target picked out during the previous turn, which might happen if it moved toward a target and then the target moved away, out of range. If it had a previous target, then the first action will take the last known position of that old target, set it as the destination and then the unit will move there. This simulates a sort of search. Finally, if none of these packages can be run, then the empty package (which is added automatically and not specified in an AI file) is run.

Now, this brings me to the next big change. All AI systems, as well as information for unit stats and attack information, are all stored in text files now. This makes it a lot easier to change values. The AI file shown above is an example of what an AI file might look like. The files for stats and attacks look similar, but specify their own information, obviously. The parser is a small library written in F#, mainly for its pattern matching abilities. The biggest challenge was getting that to interface correctly with Unity. While, it would load the library correctly, it turns out that Unity's .NET runtime is not capable of inferring types from external F# libraries, specifically the var keyword would not work correctly. I make rather extensive use of var simply because it's easier to type and the type is almost always obvious from looking at the name and/or assigned value, especially for the parsing library because everything was wrapped in what is effectively a static class. So, in order to specify the class that represents an AI package, I'd have to write DarkHorseParsing.AIPackage (and that is after importing the namespace). Now writing that isn't really an issue, but when the code wouldn't compile, it took me a long time to arrive at the conclusion that var was the cause of my issues. In end, the code was fixed up, types were specified and now everything works just fine and our data files can be easily manipulated.

Updated Art

The Basteon Holding Cells backdrop and Red Lantern Outpost sprites are completed for now.

(Basteon Holding Cells)

(Red Lantern Outpost)

Playtest Survey is up

Created a simple exploratory playtest survery today consisting of a few rating scale questions and two open ended response questions. The survey should provide us some feedback on the balancing of our difficulty, how well the game's controls and mechanics are relayed to the player, the inherent amount of fun our game provides a player, a small look at players' game interest, and players' most and least enjoyable experiences with our game. This data should prove valuable in gathering useful feedback from our playtesters. The survey can be taken here:

https://www.surveymonkey.com/s/QDL3TNW

Maps Now Generating From Code

Initially we were pulling in premade pictures to use as the terrain for our maps. This was inconvienient though because it was hard to alter and required too much work even to make small changes.

Now we generate our maps from text files that contain a series of numbers that relate to various tiles on a sprite sheet. This is much better because it means no one has to touch to code to change the map, and it can be done fast without requesting the help of the artists.

The next thing I will be working on will be a basic fog of war system.

Audio Is Finished!

All the audio sounds that are listed in the schedule are finished. They can be found in the Google Drive.

Playtesting Iteration Yields Useful Results

Had a VERY informative playtest today in Jennifer's class. I tried adding in Defense values to the listing of stats, and realized that having a flat reduction brought up some complications with balancing. A hotfix I made that seemed to work well was having a diminishing defense that restored to maximum at the start of the next turn, in the same way that AP does. After implementing this into the game, the player notably had a much more fun experience playing the game. It is still very challenging as it is right now, however, and will need some way of healing player units in future iterations. I've also begun trying to balance stat growths and experience values, but decided not to playtest those features today. Below is a picture of some of the players and commentators on the game.

*UPDATE: Basteon Battle Map

The Basteon battle map is finished. Took me awhile to draw up all the separate tiles, but here is the end result.

Two Implemented Map Designs

As of yesterday, I finished the second map design for our game. Currently that means that Basteon Holding Cells and Red Lantern Outpost are both representative of their final forms in the game. Some minor tweaking will happen once we go digital with map design, but for the most part the map layout gameplay and terrain will remain the same. I will try to design another map for tomorrow if possible. If not, then I expect to get the third and fourth maps designed over the break.

Better Late Than Never: Debriefing Design

Last Wednesday I took my "test level" into Jennifer's game design workshop for some playtesting feedback. The results were mixed, but ultimately I got a lot of good ideas and a few things I hadn't thought of were brought up.

Mainly, that I should begin the design of our terrain and our actual maps now, and stop focusing solely on stats balancing.

I've decided to also take the advice of iterating over several maps to get playtest responses on Hero strengthening curves.

As for balancing, the enemies were hit too hard for stats, I need to beef them back up for future iterations.

Logo Is Finished.

The logo for the MQP is completed, as the title says. I tried keeping it as simple as possible.

Game Rules Digitized

Game Rules have been typed up on the google drive. You can find it here:

https://docs.google.com/document/d/1fG1EWguk16i7KwHpvWqKLLPseHMQGgPVg_CnldONnN4/edit

These will mostly be useful to Tim for developing the AI, but there are also general rules written here as well which could be useful for setting up our demo scene.

Three Sound Effects Completed

Yesterday, I completed three sound effects: explosion, gunshot (rifle), and gunshot (sidearm).

1.) Part of the explosion was developed in Audacity first, and then imported into Ableton for the finishing touches. A track from the gunshot Ableton file was incorporated into the sound.

2.) Gunshot (rifle) was created by downloading a firecracker banging sound from an online sound library.

3.) The gunshot (sidearm) was created by following an online tutorial on YouTube.

Cutscene Outline Done Up Through Chapter 3

Title says it all.

I'm planning on writing more of the story in detail as we get more of our game infrastructure up and running. This will probably not happen in earnest until A term break, since I will have nothing but free time really.

Vrell's Underground Research Facility Completed

Vrell's Underground Research Facility is now completed, at least completed enough to be usable.

Opal Street (Day) Finished

The streets of Opal during the day is now finished.

Houston, we have Prototype

Prototype is retooled from last week's. Minor bumps to stats here and there. General map layout is the same.

Cutscene Manager still needs to be merged with portraits, haven't heard from Shane about that though.

Cutscene Manager has some minor refactors done, to make the code easier to understand and use.

Movement and Attacking Changed

Movement range and legal spaces to move are now always visible to the player. When the player is not moving they can see what units they can attack (within range) and cycle through different attacks to see the ranges. Also we now allow players to move through players, and enemies can move through enemies.

Going forward we will be improving the AI and also working on the character specific classes. These classes will be in regards to the actual main characters in the story and they will each have their own classes. Also we will work out how to manage story flags along with those classes.

Refactoring Some Cutscene Code

Decided to do a refactor of my cutscene code to encapsulate each cutscene's entire dialogue within one automated method call.

Almost have it working completely the same, just can't get the cutscene stopping to work right.

This refactor will enhance readability of code as well as make it much easier to add cutscenes into our game.

Victory Fanfare Music

I finished composing my own victory fanfare music using Sibelius 7. The audio file had about 7 seconds of silence afterwards for some reason. So I had to import it into Ableton Live in order to decrease the length of the track to 5 seconds.

Gunshot Sound Effects

I looked up a tutorial on YouTube and made two sound effects in Ableton Live 9 Suite.

Chapter 3's Out of Combat Narrative In Place

I decided to really buckle down and write out all of Chapter 3's out of combat dialogue yesterday. In it, Faryll and his group succeed in defeating the Archdrake. As Soanshi appears to reveal that she was the architect of her father's demise before finishing him off, however, Faryll draws his blade and kills Soanshi as she was a cruel and callous girl who couldn't be trusted to watch over the Lantern in a peaceful Arkehlm. As one might expect, Naiah, bearing witness to this, is driven berserk with despair and rage. Faryll has a difficult choice to make, as Naiah is adamant in pursuing Faryll's death, which could threaten the existence of a peaceful Arkehlm as she has the strongest rights to controlling the Lantern and the Drakes. You'll have to read it for yourself to see what happens next.

Vrell's Underground Research Facility Established

Vrell's Research Facility is now established. The image depicts some sort of room, with a large type of machine in the center that contains the Tox disease. More work will be done in the following week.

Paper Prototype Pretty Prepared Package

The paper prototype is pretty much set to go, only need to make some new pieces for the map. It has no terrain difference, revised starting points for the units, a written set of both general and AI rules, and a quick reference for Player Units and Baddie Stats.

As per Dean's request, we've stripped the prototype down to its "skinnies," choosing only to implement HP, AP, and Attack into the individual unit stats.

Combat Test Infrastructure and Small Update to Cutscene Manager

Tim and I worked together yesterday making a simple C# project that will be used to do balance testing for our units. Currently, it's a very pared down test, only taking into account HP, AP, and Attack and not allowing for any movement. As our prototyping and game progress the tests will evolve in complexity as well.

Also earlier this week, I added small functionality to Cutsene Manager that allows for sprites to appear and disappear based on who's talking.

Refactoring and Other Stuff

Sam and I made some smaller changes to deal with some concerns. The grid has been altered so that units are in in squares, rather than on lines. Units now slide around the grid rather than appearing at their next spot. The biggest noticeable change is an "inspector" of sorts. When hovering the mouse over players and enemies, some information about them (name, health, ap, stats, etc.) appears on the screen. My big change for the week was a complete refactoring of the pathfinding and surrounding systems. I was planning on bringing attacking into its own script, but it needing information that only pathfinding held. I couldn't bring myself to have attacking mess with pathfinding so I moved some stuff around. There is now a class that holds information about the world. Sizes and, most importantly, the grid which holds the state of the world. I also rewrote the pathfinding to use the grid rather than waypoints. That required that I write a minimum binary heap and priority queue because C# doesn't have any. So, a lot of the back end has been rewritten or altered to use the new class of world information, and to use the grid rather than custom structures.

Friday (9/12/14): Tox Street (Day)

Last Friday, I finished the street view of The Tox in the daytime, which will be used in the game's cutscenes. So far, everything went pretty well. The next art I'm planning to do will be Vrell's Underground Research Compound.

Wednesday: Player Switching and Very Very Basic Friendly AI

Today Tim and I made it so the user could correctly switch between characters. We also got really basic AI working. We still need to make it so the AI move on seperate turns and not all together, but that is a problem for another day. We are going to continue work on AI next time and re-implement the AP system to limit how much players/AI can move per turn. Also we will have the AI actually attack which means we will have to put in some kind of health system.

Wednesday: First Core Hours

Tim, Sam and myself are currently doing some core hours today. Apparently none of us remembered to e-mail the exact time to the alias however since we planned it out in person. As a result, our artists have not received the memo and understandably not appeared. We've decided to try and meet quickly tomorrow to go over the schedule and make sure we're all on the same page for Friday's meeting with the advisors.

Cutscene Manager code has been merged with the main DarkHorse SVN finally.

Cooked up some possible formulas and stats for later down the road, but for the purposes of the paper prototype, many of those stats won't be represented. We want to get the idea of whether the pure basics of our game are fun. With that in mind I've designed a simple non-canon map to test out the basics of our design choices so far. I'm going to transfer the design onto grid paper tomorrow.

Tuesday: Cutscene Code Changes

I've come to my first impass in the cutscene code. I've come across two features that I want to add, but the code style to implement one feature won't work with the other feature. It's essentially come down to whether I want to allow for skipping cutscenes midway through them, or give the ability for us to create a nonlinear cutscene delivery system, allowing us to present cutscenes in any order we wish (essentially allowing for optional cutscenes). Both provided noticeable game enhancement for the user, so I will bring this issue up to the rest of the group and see how they feel on the matter.

Personally, I feel the optional cutscene feature's code style is a much better way to handle our cutscenes as it doesn't rely on "magic numbers" and instead uses an enum allowing for descriptive names for our scenes which will make it easier to follow the ordering of cutscenes in code.

Monday: Paper Prototype Progressing Pretty Promisingly

Got some ground work going for the Paper Prototype. We have a rough draft of our very first map design! Oh boy! Excitement. I'll be refining it a little more (and transferring it over to grid paper) and working on the pieces before we meet Wednesday for core hours to discuss and deliberate design (how about that alliteration?) and boil it down further into something halfway decent and playable.

Alongside the prototype, I'll probably look into some ways to code appearing, disappearing and static images being displayed into the Cutscene Manager, since at present time it's less of a Cutscene Manager and more of a text box manager. No promises on that happening immediately, but I'll definitely be looking into it.

Monday: We Have a Blog!

Dev Blog is up and running.

Today I've begun work on the paper prototype design for next advisor meeting and am helping determine specific assets to put on the schedule.

Also doing some minor retouching and editing with the story.

I'm currently planning to do the prototype map based on the second mission currently, since the first mission is merely meant as a tutorial to the basic fundamentals of playing the game.

Also, came up with a possible design idea for combat, some sort of line of communication concept that if broken, you lose command of a unit and it acts on its own based on some kind of AI (perhaps even tailored to personality if we're really ignoring scope). Interesting idea, not sure how viable it is though. I'll need to think it through more with the others and see what they think.