Crate

Every game needs scene filler, and crates happen to be pretty good at that, so I made one.

Oh how lovely, ye crate of mine.

I’m also going to try and build assets from now on that are scaled as correctly as possible.  It just saves work later on if I don’t have to change the scale of things with the engine.  Here’s the crate next to a 2 meter tall character reference.

Crate with a 2 meter tall character reference

So now that I have that pesky “no crates” problem solved, the rest of this project should just fall right into place.

World chunks

Lyridia has the potential to be a very big place.  Of course, it may never get very big if I don’t actually create the assets to fill it up, but since I’m developing the world and the game iteratively I don’t don’t want to discover down the road that I’ve set my sights too low.  I’m basing the world on square chunks of terrain.  Each of these chunks is 500 meters x 500 meters.  My intended “starting area” chunk is at (100, 100).  Assuming this chunk is the center of the world, that makes the world 200 chunks x 200 chunks, or 100,000 m x 100,000 m.  That’s 10,000,000,000 sq meters, or about 3,800 sq miles.  That’s bigger than Delaware, but smaller than Connecticut.  So pretty big.

Everything is being modeled in and exported from Blender.  Since each chunk is 1/4 of a square kilometer and a bunch of stuff will fit into such a large area, I won’t have a massive number of files to keep up with unless the game truly does get enormous.  Having larger chunks also means it’s somewhat easier to keep the terrain lined up at the transitions between chunks.  Why not just model each area as a separate huge Blender file?  Performance and bandwidth.  With (somewhat) smaller chunks I can load the area around the player dynamically and unload stuff that’s too far away to see.  Hopefully this will mean the game will run more smoothly on less powerful hardware.  It will also hopefully save on bandwidth.  If the game only requests assets the player is relatively close to, the server(s) won’t be wasting resources serving up things for no reason.  If the world assets were stored on a disk locally, who cares?  It’s cheap and fast to load from a local disk, so if a game loads up a big fancy model that the player can’t even see it’s not that much wasted.  But since there’s no local disk here, every asset that gets downloaded counts.

I’m continuing to work on the “Penrith Forest” area.  So far I have a farmhouse, some trees, some fencing, a wheelbarrow, some lamp posts, and a simple terrain.  This is intended to be the area where all players start the game.  I need a basic development schedule, mostly so I’ll have self-imposed deadlines to fail.  Somehow life just isn’t the same if you’re not constantly failing yourself, so look forward to that soon.  The schedule, that is, not “constantly failing yourself.”

Wheelbarrow

Here’s a wheelbarrow:

My thought at this point is to make all assets in Lyridia very low polygon, flat shaded, and with no textures.  This keeps the asset file sizes very small and will hopefully mean lower bandwidth requirements and that the game will run on less powerful hardware.  This wheelbarrow, exported to BabylonJS‘s export format, is only 13 KB.

The general style of this wheelbarrow is what I’m going for with the whole game.  Hopefully it’s a style that works.

 

I’m Back!

After a fairly lengthy absence I’m back to developing!  This time around I’m setting my sights a little higher and hopefully that means that as I progress I’ll start seeing something I’m actually proud to show others.  The idea this time around is a basic MMORPG, but one that is playable entirely in a modern browser with no plugins, downloads, or other weirdness.  I’m not even 100% sure this is technically feasible, but I believe it is as long as the game is scoped appropriately.  I’ll be using BabylonJS (and eventually Node.js for the server side) so I’ll post here with my adventures learning these two frameworks.  I’ve already found BabylonJS to be pleasantly powerful but frustratingly quirky at times.  When I find confusing or frustrating parts of this framework I’ll post about it here as a resource for others, but also as a way to force myself to learn.

My goal is to post here at least once a week, even if I don’t have much to report, so stay tuned.