Question How do you think from what point you need to start making your game?

I mean, for instance I have an idea of gameplay. And what is next steps? Prototyping or maybe brainstorming, asking different questions like “what will player experience look like?”, changing point of view on idea?
Maybe, it’s very fool question, but I’m newbie in GD.

 

i think it is good to write out the game in entirety first. just focusing on design first.

when that is finished, then you can create a pseudo-api.

once you have both of those done you'll probably want to iterate a few times on both of them. By the time you finished, you'll have a nice checklist to start from and if any big questions remain, you'll know what they are.

 

As an alternative approach, you could jot down a few pillars and hooks.

Pillars are fundamental features of your game (e.g., crafting, linear dialogue-heavy story, etc.). If you ever have a question of whether to go with option A or option B, you go with the option that serves your pillars.

Hooks are the unique innovations that bring players into your game versus other games in the same genre.

Alternatively, you could think of these as anchor and hooks, like this excellent article by Akupara Games.

Then make an extremely rough prototype to test it out. Implement just enough, and no more, to test the idea. The more bare-bones it is, the easier it will be to iterate. Jonas Tyroller recently released a good video that shows how they used this process to iterate (and massively change) their game design:

(I think he got a little distracted having fun with an AI art generator, but I can't blame him; they're fun to toy with.)

 

What is pseudo-API?

 

writing pseudo-code. In other words, jot down basic ideas about what sort of framework classes you'll use. How will different classes in the game be organized, communicate with each other, etc.

The main thing you want to define is what sort of designer facing parameters will you need? As in, when you are working on balancing the game, what parameters would you want exposed so that you can easily do that?

As for class-to-class communications and individual behaviors, you don't need to spell out small details at first. Just big picture stuff. Once you have the big picture framed, then you can test it by going into details to ensure that you ideas hold up to scrutiny.

You can iterate on the entire game several times like this before doing anything high commitment like writing code. It can save you a lot of time and troubles compared to going in guns blazing.

However, if you haven't made at least a small game before, there is no point trying to plan like this at all. It's not useful until you have enough experience to know what tools you have in your toolbelt.

 

First of all. It's a great question. It's not obvious how to begin your journey and there are many paths to take. Some better than others.

When I made the decision to begin game dev. First thing I did was exactly what you did. I asked how to start. Put this question into YouTube and found a plethora of videos and information on just this starting point. Some of my favorites were Thomas brush videos. And GDC talks on the subject of starting a first game. GDC is game dev con. And there are a ton of awesome talks on many different subjects of game dev.

I'm fortunate to be able to listen to headphones while I work so I spent at least 4-6 hours a day, 5 days a week, for about 2 weeks. Just listening to talks and instructional videos. I would even listen to the coding tutorials just to start hearing the terms so I could recognize them easier.

When I would get home I would listen to music and just come up with ideas for games, their gameplay, story, how the game would feel. What emotions the game should make the player feel. Really just trying to get my mind into the mode of learning and uunderstanding. I didn't stick to one topic, I let the brainstorming do its thing and just made a bunch of ideas.

Next step I took was jumping into unity, blender, and gimp. All free tools which will help with developing. Watched tutorials on gimp and blender just to get a feel for them.

Also started writing some code from tutorial videos and putting together free assets into something even as simple as making a spaceship look like it's flying. Then if I wanted to make it fly I'd watch tutorials how to do that. I had 3 small projects I worked on before I landed on the one I wanted to turn into my first game or first completed level.

Started a 3rd person Sci fi game. Made the character able to walk around, learning the basics of movement and controlling a character . Started a oregon trail style game, basically messing around with and learning user interface stuff. Then started a side scrolling 2d, putting together things I learned from the last two and learning new aspects which would make it feel more like a game.

I then decided to start working on my first official project, using all the knowledge gained over the past 2-3 months to push into it.

I am a guppy in an ocean learning every day. I'm sure my code is a dumpster fire, but it's about the knowledge gained. Every day or hour spent developing is an experience to learn more. I'm looking at this first level as the stepping stone to my next project. I've set a goal to finish this first level to completion. Once I achieve that goal I can decide if I want to continue working on this project, or take everything I've learned and start a new one. Cleaner code, smoother development, all while learning even more.

All in all I think starting out with a few tutorials and free assets is a great way for you to get an understanding of how long it can take. This will help you to not make unrealistic goals and get discouraged. Take every hour, day and project as a new tool of knowledge in your belt to use down the road.

 

I think everyone has a slightly different approach, but my one is to prototype with code and quickly made blocky models, focusing on the one mechanic that defines the game the most.

For example, if I want to make a space game and the main hook is being able to take apart capital ships, then I'll model a blocky fighter and capital ship, separate the cap ship into parts, and start prototyping how the player flies around and targets the different parts.

IMO the most important thing is to zero in as quickly as possible on any disfunctional aspects of the main mechanic (e.g. being too boring, too complicated, not as good as something else etc) to see if it really plays out how you imagine.

 

My opinion is that you don't really have a game idea until you prototype it. You can have idea in your head, sure, but you don't really have any real proof that it'll translate into a fun game until you implement it. For that reason, I'd start with a prototype. Focus on the core experience and develop a fun gameplay loop.

Also, avoid the temptation to buy a lot of assets at the very beginning of your project's development. There is a temptation with any hobby or endeavor to go out and buy a lot of cool stuff that will "help" you on your journey. A lot of times it's just a way to feel like you're making a lot of progress quickly without delving in to the real work. Sometimes it's just a way of procrastinating. This is a trap I've fallen into before.

Assets can be very useful, but you really need to know what you're doing and where you're going for that to happen.

 

@TonyLi and subsequent posters made good points. The sort of planning I am talking about is like, pre-production, but not the first thing to do. It assumes your are locked onto the game, so before diving into the production of it, you completely scrutinize the full game design and also make a general plan for the technical stuffs.

But yeah, it is not a quick or low effort thing to do, so no sense making a big master plan if you haven't first made at least a small prototype to get confidence that the core premise is going to be as cool as you think it will be.

 

This is valuable advice. Also wait for the sales and humble bundles if you have the patience.