Jumping from small scope to large and in charge.

[GraysonEvans]

So far all of the games I have made have been really small and personal, also really poorly put together and an abject failure in almost every way.

 

So after purging all evidence of any games I have made I thought I would start working a project in the scope of a "real" game. But I am finding the idea of making a full product that I will have to put my name on intimidating.

 

 

Maybe I am making games for the wrong reasons, I don't want to make games to have a career, but to make friends. I have terrible social anxiety and have a cycle of losing my mind and closing my self off from people, I guess I make games because I am tired of being lonely and I don't know how to talk about my feelings.

 

 

All you guys on this forum are so talented and I am paralyzed by the fear that I am wasting everyone's time, I open up GameMaker and I have a panic attack. Half of the time I just want to quit everything and disappear.

 

 

I think I lost the message of this post in my little rant but I don't know, you guys are cool and are talented.

 

 

Making games is scary and hard and ugh

[clyde]

You aren't wasting my time. I only have a few websites I like to check during commercial-breaks and during down-time at work. It's nice to have your existential doubts available for my perusal.

As far as how to make a big game: I don't know anything about it, but if I was to try to do it I would probably concentrate on making all the components flexible and modular so that it would be easier to add stuff later. That includes trying to keep my scripts as specialized and small as possible. I didn't really know what people were talking about when they said "modular" for a while, but I found this tutorial series and the first

were very helpful for me to start to understand what modular is and why it's a desirable characteristic. Even though he is just making a database for his favorite books, this demonstration of how to use properties and constructors in C# has been one of the most helpful things I've learned about how to organize my scripts for games.

I actually have a bunch of unfinished projects that I haven't stopped working on. I've noticed that I get better at scripting over time, so I just open old projects when I'm in the mood and do something new in 3 hours that would have taken me a week back when I was last working on it. 

Sometimes I get freaked out by the enormity of all the potential consequences of the actions I am considering, what usually helps is just focusing on the most immediate next step like "How am I going to get this sprite to appear during this line of text?" instead of how much of a hassle my taxes are going to be when I get rich and how I might have to hire people that I can't trust to deal with all the money I'm going to be raking in from my sick games. 

[GraysonEvans]

I find that my fear stems from the fact that I have been lucky enough to fall into some exclusive social circle and it's a lot of pressure. 

 

Lot's of talented people in arms reach and I don't think I belong

[CEJ]

The largest projects I have worked on have almost only been in a school setting with at most like 20 people, we are at the moment like 13 I think. The actual games are scoped very small though and they are for learning purposes. But I think for any project of any size, documentation is quite valuable, especially larger projects. I get paralyzed if I try to keep it all in my head, so I write it down. For example, a lot of games needs to have an art pipeline, animation pipeline, level design pipeline. Like, what are the steps you need to do to import a 3D mesh or animation. Of course when you are working with other people, you get the luxury of not having to worry about the other disciplines as much. The only reason I specifically mention researching and documenting the content pipeline is because that's an important part of what I personally do as a Tech Artist at school.

[GraysonEvans]

The games I have made and continue to work on are so far pretty simple. I am not a programmer by trade so mechanically all my games are very simple. But I like telling a story and exploring things with in my self that I have trouble talking about. I guess the thing I have troubles with is commitment, I start working on a project and it is really bad and not fun or interesting and I get discouraged and throw it away. I guess if I just keep chipping away at it and understand that it won't be exactly as I pictured it, at least it will be done and given the proper time that it needs. 

[itsamoose]

I've only worked on 3 games, and for 2 of those it was only in a QA capacity for a period of 6 months.  I guess my most recent project is the first game I've actually made and lucky for me the guy I'm working for is a 12 year veteran of the industry so he's been a big help.  Rather than go on a diatribe about what you should and shouldn't do, here is a list of things that I have found work for me.

 

1.) Plan: Before you do anything, make a plan.  Also don't try to plan everything all at once, just take one element and plan that.  For example, how does the player move around the game?

2.) Plan Extensively: Don't just say the player can jump, describe how they jump, what the jump can be used to do, what happens before, during, and after, the jump, what button triggers the jump, how is speed modified during the jump, can the jump be comboed with any other abilities and what is the result, etc.

3.) Research: Always research something you've never done before.  This is particularly useful when working with AI, where saying what you want to do is great but making that actually happen requires specifics.  Does the player move within a navigation system, freely with physics impulses, on pre-defined paths, etc.

4.) Document: Put it all together, take the plan, the method for accomplishing the plan and make it into a cohesive whole.  For me this isn't usually a full GDD or anything, just some images and notes that describe the whole process

5.) Prototype 1 thing at a time:  Don't prototype the whole game, just one mechanic at at time independent of everything else

6.) Think Small: Rather than try to envision the whole project all at once, but rather take whatever mechanics you want to focus on and figure out what you can add to them rather than building a whole additonal system.

7.) Steal other people's code:  Don't plagiarize their code, but do steal it.  Look at it, understand it, try to recreate it, make it better, etc.  A great program for this when working with .Net languages is .Net Reflector which can open up a DLL and let you look at the code.  I learned so much that had previously eluded me by just looking at the code for Bastion.

8.) Make notes in the code:  Prefixing a comment with // TODO:   will allow you to easily resume your spot by looking at your task list (in visual studio anyway, probably other editors)

9.) Create an Implementation Plan:  This plan should basically be the code you will write for the project as pseudo-code that describes to the letter what needs to be done

10.) Be aware of interactions:  This is more something that I've learned on my current project where we have certain items that can interact with one another creating new effects.  Every time you do something like this the work involved goes up exponentially so just be aware of that.

11.) Have someone else review your work:  This is really the only way I've been able to break myself of bad habits

12.) Start over:  Just because you have something done doesn't mean it is done.  The first time through you'll make mistakes or do dumb stuff, and in my experience it is sometimes better to take a half hour and re-write something to avoid future problems than it is to try and tweak and tune everything until it works just right.  This kind of thing is fine at first, but after a while it becomes unmanageable.

13.) Math:  You think you know, but you have no idea.  Learn as much about vector math as humanly possible.

14.) Make things for other people:  Try writing a script for someone or doing some research to help someone answer a question you don't know the answer to.  You'll likely learn a lot in the process

15.) You absolutely belong:  Programmers can be colossal dicks.  They are often passive aggressive, post annoyed responses to questions, fiercely argue what way is the best, and berate you for not googling something that is common knowledge to them or not knowing where in the documentation to look.  Don't let it get to you.

 

I haven't made any groundbreaking games doing these things but I have learned a lot more than I would have otherwise, and even ended up creating some stuff others have been able to use.  When I wanted to learn about Component design I created a project where I basically recreated Unity's component system in XNA.  Then I posted this on BitBucket and have gotten a few emails from people either thanking me for helping them or giving me pointers on what I could have done better.  The last thing I would say is that you just need to be patient.  It takes a long time to do all this stuff, especially if you are teaching yourself along the way.