Indie Game Development - First Steps?

[Paingod]

For years I've talked about wanting to program and create my own game. There are things I want to do that I haven't seen done (well, in this specific fashion) and the game I want to make is simply a game no one else has that I've been wanting to play. I've been collecting notes on things I want to include, themes to use, how certain mechanics might work, what certain classes can do, building class trees, crafting concepts, etc... but haven't coded a single line.

I'm familiar (but by no means proficient) with C# through Visual Studio. In college when I took programming classes, they came to me like second nature, but it was again through Visual Studio. I feel like I do have a creative spark, and certainly have a deep passion for PC Gaming. When I get into a problem, I can't give up on it until I get my answer or find a way through it. My shortcomings for this goal are that I learn best in a structured atmosphere with clear objectives but flounder and loose attention when left to my own devices to learn something on my own.

Essentially, I look forward to the actual development of the game and seeing my ideas come to fruition, but dread the learning curve to get that far.

I'm not exactly sure what I should be starting with, either. Do I learn a programming language first? Do I go find a game engine to design with and then learn how to program for it?

I'm also trying to do this on $0.00 up-front ... but with the intent that if I find the right fit for my project or needs, I'll force the funds to come out of our household one way or another in order to make it all legit. I just can't afford $1000 for this engine, only to discover that it's only 30% of what I need, or to invest $400 in that programming language only to find that it's too limiting. If there are worthwhile tools that are "free to use privately, but cost if published" that would be perfect. Google searches turn up dozens of options of varying and bewildering potential.

[tjg_marantz]

1. Big boobays!
2.
3. Profit!

Unfortunately, in your case, I think 2. may see you become a bachelor.

Other than that, good luck and let us know if you need testers!

[NickAragua]

The first step to game (or, really, any serious software) development, once you've passed the initial "playing around with conceptual code" stage, is to throw away all your temporary code and finalize your design. You're going to have a very large amount of code, which means it's extremely important to have a more or less fixed design before you start coding. That's not to say that your game design won't change as you go along, or that you won't miss some cases, but the more of it you have figured out up front, the easier time you're going to have developing. Also, when I say "design", I don't just mean your game logic rules, I mean you want to figure out what you're going to code ahead of time as well: "I want a function that does this", "I want a data structure that contains this information", etc. Trust me, you might have it all in your head today or tomorrow, but when you look at your code five months from now, I guarantee your first thought will be "WTF". That old saying "measure twice, cut once" applies to software engineering as well.

If you have no idea what I'm talking about, you should hit your local library and grab a bunch of books on software engineering before starting to code in earnest. Ignore the parts where they talk about group management, since I assume you'll be working on this by yourself.

Unless you're interested in writing your own graphics or sound (or, god forbid, networking) engine, I would recommend scouring the internet for existing ones. Stuff like Kyra (for 2D sprites), Ogre (a pretty robust 3D engine), SDL for sound, and I have no idea what for networking or physics since I've never even dabbled in that.

Also, that Cliffski guy over at positech.co.uk has written some pretty good articles regarding indie game development. I don't feel like looking through his articles right now to find the quote, but it was something like "get the cool stuff built as soon as you can. If you're building your game it's a lot easier on the ol' morale if you can actually see things blowing up, rather than watching a bunch of text scrolling by."

[Paingod]

Unfortunately, in your case, I think 2. may see you become a bachelor.

It might, it might not. I can spin some things to my advantage.

"I know she's scantily clad. I know it doesn't make sense. If you look at the marketing, though, I could sell 43% more copies of this if I can lure people in with sexual imagry. What? Sure, I'll go get my camera. You go ahead and put on that chainmail bra."

Other than that, good luck and let us know if you need testers!

It might be years from now. I've designed some non-computer games myself that sounded really awesome in my head, but in actual play made me go "WTF was I thinking here? This is completely lame" ... so I can do some of the initial "Wow this sucks" in my own fashion, and hopefully get more positive stuff from others when I send it out. I'd have to do NDA's and such, but I would certainly come here and ask for volunteers.

The first step to game (or, really, any serious software) development, once you've passed the initial "playing around with conceptual code" stage, is to throw away all your temporary code and finalize your design. You're going to have a very large amount of code, which means it's extremely important to have a more or less fixed design before you start coding. That's not to say that your game design won't change as you go along, or that you won't miss some cases, but the more of it you have figured out up front, the easier time you're going to have developing.

So I should really plan on a temporary or preliminary game(s) before getting down into the real game I want.

Also, when I say "design", I don't just mean your game logic rules, I mean you want to figure out what you're going to code ahead of time as well: "I want a function that does this", "I want a data structure that contains this information", etc. Trust me, you might have it all in your head today or tomorrow, but when you look at your code five months from now, I guarantee your first thought will be "WTF". That old saying "measure twice, cut once" applies to software engineering as well.

I've worked with enough developers to know what this is (I think), but haven't had to do it myself yet. I see them setting up modules and routines that get called constantly instead of re-writing the same code over and over and isn't just a one-off thing. I may need to create a random number generator that gets called from 37 different places, or a critical hit interaction module, or AI modules to drive NPC behavior in non-scripted events.

During the time I worked with our developers, I really felt that I had a solid grasp of both the minute details as well as the larger picture and when they'd ask about how something would work, it rolled through my head on several levels looking for logical obsticles or interferance before I set them to actually coding it.

Unless you're interested in writing your own graphics or sound (or, god forbid, networking) engine, I would recommend scouring the internet for existing ones. Stuff like Kyra (for 2D sprites), Ogre (a pretty robust 3D engine), SDL for sound, and I have no idea what for networking or physics since I've never even dabbled in that.

I'm planning to try and shoot for simple 2D to start, just to get the "world" and themes built to see how they come together. Games like Space Rangers really intrigue me with the layers of gameplay options they give players and I'd love to incorporate things like that. Some things I had planned on building in:

Minigames - Take control of your (character type) to produce new goods, perform new tasks, upgrade existing technologies. Once you've master the task, the crafter becomes adept at it and doesn't need your guidance to repeat the task on his own and it can now be issued as a command.

Detailed crafting - I want to allow a hefty amount of battlefield salvage to take place and use what people find to create their own blends of things. Maybe you want units that have more radiation shielding, so you use a lot of salvaged lead and create a new armor composite with steel that isn't as strong as before, but protects against radiation while making the unit wearing it more encumbered. Maybe you need faster response time so you've spliced some feline reflex genetic coding into your units - making them faster but slightly smaller or less resistance to some forms of attack. I'd let players really define these numbers and combinations, even naming their new alloys. Once created, it becomes a recipe. That recipe is added to the list of materials you could build something out of and that finished product obtains its properties from the sum of its component recipies along with the skill levels of the crafter.

Character customization - I plan to allow you to create your characters from scratch - literally. Define what kinds of organs they might have, and what those organs are made of. Maybe you've got one of those lead/steel alloy skulls we just started making. Maybe you want to use genetic engineering to create supersoldiers without cybernetics. Once you've designed your perfect unit for your chosen task (maybe this is an Engineer, so he's high on intellectual abilities but low on the physical scale, for example) you can save that unit as a template for continued production. Modify this template later and then issue a recall order to upgrade the units it applies to.

Character growth - I want to build in unit-level experience so they become inherantly valuable to players and not simply disposable fodder. That Engineer might have gained so much crafting expertise that he can mass produce powered armor faster than a team of newbies. Keep him safe!

Character classes - Let players choose unit progression down skill trees as they gain experience - giving them even more of a customized and personalized experience.

Also, that Cliffski guy over at positech.co.uk has written some pretty good articles regarding indie game development. I don't feel like looking through his articles right now to find the quote, but it was something like "get the cool stuff built as soon as you can. If you're building your game it's a lot easier on the ol' morale if you can actually see things blowing up, rather than watching a bunch of text scrolling by."

I'll have to go dig that up.

[Ænima]

My shortcomings for this goal are that I learn best in a structured atmosphere with clear objectives but flounder and loose attention when left to my own devices to learn something on my own.

Essentially, I look forward to the actual development of the game and seeing my ideas come to fruition, but dread the learning curve to get that far.

I've been involved in the Indie Dev scene on and off for a decade. Here's my opinion, and I hope it's not too harsh, but I feel that when it comes to things that could sink up a good amount of time, the TRUTH (tm U2K) is best. The statement you made above sends up a big red flag to me. All successful Indie developers I've known have had the opposite personality type. Most don't do well in school, actually, because structure is the last thing they want. They have a real sense of internal drive and purpose, and don't let little things, like lack of knowledge, get in the way. Until you have a ton of experience, the "actual development of the game" is mostly learning stuff that you didn't know before. While the Internet has certainly made that easier, there are going to be a ton of things that you are just going to have to figure out for yourself. Nobody will be there to teach you, and you're going to have to figure out what to learn and adapt your game design to your limitations.

I'd say conservatively that 95% of Indie game projects that are started aren't finished. Even successful developers I know don't finish a lot of the games they start. That being said, there are some ways to shortcut to the "fun parts". Get a public engine and mod something that already exists. While learning a scripting language like Python or Lua may sound like more work, they are actually very easy to learn and will get you making a game quickly. Most of actual game development at AAA dev houses is done in scripting languages these days. The lessons you learn as you develop a mod will show you whether or not you really have the drive to do Indie dev. From there you can decide what direction you want to go, whether it's engine development, or working with something that already exists.

Sorry for the ramble, I haven't had my coffee yet. Good luck!

[Paingod]

Until you have a ton of experience, the "actual development of the game" is mostly learning stuff that you didn't know before. While the Internet has certainly made that easier, there are going to be a ton of things that you are just going to have to figure out for yourself.

It's the core functions that I dread - getting up to speed on using a language or tool before feeling proficient with it - getting to a point of comfort and finally understanding how all the elements click together - not spefically mastering it. It's obtaining that proficiency that is hard for me. Once I've got it, and get into it, I can get very very involved and dedicated. When given a challenge, I'd always find a way to the end. If it didn't work, I'd hammer on it until it did. I'd process the problem in my sleep and wake up with answers sometimes.

In school the professor teaching the class actually asked me and my partner if we wanted to come work for him in his own start-up programming business, but I didn't feel like I was ready for that sort of thing and declined.

I understand your point and can see what you mean - I'm just not afraid of this because I feel that once I can start producing any kind of code with a game engine and programming language, there won't be much to stop me except the limitations of those things.

[Turtle]

It's probably one of the best times right now to go into due to the plethora of distribution methods (even if all of them have issues) and sheer amount of support for smaller development. There's entire game engines, some highly advanced, available for free download and a pretty reasonable licensing once you actually make something you can sell.

That said, it's still all a lot of hard work. The thing is, if you wait until you're ready to do something, you won't ever be ready. Most of what you learn that makes you ready is learnt actually doing.

I've been working on my own indie game using the Unity 3D (http://unity3d.com/" target="_blank) engine as one part game development, one part portfolio piece.

[Paingod]

So I think I'm getting "Get ready for failure" and "Just jump in" ...

If you had to start over, would you stick with Unity?

I'm looking for something strictly 2D right now, more than likely starting 100% top-down to keep the visuals simple. Where I want complexity is in letting players make things and how characters are handled.

[Chaz]

I'm a QA tester by trade, not a coder, so I can't give a ton of help except to say that you should get someone else's eyes/hands on whatever you do as early as possible. The sooner you can find design problems or bugs, the easier they are to fix. Even more important, just because something makes sense or is fun to you doesn't mean that will be the case for everyone (or even anyone). You don't want to get way into a project, give it to someone, and have them be completely befuddled by the interface such that you have to go in and redesign or rethink the entire thing.

Making paper prototypes can be a really valuable exercise. It's way easier to make changes to index cards than it is to a code structure.

[NickAragua]

I'm a QA tester by trade, not a coder, so I can't give a ton of help except to say that you should get someone else's eyes/hands on whatever you do as early as possible. The sooner you can find design problems or bugs, the easier they are to fix. Even more important, just because something makes sense or is fun to you doesn't mean that will be the case for everyone (or even anyone). You don't want to get way into a project, give it to someone, and have them be completely befuddled by the interface such that you have to go in and redesign or rethink the entire thing.

Making paper prototypes can be a really valuable exercise. It's way easier to make changes to index cards than it is to a code structure.

Yeah, jeez this is important. If you're planning on making this game so that other people play it, you want to make sure that other people want to play it.

[redman]

Hey, good luck with it and all. Have you thought of maybe using an existing game eng? So many games have great toolsets and what you can do with them is pretty incredible(thinking Nehrim for one) I know some people like the Torque eng too. You can get your feet wet re-modding someone else's game(maybe you already have) without the headaches of building the eng. the Ultima 6 project is another one that I can think of and it ended up being better then dungeon Siege.

[Paingod]

Making paper prototypes can be a really valuable exercise. It's way easier to make changes to index cards than it is to a code structure.

Yeah, jeez this is important. If you're planning on making this game so that other people play it, you want to make sure that other people want to play it.

That's a good idea, but I'm not sure how I can get the relatively complex interactions I want between elements to be depicted on index cards in any successful way.

I've seen good and intutive interfaces, and I've seen horrible and cryptic interfaces. I've seen Idiot and PhD level learning scales. I want to make a game that appeals to folks interesting in the niche, but it's not necessarily for everyone. I'm not after another MineCraft - I want a game I've been wanting for years but have never seen. I plan on building in useful help and making this intuitive as much as possible.

I'm also after layers of gameplay. I'd like to make it so everyone gets the basics, but you can really fine-tune by spending time inside each section of something... like Crafting - you could use Steel, Plastic, Copper, Titanium, etc as basic building blocks - or you can go in a little deeper and customize your own materials from those. You could stick with Standard, Fast, and Heavy actuators for cybernetics - or you can go a little deeper and use different materials to make different levels of strength or responsiveness and make that part of your game. That sort of thing.

I had actually done some MSPaint mock-ups of things like Inventory screens, Unit screens, etc. and they're all pretty straight-forward to me - derived in theory from RPG's and Action games. Not Dwarf Fortress stuff or BattleCruiser 3000 obscurity.

[Zurai]

First step: Game Design Document. Seriously, the more work you do deciding how you want everything to function before you start coding, the higher the chance you'll actually be able to do what you want to do. Some basic Google searches should get you started on your GDD, and if I recall correctly Gamasutra (or another similar game-centric site) actually got their hands on a bunch of game design documents from the 90's and published them in their entirety.

And don't worry about not having a lot of coding experience; there's very little that cannot be done on modern computers that's within the scope of a one-man indie game.

Second step: Realize and accept that you will NOT actually put in everything that you just wrote down in the GDD. Some things may just not work out like you envisioned them, some things may just prove too difficult or too time-consuming for their value, and some things you just may not get to. It's OK to cut parts of the design. Every single modern PC or console game has design elements cut.

Third step: Try to avoid adding things to your design after you've finalized your GDD. If you don't, you stand a real risk of never completing the project, and even if you do complete it, it's rare for those added features to add as much as you think they do to the real game experience.

Obviously if you forget to add something like saves to the design document, you need to work that out and add it in. I'm talking more about bulletpoint features than basic game mechanics with this one.

[Jeff V]

Maybe if we say his name three times and invoke the Bauman, Cleve Blakemore will stop by to tell you how simple it is for one guy to crank out an awesome game that EVERYONE will NEED to play.

[Smoove_B]

I still have an entire filing cabinet full of design docs, treatments and various nonsense. Good times.

The only advice I can give? Don't talk about it - just do it.

[Fitzy]

Sacrifice a goat.

[RunningMn9]

Paingod, let me start by saying that I would never counsel you to *not* follow a dream. If this is something you've always wanted to do - great. Do it.

BUT...

...what you are describing here is an almost impossible task. Almost. The problem is that you are talking about wanting to program a computer game - but you aren't proficient in any programming languages. Redefine your goal. Instead of wanting to program a computer game, let's say that you want to make a computer game. Big difference. Making a computer game may or may not require that you become proficient in a programming language.

I'm a software engineer by trade, have been programming for more than 25 years, am proficient in more than 5 programming languages, have a tendency to be able to focus like a laser on things for long stretches at a time - and I've tried to do what you are talking about.

And failed spectacularly. Programming a computer game isn't really about becoming proficient in a programming language. Not being proficient is certainly a barrier - but overcoming it leaves you with the real problem - programming computer games is *hard*. For all but the simplest of games, it requires a good deal of knowledge that have nothing to do with the programming itself.

There are professionals out there that have created engines and projects dedicated to making your life (as a budding game designer) easier. Start by seeing if that route is plausible for your game idea. It wasn't in my case (our case), because our game idea was too vast to fit neatly into the available engines at the time (that were licensable on our budget). That was our mistake. Not starting simple - or not starting within the parameters of a system that was readily available (i.e. modding an existing game).

If we had originally started out with the NWN toolset, and approached it from the perspective of working within that toolset's limitations, we might have been successful. By the time we got around to that, our spirits had been broken by the initial struggle.

Having said all that, if you want to mess around, in an environment that can produce a real game, and you have some familiarity with C# - then I would start by messing around with the XNA development kit. You can learn an awful lot about making simple games from that combination.

Above all else, be prepared to have to be the driving force behind developing the skills that you seek. If you can't do that, I don't recommend committing the time to watching yourself fail. You can't succeed at this if you can't develop the drive to learn what you need to learn in a structureless environment.

[Turtle]

Essentially, start by making mods to gain experience, release them for free. Then work up to making a full independent game.

Having that body of work out there also helps attract skilled people when you finally get to the point where you need outside help.

[Freezer-TPF-]

Start small and use an established toolset/engine or mod tools for an existing game. Once you get the hang of that and actually produce a final/playable product, think bigger for your next project.

[Kraken]

First step: Game Design Document. Seriously, the more work you do deciding how you want everything to function before you start coding, the higher the chance you'll actually be able to do what you want to do.

I'll second this: the design doc is key. You won't reach your destination without a good map. Document EVERYTHING, and whenever something changes, update your doc. By the time your project is finished the doc should be a complete recipe for how it was made. This is critical as you bring other people on board (I'm assuming you aren't planning to do your own art, sound, AI, etc).

After you get the top-level systems doped out, mock up some screens to illustrate your main design elements, paying especial attention to interface. Many a good game has died from a poor interface. As much effort goes into interface design as game systems design.

After that you build a prototype that determines what technologies and tools you are using.

After those three steps are completed, you can start actual development with some confidence that you won't waste a lot of time on false starts and dead ends.

[Turtle]

The ddoc is key but it can also be a shackle. When you are starting out, think of it more as a method for you to train yourself to think and plan about all aspects of the game project you're working on, and to get other people thinking on the same page. Most design documents I've seen don't survive intact beyond the first few milestones of development due to actual prototypes and staff ideas altering the design, although the doc will help resist feature creep later, so try to avoid adding in more and just watch for changes.

[Ænima]

The ddoc is key but it can also be a shackle. When you are starting out, think of it more as a method for you to train yourself to think and plan about all aspects of the game project you're working on, and to get other people thinking on the same page. Most design documents I've seen don't survive intact beyond the first few milestones of development due to actual prototypes and staff ideas altering the design, although the doc will help resist feature creep later, so try to avoid adding in more and just watch for changes.

This. Design docs are great, but everyone has different levels of what they need in order to focus. For me, writing a long design doc will pretty much kill my interest in the project. I tend to write concise treatments and then use outlines as I go along. The bigger your team gets, the more vital a robust design doc is.

[Grundbegriff]

(a) Find the already extant game engine or moddable game that (a1) falls within your budget and (a2) comes closest to offering, prefab, the functionality and infrastructure you need.
(b) Trim your concept down into something that can be made using (a).
(c) Make the lesser game that results from (b), even though it falls short of your initial vision.

Just reaching this more modest goal will teach you a great deal about what your ultimate goal actually requires. And it'll teach you efficiently, since you'll be solving problems implicit in your grander project as well as its scaled down sibling. Following these steps will also give you an adaptable code base, (c), that you can then begin to augment or transform into the game you really want to make based on the hard lessons you've learned on the way to (c). The language and plumbing may differ in the end, but much of the logic will already be fully expressed.

Without falling back on, and accepting the limitations of, some existing framework or body of game-dev-specific libraries, the task you're describing is probably too complex to fall realistically within reach given your starting point. It's not quite "I'd like to be a heart surgeon, and I did really well in Chem and Bio....", but there's a high probability that you cannot yet see clearly the scope and depth of what you're proposing to undertake.

[mmmm]

...I'd like to make it so everyone gets the basics, but you can really fine-tune by spending time inside each section of something... like Crafting - you could use Steel, Plastic, Copper, Titanium, etc as basic building blocks - or you can go in a little deeper and customize your own materials from those. You could stick with Standard, Fast, and Heavy actuators for cybernetics - or you can go a little deeper and use different materials to make different levels of strength or responsiveness and make that part of your game. That sort of thing.

I had actually done some MSPaint mock-ups of things like Inventory screens, Unit screens, etc. and they're all pretty straight-forward to me - derived in theory from RPG's and Action games. Not Dwarf Fortress stuff or BattleCruiser 3000 obscurity.

I know many posters here are giving the OP well-intentioned discouragement, but is it really necessary? He's described a talent for / willingness to re-learn coding, and the stuff he's describing doesn't really sound all that hard to program. Not if he's got a good grip on it conceptually, anyway.

Wouldn't we have to ask Mr. Paingod here some more probing questions before deciding how impossible his hobby-game is? Because there's a couple of encouraging points you can pick up from what he's written so far:

-He's already mentioned that he doesn't need a 3-D engine or (perhaps even more importantly) the art assets a 3-D game requires. This is good to hear.
-I'm not reading the phrase "real-time" in respects to this project's gameplay. This is very, very good to hear.

So basically, to get started on his fun game project he'll need to

1) Figure out some method for creating (or preferably adopting) an adequate 2-D engine. A little complicated, but clearly not a problem for him.
2) Creating or obtaining art for this engine (this kills so many indie ambitions!) -- He could use public domain materials as placeholders, though.
3) Hammering out the mechanics of his game. Translating the vaguer ideas he has into a sort of mathematical reality.

So, supposing you can make this game turn-based, why not just start out on #3? Like, make an analog version, man. It'll probably be something too dreary & number crunchy to be all that fun as a tabletop game, but once you've got the specifics hammered out, the rest of the process will be much more focused; learning the tools needed to bring that (already completed!) tabletop game to the PC screen.

Don't let these folks get you down, man. People much less clever than you make complete, independent games all the time. What you're describing is waaay less complex than the games Toadie and Notch have made lately, and criminy, it's no secret that Notch is a terrible programmer. You don't need to master any programming language, you don't need a design document, and you certainly don't need to be dicking around with XNA*. At least the 5% (or so) of indie game makers that *succeed* certainly don't. In interviews they usually describe a similar process: "It started as a hobby. I learned as I went. I didn't involve anyone else until very late in the project (or at all). It eventually got to a playable state, I released an alpha on the internets for testing, and..."




*(Unless you're talking about making an artsy, atmospheric side-scroller that nobody actually plays -- you'll probably want to dick around with something like XNA in that case.)

[Paingod]

This thread has given me a lot to rhumenate on, and I've been chewing the brain cud for a few days.

Re: Modding - the closest game I can think of, that has the most complete framework for what I want, is an X-COM game or clone (like UFO: Afterlight or even Jagged Alliance). It's got the right mechanics - combat, character growth, squads, turn-based (or real time), line of sight, destructable environments, missions, bases - but is missing a lot of depth I want to add in crafting, character customization, scavenging, construction, upgrading, and a few other things. I may need to start hunting through those types of games and look for one with modding support.

Re: Analog prototype - An excellent idea. My boardgame ideas have always ended up "unfun" due to gobs of calculations and per-turn planning that players were required to do, but going into it knowing it would all be handled by the computer changes that. Anything that seems to bog me down would just be a process in the background on a PC.

Re: Artwork - I have some limited artistic ability, but was actually planning on attempting to do this using "static" chesspiece or statuette type placeholders. This theme looks pretty good if applied correctly - take a gander over at PoxNora. I've be thrilled to make something that functional. I had no intention of using a true 3D engine if I could avoid it. I had also considered going to route of "cards" for characters - not unlike Cryptic Comet uses for Armageddon Empires or Solium Infernum.

[GreenGoo]

I know many posters here are giving the OP well-intentioned discouragement, but is it really necessary?

Yes. He came here looking for input and got completely honest input. We owe him that much. If he wants unconditional support, he can get it from his family. People with actual experience are sharing that experience.

No one has said "don't bother", at least that I read, but many have said "holy crap that is a monster task, keep that in mind as you go forward" because it's true.

People with less talent may have made complete games, but they also had more drive. When I hear "You know what? I've had this great idea for a game and maybe I can make it in my spare time, for zero cost" the sense of deja vu is overwhelming, because that idea has been expressed by many, many people, including a few on these boards, and most have run into the same road blocks again and again.

Hell, we've even had a professional game programmer come by and solicit funds for an upcoming project, only to keep the money and have nothing to show for it.

It's a BIG project. Accounting or Tax software is probably easier and less complicated to design and make than a modern game (ignoring flash based and puzzlers).

No one wants to actively discourage Paingod. He does need to be aware of just how big a bite he's intending to take so that he has a better understanding of whether he can actually chew it or not. Being prepared mentally can help deal with those times when he gets discouraged, because he will get discouraged.

[Paingod]

When I hear "You know what? I've had this great idea for a game and maybe I can make it in my spare time, for zero cost" the sense of deja vu is overwhelming, because that idea has been expressed by many, many people, including a few on these boards, and most have run into the same road blocks again and again.

I don't have much of a choice. When I do this, it has to be zero cost, at least for a while. There's simply no budget for this in our household for the foreseeable future. I had wanted to go to school for a few programming classes (maybe looking into those "gaming universities" which are more than likely half-scams) and apply that to this project just to get past the initial roadblock I have around learning best in a structured environment.

Hell, we've even had a professional game programmer come by and solicit funds for an upcoming project, only to keep the money and have nothing to show for it.

When on earth did that happen? That's just ... ick.

[Shinjin]

Hell, we've even had a professional game programmer come by and solicit funds for an upcoming project, only to keep the money and have nothing to show for it.

When on earth did that happen?

Not sure where the original solicitation thread is (possibly lost with GoneGold?), but I think the answer to your question is [Isgrimnur]somewhere in 2005[/Isgrimnur]

[Paingod]

Hell, we've even had a professional game programmer come by and solicit funds for an upcoming project, only to keep the money and have nothing to show for it.

When on earth did that happen?

Not sure where the original solicitation thread is (possibly lost with GoneGold?), but I think the answer to your question is [Isgrimnur]somewhere in 2005[/Isgrimnur]

Arcadia is a player-supported game, both philosophically and financially. Meaning, if players take a "wait and see" attitude as a group, it will not happen (or at least not on the scale it was planned to happen). The game WILL get made, one way or the other. In this case though, if it isn't a priority for the players and gamers (and it sure hasn't created any ripples with the gaming press up until now, despite a long, pretty reliable track record), it probably won't be a big priority for me.

That seems like a really broken development philosophy. Pay me and I'll code; if you don't pay me enough, I'm not going to bother coding.

That is a really strange path ... 7 years and still counting, and not a post in over a year - links all dead. This guy'll beat Duke Nukem's 15 year run before being done.

My time is limited to about 3 hours a day in a solid block - hopefully enough time to feel like I'm getting something done and not just getting into it and then having to shut it down. I would never (ever) ask for any money up-front until I had a product to release. For me this has never been about money but more about making something fun - if it eventually gets to Steam and I get $5.00 per copy, great... but it's not a goal.

[GreenGoo]

I don't have much of a choice. When I do this, it has to be zero cost, at least for a while. There's simply no budget for this in our household for the foreseeable future.

That's fine. My point was only that it is a difficult path. I wish you the best and will be happy to line up to buy it if it turns out to be fun.

[MindToyGames]

Arcadia is a player-supported game, both philosophically and financially. Meaning, if players take a "wait and see" attitude as a group, it will not happen (or at least not on the scale it was planned to happen). The game WILL get made, one way or the other. In this case though, if it isn't a priority for the players and gamers (and it sure hasn't created any ripples with the gaming press up until now, despite a long, pretty reliable track record), it probably won't be a big priority for me.

That seems like a really broken development philosophy. Pay me and I'll code; if you don't pay me enough, I'm not going to bother coding.
That is a really strange path ... 7 years and still counting, and not a post in over a year - links all dead. This guy'll beat Duke Nukem's 15 year run before being done.

God, I sure hope not...that would be beyond embarassing!

It was (and is) a strange path, and one I have thankfully steered several other indie hopefuls away from the last year or two, i'm glad to say. I think my thought process was to leverage my 'fan base' as it were to generate a larger budget so I could really do something bigger than I could have normally, and at the same time usher in a new way of creating games with community involvement, something I say in the right circumstances would still be a decent idea. My circumstances as it turned out were not ideal, as my life promptly went topsy turvy a few months into the project and derailed it badly. The quote attributed to that jerk StormcloudCreations above was not his finest hour, to be sure.

I have still been banging away at the game here and there to get it done, believe it or not, in between a full time 'regular' job and trying to have a life too. The game now has 99% of the 'admin' screens finished now, and the quest selection screen is done too, bugs fixed, etc. It's now a 1024x768 'Windowed' game as well leveraging some DirectX, so you can do other stuff while playing it. I'd say its about 50-55% complete now. Demo link if any were interested and/or bored: http://www.mindtoygames.com/arcadia040.exe

I can say first hand: being an indie game designer is tough, hard, lonely and frequently thankless work, so think twice before you take the path. Going into it with no expectations is the way to do it, that way if you succeed, great. If you don't, you did something you can enjoy and be proud of. I can also state from personal experience going into it with no budget to speak of is doubly tough (my first game in 1999 had a $90 budget!), as it come together slowly and you'll have to supply all your own motivation to keep going.

I wish you luck though, as you clearly have the passion for gaming to have a shot to pull it off.

[Paingod]

I think my thought process was to leverage my 'fan base' as it were to generate a larger budget so I could really do something bigger than I could have normally, and at the same time usher in a new way of creating games with community involvement, something I say in the right circumstances would still be a decent idea.

I've always personally felt that communism is perfect on paper, but as soon as you get people involved it all goes to hell ... I could never personally dream of hoping that folks would support me, I may be just too jaded and disgruntled with society as a whole.

I wish you luck in getting it done! I hope I'm not being too ambitious myself - it sounds like your situation is eerily similar to mine - Full time job, full time family, part time sleep, part time gaming (which becomes game developing)... no real large quantity of time to myself for huge blocks of time.

[mmmm]

What you've been describing doesn't sound like it should cost any money, just time. For the first few weeks or even months you wouldn't want to program a thing, and if you do first make a PnP prototype you'll know very specifically what you need to learn.

A 1st year comp. sci course would be plenty to get you started -- typically you'd be learning Java or Python in one of these, which should be about perfect for writing a hobby game. You don't need to pay anything for this class.

http://ocw.mit.edu/courses/electrical-e ... fall-2008/

If you can seriously dedicate ~15 hours a week to this project, and resist the temptation to mess with sisyphean crap like graphics & sound until after the game is more or less complete, I can almost guarantee you'll have something playable in a couple of years. If it's actually fun for *other* people to play, you'll probably get volunteers to help with stickier coding tasks at that point.

It's a big(ish) undertaking, but aren't most things worth doing? You'll see people sink just as much time into building a new garage, or rebuilding an old sports car, etc. and in many respects those are more difficult tasks!

[RunningMn9]

I know many posters here are giving the OP well-intentioned discouragement, but is it really necessary? He's described a talent for / willingness to re-learn coding, and the stuff he's describing doesn't really sound all that hard to program. Not if he's got a good grip on it conceptually, anyway.

Having a talent for (I don't know that this is true from the original post) or a willingness to (re)learn coding is light years away from preparing him to do what he described that he wanted to do. What he wants to do is hard. Really hard. Hard enough that almost everyone that has ever tried to do it has failed at it.

That's not a reason to not try. It's just something to keep in mind up front to understand why he'll get to a point where he's struggling to make any progress.

[Paingod]

What he wants to do is hard. Really hard. Hard enough that almost everyone that has ever tried to do it has failed at it.

I always though that there are two ways to avoid failure:

- Never start doing something
- Never give up on it once you start it

So far I'm in the first camp. I can't fail because I haven't tried.

I'm amazed at that Python class. It sounds like the perfect starter - and the language is free. That's exactly what I needed to get going.

I'm fine with placeholder graphics for the majority of the project - workable and understandable, but by no means finished. I don't think I could do a Dwarf Fortress type of bareness (is the green "H" a threat?) but basic stuff should be easy to slap in place.

I've done some very minor modding before - nothing with real scripting but adding houses and items to Morrowind was a blast, and modifying the ship stats and racial specs in Space Empires was fun. In Morrowind it really felt like it made part of the game mine and I got to build something I couldn't find anywhere else (a house with a portal key that you bring with you, so you coul "Bind" and jump home, then teleport back - the house was in a pocket dimension contained in the key).

[RunningMn9]

On the contrary, never starting is the fastest way to fail.

Of all the things that you have said that would concern me, your preference for structured learning would be the big one. That and zero cost. It's just not reasonable to make any sort of worthwhile game for free without a tremendous amount of unstructured learning and time.

Knowing what the hurdles are should prepare you for figuring out how to jump over them, not stop you from trying.

[Paingod]

I found myself last night wishing I had the tools to start doing something with this, and instead started doodling mock-ups of character and item icons in MSPaint. I thought about posting them, but they were just tiny things - 16x16 icons, about 18 of them. That alone made me think I might need to bump up to 32x32 icons just because things were so hard to really see.

Today I rummaged through my desk and found an "old" copy of Visual Stuio 2010 that we no longer need because the project flopped hard and was restarted as a ProIV/Java program (don't ask - it wasn't my choice). I'm going to drag this home and see if I can get it running in any fashion on my home computer, which simply may not be up to the task - VS2010 was sluggish on my work machine (Windows 7, 3GB of memory) and might simply choke my home machine (Windows XP, 2GB of memory).

I also took some time and sifted through a lot of game engines - reading specs and sales pitches. HGE 1.81seems to run on Visual Studio 2008, and I'm wondering if I can finagle it into 2010. This is the environment I'm most familiar with, familiar meaning I can navigate the menus and have designed some screens in it - but not actually coded. Combined, though, if I can get this running, I have a "free" base to start with.

Still digesting all the other posts here as well.

[Paingod]

So 9 years ago I posted this, and it looks like I've gotten nowhere. 9 years is a long time. In that time I've bounced off this a few times, mostly out of frustration that I couldn't get "running" as fast as I wanted, but also because I just couldn't stay motivated enough. Every 2 or 3 years I "tried" to get into it but couldn't find the time/energy/motivation to continue.

I'm back in this with some new ideas and new motivation. Each day I'm doing a little more. Not planning, but doing. I've actually gone beyond "looking" at tools and have started using them - C# scripting in Unity and working through tutorials. Over the weekend I worked through a tutorial on animation and put together a "working" clock from scratch that was fully animated, and spent time following along with lessons on tilesets, cameras, collision, layers. Lots of basics.

The logic behind programming makes sense to me, even if the language is unfamiliar. I "get" how thing are supposed to work fairly intuitively, even though my exposure to programming was over 15 years ago. Unity makes it pretty easy to slip back in.

Today I'm spending time hammering on a Game Design Document so my ideas are more than pencil sketches. I'm trying really hard to come to terms with this being an extremely long process and have found that the incremental successes I've had thanks to the extensive guides has been really encouraging. Being able to get something done in a few hours has made a huge difference in keeping me engaged. With the way Unity works, I feel like I can take incremental little steps and combine them later to form a larger, more complex whole. There's a metric TON of free materials to start with that I can rip apart and examine to find out how they work.

It's interesting to me that the general ideas I jotted down 9 years ago still echo in what I want to do this time, too.

[hitbyambulance]

if one wanted to artificially restrict the system requirements and scope in an intentionally retro way, i can't recommend PICO-8 highly enough

https://lexaloffle.itch.io/pico-8

(it's included in here as well : https://itch.io/b/520/bundle-for-racial ... d-equality )

more info on the 'fantasy console' thing: https://uxdesign.cc/fantasy-systems-pro ... 4381be06fc

[Paingod]

https://lexaloffle.itch.io/pico-8

That's a very cool little game-builder! It kind of reminds me of a "Super Mario Maker" type theme, just at a glance.

Having completed a Game Design Document (GDD), I suddenly realized the large scope of what I wanted to do with a game that had the player experience 'evolving' through 5 phases of play... and that was probably excessive as a first foray into game making. In response to that, I've scaled my goal back to creating a more simple platform-style side-scroller with elements I wanted in the original final product. Basically, a side-scrolling shooter with character customization. Nothing groundbreaking there, but it'll be mine, and it's a smaller chunk I can tackle and hopefully re-use as elements in the next stage of development.