Did a little more with level blockout. Wasn't happy leaving the end area quite so unfinished. Added a bit more detail to a few buildings in the Agora that are very blocky. Also increased height of the acropolis so it's more of an epic climb to get to the boss fight. It can now be seen from almost anywhere in the level which I think improves scenery in a lot of places.
I'm also adding a few short indoor sections. No combat, just transition areas. I feel it may help with pacing, and gives a more intimate relationship with the setting. These will depend on some good props to make them look like actual places people live.
Since I am ahead of schedule I might spend a couple more days finalizing the level a little more. I added some simple color to some of the columns and will do more of that across the level. I've brightened the generic marble texture that is used on virtually all the buildings right now to an unrealistic white, but I feel that it may look very nice once more accent colors are in. These accents will be mostly trims on temples and columns. Some smaller buildings may be painted. But I think the very bright white will contrast nice with blood and mud splatters.
If I do much stylization with the art, I think it would be done mainly with the color palette. Simplify it down a lot and avoid too much realistic detail that can make the screen noisy and difficult to read. We will see though, I have some general principles in mind but much of the art is feeling it out as I go.
Here is walkthrough of entire level with no gameplay, just art and music. Not sure what sort of critiques can be made for a level blockout, but if anybody has thoughts, I'd love to hear them. Always good to get some second opinions before pulling any triggers:
Was getting creative burnout from so much level blockout and trying to start with characters just wasn't happening. I did get together plenty of concepts and grabbed a few models that might be used for base meshes.
Shifted gears to some more techy stuff. Working on a tool to export objects by name from maya to a csv, and then in unreal this gets read and instanced static mesh components added for each.
Tooling:
The tool is all working except that in some cases rotations are wrong. It seems that there is a formula needed to convert (its more complex than just swap Y with Z). I have some notion of the problem but have to do further research to solve it. It looks like deep math which is not my forte, but so long as somebody has solved it before and wrote something about it, I should be able to eventually. But there is alternative workflows to accomplish the same thing using unreals in built tools, they just are slightly less ergonomic.
In general I think as a solo developer it is better to avoid doing such work unless there is clear evidence that creating a tool will unequivocally save major time. In this case it seems so.
Level Design Review and Overhaul:
After some time off and then review of the level design so far, I've made some plans for an overhaul of zones 1-3. There are just a couple zones that I feel like have that special spark. Others, while okay, just don't quite feel like a proper game yet.
First, although I haven't test game with others yet, I feel pretty confident people are going to need a lot more short engagements with easy enemies to have a more reasonable difficulty curve. I also feel that my ideas for setting aren't quite communicated well enough if we are in a marble city, so I add an additional zone outside the city gates which will be in iconic greek olive farms. Terraced hills, cyprus trees, dirt roads lined with cobblestone fences. I want to see a lot of mud roads, cobblestone, goats and irrigation ditches. Things that really make you think "quaint old world charm", more so than "classical greek democracy".
I've only began poking at this, but basic idea is that we begin on an overlook, then drop down and a terraced hill village on either side should frame our path to the city gates:
Within the city, I have elevated the further neighborhoods so that we get more vertical layering.
This also gives more opportunity for interesting architecture like stairs carved into rock:
It's a visual improvement for sure, but I think I can do better than that.
The zones in the city I am going to further subdivided so that each is comprised of three layers of verticality. Basically when viewed from a distance I want to be able to see each of the layers gently rising up. This will look better artistically is the main goal and also help both me and the player see distinct arenas, where each one offers a clear challenge. I think for a high difficulty game there needs to be a distinct feeling like you get from one checkpoint to the next, so that you can easily measure your progress. If you feel like you are just lost in this big level it might feel too overwhelming - at least for the first level in the game.
Environment Art:
I'm still some distance away from replacing blockart art with finished art but I've begun iterating a modular kit a little bit. I still do most of the blockout just by scaling a few simple shapes, however now I am occassionally converting some of them to modular pieces just to start getting a handle on that. Figure out what sizes work best, how I might design buildings to maximize reuse from just a handful of parts.
Okay, this post will talk about next big iteration for the level design.
The previous design was probably fine, however I have plenty of time before my first deadline and I think there are some major improvements that can be made both artistically and for gameplay.
Level blockout update
In previous post I mentioned that I am adding some olive farms outside the city gates to serve as introductory area. I've blocked out just enough to settle on a basic composition:
The little hill towns will only be in the background, not playable space. This way it doesn't add too much extra high fidelity assets that I need to make.
The game play area I specifically want to just be a pretty large, open space. Some slow zombie like enemies will just stumble towards player, offering plenty of chance to get used to the games shooting mechanics. The visual interest of the area will rely on the ground, foliage, and props, while these little terraced hilltop towns just frame the area. Since it won't have a real impact on how the player moves I wont bother detailing it further yet.
Side note: I cannot find a good game ready olive tree model. I am very familiar with speedtree and foliage creation, but it is a pain in the ass so I'd like to just buy one. If anybody has some olive tree models for games in your library please let me know! I'll buy it!
Level design planning change
Decided to redo all areas except for the Agora.
Previously I started with some story beats and some gameplay encounters and just kinda placed those landmarks and winged it from there. That was fine - just have to get some paint on canvas to get started.
But result was that I end up with something like a painting but the fundamentals are a bit off. Pacing and difficulty curve aren't right.
So this time I am planning it out by chunking level into time slots. Basically time is the constant thing and I'll use all the other variables to solve for a given time.
As with many things, a spreadsheet is helpful for this:
It is not possible to be super accurate with the time estimates. It is doubtful I'll even be able to get enough outside play testing done to generate useful data to know for sure what optimal pacing is. So I'll just have to use similar method as I used in previous games (which turned out to be pretty accurate). Basically if a section feels mildly challenging for me, that will feel extremely challenging for average, new gamers. So then my time estimates will be my average play time on the hardest difficulty, including do-overs.
This isn't so much about trying to optimize the game design, it's more about defining a measurable goal so that I can know when the level design is finished instead of just going on gut feelings.
Modular kit, trial run
Another thing I'll be working on in this iteration is to try and redo most of the buildings from a modular kit. This is basically a trial run for the enviro art creation. Since I haven't done very complicated modular kits before, I don't think it is realistic to do it well in one pass.
Finally, I'll be updating the layout of west side of the city so that we get more vertical layering, and a stronger contrast in style between the neighborhood streets and the main road. Neighborhood should be tight, windy, with many quaint little courtyards. Main road large, linear, more grandiose.
In the level blockout I've built from the Farms up to Streets Arena
3, which is about 30 minutes of gameplay, going from easy to moderate
difficulty. I am pleased with the pacing now, it feels like what I would
expect from the first level in a game. It is a pleasant level of
challenge and feels like you are being fed enemies at the optimal pace
so that it remains engaging but not overwhelming.
I've done so using a pseudo modular kit, which is nothing more than just rectangles of standardized sizes. But this was still enough to get a good idea on what the modular kit will need to be. Since it is so ugly looking though I'll show videos once I've refined it a little further to resemble more than big blocks.
But
before I completely commit to the level art, I really need to feel 100%
confident in the gameplay. I am still using one generic melee behavior
set for all melee enemies. In order to properly test out the next arenas,
I need to be using the actual enemies as I've imagined them. So it is
time to switch gears and get the athenian soldier, athenian hoplite, and
athenian archer models, animations, and code done.
As with the level geometry, first I just do the quickest viable version that I can, being careful to setup my project files so I can easily go back and iterate on them for polish later.
Updates - Begin work on basic soldier enemies
Got a quick version of the athenian soldier done. This tough guy just gets a sword. No shield. That's why he's going to die.
Most of the mesh I bought from sketchfab, though I'll be making some edits to make it more of my own eventually. The basic design won't change a lot, but I'll probably make his blue colors pop a bit more, make his musculature more wiry looking, and of course he should have a beard.
I've done a quick job rig and skin it so just ignore some ugly deformations for now. I also dusted off the animation cobwebs and did a combat idle. Tomorrow I'll finish the rest of his basic animations.
Project Organization and Team Management
As I go through the work this time I am working on building my checklist so that I don't lose speed when changing gears in the future. This is just where I log any of those pesky issues that are easy to forget a month later. if it takes you 10 minuets to re-remember something every time you change jobs as a solo developer, it will grow to make you dread changing jobs. Builds fatigue. So it has become essential to me to meticulously write down workflow.
LEVEL DESIGN - Change of strategy
Previously, in blocking out the level, I just started with a few landmark encounters that I had in mind, or a story beat, and then just filled in the blanks from those. But this led to poor pacing and an insecure feeling, like if you were hiking in the woods and not quite sure where you are at. That's no good way to work - need a little more surety. So I have tried now to blockout the level into time chunks. Starting from a desired length for the level, then I can figure out how long each beat ought to last. It's easier to think about this way for me, and easy to analyze the level as a players experience. It gives better focus to my play testing and helps me more readily say, "okay this section is finished, because it last the desired length of time and is appropriate difficulty."
Data Driven Design setup
I am
also working on further designing way to tabulate level and game design
data. I've moved to excel spreadsheet for that. Right now this only is
for my planning, but eventually I'll put a lot of game config into this
same file. That way I can do things like " for all level 3 combat
encounters, increase enemy count by 20%", or "calculate average
estimated play time per level 2 combat encounter".
Art Design
Did more experimentation with rendering styles.Tried to be more scientific and actually compare A/B videos / screenshots. I'll do a proper write up of such comparisons in future, but for now I am strongly leaning towards a realistic cel-shaded style as is displayed in the GIF up top. Reason for this is:
visual clarity
can easily make artistic changes to values with minimal knobs (like globally adjust shadows so they aren't too dark, make highlights pop a little more, etc). Of course this is all possible with post process and the gazillion lighting tools but much faster and easier if its just three knobs in one material.
reduces total number of textures required
looks more finished with less time investment
does synchronize well with broader design principle to keep the theme adventure focused and not too heavy or grim, but it also does not feel so cartoonish that it couldn't be taken seriously
Athenian soldier and hoplite have enough animations to be playable. Now headshots and shields matter. If you headshot guys with a helmet it knocks them on ass and does small amount of damage, but doesn't do bleed damage. But in the second they are down you have opportunity to shoot their body or get away.
Quite a bit of polish is going to have to go into the fall down animations but as long as mechanics are communicated that's good enough for now. Next I'll work on wounded state locomotion and standard hit reacts. After that, the athenian archer and then athenian farmer models/animations.
I'm thinking either add some I-frame to the dive or tweak the animation somehow to make it more viable way to squeeze through a crowd without getting hit. Just cause that would be cool. Like sliding into home base.
Too much distractions in house to be able to focus on grinding out the last couple characters and animations, so did some easier work setting up a proper stylized shading system. Previously I had used some post process materials which basically act globally, and then if you want target specific things it's a pain in the butt. And there is a ton of flexibility issues. Too much to type, but very often you hit issues where getting thing A to look correct breaks thing X.
So here is a shader approach, where each building, character, etc has a unique material instance that handles the cel shading. This doesn't break compatibility with standard light or rendering features and is much easier to art direct.
The satyr that has all white material is stand in for athenian archer. I have the behavior but not the model yet. He won't be leaping like that, just a regular dude running.
Gameplay getting good. Level progression feels much better now. Just got to finish up the farmer, athenian archer, and then I'll begin work on the harpy which will replace the satyr archer in this level.
One happy accident regarding a question that has been in back of my mind about how to handle death animations: I have an animation for hit react and headshot hit react. Occassionally it happens that this animation triggers at the same time as death, which triggers ragdoll. The result is that the animation begins and then finishs with ragdoll, which ends up looking quite natural. This should allow me to get good variation with just a few death animations (like one for each cardinal direction). I do prefer the look of actual death animations compared to pure ragdoll. It will allow me to put some character in them. Like a spine shot makes enemy go rigid and them fall like a tree, for instance.
Didn't feel like starting new character yet, instead took some more passes on the main character.
This is just sort of a concept made by frankensteining parts from other characters together:
I think the basic idea works, though I'll probably just do leather gladiator sandals as bronze greaves feel too heavy. I might not have her wear any metal at all for a more primitive feeling.
For the body the main things that I think are important is that we see some of the back muscles when she draws the bow, and of course the arms and shoulders, and the thighs of course everybody liked to feel the Mediterranean breeze on their taint in these times. It must have been lovely.
The biggest focus is on her face. I feel that with some iterations I can achieve something satisfactory with the outfit and body. But the face is a big trouble for me. I am just not that great at doing faces. For now, this is just some daz model which is passable but its far from what I'd like. I'd absolutely just buy a model if one existed that fit my needs but nothing I've seen fits this character.
I generated one concept from midjourney that hits pretty close to what I have in mind:
This is pretty good because she is quite thin like you'd imagine a bronze age nomadic person would be, but she has the strong hero traits. Square face, sharp jaw, cold piercing eyes. I've been trying to sculpt this face - perhaps I have the shape correct but in unreal with the cel shader it looks pretty flat. Perhaps I need to do a little texture work to to bring in all together.
Well, I think it will be a much better game if the main character looks good so I'll keep working at it even if it takes longer than I'd like.
Okay reached a result with the hero that I'm happy with. I was feeling very low confidence about this but it only took half a day to get something I'm happy with. Face isn't exactly like the reference but I think it achieves the character that I wanted. She is attractive but not dainty / weak looking. Looks good with various expressions.
I had to crack open zbrush and spend some hours feathering the face, then send back to daz, then to maya, and finally to unreal - a pain in the butt workflow but the end result is that I want to keep the same topology as the daz gen8 so that I can load it back as a morph in daz. This way I can keep the joint-based face rig. I am not a good enough character artist to be able to judge how a matcap sculpt is going to end up looking in engine, I just have to see it.
The cel shader makes it so that you need to exaggerate features pretty heavily for them to read at all too. This was messing me up for awhile such that I ended up with some very strange alien faces, like plastic surgery gone wrong. Just a few tiny touches in zbrush can make a big difference that I can't read until the model is back in unreal under full lighting and shading setup.
------------------------------------
I considered the outfit more as well. This one is okay but it feels too... busy or something. Like imagine actually running a few miles dressed like this. Those leather slapping against your legs. You'd be so raw. What a nightmare.
I know pretty much no gamers would ever think that but I do and it's my character. So I wanted tried out some ideas from other concepts...
Something a little simple - just a tunic that might be frayed at the ends, and a leather guard for the midbody. I guess it's a corset? I think this makes nicer shapes overall and feels more iconic. Like with blurry vision you just have a few stark triangles.
So that is settled then. I won't take the model further than this now, but I'm going to rehash the animations because the way I did them before did not leave myself setup for iteration very well. And I didn't have the face rig figured out, but now I do.
Plus I am going to alter the locomotion mechanics a bit.
Tested out maya live link with unreal and it's pretty good to be able to preview animations in real time. But feedback is a bit choppy so its really only good for blocking in. Little details don't read at all. Not sure if it really speeds things up or not, but definitely nice to get some immediate feedback.
Character overhaul wasn't only about improving the model but also better setting up the rig and animation files so that I can more readily iterate over them as I continue to modify the locomotion mechanics. Since I was figuring out a lot of things with animations for the first time, I had not left animation files that could easily be modified. So now I just only do the basic core loop of the animation - no unique variations. Can add that in later if the animation survives till the end.
Also improved the rig. Now it is fully setup for everything I have planned. Have a joint based face rig. For gameplay animations, my idea is that I won't author face animations with body animations. I'll do them as additives in unreal and can fire them from events. Either notifies from other animations, or certain game events / conditions. Keeping them separate should give me more flexibility and simplify authoring.
Got a few animations re-did. The sprint fwd is more or less copied from paragon sparrow, but the rest I just make up as I go. I just know length of time they need to be for gameplay and besides that I just try to make them big and exciting. The bow charge especially is important to have timing just right - it feels great if there is a tiny little anticipation and then an aggressive fix, since the "gunplay" is really all about timing, kind of like a souls game.
*one note about timing, I have an idea, maybe it wont pan out but I try to time the looping combat animations to be in rhythm with the combat music tracks. So right now they are all 128 bpm, which means about 0.5 second intervals for major movements to be in rhythm. Probably won't read but worth a try.
All of the animations are like blockout +, meaning I just try to get the basic movement and timing good to help verify gameplay, but not bothering with polish yet.
With the locomotion loops what I learned is that they need to be cyclical - as in you can't have like a sneak walk animation with irregular forward speed (unless you were doing root motion). I mean you can get away with a little bit, but too much and it starts to look weird, since the game character moves at constant rate.
Another day or two and I'll have new controller ready and can swap in the new character.
note that some frames are lost in a GIF so animations look more choppy than normal framerate
Curious about her skirt: is that dynamically driven, or did you add bones on top of the daz rig?
the skirt is cloth dynamics in unreal, which gets added in the skeletal mesh asset . It collides with the physics asset. Getting it so that it looks natural and doesn't clip through seems impossible, lol. It looks like in examples like paragon they tend to only simulate free hanging things or just short frills, not so much a large piece of fabric that interacts with body. So I might be asking it to do too much.
The ponytails are animDynamics -> chain, and then there is some spring controller on body too for jiggly bits:
There might be some benefit to do skirt with an animDynamics chain - like I think I could better control for clipping with the body. But you wont get the cloth ripples with wind and it wouldn't really behave like cloth... however perhaps both methods could be combined. The chain for big movements and then cloth sim with much smaller range allowed just to get the little ripples. Something could experiment with later.
It is possible to get a better simulation in maya, but I don't think having them tied to animation clips would work as we can dynamically change animations at any moment. So maybe for cinematics it might do to go with better sim in maya and bake with the animations, but for interactive gameplay it seems like pretty much only option is simulate at runtime.
Frustrating previous two days. Its not an art update, however could help somebody avoid similar issues and maybe for somebody looking for a job at game studio it might give some notion what sort of stupid issues you might see from time to time.
So first big issue was that I was trying to solve a little issue where my root motion animation overrides gravity. There is some workarounds but I saw how you can just edit like one line in c++ so I tried that. What I didn't know is that you can't edit the source directly (in a launcher build it is read-only. Just there to help you learn). I disabled read-only and just tried to recompile...
So the project got broken and i couldn't open it. I did a fresh reinstall of unreal (this takes ages and having to wait drives me insane). But still with a fresh reinstall of the engine the project wouldn't open. Errors about needing to recompile from source. So I go in an view the errors and for some reason Rider is not finding the engine source directories which means certain includes can get found. If you give them absolute path name it works, but not for everything... anyway, I pull from version control and it's same story. So it is difficult to say where the problem is. Is it the engine, the project, the code? What? Long ass story short, the problem was with Rider. I recompiled the same source code in Visual Studio and voila, everything worked.
That was like a 16 hour day of debugging. Ugh. Usually I don't get too worked up over having to do some troubleshooting but this was especially stressful because even my version control backup wouldn't compile. Thought for awhile I was going to have to manually move things over which is barely viable as all references in assets aren't maintained so you have to go through a billion blueprints to fix things.
Next day I am excited to work on animations. I had done a few test with the rig file but didn't end up using the changes. Of course I do this all in separate duplicated files so it's non-destructive. But somehow in my haste, I must have done something weird. In unreal, my animations sometimes have slight offsets compared to the maya animation. The bow and arrow are like a few inches outside the hand.
A lot of troubleshooting. Rebuilding portions of the rig. Half a day wasted. Finally I find the issue - there was double constraints on the bow joints. Dunno how that happened - it's not how I built it. But apparently having double constraints can cause this issue where joints are offset a bit in the exported animation.
It is easy to forget, but when troubleshooting it's good to try and remember, don't just look where you think the problem is. Look everywhere.
Anyway, so there is something a little more 3d related, let me share my bow rig. I am very proud of this because I invented it entirely from my own mind, and the best thing is that it is simple. I think a bow rig could not be more simple. Naturally, as I'm not a pro rigger, the first thing I did was go and try to find some tutorials or existing examples. But my god, they were all complicated. I felt this could be done simpler. So here is what I came up with:
Two bones - a root and a string. Two controllers - one to handle the bow and one to pull it.
Each joint is parent constrained to the associated controller. And the string puller control is parent constrained to the bow handle control. It is important to do that constraint on a parent group so that you can zero the transforms (just watch some rigging 101 tutorials if you want to learn why).
That's it! It works just the same as any other bow rig no matter how complicated they are. I mean it is just a stick that bends after all.
With the character you can just constrain the bow handle offset to the wrist joint. But for unreal the bow joints do need to be parented with the main skeleton, so you can just add them to the root as a child.
For animations where the string puller hand should stay fixed to the string, I just add a constraint from the string puller control to the IK hand controller. Since the bows main control drives the string puller, then means you can easily adjust both arms from just one control (moving and rotating the bow to where it needs to be, and the hands follow.)
Animbot has some handy helper tools to make this much simpler, including Grab Release constraints. You can accomplish same thing using basic constraints in maya but its much less ergonomic and you'll face more hijinks. So definitely check out the trial of animbot if you're doing this sort of work.
The string only has a single edge ring in the middle. This goes 100% to the string joint. The ends of the string go just enough weight to the root so that they stay lined up with the arms of the bow when flexed.
After much playtesting I've developed an optimized way of playing the game. Now in this overhaul of character controller I am trying to make it so that it is as intuitive to play that way as possible.
Previously I had an extra button for combat stance, which ducks and crawl / ducked run. And then another button for dive. But I found dive wasnt very needed because you can out manuever enemy aim just with strafing. I like the feel of strafing and weaving but it shouldnt be OP. The dive feels badass and it should have a strong reason to use it.
I want the game to be as absolutely fast as possible, and i think to make that viable there needs to be as simple controls as possible. So i try to make it so that you can do a lot of movement just with joystick only. The cadence that you start and stop, how hard you cut turns, etc should all make for ways to out manuever the enemy.
So I am trying to give some limitations to movement so that you can still out manuever enemies aim but it takes a little more skill to do so. More than just wiggle the joystick back and forth. As you can see in the video, there is a hard stop after sprinting which immobilizes you for like 1/4 second. If you do it at the right time its a great way to break enemy aim, but it can also get you shot if you do it at the wrong time. There is also a little transition from idle to run. These animations are very rough but I need something basic to work with to get a feel for it and block in the code.
There is also some lean animations which actually help to turn you around a little more sharply. Eventually I'll polish these so that you get some satisfying footwork in there, such that when you cut back and forth to avoid enemy aim, she should look like football (american) player doing juke manuever.
Doing these interstitial animations is quite challenging. Getting things to time just right. Even getting an ugly blockout version just to work is not so easy!
a lot of work done on the character controller but probably still a few more days to complete its overhaul.
notably, I changed the dive from root motion to act more like traditional jump. it consist of three separate animations, a begin, a looping middle, and an end. This way the distance of the jump can be configurable through code. I was not sure if this setup would work or not so I just did bare minimum animation which is why it looks hilariously bad at the moment.
I've also added some lean animations when turning, though these are also just done cheaply - i just rotate the root bone in unreal. But once these get an actual animation will look nicer. Even so they make a big difference in how nimble the controller feels.
I wont bother with foot IK, instead I just have an animation that intakes ground angle and interps between an uphill, flat ground, and downhill locomotion. So far I only did the uphill version.
A lot of work with camera and camera shakes. Some near miss reactions just using a few frames harvested from existing animations but these I'll make their own animations soon and it will look better.
I suck at math so I spend too much time on some things but I think they end up being worthwhile - when sprinting and you stop suddenly there is a short foot plant transition - i add some camera shake that always goes in same direction as player velocity. I struggle with any math related code but usually after fighting with math for awhile I realize a much easier way to do it that requires no math at all. So now I just try to think "how would a caveman do this?" from the onset because there is almost always a way and simpler is always better in the long run. Much less brittle overall if everything is working with ABC's instead of trying to build a NASA rocketship.
With animation work I've begun doing more FK and less IK. It feels wonkier at first but it seems easier to get good arcs and keep range of motion within realistic limits.
Also, as you can see I've been messing around with post process, shaders, lighting. I'm not so interested in making any big decision, but since I record plenty of video then I can view it all later with many different artistic styles and see which ones I like the most.
Currently I've used a painterly post process effect on everything except characters, which helps them stand out a little bit. I also use a toon shader on everything which lets me easily art direct color and values globally. I found out that you can create material instances of material instances and this can be used to do things like change value of environment materials, or all character materials, while still being able to tweak individuals.
Past few days been animating like crazy but it's not stuff I will show because spoilers, just a snippet.
I have been working on cut scenes that happen before and after boss
battle. The only reason I do this now is because the student doing music
(for his final project) needs to have something to show along with the
tracks he scored for it and he is on a deadline. Some simple sketches would have sufficed but I
figured I'd probably be faster in 3d anyway.Kind of wish I'd just done sketches because doing two complete cutscenes (just blocking them in) in 3 days was exhausting.
Just some snippets to show the very first steps. It's all stepped animation, almost no inbetween poses, the only important thing right now was timing the scene with music. But for me personally it still helps to begin getting an idea what will work or not in cutscenes, and what sort of effort it will be to fully realize them.
Alright, hold the applause and put your wallet away. This masterpiece isn't for sale quite yet.
It is enjoyable to play as movie director. My big idea is to use a widescreen ratio like westerns and go between big wide panoramas to frame the scene and then up close to focus on character emotions. I do a few dynamic moving shots but sparingly. Here is one example, it feels weird without the music but the shot seemed to jive with the sound:
Lesson learned:
The music was scored to fit a screenplay I wrote, but since I have never done any cinematic my time estimates for shots and especially dialog were pretty far off. So I had to strip out a lot and making those decisions at same time as key framing is pretty taxing. But the good thing is now I have a clear picture what it's going to be like to make the cut-scenes and refined my maya workflow for that a bit.
It would be better to block in the cinematic first and then make music to fit it. In future I think that will be safest thing to do, but in this case it wasn't really feasible. Live and learn.
Next:
A little more work to finalize the music stuff for the students deadline, then get into adding the harpy character type.
Awhile back I saw some post on unreal forums that a student needs a game project to write music for as their final project for music school or something. I figured it would probably be some junky student music, but what the heck I won't lose anything from it and gives kid chance to work on something.
Turned out to be great music and covers like 80% of music needs for the level. More than enough for vertical slice and promotional needs. This theme song includes bits recorded by the European Philharmonic Orchestra.
I think getting some music going on early in project is pretty good. It provides a lot of motivation and direction, and other than unique scores for cinematics, it's not something that is so closely tied to anything that there is major danger or wasted time or do-overs. Like if a song doesn't quite fit where intended, it probably will somewhere else. And it seems relatively fast to produce music as well compared to 3d art stuff. Apparently the theme song for Halo was composed in like 3 days and how much of that games impact is owed to the soundtrack? Probably a lot.
First steps of the harpy taken care of. A basic model with focus mostly just on silhouette, and a rig. Animations over the next few days, and I probably wont bother with textures and refining the model until after the level art is completed. It seems much easier to make decisions about the design of characters after having played against them a lot.
I started by getting the code in place first, which turned out to be easy.
The clothing I'll probably tatter up a lot , but I think it has to be a bright color so that we can easily see the arms to know when she is drawing her bow. As for the bow, I think it will need to be oversized so that we can easily see its silhouette in the sky to also know when she is aiming at us. It seems pretty much mandatory that the wings be raven like this, otherwise she'd seem like an angel. Another option is bat style wings, but I want her to feel more fantastical and not so demonic.
The rig is a pain in the ass, but thankfully most of the hard work is already done thanks to advanced skeleton. I only needed to add some simple FK controls for the wings and talons. Of course you can make something very sophisticated and more animator friendly, but I dont think it makes sense to spend 50 hours on a rig to make 20 hours of animations.
As you can see, there is some lumps left from where I grafted the talons onto the daz base model. It probably seems sloppy to leave that sort of thing, but the thing is there is good chance I make some updates to this after playing for awhile. I might elongate the legs, might make her thicker overall, or more creature like... so for now just like everything else in game, I try to be careful about going too far too soon because there is never enough time or energy for all the task, so it has to be rationed carefully.
The main things are that the rig and skeleton are set, so changing model and transfer skin weights is fast and easy. Since so much of the character is in the animations, I prefer to evaluate the model in actual gameplay, rather than static like this. Like you might get a really nice silhouette and great shapes in some portfolio pose, but then in gameplay the typical animations just don't do that any favors. So it seems best to just get it in engine and evaluate it under gameplay conditions only.
edit: here is the code in action
and right off the bat the thing I realize is that they really won't need to be high detailed. 90% of time they are just a distant silhouette. All the character will be in the animation. Good thing I test gameplay first cause it would be easy to get into details and be texturing tiny little things for days otherwise.
Last time I fought harpies in a game I think was dragons dogma, whenever that came out, like 2010 or something. I was very excited about them - dunno why just seemed like a super cool enemy to fight. Unfortunately they were just a fodder enemy in that game and not very interesting. Not sure I ever played against a harpy I really liked. I wanted them to be like that scene in the old claymation movies, Jason and the Argonauts IIRC. Very dangerous menaces. I want them to feel menace-like. Not enough enemies in games feel menace-like. Perhaps the cliff racers in morrowind. They were menaces.
Anyway, pretty happy I think I've got the harpies that I've been wanting to fight all these years. They border on being too frustrating but I'll keep tuning things till they hit the sweet spot.
The animations feel a bit robotic. Harpies don't appear to actually be flying but rather like on an invisible roller coaster. Some inbetween animations might help... maybe. But when you are playing it's so fast I don't think it matters. You are just trying to not get shot. So I'll just work on improving the animations over a few passes and let it be.
Okay, that wraps up the little detour. I had been focused on completing level blockout, but needed to have all enemy types in order to know how best to lay things out. Now I've got them all (plus a further detour to upgrade the hero character), so back to the level blockout and then onto level art.
Okay, no new art, but some thoughts about marketing that might be something to think about even for other artist if they are thinking about how to market themselves with portfolio.
So I will start making some youtube devlogs because the common advice is to get started with marketing as soon as possible. Since the game mechanics are mostly finished I figure that is good enough time. There is a game that can be played, even if it is still largely blockout art.
I am not sure I agree with the prevailing wisdom. Even among seasoned developers and artist who understand what early stage art looks like and how it transforms over time, I don't think showing them early stage stuff really effects them in any way that is going to convert their interest into eventually buying the game. I mean I like to show all stages of my work here because I figure it may help some beginners get a realistic picture of all the ugly shit you have to work through before finally getting to something finished. Maybe some value there but if trying to get somebody interested to buy a game... I don't think there is any benefit.
Some people say that you absolutely should not show any early stuff, only dress to impress so to speak. But so what if I show something which doesn't look great? It is not like potential customers remembers some random devlog they saw once that looked bad, and thus they won't buy game if it looks good later? What is risked?
It seems like there could be a small opportunity to gain some eyes and accumulate something over time if starting early, even if game is still rough. Other benefits is I gain much needed practice to make better video content. So there is two plusses.
Downsides is I already work 10+ hours and seldom takes days off, so energy for video content is scant and I'd rather just focus on game. So interest to make higher tier marketing content just is not there, and I am not convinced that people who follow youtube devlogs are even the same ones who buy the game in the end. Seems most "successful" devlogs are focused on the person and not the game, and do not correlate to more than moderate success of the game.
Anyway, just some thoughts! Would love to know if anybody has some opinions on the topic.
Getting close to six month review. I make a full review after completing my next milestone but a few short notes might be worth sharing here.
In previous six months I have:
completed prototype, which tested out a few combat mechanics and discarded many ideas to focus on a focused ranged-only design
completed preproduction, which figured out workflows for character rigging and animation, modular level art, programming architecture covering everything from gameplay scripts to UI to SFX integration, and cinematics
refined meta game design so that no major game design questions remain
iterated blockout of first level a few times, but not 100% finalized yet
hero character and 90% enemy models and animations are close to MVP
Next six months will be production of the vertical slice. I feel that it should go faster than that but we will see.
But first...
Before getting into production, I've decided to get a playable demo ready first. I am trying to get this finished in three weeks time. In first week I got code ready so that we start from a menu with basic accessibility settings, and then can go through the whole game loop.
The demo will be a wave horde battle arena that takes place just in one closed off section of the first level.
The intent for this demo is:
Start getting outsider impressions of the core game mechanics
Have a build that can be sent to publishers
I am not sure that I am interested in working with publisher or if I ever even get any reply. But I think it can be a good exercise to get a pitchdeck ready and go through full build process and start iterating on how I market the game. Best case scenario is some publisher is willing to help me with marketing and fund just enough so that I can hire some contractors here and there when needed, but they also stay out of my hair and don't try to impose anything that makes fun work not fun anymore.
Mostly likely scenario is I do a lot of work to be ghosted, but I think it doesn't result in wasted time because I need to focus on marketing material and presentation at some point anyway.
Art updates:
Modular Kit construction
Working on kit to be used for temples first. Because many of the buildings will be partially destroyed, it means that the interior construction will be exposed. So I need a kit that is composed of water-tight, individual construction pieces so that I can basically build and deconstruct temples and the innards at least seem believable.
I was having a lot of trouble finding good sizes that work for a lot of different temples shapes. What I learned is that rather than trying to come up with the small units first, define the largest units and then just divide them. Here is what I mean:
For max reuse and easy construction, I want for temples to always be in sizes like 10m, 12m, 20m, etc. Even though real life temples are usually like 73m or whatever.
I make a cube in maya and then use the Bounding Box Scale tool to set exact measurements. This is a handy tool and also works as a way to easily measure size of a mesh.
I have started by creating the absolute biggest wall any temple will have, and then I use insert edge loop tool to break it into individual bricks. The bricks end up being half meter increments like 1.5m, 3m. I am not good at thinking in math so I would have thought bricks need to be whole sizes and this is why I was getting hung up with walls that would not interlock together correctly.
The temple does not need to be historically accurate, but because it does need to be believably constructed it has helped a lot to do some research on how they were actually made. Thankfully somebody else has already done the research and compiled into helpful videos using 3d models already:
So this gives good checklist of parts needed and also a good vocabulary. So I get one temple created from this kit and then make sure I can make some variations easily, then I'll know that it is good to go.
Making enviro art seems to be the biggest time cost in project. Everything else I have pretty good picture how long each task takes. I think with enviro art I am going to have to look for many ways to simplify it so that it can be done faster. For a solo project I don't think it is sustainable to work only on one area of project for months at a time before reaching a milestone. For instance with characters I can make a new character and have it animated in project within 3-5 days. That is good because there is a big victory and clear progress at end of week. For level art it isn't going to do if it takes me same amount of time to make a single building though. So figuring out how I can simplify and get max reuse is major thing I'm focused on now.
Before sending in enviro art I've cleaned up the materials.
Using material instances it is possible to basically use inheritance but for materials. So I have a few hierarchies so that I can easily tweak value, color, and other parameters for various groups. For instance, I have all enemies sharing a common material, all enviro art another, pickups another, and so on. This way I can do things like make all enviro art slightly less saturated, pickups a little brighter, characters use an outline, etc, and only have to change a couple material instances, instead of dozens.
Replies
Shifted gears to some more techy stuff. Working on a tool to export objects by name from maya to a csv, and then in unreal this gets read and instanced static mesh components added for each.
The previous design was probably fine, however I have plenty of time before my first deadline and I think there are some major improvements that can be made both artistically and for gameplay.
I was having a lot of trouble finding good sizes that work for a lot of different temples shapes. What I learned is that rather than trying to come up with the small units first, define the largest units and then just divide them. Here is what I mean:
Using material instances it is possible to basically use inheritance but for materials. So I have a few hierarchies so that I can easily tweak value, color, and other parameters for various groups. For instance, I have all enemies sharing a common material, all enviro art another, pickups another, and so on. This way I can do things like make all enviro art slightly less saturated, pickups a little brighter, characters use an outline, etc, and only have to change a couple material instances, instead of dozens.
Some of this is showcased here: