An update

 Apologies about the absence and my lack of attention to this platform to those three or five of you who have actually read all of my posts. I realized that I needed to refactor large parts of my game recently, so I started over from scratch with an entirely new project (in the sense that a single "game" is called a "project" in Unreal parlance; I'm not abandoning Caravanserai), and my mental health took a bit of a hit recently.

I've got some free time tonight, so I think I'll walk through another blueprint in my next post.

More modeling

I've been trying to figure out animating in Unreal and it's breaking my brain, so I need a break. Instead, I'm going to model a creature that will be easy to stumble upon early in the game, so I thought it might be interesting to show my process.

I've started with the humble cube, our morrowind mesh, and a reference drawing. The thing I'm modeling is going to be a big hulking monster, so I'm going to use this turnaround of a space marine in terminator (aka tactical dreadnought) armor from Warhammer 40k (credit to Ted Beargeon).

It looks like the easiest way to give our cube some shape is going to be by using the side view. I'm going to start by moving the faces of the cube to just encapsulate the space marine. Then, I'll add a few loop cuts, which will give me vertices that I can use to shape the cube and roughly outline the terminator's silhouette.

Since the apex of the terminator armor is a point, I need to merge some vertices on the top of my cube. I need to make sure that I don't merge all four of them into one point, however., so I'm going to step out of orthographic view and merge the pairs one at a time.

At this point, I've shaped the cube down to about the space marine's groin, so I'm going to stop here because I'm either going to make the legs out of separate meshes, or I'm going to need to be looking at a front or back view to start dealing with the fact that they're not connected past this point.

You probably know what's next at this point: loop cut down the center (sagittal plane), delete the vertices on one of the halves, add a mirror modifier.

Another thing I should mention, too, is that when you're starting out with your primitive, don't move it or manipulate it in Object mode. The first reason is that you'll move the object's origin. I think it's a good practice to have the origin always be at 0,0,0, so you know that when you add a mesh to Unreal that the bottom will always be at ground level. The other reason is that it will change the transform values, which isn't a huge deal because you can always apply them later, but it's one less thing to worry about when it comes time to setting up your export.

Anyways, here is our monster from the front view. I'm actually going to use the back view of the space marine, since it's a little easier to see what's going on. I'll at least rough out the shape now.

We're looking pretty good at this point; however, this is where I'd normally start using a top-down view to make everything look less like a block. I'll have to get creative and do my best. Also, his legs are looking a little bit too thick, so we'll scale those down. Since I can't get a top-down reference, I'll stop working in orthographic mode so I can see what sort of shape I'm creating as I go.

I've used a lot ofShift+Alt+S on him, which, thankfully, I was able to do because all the latitudinal lines I cut into him stayed nice and straight. With shade smooth on, he's looking pretty good. 

I think that what I'm going to do is take that vertex that's really protruding out the side of his abdomen and bevel it. Not an edge bevel, but a vertex bevel. Depending on how many segments you use, it turns a vertex into several faces. Here it is with just 1 segment:

Here it is with 2:

Since this is where his arm starts, I'm going to go with 1 segment. This square-shaped face will give me a better place to start.

[One hour later...]

Here's what our guy's base mesh looks like:

And here's what he looks like with a Subdivision Surface modifier with the Catmull-Clark setting on, plus a Simple one:

All in all, I'm pleased. Maybe next time we'll work on his head.

Trees

 I remember that when I made my first abortive attempt at Caravanserai a couple years ago, one of the first things I tried modeling was an olive tree. It didn't turn out too well, but I barely knew my way around Blender yet. I worked on that tree for a good long while, too.

Today, I modeled a mastic tree, the source of mastic gum and mastic resin, which are used throughout the Middle East as flavoring agents, often for sweets, such as Turkish delight (although my favorite flavor of loukoumi is rose).

The Number 1 secret to a good model is to work with a good reference. Mastic trees have this characteristic curving, twirling habit, so I wanted a reference that really exemplified that. This is the one I ended up using:

|
Once you have your reference, save it to your computer (I keep a references folder for each .blend file I have for organization). Then, in Blender, go to Add > Images > Reference and navigate to where you've saved the image.

The second key to a good model is working at the appropriate scale. imported the Morrowind Tri_Shadow mesh so I could tell how big to make the model. This looks like about how big I want it to be.

For trees, I like to start with a cylinder. Another trick that I use is that I make sure all my models have geometry down to -1 meter. That way (as long as the origin is at 0,0,0) you don't have to worry about placing the model on level ground when it comes into Unreal.

Take the top of the cylinder and, in X-Ray mode, scale it be the correct width of the tree based on your reference image. Then just extrude it to another segment, scale it, rotate, etc. When you get to a point where the trunk branches, merge the vertices on the top of the cylinder.

Now, take half of the faces to match up with the way one branch goes and make them spherical. To do this you can go to Mesh > Transform > To Sphere, or you can hit Alt+Shift+S. When you're done, you'll have this funky shape (or something like it):

Grab all of the faces on one of the "spheres," rotate it and move it around a little bit to match up with the branch in the background, then extrude it. Follow the branch in the reference image until you reach the end. If you lose the branch in the foliage, don't worry about it too much. You can keep going using your intuition or just end it there.

When you get to the end of this process, you're probably going to find that your tree doesn't have a lot of dimension, because you've been tracing a two-dimensional image. 

One relatively easy (and fun!) way to fix this is to add an armature. Once you've done that, you can go into pose mode and move the branches around to give your model more of an arboreal shape. You can even duplicate your mesh at this stage and make multiple poses for more variety in your trees.

For the foliage, I like to start with icospheres, since they don't get much play otherwise. I also like to make them as separate objects, that way we can set the foliage to have no collision if we want. Just move the vertices around until you've got a shape approximating the foliage. I like to do this with a little proportional editing turned on, using the round shape. Sometimes I do a couple of passes of randomizing the vertices and then smoothing them back out to make the shape a little more chaotic. Just make sure that your foliage object covers up the tips of the branches.

If you are going to have no collision on your foliage object, select the whole thing, duplicate it, split it, flip the normals and scale it in a little bit. This way, you'll have a copy of the shape on the inside with normals that face inside, so if the player ever goes inside of the foliage, they'll still see it.

The last important thing to do in order to get a good result is to have fun with it. Try things out, add a modifier, turn on proportional editing. And, if you're doing low poly like me, don't sweat the finer details too much.

Another screenshot

I've been pretty busy scripting stuff in blueprint so I've done much modeling in Blender or anything lately, but I added a couple more landscape components in anticipation of setting to work on combat. In the mean time, I leave you with this screenshot of the caravanserai, looking west from the top of a large switchback.

Edit: And in case anyone's paying attention, here's a screenshot of what the whole world map looks like at the moment

Books

One of the things that makes the Elder Scrolls game unique is the inclusion of readable items: books, notes, etc., and it is something that I am absolutely going to replicate. So I've been working on that today and yesterday. But one thing that I want to do is make some things not immediately readable. 

I haven't talked much about the setting or the lore, but the World Basin is dominated at its center by a city called Urrum, the World-City. Hence the name of the ancient language that was spoken in the area, Urrumi.

So, in the game, if you find something that is written in Ancient Urrumi, you can't read it. Well, I can't, but maybe you can. But if you have a piece of paper and a piece of charcoal, you can take a rubbing of it, bring it to an NPC and they'll translate it for you. Like I said before, Archaeology!

I'd been putting off actually making the text system because I want Ancient Urrumi to have its own alphabet. Despite being a linguist and having an interest in worldbuilding, I'm not into conlangs and stuff. There are enough cool real languages that I don't want to waste my time making fake ones. Unfortunately, that means that I have no experience trying to create an alphabet. I gave it a couple goes in my notebook (Old Blacky), but I wasn't happy with any of the results.

Then, as if in answer, I woke up yesterday morning and saw this on Reddit:

That's it! That is what Ancient Urrumi looks like.

In order to get something usable out of it, I went to Calligraphr, a free font making website. To use Calligraphr, you select the language you want to make a font for and it spits out a template that looks like this:

They tell you to print it and write in the squares with your own custom characters, but I don't have a printer. I took this and loaded it into GIMP, as I also did with the photo. I used the fuzzy select tool to copy and paste the characters from the photo into the template, scale them and arrange them in the boxes. Then I took my filled-out template and plugged it back into Calligraphr, which spit out a TTF file and an OTF file with my font.

I loaded that into Unreal as a Font object (under User Interface when you go to add a new Blueprint class in the Content Drawer). This allows me to use this font in any text objects in my widgets. I'll go over the way that the blueprint for texts works at some point, but for right now, I'll show you that I also added a new nametag widget for when the player looks at an object in the world, like a statue or a sign, that is in Ancient Urrumi.

Morrowind animation files

 I finally got a plugin for Blender that lets me open .nif files, which is the format that Morrowind uses for all its meshes (and animations?). I've been looking around the data files folders and found this guy:

I have tried and struggled with and failed to model a human basemesh reminiscent of Morrowind's. My attempts were based around using screenshots of the game to try to approximate the proportions, but my efforts were all doomed. I'm glad to finally have something I can use as a rough reference to ape the style. This is actually the mesh that is used to cast shadows of humanoids in the game; the actual meshes that comprise the characters you can see seem to be built out of pieces (head, hair, left upper arm, right upper arm, etc.) But this is where I want to start.

But I found something actually interesting that I've never heard of before. I can't be sure of this, because I have Tamriel Rebuilt installed and that might be where these come from, but it seems that there were some animations in the base game that didn't make it into the finished product. If you go to Data Files > Meshes > AM > II, there's a couple dozen files in there with names like AM_SitBar, Cleaner, Bandit,  and FarmerScythe. When I first came across these, I didn't know what they were, and when I first opened one up, it was not any clearer.

They all look something like this:

The rounded shape in the middle is the shadow casting mesh ("Tri Shadow"), and all of the boxes correspond to body parts. I'm guessing that this is what a character is before runtime and each of these boxes gets swapped out with the appropriate mesh based on variables inside the character. Interesting to see exactly how the game handles all of the modularity in armor and equipment, as well as faces and hair. But what's even more interesting is what happens when you hit the space bar.

As alive as Morrowind already feels to those of us who love the game, it could have had even more verisimilitude. 

And, holy shit, check out this guy (the file name is "Camonna.nif"):

Unless I am completely misremembering the game, I don't think these appear anywhere in it. Someone needs to correct me if this actually is in Tamriel Rebuilt, and also let me know if this is already common knowledge, but I've never seen or heard of it before.

Caravanserai, what is it?

Caravanserai is my attempt to build a video game, but fundamentally, I'm trying to share something with the world. The land depicted in this game (the World Basin) is a place that has been living and growing in my head for over four years now. It's a love letter to the cultures and countries that fascinate me, and a homage the media that I love, from The Elder Scrolls III: Morrowind to HBO's Raised by Wolves.

I don't want to promise a lot, because I know how most of these things go, but I intend for this game to be a little unlike most games of the genre. I'm honestly not even sure I'm going to include a main storyline (gasp!). So much of Caravanserai has been a process of discovering it's secrets through the strange and wonderful places that dot its landscape. And yes, the creation of this world has been very much a process of uncovering it as much as it has been designing it.

Have you heard of the Three Pillars of Play, the idea that a roleplaying game is held up by combat, exploration, and social interaction? Many people have their own ideas about what a fourth or even fifth pillar would be. My own is that it would be archaeology. The best game of D&D I ever played in was focused immensely on the history of the world, the dungeons we were delving into, and the treasures we were extracting from them. When the game started, there were some legendary figures in the distant past, but as the game wore on, we came into the possession of deeper knowledge about them, located their lost cities, their tombs, their temples. The world of Caravanserai inherits this sensibility.

Anyways, look at this spaghetti!

That's the inventory system (which I'm trying to model after Morrowind's as best I can).

There's more code elsewhere that handles opening up the window and pausing the game and such. This is mostly just the creation of the item slots (i.e., widgets).

It works like this:

• The first thing it does is clear all of its children (get rid of any inventory slots currently attached to it). If you don't do this, then every time you open the widget, all of items that were in your inventory the last time you opened it will still be there. We don't want an item duplication glitch that is that easy to pull off.
  
  
  
• Then it looks up every item in the inventory (this might get confusing). So, this is the inventory widget that displays what items we have, but we actually store the information about what items we have in a different blueprint (specifically, the Game Instance, since it persists across levels). That information is in the form of a map variable (which is basically just a dictionary, if you know any coding). It's a list of unique keys, each one of which is associated with some value. My inventory variable uses four-digit Name variables for the keys, and the values are Integers that tell us how many of each item we have. You can think of it as being structured like this:
  
• I run each key through a For Each Loop. So for each item I put into this loop, it does something to it. This is where things get crazy.
  
• We use the key to pull up a row in our Item Data Table. Each row is named after a key and holds the corresponding information about the item that has that key. Right now, key 0000 is assigned to my Test Item, which is just a dummy I'm using to make sure the system works. The row in the data table is where I get information about the item like whether it's stackable, what its stack size is, etc. I also take the Value and use it to set a variable called InventoryItemCount, because I need to count how many item widgets of a given item I've already created. I could decrement the Value itself 
• Next, I take the Value associated with whatever Key I'm on and run some checks on it. First thing I do is determine whether the number of the item I have is greater than zero. After that, we check to see if it's stackable. If it is, I check to see whether we have a full stack or more.
  

  
• Then I do all this. Depending on which category the item falls into (stackable and we have a full stack, stackable but no full stack, not stackable), we create the item widget and attach it to the inventory grid. If it's stackable but we don't have a full stack, I also include the number of the item in the corner of the widget. If it's not stackable, I just create the item and attach it. In all cases, I then decrement the number of item we have left by the appropriate amount, before adding 1 to the variable that keeps track of how many slots we have and finally looping it back to check whether the number of item we have left is still greater than zero. The stackable with a full stack branch is interesting (to me at least).

  

  
  What I did was decide that, since I know I have a full stack, I decrement the amount of item I just decrement it and label it using the stack size variable instead of the variable in the inventory map. Okay, not that interesting, but it took me a minute to figure out.
  

There you have it. That is the most complicated blueprint that I have figured out how to make on my own without following a tutorial.