The Rise of Dagon : Weekly Update May 31

This weeks update focuses on creating proper prefabs and laying out levels in code.  

All the previous work shown has been manually positioned one piece at  a time.  

So now its time to start putting things together in a more formalized way that can be eventually turned in to a level creation algorithm and level saving / loading serialization.

The first task was to start making the prefabs that would be very specifically sized to allow the layout to occur programmatically .  That is to say for instance if I wanted to create a short hallway I could line up 3 'hallway' segments in a row placing them 5 units apart and have a 15 unit long hallway.

So in the first screenshot here I have constructed the first hallway prefab and then manually used the type-in values in the editor to place them exactly 5 units apart and as we can see they line up very nicely.

This test turned out nicely and proved that I was ready to try laying this out in code the next evening.

The Rise of Dagon : First alpha video up!

So I took the time to capture some alpha dungeon crawling footage this evening so you can check out how The Rise of Dagon is coming along!

Just a really quick shot of 30 seconds of walking through a dungeon. I really love the look and feel of dungeon crawl games like Eye of the Beholder, Dungeon Master and Legend of Grimrock.  Hopefully you can already pick up the vibe I'm going for here and dig on it!

The grid layout is actually off so you'll notice in some spots you walk close to the wall than other places.  Heck its ALPHA everything looks whacky but its footage of walking around in a dungeon! How cool is that?!

Note: Sorry if g+ spam occurs due to this post - unintended.

The Rise of Dagon: Week of May 24

Blueprint's in Unreal Engine 4

This week was an interesting exploration in to the Blueprint capabilities of Unreal Engine 4.

If you've used PlayMaker for Unity 3D, or any visual graphing style scripting tool then you will have an understanding of what Blueprint in UE4 is about.

If not let me explain in brief.

Essentially what Blueprint is is a way to visually design your scripting of almost anything that might happen in your game including behaviors of objects, sounds, the player, or the environment.

The cool thing about visual graphing systems like this is that you can very quickly (once you learn the system) script out a solution.  The visual element can be very important as it lets you see the flow control theoretically better than in code.

In UE4 I would say the flow visualization is definitely better in than in code because the blueprint animates as it executes (if you have it open) so you can see exactly what its doing.

So my first task was to do a lot of video tutorials to learn about the blueprint system and I found this set of tutorials very helpful:

https://www.youtube.com/watch?v=cRhWc2kAhqI&index=1&list=PLZlv_N0_O1gaG5BW72It4chjhypxIO9ZB

I watched the full introductory set and definitely recommend it.

Afterwards I decided to work on creating my movement script for the player in the game.

The basic Movement code utilizes WASD,  for directional movement and Q/E for looking left/right.

So after completing the Blueprint tutorials I was able to get the following movement blueprint together which worked perfectly:

The next evening I undertook to add in the left/right looking with Q and E and found that it was not working.

Specifically I was using SetActorRotation ; and was having problems so I also tried the very similar SetActorLocationandRotation -- which also didnt work.

Neither SetActorLocation or SetActorLocationandRotation appear to work at this time.

Obviously when I say I 'tried' it I tweaked it, removed it ,re-did it. I changed all the axises, tried one at a time and all those troubleshooting things you do when something doesn't work.

I also figured out how to select my player actor while the game was in game mode and inspect the rotation variables ; and saw that it was not working properly their either.

So I began searching for any issues or help and found someone was having a simliar problem in C++ style code, but since I was using the blueprint system I went ahead and posted a question on the UE4 Answer Hub  https://answers.unrealengine.com/questions/46385/setactorrotation-setactorlocationandrotation-issue.html  but the most useful thing to come of that so far is to find someone else has the same problem.

I'll admit I'm new to UE4 blueprints and I may be doing it wrong - that's a real possibility.

I decided to try a C++ approach instead as I definitely want to be able to use both C++ and Blueprint designs in my game. I've programmed 5 games in C++ using a library called AGK and I enjoyed that work quite a bit so I was looking forward to see what the UE4 approach would look like.

Also if it worked in C++ this might give more insight as to what was going wrong with the Blueprint? 

I started off with  https://www.youtube.com/watch?v=Q3AvZmZEPyc , and found that I had not met the pre-requisite's which is you have to pull the source from Github.

So I watched this video:  https://www.youtube.com/watch?v=usjlNHPn-jo

And I started running in to some potential concerns about using UE4. 

I want to stop here for a moment and say that I knew when I started trying UE4 that eventually I would come to a 'stuck' point -- it happens in every project that I do that I get stuck .  I'm not afraid of being stuck -- being stuck is when you learn the most, albeit very painfully usually.  

So I was (and am) willing to undergo learning pain but I also have to stop and realize: I'm a lone developer. choosing my engine has to be as smart of a choice as I can make. I have to do the code, make the models, texture the models, make the levels, do the AI, create an inventory system, create and put in the sounds, create a class system, create a procedural loot system .. the list goes on and on.  I have enough things to do that I need an engine that's going to do a fair bit of the heavy lifting for me!

In other words -- I don't need a library; I need a full featured engine!

Once Again Unity vs Unreal 

So now I got my first stuck point I have to stop and take stock of what I know about UE4 and Unity and attempt to make a choice about which one is going to be the smarter choice for me to create The Rise of Dagon with.

The first  thing I learned is I would need to pull the source code and create my own branch to develop in C++ with UE4. Whenever Epic updated the source code I would have to merge their changes in to my code base. 

Don't get me wrong I've worked in an environment with multiple code branches where merges occur and I have had to resolve changelists often enough but the thing is I'm not the one who has to manage all that most of the time at my work, there are two guys who do that full time.

In UE4 I'm concerned about the amount of maintenance and technical debt that I could incur - or alternatively force me to not take updates because of that debt.  

In the Unity world they do a lot to lower my concerns in this area. For the most part the scripts I write don't break in between Unity versions.  It's possible when Unity makes the cross between 4.x and 5.x that I could incur some technical debt but this should be a one time issue - the level I'm willing to deal with.

The second item is Blueprint in UE4 had a mediocre to poor showing for my first attempt.  Sure its powerful, very cool and shiny ; but it also appears to potentially be either buggy or young and still in need of polish?  

There's a fair amount of risk to my perception if Blueprint is not what it strives to be; this will mean constant problems for my development.  How far do I go dismissing Blueprint problems before I find myself really deep in Unreal and with a crippled product? Will I end up six months along and find out that perhaps these things aren't going to get addressed?  

I have no idea at this point but all of a sudden the price difference between Unreal and Unity start looking a little less important than knowing that my time is going to be spent making a game .. rather than finding bugs in Blueprint and not having my game work??

So I end this week feeling very mixed about what the right decision is. I don't want to give up on Unreal as I really like the engine, I feel like its a more technically accomplished engine ..  but I'm starting to feel like its also a little less 'super small indie' friendly.  

What are your thoughts about Unity vs Unreal at this point?

The Rise of Dagon: Week of 5/17 Update

This week's update will focus on a comparison of features, costs, and reasons why I might stick with Unity 4/5 or Unreal Engine 4 (UE4). 

Reality Check

First lets get a reality check. Last week I was sick on Friday but it turned out I had come down with a viral stomach flu and was sick all weekend. In fact I was bed ridden most of the weekend and finally got up for good around 5pm Sunday which is highly unusual -- I'm the kind of guy who has to keep super busy and can't stay in bed.

From that point on I was in a slow recovery .. but also hitting crunch mode at my work we have a software release coming up soon and I did about 60+ hours of work this past week even when I was recovering from my flu.  To put it in one point of perspective I lost 11 pounds this week .. I was not feeling good.

I say this not to give an excuse for how much work I have or have not done this week - but to point something out to fellow and hopeful indie dev's out there: I had a hell week folks but despite that I got some things done!  

My personal rule is: I always do what I can.

That's my standard, and it serves me pretty well. My promise is I'll always do what I can!  And its what I recommend to others. Life comes up and stuff happens!. Don't feel bad if you had a busy week.  But also don't drop your project if you had a slow week either!  Do what you can, and feel good about it - then keep going. So moving on..

So a quick list of my prototype goals I worked on this week:

The Rise of Dagon : Weekly update May 11, 2014

 Hello, this week's update is a little shorter than last week. I've had some sort of flue the past few days over the weekend and it really hit me hard.  I still got some things done earlier in the week and  been contemplating some changes..

Firstly I continued to build out an initial alpha prototype dungeon. As seen in the first screenshot I started adding some small bits of visual decorations as the wall bracket seen to the left here.  Its not textured as nicely as it will be eventually but at least I got the model in.

Next I took a little bit of time and polished up my movement code. The screenshot here depicts a black and grey checked grid that I used to test to make sure it was moving me exactly where it should be each time.  

The blocks seen at the edge were an asset placement test to see how I'm going to implement arches/pillars and how they will look when you are in any particular square of the grid.  

I was concerned about having them either improperly obscure the players vision or be too 'thin'. Oddly enough It worked out exactly as I was hoping it would the first time!

Next up we have the big news of this post which I honestly would like to discuss a LOT more but because I'm sick today I'm going to just give a teaser and I will explore this with you in more detail next week and that is I decided to try UE4 (Unreal Engine 4).

What spurred my decision was Tim Sweeny modified the license terms to not charge developers for the first 3k of revenue each quarter.  That being the case there were only 2 potential barriers.

Barrier 1 "Sunk Cost" :  What this basically means is perhaps you've invested too far in to a certain platform or technology that you shouldn't consider making a change.  Or you paid too much money for it etc. One great example of too big of a sunk cost to change was  probably Duke Nukem Forever. There were several times they should have finished what they started.   Being as I'm only in my 3rd week here the risk is extremely low.

Barrier 2 "Technology growing pains" : Again here I felt the risk was relatively low. I've been using Unity for less than a year and I had used Unreal in the past for some modding. I  decided to replicate the work I've done so far in the Unreal engine and it only took two evenings to get this new shot you see below.

It looks really nice if I don't say so myself!

So I've created a screenshot comparison between the Unity version and the Unreal version -- the only thing I'm missing is the wall sconce with fire sprite.  Also I didn't align all the textures exactly the same I can see now.

Hopefully for next week I can get the torch/fire in and then have a better aligned comparison and talk about my findings and if  I'll be making the switch or not!

The Rise of Dagon : Week of May 3rd devblog

It's been a really busy and productive week for me working on The Rise of Dagon!  I actually had to pick and choose my images to share and made some combined shots to I wasn't uploading 15 images or so :-)

So the first update is with the sculpting challenges I had last week I decided that I should definitely explore some other options.  One of the items really high on my 'must use' list is Substance Designer which I picked up on Steam sale 50% this last Christmas.

So I had purchased a very nice texture from the Unity 3D Asset store and brought it in to Substance Designer.

In here I am still very much a newbie with this tool but I was able to put together a basic substance, and add some grunge to the surface.  Once I was happy I then exported the substance file and as you see in the screenshot here I have some parameterized values I can use to adjust this substance in game.

Obviously as I learn the tool better I should get a lot more parameters to adjust but this was a really satisfying first use; and was not too difficult.

So next up we have a new dungeon door I created in Silo2.  I then used the texture I had modified in Substance Designer and tiled it, adjusted the parameters and came up with a very satisfying looking wall/arch texture.