As you all know (this is the seventh installment, after all!), yours truly has been working on becoming a hobbyist indie game developer. It's an interesting and very enlightening project, and not just because I get to work with cool software and possibly make some cool games. The aspect that's been the most rewarding is realizing just how much work goes into making modern games. I'll definitely never play a game like L.A. Noire again and not have to pause a moment to think, "WOW. Somebody had to sit down and make every single 3D object in this game..." Somebody had to rig every animation, and somebody else had to script each behavior. The sheer enormity of the task pretty much takes your breath away when you really understand how much effort went into it. And let's not forget the producers, as well, who somehow have to bring all of this work together. It's no wonder the credits on a game can take upwards of an hour to scroll by!
Where I've been becoming increasingly disappointed, though, is what a dude like myself can hope to accomplish on his own. I had originally been naive enough to think that the tools had reached a point where you didn't need a full-on team of professionals to make something that looked like, well, it was made a full-on team of professionals. I didn't expect to make the next Bioware game here, mind you! But I thought it was within my ability to make something like Jay Barnson's Frayed Knights game. Jay had help, of course, and plenty of professional experience, so I figured--heck, why can't I learn the same stuff and make my own game? It *seemed* doable, and definitely fun!
So I acquired some books on Unity and Blender and went to work. As usual with these sorts of books, you make huge progress at first, but quickly level out and then find yourself in over your head. I've read many such books on many topics over the years, and the pattern is always the same--they go really slowly as you're learning the basics, but then (for whatever reason) start to pick up speed precisely when they SHOULD be slowing down--that is, when you start to hit the really difficult stuff. It's kinda hard to say it's their fault, of course, since some of this advanced stuff really needs a book of its own to cover. For instance, rigging in Blender, or scripting in Unity. It's like those branching trees in RPG games--at first it's a straightforward progression, but quickly starts to fan out in a multitude of unrelated nodes. It starts to beg the question if any one person can hope to master even a fraction of them.
By the time you stack up all the books, tutorials, websites, forums, or whatever you need to learn this stuff, you discover that even if you had the time to go through it all, you definitely wouldn't have the memory power to retain it all, so it becomes rather hopeless. To make matters worse, once you start learning HOW to do stuff, you learn how long it takes. If it takes weeks to create, rig, and animate a crude rat or hut, for instance, who are you kidding thinking you could create dungeons swarming with orcs and castles full of fiends?
They say when you're climbing that you should never look down. It seems than when you're learning how to make games you should never look up!
Several folks have written in with lots of good suggestions to get me back on track. I'll summarize these below:
1. Go back to Gamemaker (or RPG Maker), create a prototype, and take it from there. The argument is that all of the CRPG mechanics and such will need to be worked out anyway, and there's no reason I need to be struggling with 3D and such at the same time. I could do the whole thing in GM with placeholder graphics, get it up for people to play with, and--assuming it all holds together and seems to warrant it--I could take it from there and start trying to make it into a Unity project.
This idea has merit, of course, but I see a few issues. For one, I think there's a big enough different between GM and Unity that I'd basically be starting over instead of "simply" converting it. Secondly, creating this prototype would be a huge task in and of itself...I can see months and months of work going into it. I think it'd break my spirit if, after all that, I found I could only salvage tiny parts to use in Unity.
In short, it seems to me that if I continue with GM, I just need to make a firm commitment to getting the most out of that software and ditch the plans to "move on" to Unity. On the downside, as I've seen with Thrust Lifter, there is very little interest in indie games made with Gamemaker outside of the Gamemaker community itself, and most of those guys are more interested in MAKING games than playing (and most importantly, buying) them!
Not to put too fine a point on it, doing an ambitious CRPG in Gamemaker seems like vanity to me. Nobody but a few dear friends would play it, I certainly wouldn't make any money off it, and everybody else would just roll their eyes and dismiss it as the equivalent of fan fiction. Even if people could appreciate it as a CRPG, it'd still have that stigma of being "only" a Gamemaker game and not a "real" engine. Silly as it is, that's the vibe I get. If I go this route, I'm doing it strictly for the sheer joy of doing it, and quite frankly, I'm not sure that's enough for me at this point.
2. Put the CRPG project on hold and make a 2D game with Unity. I've been kicking around a project called "Rampin' Rescue" for probably a year here. I tried for months to make it with GM and failed so miserably it made me want to give up game dev altogether. It seems like such an easy mechanic--Space Taxi with a ground vehicle instead of a flying one. Instead of jumping or thrusting, you just get up speed and go flying off ramps. The problem came with the physics--to save my sanity, I had to give it up. Getting a car to roll up a ramp and behave realistically once it was in the air proved too difficult for me with GM, and the third party physics add-ons you can get are just too poorly documented and buggy for me to figure out. I gave up, and if you know me, you know that was a very soul-crushing experience to have to admit defeat.
However, Unity's built-in physics seem to be more than up for the task, and from what I've seen so far, will take a lot of this work off my hands and just let me focus on making fun levels.
I know it's possible to make 2D games with Unity, but I'm still not sure it's really any easier than making 3D ones from a programming standpoint. For one thing, I'll be fighting all the assumptions, since (let's face it) Unity expects you to be making an FPS, not a 2-D vehicle game. I'll have to figure out how to do the cameras, how to avoid taking the third dimension into consideration, etc.
In any case, Rampin' Rescue *seems* like a fairly easy game to make compared to a CRPG. I won't have to worry about a story, mechanics beyond the ramping and such, and the scope seems reasonable. Maybe a dozen levels or so...I see this project more or less taking the same amount of work as Thrust Lifter, though I'm probably being naive again.
3. Make the CRPG with Unity in 2D using placeholders. This is more or less a combination of 1 and 2. The argument is that just sticking to 2D will eliminate the necessity of learning Blender and there seems to be the expectation that if this version holds up well enough, I should either have built up the mojo to do it right, or can perhaps interest some other folks in jumping on board and helping me out.
Couple problems with this.
First, I don't want to have to rely on anyone to help me. I know from hard experience that even if people seem eager at first, that can fade quickly and leave me stranded with half-finished parts and no way to continue. I also know that anyone who DOES have the knowledge and ability to help me would much rather work on whatever projects he/she has going--there's no incentive to dedicate those resources to Joe Schmoe.
Others have suggested that if I have a prototype in place, I can use it to get funding from Kickstarter or similar services and then hire professionals, buy assets, or whatever to do the hard work for me. This idea seems the most realistic to me, though from I've heard the costs are so high that I'd need upwards of $30,000 or more. Call me crazy, but I just don't think my fundraising abilities are up to that. I think it'd be blindly optimistic to expect to raise a hundred bucks.
So what's my plan? I'm going with option 2. My plan is to try to break this project up into a few dozen discrete projects, then try to bring it all together as I get more comfortable with the software. I'll go into more detail with these as I go, but here's an idea:
Step one: get the camera setup to show a 2D terrain from the side view.
Step two: get a simple 2-D vehicle on screen and roll it around on the terrain using the arrow keys.
Step three: have the camera follow the vehicle as it moves across the terrain.
I figure those are pretty huge steps that will likely need to be broken down further, but they seem like good milestones.
Now it's time to quit yacking and start trying to figure this out...
In any case, if YOU, dear reader, have some experience with this and can provide some structural advice for me, go for it. Please, though, my problem is not that I can't find tutorials. Believe me, I'm drowning in them. What I really NEED is to hear how an expert would conceptualize this project and start to break it down into doable stages, or even how I should be THINKING about how to plan this project.
I understand what you mean; I have made a few games on my own and it is a hard slog to make something that is 'complete'. I found that deciding which engine or games library can make or break things - in failed projects previously I have ended up having to work around the limitations. The worst culprit for me was Dark Basic, which allows you to do a lot of stuff with a small amount of code, but the language is severely limited and caused me a lot of issues when it came to actually coding the stuff around the basic mechanics of the game; the thought of creating the menus and options etc gives me the screaming heeby-jeebies. SDL had some real issues for me with sound handling. I had used Allegro for a few projects which was quite good but couldn't get the OpenGL to work properly with the 2d stuff like the HUD.
I believe that Unity is a professional level API that required a 'lot' or learnin'. I did have some fun with Garage Game's Torque engine (which is still going strong). It is a piece of cake to draw rather excellent scenery with weather, day cycles, etc all built in. I would certainly recommend having a look at it; it does have a fair amount of decent examples and documentation.
I recently undertook a personal project to release an iPhone game and came across the excellent cocos2d which was probably the best example of a development library - utilising the native language and very stable. I was so stressed from the job I had, I quit and spent a month in Auckland (NZ) to produce the game. It was fab. Being in a (rather scenic) different locale without interruption allowed me to enjoy working on the game and occasionally do something Kiwi like jumping off the 300m high tower in the middle of the city.
As far as 3d goes, it is really, really hard to compete with the standard of modelling and textures in commercial games. I hate to be contradictory with a previous post, but I have no idea how someone can claim that 3d modelling can be easier than 2d sprites. Learning how to create and animate the models is a serious undertaking in itself that people spend their careers developing and perfecting. Because I cannot draw for toffee (as my Gran would say, which thinking about it, is strange as I cannot draw but she did give me a fair amount of toffee as Grans are want to do) I utilised sites like Reiner's Tilesets which are impressive and impressively free to use - even in commercial projects. I had to spent a fair amount of time adjusting the tilesets for the resolution of my game, but it was a real boon.
This is a subject close to my heart as I have often thought about the affect of toolsets and if they make it possible to create games of yesteryear more effectively or efficiently...
no idea how someone can claim that 3d modelling can be easier than 2d sprites
Maybe it's not that the claim is that it's easier, but rather, you get more bang for your buck. After the up-front work of doing the model, you can generate an infinite number of sprites from that same model - front view, back view, side view, isometric view, top-down view, etc. And that's just for an un-rigged model. A pose-able model offers even more flexibility. Definitely not a one-size-fits-all solution though, because some aesthetics or stylizations are a better fit for drawing in 2d. A perfect example is the game And Yet It Moves.
I see your point, but working with 3d modelers is a fair undertaking. Could just be me, but even producing stuff in Milkshape was taking quite a lot of time. I look at it as the difference between sculpting and drawing (pity I seem unable to do either).
And Yet It Moves was written using Torque 2d as the engine, in case anyone is interested.