Weekly Dev Update – July 24th, 2015

Posted on July 24, 2015 by Daniel

Adam

Hello everyone!

This week was a quiet one so far on the programming side. I had to attend to other business to do my part in keeping this show running. Luckily, my weekend is wide open for wrapping up connectors once and for all (for a little while at least). So look forward to more of that next week!

Daniel

Hi Everybody!

I’ve been busy working on the heads this week as well. Finished up the tests I was doing and started in on the procedural textures, making all the masks and details it will need. Fun work but not really much to talk about or to show.

Dave

Hey guys,

This week I’ll talk a bit more about missions, as it is the major feature I have left to do before we are ready to launch the early access version.

To reiterate previous posts, the purpose of missions from a game perspective is several-fold:

1) Construct and tell compelling stories about the characters that are sent on a mission
2) Close the core systems game loop. Note this necessitates using a reward system, and also balancing that reward vs the risk of a mission (which in turn needs to be extracted from the planet parameters). A reward system is necessary to give players a reason to send characters on missions in the first place. The simplest “loot” examples are resources, food, medicine, parts, etc. But more importantly there is character progression, and specifically personality trait progression which in my opinion is the most interesting one.
3) Give a purpose to the various skills, stats, and traits that comprise a character, and the gear they are assigned, to give them meaning in game terms beyond the on-station gameplay.

Suffice to say, there are a lot of moving parts in the mission system, and it’s above all the one feature we need to absolutely nail in terms of both fulfilling its goals and doing so with a fun and interesting game experience.

Up until now, I’ve been working on various prototypes which test and validate individual aspects or functionalities of missions. This includes narrative generation systems that describes what a character does (and then the system that actually does it), conversation generation between characters, as well as mission structure and flow, and the various activities characters do such as combat, mining, landing, etc. And also all the auto-generated planets and planet features upon which the mission is taking place, which is the setting and backdrop and must be interesting and compelling in its own right. It’s not fun to explore a bunch of similar and samey locations, where it’s obvious and predictable how game elements are reused!

Now that I am satisfied with the results of these prototypes, I took some time to review the lot of them, and start planning the final mission implementation. So for example, the generated story system was using data I had hand-written (so as to isolate my variables) but now I need to feed it the auto-generated data of planet parameters which I tested in an entirely separate code module. And before that, taking a second pass on the planet location data and their organization within the systems, so I can generate good stories from that using the storygen system. Everything is tied together, and it should be.

In short, what’s left to do is putting it all together into a cohesive feature. The very first step here is defining the entire list of things which need to be (re)designed, (re)implemented, and/or integrated based on how their prototypes played, which I did last week.

Typically with prototypes, you test something to make sure it works, it is fun, and the game dynamics and aesthetics fulfill the vision. But in order to isolate that something, the prototype needs to live in a self-contained box to ensure it is a proper test. Then when you take it out of the box to integrate into the larger game, there are always adjustments that need to be made so the pieces fit with the other toys in the other boxes.

This week I’ve started grinding through the list of systems now that I am confident what the pieces need to look like, how they connect, and how their final put-together form should play.

On a personal note, I took a few weeks and moved to beautiful Nanaimo. There were a lot of reasons for this move, and I’ll tell you the one which occupied my thoughts.

My observation from working in the games industry is that the environment in which games are made at a human level (at least everywhere I have worked) is contrary to good games being made. It is counter-productive to live in a concrete and glass office building from 9-to-6:30 and “be creative.” I could ruminate on the intricacies of this subject for at least an entire post, but I’ll spare you the think piece and simply say that as long as I’m working from home remotely I might as well live in a place I find inspiring. And if one believes games to be creative works, then it is also logical to assume that this matters to the results.

Weekly Dev Update – July 17th, 2015

Posted on July 17, 2015 by Adam

Daniel

Hi Everybody!

This week I’ve mainly worked on the face meshes. I’m working to get a base mesh that has the flexibility of being adjusted to allow for different face shapes, parts and variations among those. While also making sure that it is light weight enough to have many faces on screen at once, and making sure that it has the ability to support the possibility of facial animations should we find the time and budget to add such things.

I guess the TL;DR would be: I spent this week making faces, again.

Adam

Hey there Space-friends!

It feels good to finally be back online and working on our favorite space nerdfest again! I spent the last few weeks working out an emergency move to a different location in Montreal. Glad that’s done!

This past week, I focused my time on fixing up a bunch of the existing code to accommodate connectors in our construction flow. The tl;dr version is that the code previously assumed that all station modules contained rooms and could be walked through. However, we now distinguish between peripherals, walkable modules and walkable modules with rooms inside them! I know code architecture isn’t the sexiest thing in the world, but I for one am glad to know that particular problem will be sorted for future station parts!

I also spent some time working on character conversations. I haven’t touched the AI code in months, so getting two people to stop each other in the hallway to start a fully-fledged conversation based on one of Dave’s awesome conversation systems is going to take some doing.

Dave only just wrapped up his own move, which was much more dramatic than mine. He drove all the way across Canada to move into Vancouver.

VancouverTrip1

VancouverTrip2

But, after a long road trip, he’s back online and starting to tackle missions again. You’ll hear from all of us next week!

See you then!

Special Weekly Dev Update – July 10th, 2015

Posted on July 10, 2015 by Daniel

Hi Everybody.

Today Daniel is back with a Special Weekly Dev Update, or a SWDU if you would. Actually, no. Don’t, thats not great. Maybe SpeWeDUp? Hmm, no something is a bit off about that too. Anyways, lets get on with it.

Game Art Balance I:

An easy mistake to make is to think that by balancing two things means there should be equal amounts of each. Nothing could be further from the truth, most of the time balancing things against each other means figuring out how much you can squeeze into the less important without messing up the more important one.

Today we’re going to be looking at three of the axes of game art; fidelity, stylization, and utility. But don’t fear, there are many more.

To begin lets look at what they are.

Fidelity.
This is what many think of as the amount of detail something has. For example a character made of 100,000 polygons and 5 * 8192×8192 textures has a higher fidelity than the same character made with 1,000 polygons and a single 256×256 texture. It’s however different from detail, lets say you have two Cubes that to your eye, even on close inspection, appear identical. And only when you look at how it was made can you tell that one has much higher polycount and texture size than the other by several orders of magnitude. In this case there is a difference in fidelity but since the extra fidelity is not used to add anything there is no difference in detail.

Stylization.
This is how the Art Direction deems the asset should look. For example if you’re making a mushroom for a realistic FPS game you probably wouldn’t want to make it look like it belongs in Mario Kart. This impacts everything from what shapes are used to what style the textures are painted in to the proportions of an object.

Utility.
The purpose of Game Art is ultimately to enable gameplay. An object needs to communicate what it needs to to the player and it needs to be as usable as it is expected to be by the player. If you are making an explosive barrel, the color that screams explosive barrel to the player (so that they can see which barrel to shoot) is red so it needs to be red. But it might also need to be big enough to be easy to shoot but not so big that any stray bullet will hit it.

Knowing this of course brings up several issues where the needs of the different axes conflict with each other, some more obvious than others.

Fidelity vs Stylization:
You are making a chair, the poly-budget is high enough for you to make two chairs in the target style, what do you do? Stop wasting time on making two chairs, just make one at the target style and be happy you could get in under budget.

Fidelity vs Utility:
You are making a pistol for the first person view, these are usually pretty high-poly. However the game needs to run at 60 fps and your pistol is eating up 10% out of the total frame time, double what is acceptable, now what? This one is a bit trickier, mainly because there are different solutions. You can optimize, reduce the fidelity until acceptable. You can start over with the ingame mesh and get it right. Which of these is faster really depends on the situation. Another option would be to, if you never see the pistol from the opposite angle (since this is the first person version), cut off the entire opposite side of the pistol.

Stylization vs Utility:
You’re making that lovely red barrel. The style has it looking awesome, fitting in perfectly in the world. But playtesting shows that the player can’t find it. To remedy this you could make them much more brightly colored and bigger. However this would make them not only look completely out of place, but also ugly. The solution is to figure out at what point of compromising between the two you achieve the optimal balance. Or, if possible, figure out a way to get both utility and stylization. This is of course much easier said than done.

These things might, especially the first two, sound super obvious but they are still common mistakes. Sometimes due to inability figure out the balance, sometimes because they ran into the deadline, and sometimes because of stubbornness, a refusal to admit the requirements of reality.
This is why many games run poorly, look like crap, and are unplayable.

Now, this is just scratching the surface when it comes to what you need to find the balance for when making every single piece of Game Art.

Weekly Dev Update – July 3rd, 2015

Posted on July 3, 2015 by Daniel

Hello.
This week both Adam and Dave have had to take care of some stuff. But never fear! Astrobase progress has not halted.

Daniel

Hi Everybody!
This week I started with making the first pass on a system to manage special effects. This allows us to bundle particle, sound, and other effects into one package. Set up timing and other things on each part of the total effect. This allows not only for a lot more control of how they are played to make a cohesive whole, but also enables a greater amount of re-use of the individual effects.

In addition to that I recorded, processed, and cleaned up some complementary mocap. Specifically generic conversational animations, eating animations, and working animations. This should make working feel more varied and let the characters conversations not only be made up of emotive animations.

Special Weekly Dev Update – June 26th, 2015

Posted on June 26, 2015 by Daniel

Hi Everybody.

Today we’re doing another Special Weekly Dev Update. Daniel is continuing right where he left off.

Prototype Art II:

Concepts, are they worth it?
The short answer – No.
The long answer; Yes. No! Maybe? You see, it really depends on what the scope and deadline of the prototype is.

Sometimes the goal is to have a full pitch package, with a playable bit of game accompanied by concept art to show externals a wider view of the world along with the narrow bit of gameplay you present. If that’s the case, and assuming you also have enough time to actually accomplish it the answer is Yes. Without a doubt.

Sometimes your prototype has a deadline only allowing a scope containing nothing but a playable you really don’t have the time to put into making concepts, since they aren’t intended to be presented. So, no.

Of course there are any number of circumstances where it’s a maybe. Not only just the time and planning needs to be taken into consideration, but also things like the strengths and weaknesses of the involved artists as well as who the target audience is.

What tends to be the answer from my experience is that the deadlines are too short to do both. The reason is simple, it’s generally quite risky and the cost of having employees (or yourself) do this stacks up very quickly. Of course, sometimes it ends up being the playable bit that is dropped and concepts/pre-rendered images are favored.

Now, assuming you picked one path and you’re now ready to art it all up. So how do I do it?

Since making a prototype is generally a very time-boxed thing I usually start planning out what is needed by writing a list of everything I find is obviously needed to describe the game. I then sort the items on the list into different categories;
* Things that are essential.
* Things that should be in.
* Things that would be nice.

It’s not important to have everything listed from the start. I just list the things I can think off and then during the process I add things come to think off that are missing from the list, as well as remove ones that have become invalid. And of course, the categorization of any listed item is always up for re-evaluation.

With the list in hand I just start making the thing that I have the clearest mental image of and is most essential. There’s no real time to reflect too much, things need to get done so I just get at it. The biggest danger of making a prototype (assuming you have a deadline) is to not get it finished in time due to unexpected turns in making it. For example you might discover that the characters need to be a bigger focus, and therefore need a lot more work to hold up. Or maybe you realize that you might be able to squeeze in a second level set in a different location instead of just making the one.
In order to mitigate the risk from this unknown the safest approach is to have an iterative process. I make the essential items first, at the lowest acceptable quality level. I then evaluate depending on how much time I have left and how much is left to do.

If I’m already running out of time, I do what I can to polish up what I have.
If I’m good with time just go ahead and do a first pass on the next tier of items.

Once I’m at about halfway to the deadline (or when I cant think of what else to add) I generally want to start a quality pass. At this point I have a decent picture of what is done and what the target is, so it’s easier to know how much I can afford to bring up the overall quality and it’s easier to spot what is sticking out the most and potentially address it.

Sorry about the wall of text, this is a pretty theory heavy part of Game Art and it’s hard to illustrate something like this with graphics. I tried to be as brief as possible but I tend to go on quite a bit when discussing topics I’m interested in.
In the next Special Weekly Update about Art I’ll talk about how to balance fidelity, stylization, and utility.