Brian Crick

Mechanics, Mechanics, Mechanics

At last week’s game developer meetup, I got to talking about Tinselfly, and once again had to say that I just had an environment right now; there was no gameplay.

So I set myself the goal of having some gameplay by the next meetup, which is in two and a half weeks.

So far, there are these alien robot things, which are supposed to look, like, otherworldly and menacing and stuff. And I’d like you to be able to swing your sword at them, and I’d like them to fight back.

Robot-27-February-2014

I can probably get the basic swordfighting mechanic ported over from my sandbox game tonight or this weekend. And then I just want to keep revising it and iterating over it, the same way I’d obsess over a model. Thing is, I’ve hardly ever done this before. And when I’ve done it, it’s been within the context of a game jam, so I’ve spent no more than a day trying to fix mechanics once dropped into a project.

Two weeks just working on mechanics is unheard of for me.

Hopefully, if I can get myself to give this the same attention to tiny detail that I give my models, I’ll have gameplay that’s on its way to being as fun as my environment is pretty. 😉

* * *

I am, of course, trying new things to keep Tinselfly on track. But it’s also more than that. At game dev meetups, I am frequently motivated by seeing other people’s stuff; or even just knowing that other people are making progress. I want to return the favor, and make sure I’m not inadvertently making people lose faith in this whole going indie thing. I don’t want people to look at my stuff and think oh, there’s no gameplay here; you’re either a graphics person or a programmer or a game designer.

I’m frequently hesitant to break out my laptop at meetups, but It’s not so much about showing off what I can do. It’s about showing myself what I can do, and showing other people what they can do, too.

 

Immediate Deresolution

I’d like to talk about modeling a bit. I’m saying that up front because it’s gonna take me a minute to get to that part. 🙂

* * *

For a brief period in high school, I regularly had three dance classes in one day. At the time, and up until just now, I focused on the time I was putting into it: an estimated 14 hours a week. It was a pretty decent chunk of time.

But looking back on it, the number isn’t the only thing that’s important. The other important thing was that I had three separate and distinct dance-related activities.

Every morning I had a class on technique. Every afternoon was spent rehearsing pieces for an upcoming show. And frequently, between classes, I’d run off to the studio to work on choreographing and practicing a solo piece.

And in each of these three activities, my mindset was different. Sometimes I was focused on being creative; sometimes I was not. Sometimes I was trying to stay in sync with my classmates; sometimes it was just me, learning to keep an eye on myself in the dance studio mirrors; sometimes I wasn’t looking at anything at all, trying to develop a good sense of balance and positional awareness. There was a specific time for each little thing I needed to learn, to get better at what I did. And while I wouldn’t say I ever got to be a great dancer, having those things separated out, was, in hindsight, a great thing to have happen.

* * *

In an attempt to improve my skills and efficiency in, well, pretty much every creative thing I do, I am going to try integrating small-scale game-making exercises into my regular project rotation. It’s kind of like a different classroom environment. I’ve always been a fan of having multiple projects at once so they can kind of creatively feed on each other, but I don’t think I’ve specifically drawn a line before and said, these things are for production; these things are for learning. I want to make sure I spend time in both mindsets, and really commit to one or the other when I’m working so I can learn more about whatever I’m working on.

* * *

My first assignment is an arcade-style thing meant to teach me about level design. My second, which I’m working on at the same time, is a spaceship flight sim where the emphasis will be on modeling and making responsive, natural-feeling player controls. I’m afraid I don’t have much to say about the former right now, but in regards to the latter, I learned a little bit more about how to make low-polygon meshes this week.

My first job is to model a spaceship cockpit. Right now, it looks vaguely Star Wars-y: there’s a big, round window with a decorative grill.

Cockpit

And here’s what I’ve learned the hard way: making a low-polygon mesh is not about making a high-polygon mesh and then simplifying it. You have to think in terms of the simplified version before you even start modeling.

I’ll explain that by way of a simplified example. Suppose you want to model this:

deresolution1

If you want to use this shape in a video game, you have to turn it into something a video game understands: a mesh made of triangles. Like so:

deresolution4

While each triangle has perfectly flat sides, the appearance of curves can be simulated by using very small triangles. When you use enough small triangles, you get the appearance of smooth curves.

deresolution5

Unfortunately, more triangles frequently means slower games. It’s not the only thing that can affect the performance of a game, but it is something you need to worry about. And I always start off by making meshes with too many triangles.

The obvious solution here is to take the high-resolution mesh and systematically remove detail from it. Here, I’m using a subset of the points used in the detailed mesh.

deresolution6

Check out the area where the small circle meets the big circle — there’s a sort of Y intersection there. And in this mesh, the widths of the strokes all around that Y feel totally wrong. And the inner circle is a little thinner than the outer one.

What’s happening here is that I’m reducing the number of triangles in the mesh without any real awareness of or respect for when the mesh actually represents. I’m treating this as a series of outlines, like so:

deresolution2

The relationships between each of those shapes is getting totally lost. What’s really happening here, of course, is that I have two outlined circles that need to feel circular in the final product.

deresolution3

 

I need to not reduce the triangle count the intersection of the two circle outlines. I need to reduce the triangles in the individual parts of my mesh —

deresolution7

— and then combine the derezzed versions.

deresolution8

Now, that Y intersection where the small circle meets the big one looks much better.

I’ve also made a change to how the simplification of the circles happened here.

If I have this circle:

deresolution9

 

And this overly-detailed mesh:

deresolution10

 

And then systematically remove points on my mesh, I get this–

deresolution11

–I get a shape inscribed within my original, a shape which is much too small to be an accurate interpretation of the original.

The new mesh should have around the same area as the old one. Like this:

deresolution12

 

Note that the vertices of the hexagon here aren’t on the circle. My simplified mesh doesn’t actually contain any of the points on the old mesh.

* * *

Of course, it probably wouldn’t be that useful to model individual parts of something and then use your modeling program’s boolean tools to combine them. Rather, the thing I’ve learned here is that I should start thinking in terms of a simplified mesh earlier, and model that–rather than modeling something that’s too detailed, and then programatically simplifying the detailed version (whether it’s an actual simplification utility in your app, or just thinking too programmatically).

Copyright © 2017 Brian Crick.