How to Cave

Today's going to be a marathon of dwarf animation.

Just to get warmed up, I (mostly) finished my cave tile set.

Here's a half-size edition, with a superimposed grid so you can see where the tiles are:

This should account for every combination of wall and floor. The final tiles are 160x160. The art I made was 1600x1600. The spec is that the art should be made three times the final size, to enable future HD editions of the game. By making the initial art ten times the final size, I ensure that even the HD art is shrunk.

As the good book says, shrinking your art covers over a multitude of sins. The downside is my geriatric computer starts to choke whenever I load the original files.

I've made tile sets before, but only pixel art, so I had to devise the process for hand-drawn art on the fly.

Previous Experience Before Now

Just out of curiosity, how many of us who took the DevGame course were people with previous programming experience?  How much programming experience did we have?  Did any of the people working on the games now already know Unity besides Ender (who doesn't count because he wasn't an attendee, he was a TA)?

I had programmed off and on since I was a kid, but definitely more off than on.  My first game eva (called "Spy," written in BASIC on a Tandy SX, more time put into the ASCII art title than the actual game code) went to the State Fair when I was about 12.  Really it went because it was the only entry in the "Computer Programming" category in my rather rural county. There was a program to calculate molar masses in Chemistry class before I realized that I could do it faster without the program just typing in the numbers that I had memorized.  Another student asked me to make him a ship for a game he was writing for a programming class at school.  That was monochrome pixel art at its finest.  Looked like a scorpion dropping bombs out of its claws.

When the teacher retired, no one else in my little hamlet knew programming enough, so that class just disappeared before I got the chance to take it.  Not until a couple of  C/C++ courses in college did I get any formal sort of edumacation.  After getting married and getting a weird job tech supporting ancient telephone computers, I went back for grad school for about a semester and took a database course and a data mining course.  That said, most of my programming has been self-taught.  Is that how it is for most programmers out there?

 Flash Action Script was a big deal for me for animations and demonstrations in my classroom.  Then there was the ad hoc iPad app that I wrote for a grant proposal at my school, though it was really simple.  My greatest programming accomplishment before seeing the enemy ship shooting at me on its own in Star Battles was writing a recursive maze generator in Flash for my then four year old daughter who loved mazes.

If you're a programmer, how did you get into it?  If you're an artist... Ummmm...  Go draw something or write some music...

OOOOooooo! Pretty.

So little time in the day.  Sigh.

Star Battles has a new star.  Actually, the central object that provides the gravity and the challenge of avoiding it got a makeover.  But, we could use your help.

You see, there are about a trillion possible color combinations that could go on that star, and if we randomly choose, we usually get pukey sorts.  Instead, we want to pick from an array of preselected color schemes.  The more the better.

So, here is a link to a Star Color Picker (don't go there in Chrome, they don't support the Unity Web Player scripts anymore) that will let you play with the color scheme and find an awesome looking star.  If you find one you like, take a screenshot and post it in the comments here.

Here's what it should look like when you get there:

Slide the sliders around to change the colors.  The star pops up randomly from a range that normally looks yellow/red.  But, the sliders can make it all sorts of cool.

Elveteka Music: Improving Writing Speed

I need to improve my writing speed.

My old process: listen to what I've written. Analyze where music needs to go next. Theorize if proposed solution will work. Try proposed solution. If solution doesn't work, analyze why. Update theory of music. Repeat until solution found.

This is a great way to learn authentic music theory and a terrible way to meet a deadline.

My new process: Try whatever comes to mind. If it's slightly better than what you had, keep it. Never theorize. Just try and evaluate. If random tinkering works for medical research, it certainly works for music.

When learning the trumpet I was taught to be aware of my body while playing. I never heard of composers being taught to pay attention to their thought patterns while composing. I'm trying to root out bad habits:

• Get off social media. Turn off the phone. Exit blogs and news sites. (Just keep email open.)

• Don't listen to music over and over again. Listen once, think of something to change.

• If stuck, try something at random. Anything at all. Learn by engaging, not thinking.

• If I'm having a hard time evaluating a proposed change, it could be because I'm putting too much effort into playing it while also evaluating it. Enter it into the DAW and evaluate.

• Don't write everything on paper. Just write what's helpful to see on paper. Put the rest into the DAW. You can can see, compared to what you will hear, what I wrote on paper was pretty minimal.

In addition to these mental habits, I employed various tricks to speed up the process:

• Keep in mind counterpoint shortcuts. In my case that means all moves all valid except similar / parallel octaves and parallel 5th's.

• Trust experience. For example: I realized I was writing a lot of a parallel 5th's early on into the process, but realized that since the melody is based on 5th's, that's OK. Actually that's where much of the characteristic sound comes from.

• Tried all my old tricks first. I built the form around putting the melody in different registers, used pedal points, and employed tried-and-true textures like staccato strings over legato French horns.

• Used template from previous project. That's about 50 instruments that I didn't have to search for. For instruments I don't use very often, this saves me a lot of time.

• Stick to triadic harmony instead of counterpoint, and keep counterlines to a minimum.

• Hopefully I can this template for the entire project. I may even compose all my tracks in the same project to reuse the same mix settings from one track to the next.

• Certain thematic passages may be repeated in other tracks.

• Simplified mixing process: grouped 28 tracks into 8 submixes, five sections. mixed start to finish. Didn't mix from scratch but began with the levels I had set while composing. It helps that I set my levels intelligently from the get-go.

Along the way I had a few happy accidents. These were solutions I would never have reached through analysis but did reach through random tinkering:

• Choir parts alternating between big unisons and fully voiced chords.

• The chord substitution in the 9th measure. I simply replaced Bb with B natural and it's a great sound, whatever the proper name may be for the resulting sonority.

This is the final result. I may do another mix pass before the game is released, but I'm happy to put my name to this. Two minutes of music in about two weeks. I need to double my speed, but this is a good start.

Here, enjoy some random tinkering:

Duplicating and ordering sprites in Unity

The ART OF SWORD lead programmer contributes some Unity code that solves an animation problem to the DEVGAME community and explains its utility.

I was working on Art of Sword with the animation frames the artist had sent when I ran into a familiar problem; Unity's sprite Animations and AnimatorControllers do not allow you to use duplicate sprites, and neither do they allow you to specify the order of sprites displayed in the animations. That is, if you want to use a sprite multiple times in an animation, you have to include it multiple times in your spritesheet. And you essentially have to have each animation lined up in the spritesheet in order - duplicate frames and all - to let Unity's Animation system use them.

This is extremely inconvenient, particularly with the large frames the artist made and the grid-style spritesheet I had assembled them into. Without any duplicate frames the texture is 2048x1024 and contains 42 frames, each of which is 283x170. Obviously, I needed to write my own animator script. I already had a horribly kludged one from when I was first working on Art of Sword that required each individual sprite to be in a different texture AND I had to manually drag and drop each texture into the Unity Inspector. I still don't know exactly what was going through my head when I made that.

So with the new frames from the artist, I set out to write a proper animator that could take a single texture and give me an easy-to-use list of frames without my having to do anything more than copy the texture into the Unity Hierarchy. I came up with this:

Insisting on excellence

One of the things I try to teach in the DEVGAME class is to learn from your past mistakes. While I am a very good game designer, it has been said, rightly, that as a producer, I am mediocre.

The primary problem in this regard, I have gradually come to believe, is that I am too easy on the artists. I have a tendency to decide things are "good enough", which is usually justifiable on a piece-by-piece basis, but taken in the collective on the screen, tends to result in overall mediocrity.

I noticed this when putting together screenshots for one of the DEVGAME sessions. Simply by looking at a single screenshot, whether it was from DOOM, Rise of the Triad, Duke Nukem 3D, Unreal, or Rebel Moon Rising, a complete neophyte could have correctly identified the hit versus the mediocrity.

Consider the following image from the forthcoming game Art of Sword. It is a perfectly suitable image by a very good artist who specializes in 3D work.

There is nothing wrong with this image. In fact, the only reason I decided to bring in another artist to improve the art was due to the fact that the 3D artist is not an animator and some of the animation frames were a little too jerky to ignore. It was a borderline case, and in the past I would have decided that it was good enough, but applying my DEVGAME principle of not repeating past errors, I decided to throw another artist, a skilled 2D illustrator, at the game with an eye to improving it. Here is the result:

In all the substantive details, the art is exactly the same. What you can't see here are the additional animation frames that are now significantly smoother. But the sand texture, the brighter colors, the shadow, and the additional detail on the swordsman all add up to create a much more positive impression when taken in at the same time than the changes would otherwise be expected to make. (And yes, we will be doing something about the fonts, those are just programmer placeholders anyhow.)

The point is that as a producer or an art director, you must be more demanding of your artists than you probably think you need to be. And as an artist, you must be open to reworking and improving your art, even when you think it is good enough, because fairly small changes can make a big difference when taken as a whole.