The Great Gif Exchange, Week 7 (+SURPRISE)

Here’s my .Gif for week 7:

I got the ProceduralMeshComponent from the wiki to work. I didn’t quite figure out how to get reliable collisions (weird things where chunks spawned in the editor didn’t line up etc.).

I will have to redo my texturing scheme, because Marching Cubes doesn’t work with just UV coordinates. I’m thinking I need to use triplanar texturing, so I’m going to have to figure out how to do that.

I couldn’t for the life of me get movement to work how I wanted. I really need to drain some time into that so that I can actually have something game-y.

BONUS! World Tree Design Doc

Here’s my cut-and-pasted notes on how I am going to design the world representation for AI:

For the large scale AI, everything is in a tree. Something like this:

  • world
    • region
      • town
        • building
          • person
            • merchant
              • item
                • food
                  • bread
                    • steal
                    • buy
                    • pay 10 money
                    • trade
                • building materials
              • job
                • money
                  • get money
            • cannibalism
              • food
        • building
          • person
            • blacksmith
              • item
              • job
              • employ
            • cannibalism
              • food

Every node has difficulty associated with it, which can be relative to the agent searching the tree (e.g. thieves are open to stealing, cannibals don’t care about eating people, species tend to do things certain ways etc.).

By representing the entire problem like this, it becomes so much simpler. Just fill in all the nodes, plug in A*, build actions from path, and you’re done (obviously, this is still going to be fucking hard).

Agents could think about the future by having surplus as an additional heuristic on nodes, so they’ll buy more food than they need in order to not get hungry all the time.

Anyways, I’m super excited about this, because it breaks down the problem really well. It’ll take work, but I want to make it so that voxel data isn’t required for low LOD AI simulation. The AI would only use the tree for their position/actions. This would be huge in terms of memory and performance savings. However, converting from low LOD to high LOD when the player gets near could be difficult (e.g. if the AI “built” something in low LOD, it may not have been possible to build that thing in high LOD).

Advertisements

The Great Gif Exchange, Week 5

My Gif for Week 5 of the Great Game Dev Gif Exchange:

This is four separate chunks updating in real time in the editor. Their editor position determines the position of noise. This is shown when I move it slightly, showing that the (noise) world stays the same, but visual surface representation changes.

I really wanted to get chunk spawning working so that I would have an infinite/very big world, but I got stuck on Unreal’s SpawnActor function and trying to get code Autocomplete to work.

I didn’t know Gfycat limited my videos to 15 seconds until just after I made this Gif, which is why it cuts off at the end.

The Great Gif Exchange, Week 4

After two consecutive weeks of failure (no .gif), I have broken my streak.

Here’s my Game Dev Gif Exchange .gif for week 4:

In case you missed my last post, a coworker and I have challenged each other to create a .gif each week showing progress we made on our games. This is so we’re both held accountable for weeks that we slack off.

I’ve done poorly thus far, but I’m going to get better.

What the .Gif is Demonstrating

My .gif production values weren’t high because it was getting late.

You’re seeing the default Unreal character falling through two chunks of voxel terrain. They’re generated with a 2D simplex noise heightmap. He falls through because I haven’t figured out how to get collision hooked up.

Theoretically, they’re position sensitive, so where ever I put the object in the editor, the noise will be picked for that position (so if they’re the right distance away, it’ll be seamless).

I say “theoretically” because it was getting late and I didn’t have time to actually line them up and see if the right noise was being picked.

I used Marching cubes for surface extraction, which is why there are 45 degree angles instead of blocks. If I copied over the normals from PolyVox the terrain would look smooth (and if I increased the voxel resolution).

Behind the scenes, I’m linking to Galavant’s third party wrapper to get noise for the chunks. The wrapper is built by Jam and put in a static library, which Unreal then links to.

On Build Systems, Visual Aesthetic, and Other Terrors

First of all, sorry for the stupid title.

A coworker and friend of mine realized that our progress on our personal projects has been abysmal. Said coworker came up with a challenge to exchange one .gif every Friday showing the progress we made on our games. Gifs are more exciting than screenshots (a la reddit /r/gamedev’s Screenshot Saturday), which makes the challenge more exciting.

Anyways, here is my .gif for the very first week :

It’s pretty shitty, but an important submission nonetheless. This is me dropping an Unreal Actor into the editor. This runs my own C++ code which uses PolyVox to generate a 3D voxel mesh. Yes, I’ve decided to go with 3D voxel, which brings us to the first part of this post: Visuals.

Visual Aesthetic

Now, one thing that I’ve been struggling with since Galavant’s inception (as Horizon), is what Galavant will look like visually. 2D, 3D, top down, first person, parallel, isometric, and the list goes on. I think I’ve made up my mind to use 3D top down voxels with Marching Cubes.

Because the view is top down, I don’t have to go to any extents to make LOD or far views possible. Top down should have less demand for high performance as a result of this. I don’t want the rendering to take too much time because I want to focus on simulation.

I am using voxels because building and a large procedural world are essential to my vision for Galavant. Marching Cubes is an algorithm that generates a smooth mesh for voxels. I don’t want my game to look like Minecraft, especially because of the amount of terrible games that have the same aesthetic.

Because of my unique view, I have done some research to find games that employ a similar style. I’m going to dump it here so you can get some idea of what I might be going for.

This video showcases the 3D top-down perspective with voxels:

I also plan on having a similar technique of fading the roof/things blocking the player once they go indoors. Note that I’m not going for the blocky look (at least, not for terrain).

Here’s another 3D top down voxel game:

I think the controls in Galavant will be twin-stick style, like the .gif above.

Here’s a 3D top-down game which almost exclusively uses billboarding (which I like):

An isometric 3D tile-based game:

Another top down 3D voxel game (remember, I’m not going for the blocky look for organic things):

An example of a pretty 3D top-down shooter:

A 3D top down low-poly Crossy Road aesthetic:

Mix between hard-edged building and Marching Cubes terrain:

I’m not going for a photorealistic look like this game, although I am going for smooth terrain plus voxel building.

Another 3D top down voxel game:

All they need to do to make that game look way more enjoyable is make everything five times faster…

This is a really interesting voxel game:

What’s interesting about this is that I believe they are using Marching Cubes, but in order to get the blocky look as well as nice slopes, everything you place is actually four voxels rather than one. I think I will likely do something very similar for Galavant.

They go a little overboard, but I do like their post processing shaders. I don’t think I could manage their hi-fi textures, though.

It’s also interesting how they add a bit of noise at mesh generation level so that the world isn’t a perfect grid. It gives it a Sly Cooper-type look to it that I like.

Here is good looking low poly terrain:

I like the overall aesthetic of this, although it’s a little too indie/artsy for Galavant:

Steven’s Sausage Roll has a 3D top down view with blocky, noisy tiles:

Traverse MMO has a gorgeous low-poly aesthetic:

I do like the vignetting; it’s a little too heavy in these screenshots, but I still want some in Galavant.

Technical

If you guys actually read and enjoy my posts, I know you like the dirty technical details.

Unreal Engine

I’ve decided to use Unreal as a frontend (more on that later) because I believe it has the least amount of effort to go from zero to triangles on the screen. I likely will not be using Unreal’s physics, logic, etc.

I learned about how to link external libraries in Unreal’s build system, which was a massive pain in the ass, both because the documentation is lacking, and because I’m on Ubuntu (mostly undocumented). Galavant is going to be an external library, so this is important to know how to do.

Frontend/Backend: The Grand Construction of Galavant

I plan on using a somewhat novel project construction for Galavant. It’s important to me to have Galavant available for as many platforms as possible. In order to accomplish this, Galavant itself is going to be a platform independent library. This library (called the “backend”) references wrapper functions for everything from threading to sound and graphics. The “frontend” must provide all of these wrapper functions with implementations. I plan on using Unreal as the first frontend for Galavant, but I am going to make it as easy and as straightforward as possible to make new frontends.

One very interesting idea is making a LibRetro frontend. LibRetro itself is designed for this strong separation, so making a LibRetro frontend for Galavant immediately makes Galavant work on all LibRetro frontends (like RetroArch). I could directly use LibRetro as the abstraction layer of Galavant, but I don’t want to rely on any external libraries within Galavant (this includes the STL).

Build Systems

Another thing I’ve struggled with is the build system. Previously, makefiles were my go-to on both Horizon and Base2.0. If you read Horizon’s and Base2.0’s makefiles, you’ll see they sucked. A lot. Now, to be fair, I was somewhat using them incorrectly because I couldn’t figure out how to automatically generate dependencies.

Late in Horizon’s life, I decided to switch over to using Code::Blocks project files to build Horizon. However, I cannot stand doing text editing in Code::Blocks (Sublime Text is simply too good), and adding files is painful.

Sublime Text has a mechanism to add Build Systems, which is awesome, powerful, and customizable, but requires a makefile-like thing to actually do the work.

I asked my coworkers what they recommended, and Jam came up. The side-by-side comparison on the introduction page between Jamfiles and Makefiles instantly sold me on Jam. They’re platform agnostic, simple, and straightforward. Within a couple of hours, I got them working on a few of my test projects in Galavant, and I’ve been won over.

The Near (-ish) Future

For the near future of Galavant I will be working on the lowest of the low – getting a solid build system workflow set up, creating the abstraction layer for threading, debugging, performance, and other essential features, and thinking more about how to proceed with the large scale engine design.

I will likely also be experimenting with Unreal on the side. You can check out my Twitch.tv channel for past dev live stream shit if I remember to turn it on here and there.

My last broadcast showed me experimenting with voxels in Unreal:

https://player.twitch.tv/?video=v61092134Watch live video from makuto9 on www.twitch.tv

That’s all for now; hopefully, I didn’t bore you to death.

Then Life Hits…

It’s obviously been another large span of time without any activity.

It’s incredibly difficult to even think about writing code after coming home from and 8 hour day at work, writing code. That’s my excuse.

What have I been up to? I built a new PC, and  here are the specs:

  • MSI GTX 970 TI GPU
  • Intel Skylake i5-6600k 3.5ghz processor
  • 32gb Corsair Vengeance RAM
  • 120gb SSD, 1/2 Windows 10, 1/2 Ubuntu 15.10
  • 1tb Ubuntu /home
  • 2tb Windows+Ubuntu shared

Having this new machine will (hopefully) motivate me to do more work. I am used to the large monitors I have at work, so the next step is going to be buying nice monitors.

I have renamed Horizon to Galavant. This is for two reasons. One, a new game called Horizon was released recently, and two, Galavant won’t use any code written specifically for Horizon. It’s essentially a complete restart.

“So, Galavant, how is that going?”

Well, I haven’t made any progress really, although several ideas have been stewing. I think I have figured out Galavant’s file I/O and procedural generation system architecture.

I’ve never worked on multithreaded code, but I plan on making Galavant multithreaded. There will be a main render/high priority simulation thread, a low priority simulation thread (to handle those thousand AIs being simulated miles away from you), and a Generation/File IO thread (to handle all I/O, whether from a network, file on disk, sqlite3 database, or mathematical space). I think this is a fairly clean architecture that will allow me to use the parallel power to make Galavant a reality.

The Object-Component system is probably going to need a rework – both because of this new architecture, and because it is currently not very good. It was the first code I wrote for Galavant, and I’ve already buggered it up.

images.akamai.steamusercontent.com
Screenshot from Delver, available on Steam. Similar visual style to what I might want Galavant to have.

I’ve once again got locked up on the problem of how to visually represent Galavant’s worlds. For initial development, I plan on using very basic 2D topdown tile-based graphics, but once I get the low-level structure implemented, the decision will have to be made on whether or not I’m going to stay 2d, go 2d parallel, or full 3d (likely with similar style to DOOM – billboarded sprites in a mostly flat world). This is important both because of game design as well as production (how will I make art?).

Anyways, that’s the update. Thanks for reading my rambling.

Re:Horizon

Obviously, this blog is utterly dead. I, however, plan on changing that.

Job

First things first: I have massive news: I got hired in the game industry! I’m a Junior-level Gameplay Programmer (with a capital P!). This has been a huge benefit to me because A) I’ve learnt so much already and B) I now have money! I’m going to opt out of telling you where I work for liability reasons (do some digging and you can find out easily enough).

The bad thing about working full time in the industry is that it is now quite difficult for me to find motivation to work on my games. After a good eight-hour day programming, I’m pretty coded-out. Horizon (the game of my dreams) is still calling, like it has since November 2014, so I still yearn for it.

To give you an idea of my development process, I generally just do nothing until I feel the urge strong enough, then do a significant amount of work. I find this to be the most maintainable for me because I don’t have to pressure myself too much. This is NOT a good development process because I will never get anything done. Once I get used to working full-time, I will try to make myself more productive while not getting burnt out.

Problems

Horizon has had very sparse development since around the time I was graduating high school. I was focusing more on my short-term future (sending resumes, having existential crises, etc.). Additionally, I have realized that I did not design Horizon very well at all on the code front. I did not put enough thought into my Object design, which meant a very large amount of friction if I wanted to create new Objects (i.e. do anything useful). After getting some advice from my coworker on the subject, I have redesigned the Object system to be heavily Component-based. I am very confident that this is the proper choice and that it will speed up development times.

Realizing my Object system was poorly implemented revealed to me that many of my other systems were also shabby. For example, the World should not know anything about Objects, and Objects should not know anything about the World. In its current state, I have collision and movement code in Object!

Another large problem with the code is that the World is tied to rendering. I have thought about solving that problem, and think that the World should only store gameplay data about the World. Renderers (notice the plural, meaning possibly many!) will have the burden of deciding how to display the data. This decouples the two components in such a way that A) Components can do all sorts of things to world without needing to have spritesheet tile coordinates (the current system does this) and B) World can store data in the way that makes the most sense to it.

These problems require enough modifications to the entire structure of the game that I believe it is more efficient just to start over. I know what you’re thinking – “Macoy, no! You’ve fallen into the classic trap of being a Perfectionist Programmer! You’ll always want to rewrite all of the code!” In this case though, there is so much friction within the current codebase that I do not want to write any code at all. I have coded myself into a corner. I am going to start over, but this time, I am truly going to do it right. Mark my words though, I will not start over again!

Plan

A coworker pointed me to a very good 2015 PAX panel on procedural generation. The main thing I got from it is that I need to focus on releasing early. I should be making the minimum possible game I can, then slowly adding all of things I want (releasing along the way) until the game is an incomprehensible steaming mess closer to what I dream of making. This will make the game seem a bit less absolutely insane in scope. It will also help keep my morale high. Release – I like that word. A lot.

I’d like to keep this blog up to date so I can stop wanting to tell my coworkers about my game (they’re probably sick of me already). I want it to provide more motivation for me to keep going. In my next post, I hope to be posting about fun stuff like a better build system (makefiles are awesome, but it creates too much resistance to adding new files) and the Object-Component system.