Revival!

It's been far too long since I've posted an update to anything here, but I should start getting back into the habit.

So where has all the time gone? Work, mostly. All of this was just something I could mess with in my off-time, and when that dried up so did this. No further updates to Omni, or the Tower project, but I'm not completely empty handed.

After years of meandering, I'm finally making a push to change my career and make this stuff my primary focus. Last fall I found Codify Academy, attended, learned, and graduated earlier this year. Web development is a bit of a shift from game development, but I ended up with an affinity for JavaScript which can help me do both. As such, this blog is going to be more focused on general development, and whatever I happen to be working on.

And that's not all! Along with my github repo expanding, I also now have a portfolio and a working app called Conclave (currently in open beta). Conclave is my first big project since finishing the Academy. It's a social platform built for the Academy, so mentors, students, and alumni have a central place to talk, share code, help with questions, communicate, and collaborate. It's built on AngularJS and Firebase, and will be a common topic on here as I talk about the ins and outs of how it works (and how to make your own!).

Feelin' good to be back.

- r.h

The calm after the storm.

It's been well over a year since the last update, which is just terrible. And for that year, a whole lot of 'not much' got accomplished with Omni. So what happened?

• Unemployment, so all my free time went into job hunting.
• New job, so free time got focused on that.
• Marriage, which takes a LOT of planning.
• Honeymoon planning, which is to be expected.
• Holiday stuff, which is always a mess, regardless of planning.
• Finally the year rolled over, and I found the time to actually work on the game.

I had also made a self-imposed rule that I wouldn't post here again until I had something to show for it. I've been working pretty solid for the last couple months, so here's what I have so far:

• A menu skeleton, complete with functional buttons.
• Re-Re-Re-Re-Optimized Unicycle, Bicycle, and Big-Wheel vehicle models
• The start of a brand new Character Controller
• A rigidbody version of the Unicycle, that is (mostly) self balancing and has some movement.
• A github repository. 
• A potential partner, as a friend of mine may be able to lend some time and help with the core coding.

So what then now? Hopefully, more frequent blog updates. Some about actual game progress, probably a few how-to posts with some code snippets, theory, I dunno. I plan on writing up a proper post in the next day or two about the movement module I cobbled together (Spoiler alert: it's a simple and common idea, but not exactly intuitive). 

In the mean time, here's a little something.

Unfortunately, I don't have a splash image, or even a logo.

This woulda been part two.

Part Two to the previous entry (regarding the animation dilemma) is long overdue. In fact, it went long enough that the problem sort of worked itself out. Partly. There's still a matter of practical implementation (actually doing it and making it work), but so far my current method of problem solving is working out alright. I basically keep looking at it, reading books and articles, watching tutorial videos, scrapping and restarting, and then eventually everything starts working. Then I scrap it once more to have a good working version.

Since the last entry, I've redone the Unicycle 4 times and it'll probably need at least a couple more fixes to get it just right. I was working on doing a whole custom Controller, Motor, and Camera scripts but I got the stock scripts working pretty well. Unity upgraded from 3.5 to 4.x now, and it's given me a few new things to play with and learn. One of those new things is improved scripting, and it works right out of the box so far. I'll have to tamper with the camera controls, but the vehicles actually move pretty well so far.

One of the other nice things about the new Unity is it comes with Mecanim: an animation studio. I've not had a chance to try it out yet, but it looks pretty extensive. There's a good chance I'll use it instead of the stock Blender Animation studio, but who knows. Lately, I've been more concerned with getting the controls working at all to worry about the model animation.

Another nice thing happened, Adobe Photoshop CS2 is now free to download and use for everyone! The way I understand it, it's too old to install properly on 64bit systems so Adobe dropped support for it, I guess to dissuade people from buying it. Anyway, supposedly there's an easy fix to install it on 64bit systems, so now I get free Photoshop to use. I really wasn't liking Gimp.

Here's where I stand now. Actually seeing it laid out is sorta disappointing, but not disappointing enough to stop me.

• Unicycle Model is complete. I fixed the Blender -> Unity conversion problem, redesigned the UVMaps so people can do custom textures easier. The Tire-Treads UVMap needs to be redone, but it's functional as-is. 
• The Bicycle Model rough draft is done, but needs to be redone from the ground up. The shape is alright, but it needs to be made a LOT more efficent. Then UVMapping, then texturing. 
• The controls actually work. The model faces the right direction and moves like it's supposed to. No animation is attached yet.
• A very very simple test level is set up. The platforms are simple enough that they can be created, moved, retextured, and manipulated in Unity on demand. 
• Music software is ready, but I'm still looking for better options. Still need to get a usb-to-midi cable and do some sample loops.

And that's pretty much it for now. The next thing to work on is getting the camera to move the right way, setting the speed/drag/friction settings for the vehicle, and expand the test level a little. Then I'll look into animation. After all that's squared away, I'll work on redoing the bike, getting it set up, and see about adding sound and/or music.

The next entry is going to be about fixing some of the Blender to Unity bugs I've run into, because it was damned hard to weed through the internet to find the answers I needed. They seem to be common issues, and I want to just lay out the answers very plainly for anyone else that's having them.

Decisions, Decisions Pt.1

Prologue: This is Part One of a bigger issue. It was originally one long post, and has since been edited for brevity.

I've had a new issue come up. Maybe issue isn't quite the right word though, quandary sounds like it might be more accurate. I need to make my models animated, there's two different ways to do it, and I'm not sure which one is the better choice. Unfortunately, it's not as clear cut as it sounds. Both have bigger implications further than 'do the animations, save, and apply'. The issue at it's core is whether the animations should either be

* Done in Blender, then imported to Unity, or
* Done entirely in Unity, by way of scripted events

Normally, this is a matter of personal preference; whichever program you're more comfortable in is what you use and you get roughly the same result. The result I'm looking for is controlling the way my models move in various situations: specifically I need an idle state (doing nothing), walking (moving slowly), running (moving fast), and death/respawn. This particular situation has an issue with what happens after you do the animation; how do you handle the movement and physics of these objects? This changes depending on which way you go, so let's just look at both cases individually to see what happens.

Animating in Blender, Importing to Unity
Animating in Blender is a little convoluted to explain, but pretty straightforward to do. In the animation window you select what frame you want to end at, position your object(s) at the beginning, reposition them how you want them to end up, and Blender does the rest. It's called Linear Interpolation, and the easiest way to explain it is that Blender measures the position, rotation, and scale of the object at the beginning and end of the sequence, then changes all the values linearly to turn State 1 into State 2 over a set amount of time. You can take it a bit further and change the Bezier curves too. Those are the "line" part of "linear"; it's a visual way to see how the changes move over time. For example, if the beginning is 0% and the end is 100%, maybe you want it to dip up to 110% right before it settles at the end. You can do that!

Rest assured, there's several dozen horizontal lines going on here. See all that stuff on the left?

Curves can get tricky though. Each possible value has it's own curve you can alter. That means for each object (the unicycle, for example, is 11 objects), you can alter Location, Rotation, and Scale for each of the 3 axes. There's also transparency, diffusion, shaders, and a few other traits that can all be changed in animation. If you're keeping count, that a minimum of 132 possible traits to be altered for an animation for a single (simple) object. If you were doing an entire scene, not only do you have to keep track of however many other multiple objects in the scene but also the camera, lighting, and the headaches involved with staging the scene properly. Thankfully I'm not, and most of my animations will be pretty simple.

Give it a little flourish!

Now let's skip ahead a bit and assume I've got my unicycle's 4 animations done and ready. Once I go back to Unity everything will be there waiting for me. All I have to do is write some scripts to say 'if this is happening, play this animation', then make sure they all work. A little fine-tuning later, and that's pretty much it.

It doesn't lurch forward yet, but look at it go!

Animating in Unity through scripts
This one's completely different, obviously. I still have to tell it 'if this is happening then do this' but I have to specify what 'do this' means. Like with most scripting problems, there's a dozen or so different ways to do it, but I only know one or two. Here's a (very dirty) quick pseudo mockup of what 1 animation state would look like for a "running" unicycle:

if (getButtonDown == "Right") {
   xVelocity = vehicleSpeed + xVelocity;
   if ((xVelocity > thisSpeed) && (xVelocity < thatSpeed) {
      gameObject.wheelAssembly.rotate (0, (xVelocity * 3.60), 0);
      gameObject.pedalLeft.rotate (0, (xVelocity * -3.60), 0);
      gameObject.pedalRight.rotate (0, (xVelocity * -3.60), 0);
      gameObject.yFrame.rotate (0, ((xVelocity / 10) * 3.60), 0);
      gameObject.yFrame.transform (localX + (xVelocity / 15), localY + (xVelocity / 15), 0);
      gameObect.seat.transform (localX + (xVelocity / 12), localY + (xVelocity / 12), 0);
   }
}

You can see sort of what's going on here. If the player is pushing 'Right', then increase speed. If the horizontal speed of the object is in a certain range, the wheel assembly rotates around, the pedals rotate backwards (to stay parallel to the ground), the frame tilts and lurches forward, and the seat moves to match the frame. Since this is being written from scratch, I can make it as versatile as I want. I could probably get the walking and running animations under the same set of conditions, I can change the values to fit whatever I need to on the fly (as opposed to going back and forth between programs testing values). I can also use this as a template for vehicles later. Copy, Paste, change a few variables around, and my next vehicle is animated and ready to go too. It takes a little more creative thinking to solve, but could easily save a lot of time.



There is a common issue to both choices though, and that's trying to make the animations and their physical movement line up properly. The appearance of sliding around just looks bad, as does awkward wheel-spin. While a big part of that is just tweaking the animation so things match up, an equal amount is handled by the physics in the game itself. That's for the next section though; it has it's own pair of choices to decide between.

The UVMapping Hurdle.

I'm actually writing this post while I'm in the middle of figuring this out.

This has actually had me stuck for a long while now, and that's model/mesh texturing. In a perfect world, I feel like you should be able to just directly paint onto the 3d object and save it as a texture file to use later. That's probably an option for the really high-end stuff, but when you use the free stuff beggars can't be choosers. I've known for a long time it's possible though, and it involves this thing called UV Mapping. I don't quite get all the technical bits about it, but the important part her is that UV maps take 3d objects and flatten them out into 2d schematics. Those 2d pictures are what you use to create textures on/with.

For a while, I thought I could get away with not doing it. I thought maybe if I could get clever enough I could make my models efficient enough that I could just do a simple material instead of a full texture. That doesn't work though, and at it's best it still wouldn't look that great. It doesn't help that it looks like it should be incredibly easy. Blender has a button that says 'Unwrap to UV' and another to 'Export UV map to png'. Over in Unity, you can apply a texture with a regular drag-and-drop directly onto the model.

I can't count how many weeks I've been stuck on trying to get this to work. Only right now do I think I may have finally cracked it, so here we go. Right now, I'm using the Y-Frame from the Unicycle as my experiment. It's a custom mesh made of 2 separate pieces overlapping. The top bar (the seat would be connected to the top) is a cylinder that flares at the bottom. That opening is normally hidden by the bottom half, which is another cylinder that's been elongated, bent into shape, and the ends have been tapered off where the axle for the wheel would go. Looks like an upside-down tuning fork.

It's also the front half of the bicycle.

The answer to my problems is a single button that says 'Mark Seam'. It's not very descriptive on it's own, but  it does exactly what it says. You pick out a line of points and click that button to create a seam in the object. Then when you go to unwrap it, Blender has a point of reference for how to unwrap it. I don't think there are any specific rules regarding how you're supposed to mark of the seams, like if you're supposed to open it top-down, or sideways, or whatever, so I went with what made the most sense.

You can ignore that one grey square. That's some dumb Blender thing.

That's a top-down view of both separate pieces of the frame. Now from here, I can export it as a png and use it as a texture template. This is extremely helpful if you have super hi-poly models, because you can craft intricately detailed models, flatten them out, save that texture, then paste it on a low-poly model to make it look identical. I haven't gotten that far yet, but I don't think I need to right now. My current vehicles are already low-poly and look well enough. It'll probably more important later when I start working on level art and assets.

Anyway, now that I have this uv map, I think I'm supposed to export it to Gimp, paint a texture file, save it, bring that back over to Blender, and replace the 'blank' uv map with the painted one. I'm still a bit fuzzy on details, but if this works it'll be a huge breakthrough. I still have to deal with getting it to work in Unity, but at least things are moving in the right direction.

There is still one other annoyance I need to solve in Blender. One of its options lets you split the screen up in many different ways, and each panel can be any combination of Uv/Image editor, Render Viewer, Animation Console, Default Workspace, and several other such choices. It's pretty handy and sometimes mandatory. The problem is that each window can be resized or created, but not deleted. Furthermore, if you shrink the window at all the other window(s) don't move to compensate, but instead just create a duplicate window. You can sort of resize it to almost-zero, but not really. The only way I know to fix it is to just save everything and restart Blender. Seriously, look at this mess. That's about a dozen different window panels of the SAME THING. Ridiculous. I wish I could say that that's the only time it's happened to me. Today.

Nollij + Progress

Copyright Bill Watterson, posted with the highest respect.

Note - I was recently hospitalized and am on pain-killers while writing this. I'm aware it's not a great decision to write in this condition, but I've been putting this off for a while. In any case, should my tone get confusing or long-winded, you know why. 

It's hard to quantify the current 'progress' of the Racer project. There were a few false starts, a couple restarts, and for all the time I've found/spent, I can't say there's any tangible progress made towards it. No new models have been rendered, no level has been constructed, no scripts written. That isn't to say I've been slacking off though; I've spent as much time as I possibly can working on making this game happen.

If memory serves me right, my last post regarding the Unity book. Since then, I've read nearly every page, footnote, article, and referred link it's had to offer. With less than 100 pages to go, I'm on the chapter regarding final deployment; how to build the program, last minute efficiency-boosters, things like that. The included tutorial that's run through the book was to make a simple first-person puzzler, and each section of the book shows you basic scripting commands and their practical usages. It's been sort of slow, but the "Survival Island" game is done now. The player is stuck alone on a sizable island, and the goal is to light the campfire to signal for help. One booth has a minigame where you throw coconuts at targets and the player is rewarded with a battery. After finding the other 3 conspicuous batteries, a bunker is powered and its door open, revealing a pack of matches. Total play time is about 2 minutes. Nothing exciting at all, but it's taught me damn near everything I need to know about making the rest of my game.

If I'm honest, it was sort of boring. It was difficult to stay concentrated on it long enough to actually do any of it. I stuck with it because I knew that even though it was taking a lot longer to get to what I wanted to do, I needed a proper foundation of knowledge first. Too many screw-ups have happened, a lot of time has been wasted, and I'd rather just spend a little extra time and do it better. Righter. More correct.

I've also realized that the occasional change of pace helps me stay focused. A couple weeks ago I bought some graph paper, some folders, a clipboard and a few other things so I can work on paper. It's actually been incredibly helpful. I've plotted out several different designs for menus and gui-buttons, character sheets, and I even drew out my Dev Level.

Level 0-1, Click here for big

This is the first thing I'm going to build. It'll have every element that will get used in the game. This includes power-ups, hazards, mechanics, misc items, event triggers, and anything else I can think of. It's strictly going to exist to figure out how things work and getting everything set right. Hopefully though, if I get everything set properly here, I can drag-and-drop it into the levels afterward and not have much to do in terms of 'creating' it.

To further expedite things, I went and got a Blender Book to go along with the Unity Book. It seems a bit more geared to person-character creation (as opposed to vehicular creation) but my track record with Blender so far hasn't been great. It may take making yet another pass at building my two basic vehicles, but at least then it'll be done more correct. I've not started reading it yet; I've wanted to finish the Unity Book and the tutorial project before I tackled it, but it's about to happen.

The next update should have either new vehicle models or some semblance of a playable level. Either way, it's starting to get fun.

PS - I've also been wanting to do an entry regarding the Tower project, but I don't think that's going to happen anytime soon. I recently had some computer problems and had to reformat. I've not reinstalled Visual Studio, and frankly, I think it's been too long that I don't remember much of it. Furthermore, I can probably do it a lot better and easier in Unity later if I really had to. It'd save me the time of writing an entire simulation engine. I dunno. I just feel horrible because EVERY open source SimTower clone I've seen gets about as far as I did, stops, then disappears. I wanted to beat the curse, but maybe not.

Working towards a demo level!

It's been pretty quiet on here, mostly because there isn't a lot to report. I think now though, there's enough little stuff I can scrape together and make it into a full dish. This is a casserole post, or a maybe blog-loaf; all the bits put together mostly cohesively.

The biggest thing that's been done since the last post was finishing up the Bicycle model and optimizing that and the Unicycle model. I'm happy to report that the Unicycle went from just over 23000 vertices to about 800, and the Bicycle went from about 65000 down to 1100. They still need to be textured properly, but they should work tons better once I drop them into Unity. Also, I need to figure out how to make them show up as box-colliders instead of mesh-colliders, because I think that may have also been part of the last performance issue.

With 2 models done, I do need to see how well they work. The last thing I want to do is waste a ton of time knocking out 20+ more vehicles and finding out none of them work. At long last, I get to crack open the Unity book and start learning. The immediate plan is to follow and recreate all the tutorial lessons in the book, render a few basic surfaces, plan out a very rudimentary level, attach controls to both models, create movement animations for both models. and finally see how they look and how they work. After I get the models moving properly, then I can go back and worry about texture/shading them.

I hate to admit this, but I've sort of gotten ahead of myself in two ways. I'm starting to look up music software and everything I'll need for that. I already have a midi-keyboard, and I'm forcing myself NOT to buy the appropriate cable, because if I do I'll just be caught up in music and making even less progress. Regardless, my big decision is whether or not I want to use Reason. Reason is a brilliant and powerful piece of music-making software, and I have a legit copy from years back (about 4 versions prior to current). While it does work, and I'm not technically spending money on it now, it's pretty expensive and thus, goes against my idea of making a game on a zero-dollar budget. It's a tough call. Thankfully, by putting off answering it I can't use anything, so I can stay on track for the time being.

The other thing from down-the-line that's showing up early is another game idea. Every now and then I get a vague idea of something that would be cool or fun, but I write those off as passing thoughts. This one has been in my head a few days now fleshing itself out. I'm not going to go into too many details now, but it's a detective game; a nod to text/point-and-click adventure games. Find clues, solve a major case, many different endings, all the basic points. This idea is so far in the distant future though; I'm trying not to give it too much thought but my head keeps giving me story-line ideas for it.

Be that as it may, the priority now is to finally get a taste of Unity. Once I have moving vehicles, I'm going to expand the demo level a little bit and do a (very) small release for people to try out. No idea how I'm going to host it, but I should probably start thinking about a website somewhere for it. If anyone has recommendations on decent web-hosting, drop a line in the comments here.