Hi, guys. I am really planning to dive into making a game, but I have ‘tried’ to dive into ‘making a game’ at least three times and got stumped all three times. I was thinking that it’s possible that I am just going at it wrong. I think I need to find a new process, orway to tackle making a game. So, what is it that you do? Obviously planning it comes first - I get that much. My goal shouldn’t be to wing it and see what comes out. I know what kind of game I want to make. I just want to know what part of the actual making process I should do first. Is it best to focus on art style, assets and animations first, or am I better off making the coding of everything first? Thank you!
Code everything using placeholder assets. This will help get a prototype running fast and thus makes it possible to evaluate the actual idea of the game. If you have a decent prototype running and you still think the game idea works, then get the art assets and code the rest of the game.
That’s what I thought. But, what would count as placeholder assets? Should I just use, like, cubes and spheres and such? Or should I actually get 3d models that I just wouldn’t use in the final game?
What that guy said! You have to keep your motivation up and not get swamped.
Try make your idea simple as possible while getting the gameplay you want, then make a promise with yourself not to add to it mechanically before the core is in. Making every aspect of a game is incredibly time consuming and hard I suppose, i’ve certainly learnt a few things about scaling down, forward planning and design, but most of all keeping it exciting. Unity’s perfect for this though, you can get stuff done fast, so keep it so you’re moving forwards and not getting trapped into months of noodling then losing all wish to ever see it again
And yes he meant use cubes and spheres or just any old stuff, doesnt matter, it’ll be replaced when you have the comfort of an actual game to rest on while you make it pretty
Wing it and see what comes out sounds exactly like my process. Get an idea, start prototyping and then iterate, iterate and iterate.
Well, since you asked:
1: Think about what I’d like to make.
Usually, while I’m gaming, or watching Let’s Plays on YouTube, I get an idea of something I’d like to build.
2: Identify things I would change about the existing work.
In my current project, which is based off of Zelda 2: The Adventure of Link, I wasn’t too hot about the way enemies and players interacted. I felt that Zelda 2 relied far too much on key items in dungeons, to the point where later dungeons felt contrived. I felt that the text engine was entirely too limited; NPCs couldn’t make themselves feel like a part of the world. I felt the level system to be superfluous. I felt the magic system to be either an implicit requirement for some circumstances (the second continent you go to, specifically) or superfluous (half of the magic in the game you’ll need to use exactly once.)
In modern works, nearly everything has been done once before; what will make your work stand out more or less is deciding what you will add or remove to make it effective. This is where you make that decision.
3: I start implementing the game, a feature at a time.
A feature is not the same thing as a mechanic, though it can be; mechanics (e.g. Overthrust and Underthrust in Zelda 2) are features, but so is basic movement, jumping, the Slime enemy, the Steelguard enemy, Fire barriers, swtiches that interact with various things, etc. Finally, give yourself a deadline such that you can either say, “everything is proceeding as I have forseen!”, or "maybe I’ve bit off more than I can chew.
I typically work five one-hour days (I have a day job) on my works. I usually devote the whole ‘mini-week’ (5 hours) to a single feature. If I get it done before then? I test, and add other small stuff. The point is, I keep the momentum going. I see that people tend to give up when they run out of steam, so I religiously avoid hitting the point of no momentum.
4: After implementing a few features, I release a webplayer and get public feedback.
This is very important, as your players will tell you all sorts of cool things. For instance, Caliber Mengsk was able to help me fix my basic movement and jumping controls to not feel so resistant to the player. Kelde has mentioned that the game world seems a bit sterile, because it lacks doodads that makes it feel lived in. These are all things I either A) have, or B) am currently working on prior to my release. These changes are recorded, and analyzed, and integrated into Step #3 above.
I usually release an update to my forum topic and IO website once per week; doing it any more frequently impedes making progress on developing the game. In any event, usually when something is implemented, it needs a lot of testing, recording, and analyzing before its to a point the general public would feel the slightest bit happy with. Even with you all, my fellow developers, the state of some of my webplayers is best described as ‘obvious alpha.’
5: When the game is in a place that it is publishable, I do so.
I usually have a deadline for that too, to create urgency, but often I can justify not releasing as, “it’s just not ready yet, [insert things here] need to be fixed before the wider public can see this.” I create my topics here, in various online communities I participate in (in a respectful manner, of course), and I update my personal website as these are achievements of mine. I rely on word-of-mouth advertising, because even though I can buy all the ads my budget will allow, the fact is that I have either A) made a game worth others’ time, or B) not. This evaluation is made by the wider gaming community, not me.
This counts as an additional layer of public feedback, leading to:
6: I write the Post-Mortem, or Retrospective.
Either in a forum post here, or somewhere/somehow else, for myself and others to benefit, there’s a few things to take note of:
What worked - What went as planned, if not better? What made even part of my goals succeed?
What didn’t work - Usually much longer, what were the stumbling blocks I encountered? What were the final criticisms of my game?
Takeaways - Based on the above two, I can derive new best practices, or reaffirm existing ones that I may have ignored. This is important, because…
Action Items - What will I do in the next project based on my takeaways, such that my next Post-Mortem produces more ‘What Worked?’ entries, and fewer ‘What Didn’t Work?’ entries.
EDIT: Added some more detail/thoughts/reasons on why parts of my process are there.
+1 I like Pelajesh idea, that’s actually what I’m doing now… working on a Multiplayer RPG, don’t have a name for it, no story, just thinking about how I can make a Web-based casual,multiplayer rpg that is fun, and easy to play with some unique features. But working on the very basics first, not going to kill myself with being too ambitious about the initial idea… the Basic Game idea needs to be Solid, and Tested before Investing too much into something that you’ll give up on later, or may crash and burn. Sadly that is the case with most Games I think that aren’t planned correctly.
I’ve learned the hard way, winging it isn’t the way to go. That being said though, sometimes it’s good to take a weekend off and just wing it and make a prototype, sometimes you’ll accidentally create something awesome.
If you don’t have dedicated artists, code first, and art later. This can be tricky at times, but if your game is fun while it’s made of cubes and spheres, then it’ll be even better once the art is done for it. Also, know when to scale down your grand vision. This is one of those things that just comes with experience, it’s easy to think you can do way more than you actually can. But this is a good thing, because a focused game is usually better than a game with 1001 half baked features.
Good luck!
Please list in brief what those 3 games involved and how you approached them, and we should be able to help you out.
I’d start by guessing you didn’t have a GDD and the games you were trying to make were too ambitious for you.
Well, the first two were kinda gone in a flash. I came up with the idea, looked at Unity, realized I didn’t know how to code, put assets in the game, or anything, and so I just gave up. Then I got more ambitious and willing, and I decided to try and make a MOBA; I’m actually going to start working on this again, right now, the right way. But, I tried to get working assets first, which seemed to be a bad idea. I downloaded a game character, made him low-poly, rigged him in Mixamo, then tried to animate it, but nothing came out right and after 3 days of virtually 0-0.1% progress, I just kinda quit on it.
My other project that I’d love to work on eventually, probably after I make my MOBA, or after I’ve sketched most of it out, is an ultra-realistic TPS. My goal is to emphasize the realism and the need to be tactical and work as a team to take down enemies, with realistic explosives and explosive radii, super quick-killing guns, a cover system and the likes. Think of it as combining Arma and BF4 style gameplay with CoD style maps and gun customization. I was also EXTREMELY considering going WW2 with this, as well.
I usually write a document with all the gemaplay and systems (camera, UI etc) I want in, then divide them to the smallest components or scripts and assets that will take to make them work, this helps me keep the scope to something manageable. Then I use Trac to manage my progress (or lack thereof!). It helps keeps me focused because I tend to derail a LOT when I find something I particularly enjoy coding, like AI.
Try not too get too ambitious from the start. A MOBA, for instance, would be waaaaay too big. Our imaginations are very powerful, but getting all that stuff in the game is hard work. Even experienced programmers have trouble making something ambitious if they’re working alone.
Start small, then keep on iterating.
Our process (honed over the years):
-
ideas shortlist, pick one (great ideas are common, and worthless)
-
prototype, no GDD. Is it fun?
-
lots of meetings over the direction for it
-
when a game is agreed on, we don’t work on it, instead we use google docs or equivalent and make lots of detailed documents. There’s the level design doc, the story doc, the systems doc (one doc for every major gameplay mechanic) etc - you get the idea, lots and lots of design, and these docs are continually evolved.
-
milestones, each milestone takes into consideration what needs doing and how long it will be. At this point only minor things are allowed to change in the game. A lot of time is available for polish too.
-
Repeat until finished.
Sounds anal, and not so much fun, but thats how you make a game with a serious intent on completing it. You can do it with an undocumented process but it will be a nightmare for anything larger than a tiny indie title.
I totally get what you’re saying. But, maybe MOBA isn’t quite the right word for it. Maybe I just meant like an rts. I wasn’t necessarily thinking of anything like LoL, with hundreds of different characters to play as, ranks and the likes. I was thinking more along the lines of Fat Princess style gameplay. My game would be: You’d pick from 3-4 classes, and try to get past archer barricades and destroy the enemy team’s castle.
Like a lot of these other people said, it would be one function at a time, too. I wouldn’t expect the prototype to be made in a week. Maybe just the character, or even just a prototype of the character and MAYBE a simple attack function, too. I get that making a game can be a very long and sometimes boring process. But, it’s hard to keep the idea in my head, especially when there is a way to get it on the computer screen! Haha!
An RTS or a “Fat Princess” game is very feasible to prototype by one person, think of the systems that are involved, deconstruct the games and make a list of the features. Then start coding them down one by one. Just remember to keep it small or you will never finish, giving yourself a deadline also helps.
I only develop 3D games “for now”. I have no clue how to go through with making 2D yet. My 3D game developing process is quite odd to be honest.
-
Lots of Research. I try to figure out both what the public is playing or has interests in and what my current interests are. I try to find if any games similair to my project are currently out there. If not then start making. I personally like to make simulators so I try to get clear info about the thing that i will be “simulating” and the locations these things are used.
-
Design build the models. I always make extremely rough looking models first just to get the scale and stuff correct. I always use 1:1 to try and prevent future issues. If I know a model is the biggest thing in real life then ill use that as a scale “representative” to relate the smaller items. After a couple of the rough models are made then ill start “smoothing” them out to make them seem correct. Basically I try to get as many as the models made before making the maps. If I feel I have enough items for on the map then ill put it together. I don’t add textures to most of the models till I feel that I have the folder layout correct.
-
Scripting and manipulating. I don’t get this far most of the time sadly. When I get one “scene”, view, location, etc roughly layed out, ill start to code and allow each thing to come to life.
-
Texture work. This part happens very rarely in my process. Basically I just get all the models textured and see how much of a performance hit the textures are. I don’t get to the texturing part that often due to a strange issue within either my textures or models. My projects never run right when I get to this point.
-
“Alpha” Testing. I’ve only gotten to this part ONCE and everything went down hill. If I actually got the textures fixed I would test to see what else would cause problems. I would test collisions, general animations, lighting, etc for any performance hits, bugs,glitches, etc. This part bogged me down so much that I actually got depressed. I stopped working on the project completely.
-
Repeat 1-5. Research, model, script, texture work, and test. Basically this would be the part where I start to add more. Never have gotten to this part.
First, do yourself a favor and read this thread. Finishing a product, however small, was always more important than WHAT product I built. I finished one, then another, and another, until I now have 5 products, and am starting on my 6th.
I cannot overemphasize how much I have learned via real products and real customers. Hippo, Asvarduil, cCoding, etc… offered great suggestions. Learn from their experiences and as a newbie game dev, make sure you take the path to the left.
Gigi
I agree with this to some extent. You should always start small, but it’s another question of whether it’s a good idea to release small. If you’re aiming for a small, mobile app, then small time-frames are doable. But if you’re trying to sneak something past, say, steam greenlight, 2 man-months is probably not gonna cut it.
Consider them prerequisites.