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.
9.28.2012
7.31.2012
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:
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:
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:
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.
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.
7.23.2012
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?
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?
7.18.2012
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 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.
6.20.2012
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.
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.
6.12.2012
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.
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.
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.
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.
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). |
 |
| Model 3: Untextured |
 |
| Model 3: Textured, still horrible. |
 |
| Model 3.5: Gentlemen, BEHOLD! |
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.
6.06.2012
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.
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.
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?
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?
Subscribe to:
Posts (Atom)