Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Hi! So...how do you start building a video game? Locked

A topic by Medinut created Jul 13, 2022 Views: 2,477 Replies: 13
This topic was locked by No Time To Play 77 days ago

spam prevention

Viewing posts 1 to 8
(+1)

So I was thinking of  making a video game... a room escape game, to be more specific. I have done several plannings on a piece of paper about the flow chart, and I tried to do some layout design and several case studies. But I still have no idea where to take the first step: do you do the programming first? If so, which platform would be the best to perform the task? Or do you make the art first? And the most part that freaks me out: how is it possible to just start learning an engine from scratch? (for some reason I feel like I don't speak computer...like I am allergic to technology)

(+2)

Before jumping into making a game, you should do a bit of research and maybe a couple of tutorials. The research part is looking at what engines are available and which will fit your needs and skill set. I can only speak to the ones I’ve used: Unreal, Unity and Phaser. In the order I listed, Unreal is the most difficult to learn but does more of the work for you. Phaser is the easiest to learn, but you will be hand coding EVERYTHING! And Unity is somewhere in between.

As far as coding, Phaser uses javascript and you will code everything. Unity uses C#, but you’ll mostly be attaching individual scripts to objects. And Unreal uses C++, but, most likely, you won’t write a single line of code.

Myself: I use Phaser because it’s what I use at work. I’m writing code in Phaser for 8+ hours a day - so I know my way around it. This is part of choosing an engine. Unreal or Unity may be a better choice for a given project, but I personally could get the project done in Phaser in less time.

As for your question of art vs coding: TBH, most people focus on one or the other. The reason I have an account on this site to begin with is I’d rather just buy some artwork that’s already done and dive into the coding.

Thank you! I think that is what I am going to do... looking at the engines and taking some notes down perhaps. Thanks so much for the advice!

(1 edit) (+5)

Leave the final art until later.  The reason is that you probably don't know exactly what art you need at the beginning.  If you buy or create art before prototyping the game, you are likely to find that some of it doesn't meet your needs and has to be redone or replaced.  It's generally best to start with placeholder art and fill in the real art as you go.  A five-second scribble or grey box works just fine at an early stage.

As for how to get started, if you don't have a programming background, I would probably just pick a free engine like Unity or Godot and start doing the tutorials.  They start out very basic.  What technologies work best for a given project just depends on the nature of the project and your personal preferences.  I would really recommend doing some small projects first to get used to the process, decide if you like the tools you are using, and get some rookie mistakes out of the way.  If you are starting from scratch and try to jump straight into a large and complex project, you will probably have a difficult time.

Thank you! I guess I should break it down a bit more since I feel like I am making the whole thing complicated for myself. (BTW I guess I failed to explain about the layout design part...I started on that earlier because I thought if I am designing a room escaping game I should work on how the room looks and how the props in the room can help the player. But I am sure that I am a bit off track since I did spend a lot of time tangling in art. Thank you again!)

I'm not sure if I agree with that.  No, wait, I'm pretty sure I disagree with that.

If you're going to be buying stock art, then I think it makes a lot of sense to buy as early as possible, and to design the game around the art instead of the other way around.  Because if you fully design the game before acquiring the art, then you're going to have a very hard time finding the art you need.  The last thing you want is a full game with ugly placeholder art and no way of replacing the placeholder art.

If you're going to make your own art, then having some "real" art is a great way to experiment with and ultimately tie down the look of the game.  It also allows you to quickly identify your limits as an artist.  It's also best to tie down the look of your art as much as possible before you start animating, because it's going to be a lot harder to make changes once you've started animating.  Do test your game, and your art, at all stages of development, but don't put off until the end.  Often the art influences the game as much as the game influences the art.

On the other hand if you're hiring a third party artist to make custom art for actual money, then you probably do want to create placeholder art first, if only so that you can communicate effectively with your artist.

(1 edit) (+1)

I didn't say to put it all off until the end.  The question in the OP was whether to do the programming or the art first, and my advice was to not focus on making art before you know what art you need, in what quantities, and to what specifications.  You don't want to spend days meticulously drawing enemy sprites, only to realize later that you really needed them to be 20% smaller.  Placeholders are what you use to figure that stuff out.

(+3)

Midnight Spire and Pritt have some great advice, especially in regards to tutorials. 

To add to that, I would recommend getting your basic game loop working before spending too much time with levels and assets. By "game loop" I mean all the logic from starting the game, playing a level and then failing or continuing to the next level, quit and restart options, etc. If you anticipate that your game will have a menu of some sort, do a very basic text-based menu first with only the most essential features (Start, Save, Load, Quit, etc).

Think of the "game loop" as the skeleton of the game. 

Thanks a lot! So just putting down the process that the player ideally would go through? Should I also run some play-testing to see if things work out for the player?

Basically, yeah. Have your initial "game loop" be a very basic player experience. Have two levels, one to play and test your game mechanics and then the next level is there to test that the game transitions to the second level properly if the first level is completed. Once your "game loop" is working, you can start to "flesh it out" with levels, sounds, music, assets, etc. 

I would also recommend archiving your project once you get the basic "game loop" done. This way, if you decide your game needs to be drastically different, you have a fully functional "skeleton" to work with so you're not starting from scratch.

(1 edit)
join a Team, or if you can Lead use https://itch.io/docs/creators/kickstarter brainstorm to collect unityassets for the videogames, test and build it together. [unpaid] Free Levels in WebGL play & like.. Ref:Gif https://tenor.com/view/unity-sucks-unity-yeet-unity-yeeting-unity-unity-engine-gif-15045116 invite:dev
join a Team, or if you can Lead use https://itch.io/docs/creators/kickstarter brainstorm to collect unityassets for the videogames, test and build it together. [unpaid] Free Levels in WebGL play & like.

Thank you! Haven't noticed that there's this useful section...Thanks a lot for telling!

(+2)

On the subject of levels: 40Watts brings up a good point to start learning that right away. Every engine has some sort of system for building levels and for transitioning from level to level.

Another point about levels is to get comfortable with how levels work in your engine of choice (or “scenes” as some engines call them). At first you may just start building out every level. But once you learn your way around, you can start to sort of template your levels. I make, at most, four levels per game. The main playable levels will read in some sort of configuration that tells it what assets to load and what to do with those assets.

For 2D games, for example, you could use something like Tiled to build your levels (https://thorbjorn.itch.io/tiled). So you build one level in your game, then just use Tiled to drag&drop levels all day long :)

Deleted post
Moderator locked this topic