The Rise of Dagon: new Unity GUI Screens - Week of August 30th 2014

This week's update is beginning to show the fruits of the new Unity UI release; I have been able to take a first pass at the new Main Menu for the game and the  Party / Character creation menus.

These items haven't been coded in yet to do what they need to do

Changelist:

- Created new "Main Menu" scene
- Created new "Create Character" scene
- created enum in BaseCharacter class for CharacterRace
- added first six races to the character race enum
- created first pass main menu using new uGUI
- created script for main menu for each of the buttons to take you to the appropriate scenes (note only implemented the ones that exist so far)
- created first pass layout for the Character Class selection using uGUI
- created first pass layout for Character Race selection using uGUI
- created first pass layout for Party Creation using uGUI
- created first pass layout for Character Naming and Portrait selection using uGUI
- created first pass layout for Character Summary and confirmation using uGUI
- fixed a player movement bug that was created from the refactoring of the player movement in to its new PlayerMovement class

In the screenshot below we have the race selection screen, where you can see by the placeholder text once the player selects the potential race they will receive more information about that selection before deciding.  

Next up we have the class selection screen, similar to race selection previewing a class by selecting it will eventually give you more information about that class.

At this time I've put in four 'core' RPG classes but I definitely will be adding more classes; I might utilize classes to put in the game as a kickstarter or indiegogo campaign - but that will be a little ways out before I decide how to approach that.

Next up we have a screen to name and configure your character portrait.  The portrait area is using the new scrollable rectangle element in the Unity 4.6 GUI and works really nicely.

And finally we have what will be the final character creation screen where you review your character abilities and skills(and potentially assign out extra  points) before finishing and saving the character:

So obviously these are using placeholder graphics but they still look fairly nice for what they are.  By putting in some of the game set pieces in the background it actually presents as a fairly solid looking UI. I can definitely see people being able to use the Unity UI to pretty good effect without too extensive of effort needed.

I did encounter some difficulties with the UI though.  There were times when it does not scale properly, or it will flip the graphics (showing as a red X).  Its not clear to me yet if this is a bug or if I'm just doing something wrong when it happens.  Typically when scaling it too much in just one directoin is when it happens, but there are occaisons that it would happen when just changing to a different aspect ratio or screen resolution.

For the most part I was able to design around that -- which leads me to believe that perhaps the issue is just a learning curve rather than a bug?

I did however have one thing occur I feel that really must be a bug which is while in the unity editor you often have a small window for a game preview which is supposed to look as much like the actually game will look when you press 'play' as possible.  There are always a few things that don't always render though like particles won't play unless they are selected and lighting and shadow effects largely don't show in the preview window either.

So what happens is say you selected 1024x768 as the target size , but because of your window layout the window is actually scaled down to something like 512x  the UI will not scale properly until you either undock the gameplay preview window or put it in its own tab so that the preview can match the desired target size.

Once I realized what was happening I was able to work around it easily enough - but until I figured it out I was having quite the hard time figuring out what was going on!

That's it for this week, thanks for reading!

The Rise of Dagon: Week of August 23 2014

Greetings!

Unless you've been either sleeping under a rock OR you aren't currently using Unity 3D you already know that the Unity 4.6 beta was released this last Wednesday.

The big feature in 4.6 is the new Unity GUI update that has been coming for about 2+ years?  I know it was scrapped and restarted at least twice, and the NGUI developer was hired for one of those re-writes and then left .. which publicly was very unclear if this meant things were in a horrible state or being just a philosophy disagreement?

It was very difficult process as a member of the public waiting for the new UI but finally it has arrived!

So I've been thinking about changing the format of this dev update a tiny bit - and that is to try and include a 'changelog' list of items I've worked on.

Many times I pick and choose what to write about but I may have actually done a lot of other work that isn't glamorous or screenshot worthy -- but was still work towards the project goals.

So for the near future until I decide that I like or dislike the format I'll be include a changelog list such as the first one we have here today.

This weeks changes:

• Refactored PlayerBehavior class to remove the player movement related code in to new class PlayerMovement
• Created BaseMonster class which inherits from the same BaseEntity class that the player characters do
• Created AMeleeEnemy class which inherits from BaseMonster
• Created new interfaces  IMeleeBehavior, ISpellCasterBehavior
• AMeleeEnemy class now implements the IMeleeBehavior interface
• Created new IGo interface used by the EnemyManager class to tell the monster to take its turn
• Created new SkeletalFootman class for the very first complete monster class
• SkeletalFootman now implements the IGo interface 
• The SkeletalFootman creates a new instance of the AMeleeEnemy class to implement its character class and combat behaviors and interfaces
• Worked on EnemyManager so that it now can spawn multiple enemies and control a generic C# style List of enemies. 
• Recreated player portrait in uGUI
• Recreated player hotbar in uGUI
• Recreated player healthbar in uGUI
• Recreated player manabar in uGUI
• Resized sprites for new GUI (was too big)
• Made it so player GUI bars should resize to any reasonable desktop screen size and orientations ; only thing it doesn't handle is small resolution portrait mode resolutions (mostly only found on mobile devices)

And that's all I can remember; unfortunately I decided to make this list at the end of the week instead of keeping track from the beginning so it may be missing a few items!

I should mention this week was a bit of a blockbuster for productivity - I was on a real roll! I do not always get this much work done so please don't expect a changelist that big every week!

And so we have a short video showing off the EnemyManager telling the skeletons to move forward each time the player moves.

It is just hard coded to have them move forward for now; I still need to do pathfinding an AI in a future update.

Thanks for reading, see you next week.

The Rise of Dagon: Week of August 16th 2014

So last week I had finally gotten my level logic tied in to the game but wasn't quite sure what to do next.

Sometimes there's a gigantic list of things you know you need to do, and an even bigger list of things that you aren't even sure of yet but you know are lurking out there somewhere just waiting to spring up and surprise you right when you thought you were going to actually get something done!

Thankfully this week that didn't happen and I was able to pick something to do, and actually do it!

What I chose to do was to work on the game 'state machine'.   As I'm unclear who may be reading and what your knowledge level of game programming is I'll explain that just a little bit.

A 'state machine' is the area of the program that handles what goes on in the game. 

Is it the players turn? Is it the monsters turn? Should the game spend a few milliseconds updating the game world and checking for any special events?  

Quickly swapping between these things and deciding what's to be done next is the state machine's job.

It's not actually a terribly difficult thing to create but it is easy to do things that cause your game to slow down and run poorly if they spend too much time in any one part of the state machine for too long.

Imagine if the calculations of determine what move the monsters are going to take took several seconds?  Well then you would have to wait several seconds between each turn!

Previously I demonstrated combat between the player and one monster.  This was a basic two state machine handling the logic for that sequence.

Now I have increased that to the following states:

START,

GAMEUPDATES,

PLAYERTURN,

MONSTERTURN,

WIN,

LOSE,

PAUSED

I'm not actually sure I will use all of these states but its better to have them available rather than try to squeeze to many things in to the wrong areas.

The "LOSE" state will clearly be needed -- this is when all your character are dead and the game is about to end. If I want to disable player control but let the game state continue for a moment and say have the monster do some sort of cheer over your body then this is where I will do that - and then transition to the game over / load game screen right?

The "WIN" state could be where I handle handing out XP and playing audio events after you've defeated an opponent. It might also be that could be handled during the PLAYERTURN or GAMEUPDATES so WIN might go away if it doesn't work out :)

As I noted before this wasn't too difficult and went in smoothly.

At that point I still had a nice chunk of the week left and decided to start moving forward with the next bit of the state machine progress and move the MONSTERTURN in to a more formalized system that handles the logic for all the monsters instead of just one.

This actually caused me a lot of pain and I want to share why & what happened , this could potentially save someone else a nice chunk of time and pain if they run in to it!

So keep in mind I'm using C# and Unity 3D here.. if you are using other languages this might not be an issue.

Firstly I made a EnemyManager script. The EnemyManager is what does all the work during the MONSTERTURN ; when it is finally done it will tell the game state machine it is done and the next state will proceed.

So firstly I decided to get my single skeleton monster in to this Enemy Manager and let him do what he had previously done .. sure no problem just a little bit of research here.

I decided to go with a Generic C#  List  See MSDN here.

So what I did was  in my EnemyManager class declare :

private List<Monster> monsters = new List<Monster>();

Then later after creating the monster in the scene I used Unity 3D's "FindObjectOfType" to add it to the list like so:

monsters.Add(FindObjectOfType(typeof(Monsters));

This worked great, and I had my one skeleton added to a list and was then able to reference the script in that list and call it from the MonsterManager!

But then I wanted more than one monster in my scene  .. and did this

monsters.Add(FindObjectsOfType(typeof(Monsters));

Notice the bolded and underlined s in FindObjectsOfType ..   and all of a sudden errors are coming up left and right!

So I spent the next couple of days trying to figure out what I was doing wrong.  It did not help one bit that Monodevelop did not detect any errors, but when swapping in to Unity 3D it would give anywhere from 1-3 different errors depending on how I tried to change or fix it.

To make a long story short the problem was this :  it was not returning the system.generic.collection List type!  I believe it was returning Unity 3D's ArrayList!  But this wasn't abundantly clear in the documentation because   from the Unity documentation here you'll see it just says it returns a list (near the top).

Once I understood Unity's FindObjectsOfType was not returning the type of list I wanted it was easy enough to fix.

I was doing this while instantiating new prefabs anyways so I simply add them when I create them by doing this now:

monsters.Add(prefabname.GetComponent<Monster>());

The funny thing is , I decided to use the FindObjectsOfType because I wanted to learn the Unity API better -- and I guess I got what I wanted - just not in the way that I expected!


Thanks for reading, see you next week!

The Rise of Dagon: Week of August 9th 2014

As mentioned in last week's update I had been doing some cleanup from designing the logic for levels so that I could finally tie together a level's logic with its physical attributes.

The first thing I decided to go with was to tie the players movement to the physical aspect of the level. What you did not realize previously (because I never showed it) was that if you attempted to move through a wall -- well you would move through the wall!

I was always careful in my video's to not move through walls -- simply because it would be odd for the viewer to understand what exactly was going on if I had done that!

Tying the logic to the physical structure was actually a two part task:

1. When actually constructing the level from prefabs make sure to mark the appropriate data so the player can actually use it.
2. Create code for when the player attempts to move to check the square that is the destination to see if it can be moved to and allow/disallow as appropriate.

To do this I decided to pick up a bit of code I had used before to create a dungeon room out of prefabs.  For each type of prefab I made a method that not only lays down the appropriate type of floor, ceiling, and walls but it also tells the "logicChunksArray" if it is passable by the player, and if each wall is playerapassable or not for instance.

So as I did that in steps I have a little in-progress screenshot here showing that I had the outer walls, but no corners, or center squares yet:

 This went fairly well but it was a little bit messy and I now have a method for each type of  grid you can have like so:

When you look at all of these combined they call out to be refactored as there is a lot of similar code going on but right now I was just happy to get it working!

Eventually what really needs to happen instead of having methods like this to construct very particular types of a square grid is I need to have an actual level format that just constructs exactly what needs to be in each square but for now this was a fairly quick and dirty implementation that takes me another step towards reaching functionality goals that I have.

This coming week I intend to continue working on logic related tasks -- I haven't actually decided what specific sub-task I'm going to tackle yet honestly I just finished up this work last night that I'm showing off today and need to pick through what looks like the most attainable bit of work I can take on for the coming week.

See you next week!

The Rise of Dagon: Weekly update August 2, 2014

Greetings!

This week's update is progress on the level format, level logic and the inevitable collision of the two.

As previously mentioned I've made preliminary efforts at laying down levels in code which worked out quite well.

I also mentioned working on level logic ; the bit that ties the things you can see, to what you are allowed to do.

Those items are coming very close to meeting in the middle now however I found that I actually had quite a bit of a mess as I had been slapping things together in a way that was taken from the 'just get things working' angle and now that it was time to stitch them together it was just obviously a bit too messy to work with.

I don't believe in over-optimizing at the beginning but I also know a mess when I see it! So I spent a good bit of time this week condensing the code from about 10 classes in to 3-4 classes and eliminating several class members from the primary logical class as they ended up being redundant as I saw how things were cleaning up.

Here's a quick screenshot of a mostly optimized  bit of logic inserted in to an array:

I was in fact still working on it, I had some public variables that ended up private later and the getter/setter properties are all that you can see for most of them now when you inspect it.

So starting Friday I have been doing testing where I use my current level code to insert a bit of the logic, and then I have a gameobject that I click on that prints out in a debug statement if the logic matches what it should be.  

The tests have gone well so this coming week I will begin integrating the level construction  with the level logic!

This task is complex enough I expect it to take more than a week, and I am very much wondering if its time to write a first pass file format for this or not? I would prefer to wait longer because I'm sure the format is going to change as I explore more .. but at some point I'm just going to need it! In any case I'm attempting to delay that decision until it becomes clear that its needed to proceed.

Thanks for reading, see you next week!