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.

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.

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. 

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 -?, 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.