The Rise of Dagon Week of Sept 27th

EDIT: I originally posted this with the wrong date. Title has been updated for correct date.

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!

Rise of Dagon : Week of Sept 20, 2014

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!  

The Rise of Dagon : Week of Sept 13 2014

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!

The Rise of Dagon : Week of Sept 6th

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!