next »

[erebusman]

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!

[erebusman]

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!

[erebusman]

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.

[Cronnix]

Nice seeing your progress man, keep it up! Love reading your detailed thoughts.

[erebusman]

Nice seeing your progress man, keep it up! Love reading your detailed thoughts.

Thanks for the comment Cronnix! Much appreciated.

[erebusman]

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!

[erebusman]

This was a really great week for The Rise of Dagon development!  I hit a very nice milestone where you can start a game, create a new 4 character party and then hit the Play button and load the first level with your newly created party!



This work was all made possible by the recent release of the Unity 4.6 Beta including the new Unity GUI update. I have been holding off work in that area attempting to 'work around the edges' of things needing GUI interaction.  So after making the base screens the previous week I tackled actually adding the functionality to the entire sequence of screens. I had never worked with the programming end of new Unity GUI so it was really big question of how
difficult this was going to be and how far could I get in a week?

The character creation screens have a baseline functionality on them so they will be improved over time both to look better (including portraits!) as well as to provide additional features such as gender selection, attribute allocation, and potentially starting special skill/ability selection.

Changelist:
- created new CharCreateController class to control the Character Creation scene
- added  several enums for creation process
- added  created variables for each character slot to control race, class, first name, last name, full name
- created function to create a new character
- created function to clear an existing character
- created function edit an existing character
-  created function to set race
- created function to set class
- created function to set name values
- created several helper functions as the Unity GUI (hereafter uGUI) does not support custom types so I made helper functions that convert an int to a character class for instance
- added uGUI Text to party creation screen for the character name to show up per slot
- added uGUI Text to party creation screen for the character class to show up per slot
- added uGUI Text to party creation screens to show base attributes for the current char
- wired in all the above functions and tested
- found a few bugs and fixed them right away, most notably name creation was keeping the old characters name when the next character was being created
- created new SavePartyToPrefs class to save newly created party temporarily to playerprefs for new game
- created LoadPartyFromPrefs class to load newly created party in the first level
- added new methods to PlayerBehavior to instantiate the proper classes loaded from LoadPartyFromPrefs class
- improved first name and surname entry fields to clear the text inside them as soon as you click in them for easier character naming
- refactored some code from the character creation class in to a new ClassDescriptions class to handle the part of character creation than handles updating the uGUI fields for the class you are previewing
- refactored some code from the character creation class in to a new SummaryInfo class that handles the final summary screen of the character you are creating
- removed the GUI button to edit a character, I still may support this but the work to do it will take a while and was not essential at this time




In addition to the items above I also spent a pretty large chunk of time tweaking the uGUI interface elements to make sure they scale properly.  There are quite a few different options available for each element and depending on how you nest things it takes a bit of adjusting to get things to look and scale right as screen resolution or aspect ratio's change.

As seen in the screen shot the 'red x' patterns show UI elements that are not scaling well when you resize things around it. Lots of small adjustments are needed to get things right.  It's not horribly difficult and I suspect over time I'll understand the system better so I make better choices initially but for right now it does consume time trying to get things adjusted.

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

[erebusman]

This week was largely focused on the very first passes of the level editor for the game. However I did create one new piece of art which is the ever present dungeon wall "with shelf" to place and retrieve those all important quest items upon!



As you can see in the above shot the shelf is on the right hand side, a little hard to see in the lighting but I do prefer dark/ominous lighting for dungeon crawls as it really adds atmosphere!  Certainly as a player you will have different forms of lighting that you can adjust that with such as torches or light spells but this is roughly how it would look with only the wall torch nearby.


So I'm going to forgo the changelist this week because much of the changes were not code related but instead exploratory UI building tasks.

I am still very much trying to find all the right elements and a simple elegant style to editing the levels.

I would like to have some power in editing, yet an over arching simplicity.  The screenshot below show's off the state of the editor UI today.



In the bottom right hand corner will eventually be a preview window rendering the players perspective from the selected square but its just a black square at the moment.

I'm sure that I'm not satisfied yet. I sort of added things I needed to get the first pass of things going such as the slider bars that show the X, Y and Z of the level.  If we set those values to something like 10/10/3 we would get a level that looks something like the one shown in the shot below.



Then you would begin carving out hallways in each level depending on the layout you wanted.

You may notice if you look closely a small transparent layer above the red level blocks -- that is actually a transparent UI layer to help select the grid member you are working with rather than part of the level.

My current idea after a week of exploratory design is I want the flow to be something like this:

Choose your levels size
Select the layer you would to begin editing
Carve out your halls ways and rooms with a carve tool
Place major items like doors, arches, pillars, connecting walls, stair ways etc
Place Monsters (potentially with some path editor for patrols)
Place decorative items like cobwebs, debris, skeletons etc.


What you don't see in that list is where / how you would add things like quest items, monsters, loot, and game logic like "this door requires the gold key with id 437"

I'm picturing while editing and placing items that they would have meta data style properties to add these things in. But I would also really like the editor to be super smart and have a warning list that tells you "hey you put in a door that requires key 437, but you have not placed a key 437 in the game yet!"

There's really a ton of work left both in the interface of the level editor itself as well as the logic it needs to help you build a level!  I expect to be working on this for the next several weeks!

Thanks for reading!

[erebusman]

This week was my CAKE DAY!  Good times indeed.

I did short 5 minute video with commentary on the upates for the editor and Substance Painter quick demo this week you can watch on Youtube here:




For my birthday I was able to budget out an upgrade to Unity Pro 5.0 !  This was huge for me - I really want to use the PBR (Physically Based Rendering) feature for The Rise of Dagon and budgeting this out was a major goal for me. I'm really hyped that I will be able to use this more advanced shading/lighting model for this game!


First I'll go over the changelog , then I'll discuss what some of those line items mean and then finally I want to discuss Mudbox 2015.


Level Editor shaping up nicely!



ChangeLog Week of Sept 20:
added new EditorMouse class
added mouse wheel zooming  EditorMouse class
added right click panning to  EditorMouse class
created new OverlayAction class
added new 'overlay' quad primitive and gameobject , which uses OverlayAction
Added methods to OverlayAction that help track what dungeon grid/square you are referring to when you click on it
wired in the "NEW" Button to instantiate a level that is as big as your level sliders have been set to, currently supporting levels that are up to 3 layers deep, and 50x50 squares wide, and tall accordingly.
added HitReceived method/listener in the EditorInputHandler that receives hit info from OverlayActions
Added tool detection methods to HitReceived and branching decisions on what to do based on current tool
Implemented first two methods for level editing "carve" and "solid block" so you can now carve out areas of a level, and you can fill them back in with solid rock.
Added GUI toggle boxes for choosing which layer of the level you want to view/edidt
Added SetLevelView method that toggle boxes call, setting the selected level layer active, and the others inactive

So this work is largely control based for navigating around and making selections in the level editor. This work was needed to lay the foundation for actually editing the dungeon itself which is up for the first pass of work next week.


New Skulls in a Scene


Next I wanted to talk about Mudbox 2015.

I have been really working hard to use Blender 3D for my sculpting tool but the longer I use it the more I realise while it is technically capable; its really not as smooth and productive for me as either ZBrush or Mudbox could be.  I don't want to make this about tearing down Blender 3D as I do in fact use it for many things and appreciate the free software, its actually great for a lot of things! I do all of my animation in Blender 3D.

I have used both ZBrush and  Mudbox on student licenses in the past so I'm familiar with them, but I can't use a student license to produce my commercial game!

So ZBrush was my #1 choice , but its very pricey at essentially $800 US dollars. 

The last time I checked Mudbox was also about $800 US dollars, and while I do think its a very competent product - lets be honest ZBrush is a pretty clear leader in the industry

Skull in Mudbox


Skull painted in Substance Painter


and if your going to be paying the same price then which are you going to pick?

However since I had been able to afford Unity Pro I set my next goal of attempting to finance ZBrush, but in doing so I did a round of research for pricing just to make sure that there was no "indie" pricing or leasing options available and much to my surprise Autodesk now offers Mudbox 2015 subscription at a monthly rate of $10.00 a month!

That adds up to $120.00 a year, and they typically update their products once a year. This means for about 1/7th of the price of the stand alone product  I can stay perpetually up to date!

Needless to say I double checked ZBrush did not have a similar deal (they do not) and I plunked down my $10.00 a month right away! 

[Jondog]

Looks like a pretty interesting project, so I'm posting to follow.

[Gamedragon]

I really am enjoying reading your devlog. I love how in-depth you go and how you talk about your decisions.

[erebusman]

Well its been another very nice and productive week for working on the level editor for the Rise of Dagon.  These improvements start implementing the ability to configure the makeup of the architecture of the level rather than just carving out the halls and rooms.

For the most part this looks very similar so I've made a comparison image with a detail zoom in to show it a bit better:



You would actually notice a huge difference if you were in first person in the dungeon of course but as this is editor work I wanted to show it off like it looks in the editor.

Change List for the week:
- added greater scroll range to editor camera
- coded in "EDIT" tool to enum for ActiveTool
- added icon for edit tool
- created three new graphical 'tabs' for the editor tools
- created code to update text on screen to let player know what tool they have selected at the moment
- created new GUI element for the edit tool where you can set edit individual properties of a dungeon square
- created new toggle boxes for each GUI element for the edit square gui
- created a new class "EditSquareAction" that  receives the messages sent by the togglers
- created public members for each of the buttons and togglers in the edit square GUI in EditSquareAction
- created public methods for each of the Togglers
- created if statements that mark the buttons interactable/non-interactable depending on toggler state for each of the togglers on the edit square GUI
- added level logic to the EditorInputHandler.  Previously it was just throwing down blocks.  Now it will build logic attached to those blocks
- added new method to set solid block logic
- added new code to carve tool to set the block to a carved logic state (passable by the player, etc)
- added new SelectionSquare class to track the current selected and previous selected square (because apparently structs are a bitch to work with in C#/Unity)
- added methods for the EditorInputHandler for pillar instantiation
- added methods for EditorInputHandler for wall instantiation
- added code to prevent 'click-through' on UI elements vs level square grids as this was causing problems
- added methods to the EditSquareAction to reset the square when you change from editing one square to a different square by reading the logic array
- added a new boolean that tells the UI not to fire the Toggler actions while I am changing the square in code ; as the UI was firing as if someone was pressing it. Its unclear if this is intended or not but was an easy work around.

This work will continue over the next  couple of weeks at least and probably a bit longer as this is where much of the game detail and even eventually the logic around keys, triggers, quests will need to be added as well.

Thanks for reading!

[erebusman]

So this week started off a bit rough, I was able to complete what I thought was going to be a week long goal the first night.

I know you are saying to yourself "how is that rough?!"

We'll that means I did a bad job estimating how difficult the task was for one thing.  Secondly it means that I hadn't thought out the next item fully and wasn't prepared for it yet. That item was in fact part of last weeks update.

So Saturday afternoon and Sunday ended up being a bit of a wash from the standpoint of getting my head back on track.  I took the opportunity to relax a bit and enjoy my weekend and played a bit of Terraria with my son which was a lot of fun.

And then Sunday afternoon I had my thoughts together and sat down to program and I kid you not - just as I did so I got an email from Netflix saying that the Walking Dead Season 4 was available!

Now this was just bad news. I really try to avoid getting wrapped up in entertainment when I'm trying to program but I love this show so I decided that I would try to do a 50/50 approach. I have been doing programming for half the night and art for half the night while I watch The Walking Dead.

This worked out okay though as I needed to get some work on concept art for character portraits done.

I have Adobe Photoshop and Illustrator but I have been hoping to use Art Rage 4 as I really appreciate its natural brush feel it has.  But I was really unsure of what I can actually achieve with it so this week was a experiment in that direction.

While I did do a small set of test portraits I won't be showing them off today as I think they all need more work before sharing.

So here's a quick video showing off the level editor work that I did this week:







Changelist:

- Created new Carve class to specifically handle level editing
- Refactored all carving items out of EditorInputHandler and placed them into the Carve class. This was a big job as there were over 1000 lines of code that had to be separated in to the two classes!
- created new methods in the Carver class to delete child objects when using the Edit Square inspector panel to remove elements (walls, pillars, etc)
- did some further optimization/refactor of methods in the Editor Input handler that could be simpler due to functionality moved to Carver class
- added new class CarveBrush which will be used to make customizable carve brushes
- refactored the Carve method in Carver to use logic according to which brush you have currently selected
- added new Custom 1, Custom 2, Custom 3 carve brushes to the UI
- added new "Apply" button in the brush inspector panel, this allows you to apply the pattern in the square editor inspector panel to the currently selected brush
- added UI for toggle between "Smart" carve and "Strict" carve
- added new logic for Strict carving in the Carver class Carve method
- added new logic for Smart carving in the Carver class Carve method
- adjusted material on solid blocks for the dungeon to be a flat black material; makes it easier to see the dungeon you are carving
- adjusted the lighting used in the editor to give a bit more atmosphere and shadow to the tiles

Thanks for reading, see you next week!

[erebusman]

I was able to hit a really huge milestone for the Rise of Dagon this past two weeks : Level Saving & Loading is in!

This was a big deal for more than one reason and there's a lot to talk about so I decided to do a 5 minute video to cover all the reasons and what happened the last two weeks for this update.

Video


 
Thanks for watching, see you next week!

[erebusman]

This week I  worked on some tasks that help bring things together in a bit of polish and some various steps towards getting the core game play one step further towards being implemented.



One of the polishing steps was to work on the way the player moves, including the smooth turning to the left and right which really enhances the feel of navigating through the dungeon as you move and looks really nice.

One of the steps moving closer to core game play is I have put in a test monster spawner that will spawn 3 skeletons in any level that I create in random empty spots in the dungeon.

The point of this is I want to test out their ability to move throughout the dungeon, and then test their ability to see the player if they are in 'line of sight' and then furthermore seek the player out (navigate to them) if they can indeed see them.


I also have been working for several weeks on attempting to create character portraits.  I have used  Art Rage 4, Adobe Photoshop, and finally I started using Mudbox and I think with Mudbox I am finally getting close to satisfactory results.



First I have a Dwarf who is looking pretty solid (but not finished of course). You'll notice he is missing any kind of clothes and armor but his face, beard, and color tones are all fairly decent. I would like a slightly more polished look in the end but this is a really nice effort at this point!



Next  I have also been working on an Elf who is not as far along as the Dwarf but this sort of shows how the carving phase looks before I start putting on hair and painting the model more. It's a little hard to tell because the dwarf has a beard but the elf has higher cheek bones, a more pointed chin, a thinner nose and of course the pointed ears are easy to spot!



He does look a bit creepy with no hair but I will be working on that soon!
 

With the continued use of Mudbox I have been getting better at it and have started to try and use it to take models from Silo 3D and start figuring out a workflow and pipeline for asset creation.  This Dungeon Door took me about two evenings of work to get to the state you see it in here.  I would definitely like it to have more detail but again its such a nice quality level as is that I'm really  happy to be able to hit this type of quality with the tools I have. It makes me feel really optimistic about the look and feel of the game that I will be able to create!



The changelist is a little light this week mainly because it was a split week between art and code.

Changelist:
- created a test method for spawning 3 enemies in random places in the currently loaded level
- refactored some movement code from MoveActor into PlayerMovement to fix some movement bugs
- found another bug in movement code that I wasn't aware of previously and fixed it (after moving in to a wall sometimes you could not move again)
- created new methods to apply SLERP to player turning LEFT/RIGHT
- created new monster interface class IMonsterMove to handle the AI for monster movement

And that's all for this week I hope you enjoyed reading, see you next week!

[erebusman]

This week was really exciting because the Unity 5.0 Pre-order beta came out!

I spent most of the week converting the project over to Unity 5 beta and testing out if anything had gotten broken and converting materials over to the new Unity 5 default material.



So I made a comparison screenshot (seen above) for your review.

On first past you might not actually notice the difference except for one notable thing and that is the portcullis gate that I was working on can barely be seen on the right scene..

However if you look closely at the ceiling in both pictures you'll notice that they actually look pretty different when it comes to down to it.

The ceiling on the left is very  'sharp' and 'flat' looking with a lot of 'shine' where the light catches it. It almost looks like  newer polished stone? Which is a bit odd for a dungeon right?

 While the ceiling on the right looks more like old stone with dull shine .. more like a cobblestone rock would actually have.  This look is the look I was going for when I made the ceiling so I'm happier with it. The thing is in neither case did I spend much time tweaking it -- I used the default shader in 4.x and 5.x.   I'm still very much in early phases of production and don't want to spend a lot of time tweaking the way things look -- which is one reason I wanted Unity 5 - its PBR (Physically Based Rendering) pipeline was likely to pay off and look more like the way I wanted without a lot of work to tweak the materials manually.

So back to the portcullis.  I agree its much easier to see the one on the left but for a rusted metal its far too shiny!  It looks almost liked a polished metal in Unity 4 and it should look very dull and dark -- like it does on the right.


In the end I might need to adjust my lighting levels up a little bit but as I understand there are still some lighting features they haven't finished yet so I'm tempted to not spend a lot of time tweaking it right now.

There are other more subtle differences.  If you look at the very far right of the image you'll see the stone's there look chiseled and sharp .  Most particularly where the cracks are.  But if you loo to the same area on the left image .. sure the cracks are there but they are missing the highlights that give it that extra edge.  There are a lot of small things like that in the visual area that I like about the new lighting model as well.


Code wise this week I didn't do a lot of work so I am going to roll that discussion in to next week's update.

I will continue to do further testing in Unity 5 to make sure its safe to cut over to this for my project before I make a commitment. I need to vet that everything I've worked on so far either continues to work or can be fixed.  Things look really promising for swapping over to Unity 5 and I should be able to make a call on it in the next few days whether its a go or not.

I'll update you on progress for Unity 5 change over next week, see you then!

[erebusman]

As mentioned last week I was in the middle of evaluating the viability of swapping the project over to Unity 5.0 beta but hadn't quite finished. The question was is: beta was stable enough to allow me to move the project over, or was there some sort of blocker or bug that would break the project?  At this point I've finished and feel satisfied I can go ahead and fully swap over to Unity 5 from this point forward as nothing severe enough to stop the migration was found.

This will make things much simpler as it has always been my goal to utilize the PBR (physically based rendering) approach for the materials.  Being able to cut over to the target approach as early as possible is very desirable as you can imagine.

Code-wise I was able to work on the first pass of path-finding for the monsters. They are now able to navigate through the dungeon on their own making turns down paths, or alternating routes as needed.

Video of monster pathing in action:




I was also able to get a first pass on line of sight check for the monsters which should enable me to have the monsters seek the player out once they see him.  So that's my goal for this next week!

I've also been working on some additional environment models and art , one of which shows up briefly in the video -- there is a portcullis gate that the skeleton walks through at the end of the video because I haven't put in the code for doors yet!

That's it for this week, see you next!

[FuzzySlippers]

I'm running builds of my crawler in Unity 5 now and its workable though very unstable. I dunno if you are tied greatly to scenes, prefabs, or mecanim animator controllers but watch out as 5 can corrupt all three. I don't really use scenes and I'm in the process of un-tethering myself from prefabs and controllers but it still caught me by surprise. Definitely gotta be more persistent with backups. I svn my code but I've setup more regular full project backups for 5.

[erebusman]

Hey Fuzzy,

Thanks for the heads up!  I have not run in to those yet.. but then again I'm not really relying on those things much ; and I do use a source control if anything went wrong!

I construct most of my game objects in code at runtime is probably why I haven't seen that is my guess.

How would you spot a corrupted item? Just looks wrong? Or has some form of glitch?

[FuzzySlippers]

Unfortunately its a rather unambiguous crash. If you access a corrupted prefab you get a out of bounds crash in a build and it spams console errors in the editor if they are in a scene. If you access a corrupted animator controller it just crashes and if you even click on it in the editor it also crashes the editor. I had to delete the file outside of Unity.

I also assemble most things at runtime but I'm unfortunately tied to Unity components here and there. Like I use AnimatorOverrideControllers to assign animations but unfortunately you can't assemble mecanim controllers at runtime in a build (it's in the editor namespace) so I have to at least have a controller to modify.

I also have to rely on prefabs for my UI but I've been looking really hard at Coherent so I could switch to an HTML based UI and get one step closer to ignoring the Unity editor.