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.

Baby's First Performance Issue

A couple days ago I decided to jump the gun a bit, and now I'm glad I did because it's taught me something new and caught a huge mistake early enough that it can be fixed.

One of the downsides to working alone and self-teaching is that it's incredibly easy to miss things, big and small. What I missed was that there's an inherent limit to the amount of "stuff" that can be rendered at any one time. And that makes sense to me, computer power isn't infinite. What I did was grossly overestimate how much stuff I've actually been making. Take for example the following:

Cue the circus music.

That's the first vehicle, made over one single night. It's not textured or properly shaded yet, but that's ok because it'll be easier to do in Unity. Since I'm all about efficiency, I can take parts from this and use it for the bicycle model I have planned and save a fair amount of time. Looking back, I still maintain these are good ideas in the right direction, but I was slightly wrong because I didn't have enough knowledge. Here's another look at the same unicycle:

POLYGONS!

That's the 3d mesh version, and if you zoom far enough in you can manipulate each individual vertex, line segment, or polygon. This unicycle is made of a little over 32000 vertices making nearly 27000 polygons. To put that in perspective, the models Capcom did for RE5's cutscenes only have about 20000 polys. Of course I only just now looked that number up, but maybe you can see where the problem is. At the time though, I'm still proud about making a pretty nice looking model. Charged by this excitement I wanted to drop it into Unity right away, put some basic movement scripts on it and see how it looked.

It didn't go well. To be honest, it didn't go at all. It took minutes to render, and when it finally did, the fps dropped to about 0.2. This was from only 1 (relatively simple) vehicle and 1 plane (4 vertices and 1 face). If I go through with making this an 8-player simultaneous game, then adding the the level and all the decorations, I can only think about my computer melting because of it. I was disappointed that this great job I did turned out to be not great, but more disappointed that I'd have to go back and redo a lot.

Optimization is mandatory. It's not something I wanted to do at first, but it's necessary and it's given me more ideas on how to streamline things for later. Looking around on Google for a while, I came to realize the following:

* It's not so much about the polygons as it's about the vertices.
* For each mesh, take into account the number of materials and shaders applied, the complexity of the physics applied, and the number of attached scripts. Each of these gets refreshed on each redraw for each frame and can tank performance.
* Redundancy is a bitch. If an asset (a tire, a seat) can be reused more than once, save it to a separate file and rebuild the object(s) in Unity later.
* Baking is something I need to learn. Yes, I'm well aware of the irony.
* A sense of scale is important. There's no sense in making ridiculously detailed models if it's too small to be seen. Those tire treads above? 23k vertices and they wont hardly be seen by the time you scale the model down to fit in the level.
* Similarly, there's no reason to render things that can't be seen. Any "invisible" polygons are just wasting time and power.


Baking (as mentioned above)... I don't know hardly anything about this. From what I gather, you can break meshes down into flat files to make thing render easier later, or something? I'm supposed to use it on high-res models to apply to a low-poly model to make it look really high-res, but Blender doesn't make it easy to figure out.


All of this leads to me cleaning up my models, redoing a few of them yet again, and trying to build them "differently". As mentioned above, redundancy can be worked around but you have to have each piece separate from the whole. With the Unicycle above, almost all of it can be reused for the bicycle later, so the Seat, Pedals and Assembly, Wheel, Spokes and Metal Rim, and Y-Frame have to be separated to be imported later. Once I get to Unity, I can import each individual object, put the pieces together and save the schematic as a Unicycle GameObject. After I finish making the bicycle frame in Blender, I can add that too, use the other imported parts, and make a bike with only one new asset. It's a bit disjointed to think about, but if it's going to make things run better than I'm all for it. Here's a preview:

Look at all of those vivid colours.

It still has a long way to go, but it's going alright so far. You can see the reused Unicycle assets here, but it's the "unoptimized" assets. Since making that bike, I've cleaned up the Unicycle a bit. I've reduced the vertices from 32k to just under 5k just by cleaning up unnecessary things. Rebuilding the bike wont take much time, and the only new asset to clean up will be the bike-frame and I'm not even done making that.

After the bike, I'm working on the next vehicle. I'm making a pogo stick.

Book learnin'

I burned through one of two books already. I'm going to try to keep this from turning into a book report, but it was definitely a good read, and very necessary. It's given me a ton to think about, new ways to think about things, and pointed out a billion things I had completely missed. (see edit at bottom)

Armed with all this new knowledge, I stopped playing around with Blender and Unity and started writing and brainstorming instead. In just a couple days, I've scribbled out a dozen or so pages worth of ideas. Notes, maps, screens, sketches, half-assed ideas, lists, really bad ideas, all sorts of things. Now I'm refining them all and sorting them into coherence by typing them up. I can't type maps and sketches, but that's probably just as well. There's something fun and calming just writing up a bunch of bizarre ideas and seeing where they go.

Anyway, all of this has helped me get together some new ideas and a more focused direction for where I want to go with the game. My next big push is actually going to be going back to Blender to work on more vehicles. On the idea list, I'm up to 17 vehicles (and counting!). I have no idea how many are going to make the final cut, but I'm aiming for a minimum of 10. A bigger constraint on the number of vehicles isn't so much about making them visually different, but more about making them handle differently in the game.

I've come up with 4 basic modifiers for each vehicle, being Top Speed, Acceleration, Jumping Height, and Rotational Velocity (specifically, how fast they can turn around any 1 axis to perform tricks). It'd be frivolous and a waste of time to have 3 vehicles with otherwise identical stats, though I may circumvent this by adding special abilities per each vehicle. I've been toying with the idea, and while I like it, I'm currently a bit stuck trying to figure out what some of these things could do without completely shattering the balance of the game.   In the short term it may not be much of a problem, but later I want to (eventually) add competitive multiplayer, and if everyone only picks 1 specific vehicle all the time then everything else is just a waste.

I'm sure eventually it'll all get figured and sorted out. First thing's first though, need to get back to modelling. Not going to lie, it's not a fun gig for me. Ever since Mario 64 came out I've had problems with manipulating 3d objects in otherwise 2d space. The clunky ui in Blender doesn't make it easier, but at least I'm finally starting to get the basic concepts enough to do something worthwhile. Slow going, but it's picking up some speed. Will post pictures of new models/concepts in a week or so.



edit - The book in question is this one. I'm not trying to advertise or anything like that, but it's well worth it's price; more so since it's discounted. It's a bit cheesy at times and aimed towards beginners, but it's amazingly thorough, comprehensive, and easy to understand. I highly recommend it if you're starting out in gaming. It's mostly oriented towards wide-appeal adventure games, but the information is broken down far enough that you can apply it to almost any genre.

edit 2 - What the hell was the formatting error all about?

Filler.

I'm afraid that this is more an update of reassurance. Yes, this is still a thing, and yes I'm still working on it. It's just been very short going lately, with a lot of setbacks.

The first major setback was finding out that the vehicle model I spent so much time on was broken. Specifically, some of the meshes had randomly missing faces, so that when rendered in Unity everything looked horrible. Not only did I have to make a new one, but I had to learn a new method to prevent against this happening again. The silver lining is that regardless of how annoying these setbacks are, it forces me to learn and actually gets easier each time. This will be a big help later.

In the interest of time (and perceived progress) I decided to skip designing an entire vehicle and instead opted for the simplest of vehicles; a single tire. No hubcap, no axle, no calipers or discs or anything else; just 1 object that can rotate around 1 axis and move in 1 direction. Simple enough, and exactly the thing I need to start learning to script in Unity.

This offers a new issue though. For all of it's greatness and ease-of-use and compatibility, it's really strange that you don't have direct control over the actual core of the code. If I'm using a standard IDE like VisStudio or Eclipse, you're working with something that's little more than Notepad++*. You type in everything (with some helpful auto-completion), compile, link, build, and run. You write functions, create classes, set up case-switches and if/else conditions and do/while loops. The contrast is that Unity attaches scripts directly to Objects. There is no int main() that governs everything. There's no source files to look at or change. While I had some idea of this before, it never occurred to me how counter-productive it would be. Each object gets a class script that manages how it works, but everything else is done through the ambiguated Unity interface. 


Don't get me wrong though. It's definitely a very clever system. Whenever you attach a script to an object, all of the public declarations are shown in Unity. Want to change a string? There's a text-box right there! Is there a double that you have set to be true only between values X and Y? Not only can you change the number on demand (with safety checks to make sure it's within bounds) but if applicable it gives you a slider for the specified range. These might sound like little things, but I have to appreciate it. It's unobtrusive, automatic, and as far as I can tell it can't screw it up. At worst, it wont bring the values in, which generally means you messed up and have to fix something anyway. 


So, where does this leave things? 


Realizing now that I'm struggling to grasp the basic concepts of what I'm trying to do, I've had to make concessions. The most important is that I broke down and spent money on the project. I'm not thrilled about it, nor do I like making excuses, but it had to be done. I ended up buying 2 books to help me through this. One of this is a reference book for Unity, inside and out. The other is more about game designing in general, encompassing all parts of game making. It sounds a little hokey, but it's actually a good read from a guy who's worked on several recognized titles. I'm not even a quarter-way through the book and it's pointing out a lot more things for me to think about.


The short-term plan is to read the entirety of the second book, the majority of the first book, and then pick up scripting again. By then, I should have a better understanding of this stuff. In the meantime, I'm coming up with a list of details to eventually work out, though I know most are not important right now. 


Also, the official working title for the racer project is now Omniracer. Or possible Omni-Racer. 

There's a slight change in plans.

I've had to make a decision, and it's that I have to drop mobile gaming for now. PC and Mac support will stay, maybe eventually I can port over to mobile, but it's not going to be my target platform anymore.

There's a few reasons for it, and I could go on at length about the nuances of whatever, but it all comes down to the simple issues of Time and Money. To develop cross-platform for Android, iOS, PC, and Mac, it would cost nearly $1000* in licensing just for Unity. If I chose to drop Unity altogether, it would mean either A) a downgrade to 2d sprites or B) finding and learning yet another language (which would more than likely cripple the idea of cross-platforming). In either case A or B, I'd have to go back and learn even more stuff, start over from scratch again, and probably still stuck paying for software licenses.

As it currently stands, sticking as close to the vague "plan" as possible still sounds the best idea. I can keep going in the direction I'm going and make non-mobile games for now with no changes or loss-of-progress. I'm not entirely happy with the whole thing, but I hardly have a choice. This whole project is founded on the idea that I can make a game from scratch, on my own, in my free time, for practically zero financial input, and make profit from it.

Sure, I could just pirate the whole thing. Easily, in fact. It would be a bit suspect if I was suddenly (and publicly) using software that's worth 3 months of rent though. Also, somewhat tied into the sentiment above, I'm still sold on this idea that anyone can do this, and an entire studio-suite of software doesn't fit in with that ideal. I'd be lying if I said I didn't think about it, but I did decide against it.

On the bright side, this actually does give me a few more options now. Mobile gaming is good in its own right, but for actual "gaming" it's usually handicapped by its own limitations. Screen size and resolution, processing power, controls**, these are all things I don't have to be as concerned about. Testing will be a lot easier. I have other new options now too, in regards to game engines and languages as well. I only just found out that Unreal Engine 3 is free to download; how cool is that?

In other news, modeling is still very slow going, but it's going in the right direction. I'm trying to move more into using Unity than using Blender, but it's still a lot to learn. I found some more tutorials though and I'm making some progress. After I have the meshes all set, I'll figure out how to decorate and/or color it, then see what I can do about making it move.

* - That's just for the ability to save in Android and iOS formats. Unity Pro costs over $3000 by itself.
** - Say what you will, mobile gaming flat-out sucks because of three words: No Tangible Buttons.

Literally reinventing the wheel.

Several days later, I don't have nearly as much to show for it as I'd like. I've made and destroyed three different models so far, and I'm working on number "about-three-and-a-half-ish" right now. The more I make them, the more I realize that I hate the design and need to learn more. Seriously... while I'm picking up on the nuances of Blender, there's so many options that it's still unwieldy to use. Watching a 20 minute tutorial takes upwards of 2 or 3 hours, and only scratches the surface of one particular thing (usually without actually explaining the "how and/or why" part of things).

I know I harp on this a lot, but Blender is nigh-impossible to to use without tons of external help and support. An example I came across earlier; want to open a background picture to trace over? First, you have to push N to open another menu (by default this is turned off (Seriously? A hidden but important menu?)), check Background Images, expand that menu, click add image, search for the image, apply the image, expand the View menu, change the opacity (default is 0; completely transparent) and size (default is miniscule), accept the changes, AND THEN you have to find it. Because it's a 2d image in 3d space, it's only viewable when the camera is locked to one of the 3 planar views. All of this to open an image you can't even manipulate. But I digress.

The first design was a flat skeleton that didn't have any textures applied to it (because I couldn't figure it out). It had the basic shape right but wasn't more than a flat white bumpy cylinder and box with 2 tubes on it. The second model was about when I figured out how to smooth the surfaces AND add colour. Still a far cry from where it needs to be, but inching closer.

Model 2: For legal reasons, this is not a Segway(tm).

See that tire texture there on the right? You'd think it'd be easy enough to line it up proper and texture the wheels, but then you'd be wrong. I can't even recreate how awkward it looked, but take my word for it; it looked less like treads and more like bluish marbling. Horrible. It had to go. The third design was a smidge better. A couple minor changes to the body (seen below), but nothing amazing.

Model 3: Untextured

Model 3: Textured, still horrible.

I tried adding a brushed-metal texture to the frame of the body, and the result was... less than desirable. It's like I'm slowly progressing through history; starting with Starfox SNES and ending up just before Quake with all the visual effects turned down. The current version has a long way to go, but has stepped up another generation.

Model 3.5: Gentlemen, BEHOLD!

This was another case of things being non-intuitive, but at least I figured out how to design proper tire-treads from scratch without textures. This was a complete rough-draft design, they're not great, but I'm not too worried about it. I'm actually fighting the urge to go back and re-re-re-redo them. On a tiny screen, no one is going to be able to see the tiny details like sidewall writing. The next thing to tackle today is finishing a new rim design. Then the main gearbox/motor/platform assembly, the steering column, and the finally the handlebars. Only then can I worry about other things like level design and assets.

Given the current pace and workload, I may have to pare back the total number of vehicles. I had planned for 3-5 different selectable vehicles but right now I dunno. I'm more concerned with getting 1 vehicle and 1 track finished and working, at which point I'll have figured out enough infrastructure to add more later.

The "joys" of working with Blender

Amidst all the madness of E3 I found some time to start official work on the games. Most of the 'planning' stuff is already done, I have a decent idea of where I want to go and how to get there, I can sort of the details later when I get to it. The first step I took today was making the models. I gotta say though, it's a very slow start.

Given 2 programs, Blender and Unity, I know (roughly) what each one is capable of, but not their full potential. The original plan was to make all of the models in Blender, import it to Unity, and finish everything there. My first impressions of Blender aren't entirely positive. I'm familiar with Photoshop and Illustrator and the like, but Blender has billions of options and nearly all of them are unlabeled. Options disappear, reappear, and change dependent on which mode you're in and with which type of object you have selected. Most of the basic/common actions are bound to the keyboard but there's no real mention of this anywhere. The fact that I have to use a tutorial to figure out how to do the most basic things isn't a great start. It took me nearly half an hour to figure out how to move the camera, which is ANOTHER dumb thing. It's mapped to the middle-mouse button of all things, which means I can't use it at all on my laptop, and I had to manually remap my mouse to make it work.

GAZE UPON MY INFINITE COMPLEXITIES

BUT! After all that, if you can look away from the labyrinthine layout, it's actually pretty nice. I haven't figured out how to apply textures (even though I see options for it all over the place none of them have actually done anything yet) but I feel like I'm getting close. By the end of the day, I hope to have that sorted out and have a fully functional model.

In the interest of experimenting, the next logical step was to move to Unity and see what I could do. Importing Blender files was surprisingly easy, which is promising for later. The overall layout is a lot cleaner, but therein lies a new problem. It's intuitive in exactly the opposite direction from Blender. It's easier to choose objects, but harder to manipulate them. It's easier to move the camera, but I can't figure out how to re-position it to point a different direction. It's easier to fine-tune the exact coordinates and sizes or objects, but they can ONLY be changed by manually typing out exact decimal numbers for each individual object.

Less is More is Less.

To be fair though, just because I don't know how to do it (I only looked at it for about 30 minutes with no tutorials or background) doesn't mean it can't be done. It may ultimately be easier than Blender for all I know. Personally, I'd prefer to do it all under 1 roof instead of shuttling files around between multiple programs, but I suppose a single one-way transfer isn't too bad. That was the original plan after all, who am I to stray from it?

Day -3ish, Project Ideas and Planning

Rereading my last post put some things in perspective. Namely that my sights are set pretty high, and there's a lot of work to do over a long period of time. I'm aware of that, and I'm trying to keep myself grounded, but optimistically realistic. I'm not going to make the next Minecraft or Fez or Narbacular Drop, I probably won't have finished product by the end if the year, but maybe I can make a few extra dollars worth of beer money for a bit. I'm quite comfortable with that idea.

Keeping all this in mind, I'm trying to keep everything from here on out clear and focused. Mostly. Wiggle room is always nice to have. Anyway, I've narrowed my scope to 3 games, each with a specific plan of execution. None have names yet, but I'll be referring to them by their base  parts until they do.


1) Racer - A 2d side-scrolling platformer, released as a mobile game. With a proper setup, level/character design should stay simple. Ideally released as a demo (limited number of maps, 3-5 maybe?) and full (possibly extra vehicles, many more maps, possible multiplayer support). If at all possible, no ads on either. The original draft of this idea was a sprite-based Java game, but Unity may prove to be better.


2) Space - A multi-phase game centered around the idea of space exploration. I intend for this one to be far more involved than the previous one, so it can't/won't happen until after I know I have a decent grasp at all of this. With the game itself, I plan on having a "logbook" of semi-random collectibles that occur during normal gameplay, and is ultimately viewed as a 2d map. The unfortunate thing is that I'd like to have real names & representations of established scifi/space related entities (The Enterprise, an X-Wing, etc), but I'm pretty sure there might be some legal issues there. While I don't mind the extra legwork of figuring that part out, I don't have a clue HOW to go about it. Like the previous game, this will be released as a mobile game. If I've figured out iOS stuff by then I'll certainly port it over. Barring that, a slightly longer term extension of the project is to redo parts of the game for a release on Steam.

3) Tower - This one is a labour of love, and I could wax poetically about for a long while. It's an open source clone of SimTower, written in C++ for pc. It'll be released online for free, probably through Github. Because of the nature of the project, I only really plan on working on it sporadically but I'll be more apt to discuss it and share some/all of the code as it happens. I've already started on this one a couple months ago, and it was delayed because of the Minecraft server. This will be the thing I go back to when I need to clear my head, and at all costs I'm determined to finish this one.


So that's it. That's the plan. Just make 3 completely different games, in different languages, from scratch, in their entirety, without spending any significant amount of money. No problem, right?

Day -?, The toolbox

Day counting has become temporarily irrelevant. Due to things out of my control, the Minecraft server launch date has been delayed until next Monday. Which is just as well, there's a few things left that need to be sorted out. I would have liked the weekend to actually put some good work into these projects, but a couple extra days of practice wont hurt. In the meantime I can at least talk about the programs and such that I'll be using and learning.

Unity - I have a feeling I'm going to be focused a lot more on this one. You can download a free license for it through their site. Unfortunately for me, the add-on for Android is $400. Cheap by comparison, but I'm looking to spend closer to $0. In any case, I figure if I can learn this I'm going to have a lot more options later. There's definitely a lot of tools here, so while it might have a steep learning curve I think it'll be worth it in the long run. It's primarily 3d but can be forced to a pseudo-2d by locking the camera to an axis. Most of my plans are 2d oriented, but I think Unity would give it a much better look.

Blender - Free open source 3d modeling program. Even better, you can create models here and import them into Unity (which as far as I can tell is the popular method). My first impressions are mixed; lots of potential but the interface isn't very friendly. Other than that, it looks like it'll accomplish everything I need it to.

Visual Studio 2010 Express - This is my haven. C++ is what I started with, it's what I know best, and one of my projects is already started here. The express version is free to download with no real limitations, and has lots of resources available to it. Lots of people seem to dislike starting with C++, and it might not be the best for gaming overall, but in a pinch I know how to bend the rules enough to get my programs working here. If I can't figure out the things I need to learn, I'll be defaulting back to this.

SFML - The Super Fast Media Library is an open source package that is amazing for 2d games. It comes in 2 flavours; 1.6 and 2.0. I personally use 1.6 because 2.0 wasn't ready when I first installed it. While I gather that 2.0 has better support now, 1.6 has more documentation and information behind it. As far as actual differences between the two, I couldn't tell you. There's talk of eventually porting it to Android, but nothing has been done about it yet.

Small aside regarding SFML, there's some problem with SFML 1.6 and Visual Studio 2010 Express, that you need to go here, towards the bottom of the page there's a few extra files to download. I may not touch on it later, but that site has a lot of great tutorials for starting off with C++

Eclipse - An open source environment for Java. I know it's harsh bias but I'm not a fan. I know very little about Java, and I'm only getting involved with it because Android programming requires it. I hear that it gets easier as you go along, more so coming from C++, but I've yet to get there. Right now, it's just different enough that it actually makes LESS than zero sense.

Android SDK - This is the free kit that lets you write apps for the Android platform. Also, tons of great resources, tutorials, sample downloads, and support for it. Follow the instructions there for installing it and adding it to Eclipse. There's also the Android NDK available; another kit that lets you to use some C++ code instead of strictly Java.

You might notice a distinct lack of iOS here. In a perfect world, I'd aim my sights there too, but there's a few reasons why that's not going to happen.

1) There's no official iPhone SDK for Windows. I don't own a mac, nor do I intend to buy one. Yes, there are obtuse options (like setting up another partition for mac-OS and running dual operating systems) but I'm not looking for that either. Unity offers some support for iOS though, and apparently there are a couple unofficial packages that work to varying degrees, so all hope isn't lost.

2) No iProducts to test with. There's no iPad or iPhone lying around here that I can use to test things out. Even if I made a decent program to release, an emulator would only work so well. There's a minuscule chance that later I'll invest in something, but I have no intentions of that, and I'm not going to lose any sleep over it if nothing comes of it.

3) Flat Out Preference. As you can see above, there's already a lot on my plate right now, and one additional thing (that, for my purposes is completely different) is too much right now. A license to sell apps through the Apple AppStore costs nearly four times as much to sell through the Google Market. There's also all the horror stories of how the AppStore is managed which isn't exciting. All of this, plus the above 2, adds up to "Not Currently Worth It". Maybe later, but not now.


The next post will probably be a minor breakdown on the projects I have planned, and a rough schedule of how I'm going to move forward with it all.

Day -4, Prologue

Rather than clog up Facebook and Twitter with minuscule updates to the games I'm attempting to make, I'm condensing it all down into this little blog. I'm going to do my best to keep game-dev stuff separate from the usual social-media chatter and vice versa.

So what's going to go on here? The short of it is I've decided to start making games. Before I moved to San Francisco, that was the original plan, but things changed and I got off course. Now instead of lamenting it, I'm going to get myself back on track. There's a lot of catching up to do, a fair amount of relearning, and even more new things I've got to figure out. Since I'm pretty much doing it all from scratch, I figure I can share my findings along the way with the occasional progress-update.

I'm not generally a fan of blogs, or talking in general, but I figure there are many others in my spot; that don't know how to get started, don't have the tools or time available, or maybe they just don't understand one part of the whole. In any case, I plan on figuring it out and talking about it here.

I've marked today as -4 because I won't be starting the heavy-lifting until after June 1st. I've been setting up a Minecraft server for the people over at ApocoPlay (formerly ECGames) for nearly a month and that's the official start date. It's been consuming ALL of my free time, and after we turn it on I can start taking some time off from it.