Atavism Dev Log 7 – Midterms vs. Modeling

Week 7: February 11-17

Hey so this week is gonna be pretty short but I’ll find something to talk about nonetheless.

And Then Everything Happened At Once


So after the gamejam I was ready to take it slow and recover from the immense fatigue, but on top of that was just an incredibly busy week with another one following this. I’ve got a really busy schedule this semester and it’s the first midterm season, so I’ve got several projects and four tests for the week of the 18th, meaning I’ve been busy working on those in almost all of my free time. I don’t like when everything cascades down like this but it makes the inbetween weeks a little more free, so after this hurdle things should easy out a little.

Does this mean I have nothing to show? It means I have a lot less, but above you can see a WIP of the tribesman model, which is what I’ve been dedicating my time to. For the demo day, as I’ve previously stated, there’ll at least be two types of tribal enemies roaming around and this is the one armed with a knife. He’s got a little pelt scarf, some pants, and he’s gonna get some very basic texturing after I finish up the detail and before I hop into animation. I’m gonna try to have him detail-done and rigged by next week’s blog, which at then point I’ll scratch my chin and wonder how “placeholder” the animation should be and probably end up trying to make them look real nice anyways.


I’ve been listening to Toccata and Fugue in D Minor recently while I work. It starts out and you immediately recognize it as “The Dracula Music” but it’s got of that organ-style complexion to it too when it gets all Fugue on you. It builds a really dark melody on itself that makes for a rather holy-feeling midsection with a strong ending that harkens back to the start. Would recommend giving it a listen, and if you have an organ nearby, I’d recommend playing it because it’s really got a full substance that can fill a room like nothing else.

Anyway, until next time, when I hopefully have more substance to show.




New Game – Bringer of Brilliance

Instead of the regularly scheduled Atavism blog, today I bring a postmortem of the game I’ve just made for my college game jam.


Bringer of Brilliance is a First Person Action game that I and two friends made during the 2018 K-State 48-hour Annual Game Jam, a jam hosted by my own college where we competed against about 17 other teams to make a game with the theme “enLIGHTen”. Armed with more experience and ambition than 2017, the development process was smoother and more productive, but ultimately far more intensive, but resulted in a good end product that won 3rd best overall. Download Link.

If you want to check out a more detailed description of it’s production, check out my postmortem here on my portfolio. Leaving that there, I’ll get back to work on Atavism and should have something to show on next week’s blog relating to the game.


ATAVISM DEV LOG 6 – Loose Ends and Floor Plans

Week 6: January 29 – February 4th

There’s not so much to say in this week’s devblog that I haven’t already mentioned, but you can see the fruits of my labor with the Hare AI and check out an in-depth idea of my dev plan leading up to the end of April.

Seek and Destroy

Like a swarm of locusts but somewhat more endearing.

One minor detail I’ve included real fast is ragdoll physics for the hare. It took a small while to figure out but didn’t end up being hard to implement, even with some difficulties in the process. It could use some more polish but it looks good and adds some surprising physicality.

I managed to integrate most of the code I mentioned last blog in the hare behavioral scripts. When scanning, they now search for plants at the beginning – using a Physics.SphereOverlap function in Unity to get colliders for every plant object in their radius -and move into a phase at the end where they analyse the results. This result process involves taking every collider in the array, calculating a navmesh path to it, and then counting the distance node-by-node to determine the length. The smallest path ends up getting put into the CurrentPlant memory for the hare.

It certainly evokes more sympathy than disappearing.

On a practical level this means hares will seek out and eat plants – with animations and all – and bounce from place to place until they’ve had three (or however many I think they should have max) before they go home. What’s more is that the runts are pretty considerate of one another and won’t eat plants that another hare has already chosen to eat.

Here’s a video.

On top of this, they now change their radius of vision depending on their current state (a hare who’s busy having his meal won’t be able to see anything) and will run to a hiding place when they see something dangerous, which I currently just have set to their home. I should probably flesh out the “running away” behaviors a little more, but in all honesty I’m tired of working on them and I need all the hours I can get put into the work for the April deadline.

The April Deadline And The Plan To Get There

The April Deadline and the plan to get there are pretty simple; my objective is to get a playable demo of the game released with a few human enemies and a few test environments – all of it down pat and fair enough looking by the TBD date in the fourth week of April.

The gameplay loop will mainly be avoiding roaming AI of tribal warriors while trying to reach some location while trying to survive. There will also hopefully be a few passive/defensive stone age humans based around camps, which have resources if the player really needs them. Player weapons will be restricted to the knife at first, but I’ll include the spear and shield separately within the level along with a few javelins out and about for throwing. The player will be able to die from combat and take fall damage and such, perhaps with a basic health meter that won’t make it into the final game.

Here is an image of the rifle animation states because I have nothing else to show in this slot.

From a presentation standpoint, I hope to have at least a fairly natural feeling environment with good lighting, but I’d really like to nail down some grass effects, minor props, and trees. If things are just super swell I’ll throw in an attempt at a nice water shader, but I don’t expect it being high on the priority list. I’ll need sound effects as well for the majority of this, but as is tradition, I can essentially put that off until the end. Music would be nice but the same thing goes.

I can’t really say how much of this target I’m gonna hit but it’s something I really need to buckle down and aim for. The intent is not only to get a good, shareable version of my game up for people to test out and provide feedback on, but on the visual side of things I need to figure out an art style and the environmental design process should kick that off in a direction that I can either decide that I like or decide that I don’t like.

Next Week

Next week is the 4th annual K-State game jam, and as is tradition, I’ll be competing. This means I won’t have a blog relating to Atavism, as I probably won’t get to work on it, but I should at least have something interesting to slap onto my portfolio and write a postmortem on before we get back to our regularly scheduled progress updates. I’m excited and nervous for the jam, but they usually work out fine, so I guess I’ll just be back again in a week and talk about how it went.


ATAVISM DEV LOG 5 – AI Groundwork

Week 5: January 22 – 28

The actual meat of this week’s blog is fairly technical, with talk about the AI framework I’ve been implementing  if you’re into that, but if you aren’t then you get a neat video and a progress plan at the end. Let’s jump right in.

Decisions, Decisions, Decisions

This is the “FoundNextZone” decision for the hare, where he checks for any waypoints that are lined up in his Queue.

If you’ve never heard about it, there’s a good idea for AI framework in Unity derived from using Scriptableobjects instead of Monobehavior to create inherited and instantiatable script objects that can run off of an entity using a simple AI monobehavior and custom state objects filled with realizations of these custom-coded items.

If you don’t know what any of the above meant, it means an AI framework consisting of a lot of behavior pieces that can be neatly arranged after it’s written without diving into code.

In the Unity-hosted tutorial on this system, the items are broken down into Decisions, Transitions, and Actions, both of which execute constantly by the use of a State object that’s called from your AI controller’s update function. The states are created like any other object, such as materials or meshes, and can be made, customized, and filled with Actions that execute every update and Decisions that check every update before moving to one state or another. The “generic” kind of framework here is incredibly open to customization, and combined with a one-time-Action object type I added on top of this is a versatile manner of writing a ton of behaviors and managing their terms of execution within the inspector itself.

The circles around the Hares indicate their current state, with the Brown color meaning they’re going somewhere, and the blue one meaning they’re taking a moment to scan for danger and food.

While I spent all of my time this week implementing and understanding how to use this effectively, the stuff I was actually making was some AI for the hare to run between plants. While I’ve currently only just activated and debugged running between waypoints (seen here in video), there’s almost all of the inert code for waking up, scanning for and running from danger, smelling out plants and eating them if they’re not currently occupied, and hiding until danger is out of the vicinity, all while changing sightline based on they’re current state. You can see the color of the states indicated in the sphere gizmos up above; Brown means the Hare is making it’s way to a waypoint and Blue means that it’s scanning for plants and predators.

Next Week, and further still


I hope to have the above paragraph’s AI done by next week, but I’m not too sure on how long it’ll take to bug squash. Afterwards continue to mop up a few aforementioned bugbears, such as ADS FOV, switching weapons while reloading, cartridge ejections from shooting the rifle, and an Inspector tool for choosing an initial weapon.

My current plan of implementing just this and that until I’ve thought of something better to do is kind of coming to a close. While there’s plenty of random stuff to implement, the end of the work above is going to mark an end the kind of “pre-prototype” time I’m in and morph into a more structured model of development as I try to make a deadline for the end of the semester. I’ll talk more about this, and indeed the contents of this plan, in next weeks blog, but it could be a few weeks yet due to an upcoming game jam on the second weekend of February. I’ll talk about that more next week specifically.

Until then, cheers.

Atavism Dev Log 4 – Hare Test

“Week” 4: January 14 – 21

After getting derailed 2 weeks ago from my computer problems, the last week has been going pretty smoothly as I’ve moved back into my dorm at University and did my thing over the week. Most of the time working on it was last Sunday and the 20th, where I worked about 11 hours on both of those days with only a passing few contributions over the week. I think I’d prefer to meter my schedule out better, but so far the binging works well until I have a more permanent schedule to work with.

Cleaning Up The Rifle


The first half of the week was spent cleaning up the rifle now that I’d fixed the animations. I implemented aim spread, so firing in quick succession will increase a firing cone of varying sizes depending on whether you’re aiming, moving, sprinting, and/or crouched. I’ve been thinking back and forth on this, but I’m fairly sure I’m gonna keep the ability to shoot while sprinting.

When shooting the rifle, the camera now kicks vertically with recoil, requiring a little bit additional aim compensation on top of the spread. I’ll be fine tuning these values as I implement enemies to test against, but the features are now in there and working smoothly. Another small thing I’ve added is “Max+1”, an unofficial term which essentially means that if you have a bullet in the chamber and reload, then the bullet will stay as an extra shot while a full magazine is placed below. I should also note that I’ll be overhauling the magazine reload system later to include a light inventory and bullet management, but that’s lower priority than making enemies to test against, which is the next step.

I also added the ability to sprint out of a crouch, which is something I should have added forever ago and really feels a lot better that it’s in.

The Hare and the Unity Documentation


The second half of the week began an undertaking of learning out what I need to know to implement enemies, which is to say something I can test low-poly organic modelling, organic rigging, animation layers, and AI implementation on. A hare is precisely a small and simple enough creature to test this on.

The hare! The desert hare. Modeled after the Black-Tailed Jackrabbit, I’m ultimately quite happy with how he ended up looking, which was a relatively short and sweet step on the artistic journey of nailing down an art style. I’m starting to get used to rigging and ended up doing it pretty fast, and the animation afterwards went quite smoothly, although I’m still not sure where I put it on a scale of “placeholder” to “done”, but it’s probably in the middle.

The hare should be a pretty simple AI test to match the following behaviors:

  • “Waking up” and leaving his den to initiate his idle state.
  • Running to waypoints where it will stop to look for food and danger across the way.
  • Eating at various branches until he gets his fill and goes back to his den.

As he performs each of these animations, I’ve figured out Unity’s Animation Layers documentation and gave him a little breathing animation that’s additive to whatever else is playing on him, which is a technology I’ve been meaning to learn for a while. The effect is almost too subtle on him but the skill will come in handy in future NPC’s.

A modeled a branch real fast, added health and dying to the hare, and got a basic “follow the player” script working on him with animation, but a lot of time was spent planning out how I’m going to structure the behaviors of the AI and the other facets of enemy variables. I’ve implemented an Abstract class for an enemy Health and Controller script, wherin the former now allows NPC’s to take hits and Die using a delegate from the latter, which will host all the executable behaviors and have access to the Animation Controller. AI will probably work similarly with various behavior delegates that are updated in the AI script.

Next Week


It will probably take much of the time to properly understand and implement how I want to be doing AI for now and in the future, but after I get the hang of it, it should be something I can add on fairly quick, so it’ll mostly be predicting interactive behaviors with multiple hares and squashing bugs from emergent stuff in testing.

I predict that by next week’s update (probably something I’m gonna do on Mondays from now on) that I’ll have finished and moved on from the hare to fix a few bugbears like fixing weapon switching while reloading, adding a tool for the current weapon in the editor, and adding a few effects here and there like cartridge ejection and FOV zooming on the Rifle. After that I’ll start working on a template human model, which will probably take some time to get right, but it’s the kind of thing that’s worth taking time on.

That wraps up this update. I’ll still hold to putting the next one on Monday but college is gonna come first and I can’t predict how hard this semester is gonna ramp up. I’ll do my best though.


Atavism Dev Log 3 – Computer Troubles

Week 3: January 1 – 5

This devblog is a week late – and for a good reason! After (and only after) a stressful week of work, on friday night, my computer shutoff while I was folding some laundry in my room. I left it until morning when I troubleshooted, took it apart, and discerned the problem as the motherboard being shot. There was no power, no lights, and the PSU was working effectively when I tested that. Neither the CMOS nor the CMOS battery inspections returned positively. I needed a new board.

In a poorly considered but (barely) affordable financial decision, I quickly researched a cheap set of replacement parts and dropped the cash to get them. It is only now I am able to access my progress, verify that nothing was lost, and put together a dev blog for what even happened that week.

The Rifle

So what do I have to show for week 3 after such an extended period of anticipation?  Well, I have the rifle. It’s just one weapon, but I learned a lot about both myself and Blender in the process, which is why it was such a productive and stressful week.RifleReference

Wheras the other two weapons were hastily sketched and then laboriously animated as I learned the tools, I went into the rifle already knowing what I wanted visually, which sort of affected my mindset on the whole thing. Where I could easily make a couple boxes, animate a few seconds of placeholder, and call it a day (it would honestly only take about an hour to get a full set done), I, for whatever reason, couldn’t shake the feeling that I couldn’t stop myself there, but that if I were in blender with an idea of what I wanted, I might as well make it and animate it out as best I can. So that I did.


The rifle is planned to be found by the player at an altar about 1/3 of the way through the game, representing a sudden and violent push into the blood-soaked, industrial nightmare of the 19-20th century’s infamous wars. The capability and visual design, then, had to mirror the impression of weapons during this time, and so a semi-automatic rifle styled after the Springfield M1A, both a visually appealing and relatively representative choice.

It turned out swell, but the stressful part of the week was ironing out all the minor imperfections that I really shouldn’t have been focusing on. Seen above in the gif, the hands will float around their target destinations, the spread is wrong, the FOV is wrong, and the bullet remains in the cartridge when flying out of the gun. The hands part alone took a lot of researching into the weird kinks of blender to figure out what was wrong (long story short, animation compression and simplification when exporting). These are things I could have ignored (like I did for the spear and the knife) while getting out other features, but they were things that had to be done eventually.

Next Week?


Well “Next Week” is already over. As of time of writing, it’s January 12th, the friday of what should have been my last week of this weird project. Instead of working 3 weeks, excluding Christmas, I’ve worked only two, excluding Christmas and this one where my computer broke. All I really accomplished was some brainstorming, a few sketches, a bit of level design and narrative ideas, and a fair amount of gameplay into Breath of the Wild while I waited for my parts to ship.

I plan on at least delivering a fourth week update, even if it takes place over a weird amount of time. On the day (night) I’m writing this, I’ve been working a full day, and over the next, first week of the semester (but maybe longer), I’ll probably have time to make another blog’s post worth of content to write about. I’ll try to keep that up probably indefinitely, but after the next post it could start being a while between updates, although I’ll try to do it more than my big drought recently.

If there’s one unmovable fact of life I’ve been enwizened to from my experiment this break, it’s that sometimes when things are going great, life just kind of lays into you and doesn’t stop for a while. It can only really improve from here though.


Atavism Dev Log 2

Week 2: December 25 – 31

Over the week I didn’t get too much that was terribly exciting done with the game. I went on vacation with my family and chilled out with my friends for the week, but that’s not to say I got exactly nothing done.

As a Christmas gift I purchased and downloaded Autodesk Maya LT 2018 and gave it a whirl, my head teeming with ideas how how this professional tool would certainly improve my productivity. I designed a quick animated “enemy” so to speak and got to work on it, but after a few hours I came to pretty much the opposite conclusion.

Working in Maya is nice, and I feel it’s strengths in certain types of modelling (higher-poly models and rendering specifically), but overall I had gotten too used to the maximalist but useful keyboard-oriented shortcuts of Blender as well as the general layout and logic the program has going for it. I’m aware I can probably get used to Maya, but I already know Blender pretty well and don’t need to spend 240 dollars a year on it.

I’d still like to save money on embedding videos to the website, so here’s a link to the test enemies in action, and by that I mean idling. Don’t expect them to be in the game at all, they’re just something I thought would be cool to test. Below is a bona fide jpeg.


Next week I’d like to clean up some animation transitions for the knife (and maybe the hit detection) and then just implement another weapon for prototyping. I’ll also update my portfolio to include an older demo for the older project and then also add my Chillenium 2017 game and write a post-mortem for that – both things of which I’ve been needing to do for a while now. Specifics are something I’ll find out as I delve further into the week.