This week both Adam and Dave have had to take care of some stuff. But never fear! Astrobase progress has not halted.
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.
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.
This week I jumped in and attacked one of those strange beasts that lie at the intersection between art, design, and code. A GUI (Graphical User Interface). We tend to split these up and do a bit of the work each. However this one was heavily dependent on work and systems I had designed, and Adam was busy with other super important code stuff, so I have been spending my time implementing the Species Creation UI. Or at least the first pass of it.
It’s a pretty intricate piece of UI. In part because it is tied to (and controls) the massive substance that generates portraits, and in part because it needs to have some UI elements and concepts that are non-standard.
This is one of the more interesting parts of working on a small team, you cant just hand stuff over to others once the task leaves the most narrow definition of your discipline but you sometimes end up taking it all the way.
This past week, I’ve been focusing on setting up some simple game settings. I specifically gave myself the ability to disable graphical features so my terribad computer could run it smoothly. I’ll be spending some of the weekend integrating Daniel’s connector graphics to really tie together the station graphically.
This week I wrote the sentencing parsing for generic actions that a character can execute on a mission. So, for example if a pilot avoids a plasma storm while landing on a planet, this is structurally the same in code as a character exploring a planet scaling an ice wall. They both have the form of subject, modifier (quality), operative verb, object. This is after a successful result has been generated that allows the character to execute the action.
My next step is writing the failure cases (unsuccessful result), which cannot be generic. If a pilot doesn’t manage to avoid the plasma storm, or if a character slips and falls while scaling an ice wall these are vastly different things. But I find failure more interesting than success, and opportunities for recovery or partial recovery (the character uses an ice pick to stop his fall, but now he’s stuck on the side of a cliff) to be where I want to spend my time.
I’ve probably posted before about having a system under which characters can be “creative” based on their skills and personality. But this is why each system needs to be custom per action category — how a character can be creative when trying to keep the shuttle from crashing is different than how a character can be creative when trying to survive the ice storms. I suspect some general patterns might emerge, and we’ll see what I can reuse.
Today we’re doing a Special Weekly Dev Update. This is a first for us so if there will be more in the future will depend on how you guys like it compared to the increased time investment to make them.
The goal of this is to (hopefully) give insight into how and why we do things, and perhaps help you better make your own games in the future.
The order of the discipline for the Specials is not in any particular order, in part because of our scheduling restrictions, and in part because its not really do one first and then the other. They tend to intertwine the entire way.
Astrobase Command is not a prototype. But everything starts in the beginning, and for games the beginning is a prototype. Prototypes are relatively small things and can be more easily explained and summed up than an entire production cycle. This is why the Specials will focus on prototypes.
This first Special will be Daniel talking about the initial stages of how he finds a style for a game. This is in part Art Direction and in part Concept Design.
Prototype Art I:
Making a prototype is a lot of fun. It’s a limited period of time where you get to fill your mind with new cool and shiny things. It’s something I’ve done quite a bit and always enjoy getting another opportunity to do.
Starting out making art for a new prototype I usually start by taking a while to get a feel for how it will feel to play. If it has any particular story elements tied to them or if it belongs to an existing IP that of course has to be included in the consideration.
Depending on if the vision overlaps with already existing art, or if there is a need to be extra unique, or if I already have a good visual library in my mind; my course of action differs. If I have a good visual library to pull from I skip ahead to either concepting or production. If I am exploring new ground I start gathering references.
References are super powerful but can also be very dangerous. References are basically any images or videos of stuff that has some element you like for your own project in it.
Their power is that you get to very quickly get a great way to communicate to a Concept Artist (or really anyone) what style of technology, creatures, mood, colors, etc you are aiming at. This is one of the cases where an image says a thousand words.
The danger of using references is that for a less experienced artist (or other people without a lot of experience in how to art) it is easy to just pick up a specific reference, instead of using it as inspiration, and make a copy of it.
Making a copy of someone else’s work aside from moral, and potential legal issues generally has the piece end up being boring and uninspired. So much of creativity in design comes from the individuals mind.
Another potential pitfall with using references is that if you find something where one element of it is a great fit for you it’s pretty hard to not let the rest of it sway you from your vision. Of course sometimes those things swaying your vision are valid solutions to issues you haven’t yet realized you will encounter down the road you’re going. You need to weigh this carefully.
Concept Art is a tricky subject as the term has become a bit blurry. Much of Concept Art that the average person sees from companies is not made to communicate how something should look between people on the team. To show the production artist what it should look like all you really need is the designs for the specific object and some information (painted or written) of what types of materials and colors it should use.
What you see from most games getting called Concept Art is really highly rendered, detailed, and polished illustrations. Much of their purpose is to be Promotional Art.
Now, there’s nothing wrong with promo-art. It’s not only pretty pictures but it also helps to communicate the style to non-artists, externals, and players. It does however take a lot longer to make than just getting the design down.
When a concept reaches a 3d artist it helps to have a nice picture for them to pull from but it is not needed. Most of the work done aside from figuring out the design of the object will end up being discarded as you can’t use a concept as a texture (usually), and even if you could you wouldn’t want to since it’s not compatible with PBR shaders or procedural textures.
Another consideration you need to make is if it is worth it to make a single concept. Especially when working on a prototype. I’ll go into that in more depth along with actually how to actually make the art for the prototype in the next special.
This week, I finally managed to wrap up connector construction, which brings us one major feature closer to an alpha build!
Since I’ve been spending a lot of time lately integrating a metric butt-ton of cool new arts assets, we’ve started to encounter performance issues on low-end machines. So, I also started looking into graphics optimizations and thinking about system requirements and settings to expose to players!
Hello, this week I’ve spent most of my time fixing things, setting up technical art stuff, and looking into how to balance visuals vs performance further. This is of course important work but not super shiny to look at.
I’ve been architecting what I hope to be the final version of missions (I’ve been through about 3 or 4 prototypes until I got happy with it). Nothing too exciting yet, last week I was finished up the mission launcher code that allows me to start new missions from our in-game debug console, and there was some behind the scenes technical stuff there left to finish off. The first step afterwards was implementing the shuttle landing phase, since this has to be a critical element with not just the pilot skill but giving the crew opportunity to react to things that might go wrong.
For example, if a player has an engineer on board, he might reasonably expect that engineer to be able to do something about the plasma storm shorting out the power conduit. Likewise a character with astrophysics might have an entirely different set of options. Since we don’t want to hard-code any of this (which would make it a simple problem X = solution Y), we essentially need a generic system that governs “sci-fi physics” which yields solutions to problems similar to what you might find in an episode of your favorite show, but does so in a dynamic and procedural fashion.
At the very bottom it comes down to a series of weighted rolls which takes everything into account, and I needed to make some bug fixes to the weighting system which became clear when I started implementing.
This is a Big System ™ with an enormous amount of depth, so I’m just taking the time to make sure it’s right and plays awesome when its done!