I did it again. I didn't post on Friday. I know why now. It's because I work remotely on Fridays and I end up getting distracted doing other stuff. When I'm in the office I don't have those distractions. Therefore, I think I am just going to post Mondays and Wednesdays from now on. Those days seem to work best for me. Anyway, I've worked on some stuff since the last post. I learned how to model, rig, and animate using Blender! Now I'm no character artist. My modeling skills suck, but I thought it would be good to learn this stuff so I could make some simple assets and animations for my game. I followed this awesome tutorial and got some pretty good results.

If you didn't know already, inverse kinematics is the greatest thing ever. It was so helpful for posing and animating. I know that it's really great for other things too, like getting a character's hands and feet to be placed correctly on the ground, etc. By the way, if you haven't seen it, I really recommend watching this GDC talk video on the game, 'Overgrowth'. He mentions using inverse kinematics for his character and I am still blown away by the way he sets up his character animation and movement. 

It's going to be hard to make any progress on the actual game and mechanics until I can figure out how to put Unreal Engine on my external hard drive. It's a long story. I'll try to get that done and give an update on Wednesday.

Remember how I said I wouldn't plan out Wizbiz and just add a bunch of mechanics instead? Forget that. I've thought about it a bit and I have an idea of what I want Wizbiz to become. My idea is to make a hardcore survival game based around magic. I'm imagining something akin to Factorio, except it's First-Person 3D and you would use spells to automate instead of machines. You might use some simple tools to start off, but you would progress and get spells and magical items to replace your tools.

I've actually been getting pretty excited at the idea of making this game, which is a good sign. I think the next step right now is to make a simple game design document and plan out how the base progression system will go down. Making this game in Unreal is going to be challenging for sure, but I know that as long as I keep at it consistently, I will have something awesome to show for it. I'll keep this blog updated with my progress.

Ok yeah, I know, I screwed up. I didn't post on Friday. I don't have an excuse, but if I said I started a game project would that make things better? I'm calling it Wizbiz. Short for wizard business. I don't have much of a plan right now. I'm just going to implement stuff and decide what to turn it into along the way. It's a horrible strategy, but I don't really want to spend time trying to decide what the game is going to be. Currently I am working on implementing wall jumping for the player. I'll give an update when I get it working. Wish me luck!

I didn't get very far in the tutorial today, not because I was slow or distracted, but because I took a deep dive into the material I was learning. I was Googling stuff, I was reading Wiki's, I think I reached stack overflow levels at some point. It was pretty intense.

I think I have a handle on it now. Mind you, this only took like an hour because I don't have a lot of time in my day, but it was a pretty productive hour. So, the first thing I learned was about making custom functions callable from Blueprints so that the designers can access them and screw around with it, do what designers do. Yada yada. I do like being able to control what the designer can do, though. It's like having parental controls in Unreal. I could make a actor string property that just says, "Delete this please" and make it read only to mess with them. Anyway, I'm off topic. You can create custom functions that can be called with Blueprints by adding the UFUNCTION() macro the line before the declaration of the function. Handy stuff. I also learned about overriding functions, which I did not know much about before. I had heard it mentioned plenty of times in school, but never really needed it. So when my teachers were talking about it in class, I just nodded my head like I understood. I didn't.

This is where the Googling and Wikipedia-ing came into play. I did some research and found out that overriding functions deals with inheritance. With inheritance, you can have a parent class and a child class that both have a function with the same name. The way I understand it is that when you call the function with that name, the child class's function automatically overrides the parent class's function and the child class's function is used. You can get around this by calling the parent class's function within the child class's function using the '::' operator. Like I said, I didn't get through much, yet I learned a lot. Hopefully I will make a little more progress on Friday, but the tutorial said that things will only go deeper from here. This worries me. Wish me luck.

I went through about 1/3 of the C++ Introduction Tutorial today, and I have already learned a ton. I learned about header files and how you can expose properties to the editor from there. I learned about the different ways to expose variables to the editor. For example, you could use the 'VisibleAnywhere' specifier to mark the property as viewable but not editable in the Unreal Editor, and the 'Transient' specifier means that it won't be saved or loaded from disk. I also learned about the 'PostInitProperties' call chain which can be used to update the default values at runtime. Right now, you might be thinking, "Why did you just tell me all of that when you linked the tutorial in the previous post and I could just look at it myself? Idiot."

I'm gonna be honest, I didn't do a whole lot of learning today. I mean, I went through a couple guides(Rendering Overview and Atmospheric Fog User Guide), but most of today's session was spent figuring out which tutorials/guides I am going to go through next. My initial thinking was that I would just do them in order from top to bottom, but that idea went out the window as soon as I saw that the first guides were about rendering and atmospheric fog. I realized that if I want to be a gameplay programmer, I should learn programming first. I can tinker with the rendering or whatever else I want after I've learned how to code for Unreal. 

So the next guide I will follow will be the Introduction to C++ Programming in UE4. It's a pretty long one and I don't have any time to go through it tonight, but you best believe that when Monday comes around, ya boi gonna gain some KNOWLEDGE. Anyway, it's getting pretty late and I need to get up early tomorrow to play some Pokemon Go. See you Monday!

I know it's still early on, but I can already tell that doing this every day will be next to impossible. I'm not giving up though!! I'm just going to tweak the schedule a bit. I have recently started going to the gym on Monday, Wednesday, and Friday after work. After my workout, there isn't much time to do anything else before I need to go to bed, so I will dedicate that time to doing this. This means that on Tuesdays and Thursday I can just

By the way, today is Thursday, so I'm gonna go do that! See you tomorrow!

Today I went through the Unreal Engine 4 for Unity Developers guide. It was pretty helpful, especially the 'Quick Glossary'. 

The first half of the guide was more helpful as it listed Unity terms and components and posted side by side comparisons of the Unreal equivalents (or the closest thing to it). The second half of the guide was not as useful, however. At least not right now. It compared code functions and libraries, which I'm sure would be helpful to some, but I can't just take one look at that and remember how to do everything. I'm much more of a hands on learner.  Overall, it's a pretty handy guide. I probably should have started with this.

I attempted the Programming Quick Start Guide today. It went pretty well, but I was only able to complete 4 out of the 5 steps. The first 4 steps are instructions that were very easy to follow, and I was even able to mostly understand the code while I was writing it. I knew that when they introduced the Sin function that I was going to be making an object move in a wave-like motion. However, I was stumped at step 5. It is a DIY step, where I was supposed to add a particle system to the actor that I was scripting for. This had me stumped. I have no experience with the referencing particle systems, or anything else in UE4/C++ for that matter. I will need to do some research and come back to it. 

I began going through the Unreal tutorials yesterday. I made it through the entire Level Designer Quick Start Guide. I have used Unreal before and have a basic knowledge of it, so most of this stuff I knew already. However, attempting to change the lighting from day to moonlit night proved to be challenging for me.

This was a good start, but I am already itching to get into the programming side of things. I'll try to be patient.