Jump to content
  • Advertisement
Sign in to follow this  
W84M3

First game engine

This topic is 1059 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello!

I'n new to this forum so i don't really know how this works smile.png

 

For some time I want to create a game... any game but i don't want to use any game engine our there simply because i want to understand how all of this works, so i want to create a game with an engine built by myself.

 

All i want is a game engine capable of run a simple 2D game, for now since i want to start with the very basics and grow it from there. I would love to have a final engine that could run anything, for purposes like LudumDare for instance and to grow my portfolio.

The game will be something like a top view shooter, with simple AI that follows and shoots back.Or even pong, that will work.

 

Now i have some experience with programming since i'm taking a computer science course at university.

 

I'm thinking of using C++ and OpenGL. (This is not definitive. If u think i should start with something else please do tell me)

I only know the basics of C++ and i know very little to nothing about OpenGL. I've been watching a youtuber (thecherno) create his own game engine with GLFW and GLEW, So i want to do something in those lines aswell

 

My issue list:

Where do i start?

What design do i need to do in paper? Diagrams and such.

What does a game engine need to work? What are the main classes i will need?

After I have built the basics to run the game how do I improve from there?

 

Hope i got everything cleared enough to be answered.

Edited by W84M3

Share this post


Link to post
Share on other sites
Advertisement
Well first. You don't start with an engine. At all. You start with making a game. Many games. And your experiences in making game will help you later on, much later on, in your game engine decisions.

But for now, you need to know how to make a game. From start to finish. So you'll need to use a library. My suggestion right now is to use Python and PyGame. It'll get you up and running sooner than dealing with C++.

tl;dr: You're not ready for game engines yet. You need to make lots of 2D games first (and complete them). Focus on that first.

Share this post


Link to post
Share on other sites
Where do i start?

 

 

First, you give up the idea that you need to -- or should -- make a "game engine." It's a waste of your time. You don't need an engine to make a game, and given your documented level of experience you aren't capable of making one that measures up to your own standards yet anyway, because you know almost nothing about what goes into game development or game engines.

 

You need to learn that. Which means you just need to worry about making your game.

 

What design do i need to do in paper? Diagrams and such.

 

 

You don't need to do anything on paper, although you can if it helps you refine your ideas.

 

 

What does a game engine need to work? What are the main classes i will need?

 

 

That depends on what kind of game engine it is, and what its goals are. It's also not something you need to think about right now.

 

After I have built the basics to run the game how do I improve from there?

 

 

As you're building something, you'll come across problems you have to solve in ways that you're not super thrilled out, that you think could be solved better but which you're currently prevented from solving better by some other issue or architectural decision you've already made. Some of these you'll solve immediately. Others you'll put off. When you're "done," you can maybe consider going back to revisit the issues you've put off.

 

 

The "basics" of C++ is probably not enough to jump immediately into creating your own 2D game with OpenGL. Generally I'd recommend starting with text-mode, console-based games first, to flesh out your ability with the language and to practice some common game development idioms and techniques. Can you write a text-mode guess-the-number game? What about blackjack? Or hangman? What about a text adventure game like Zork?

 

If you feel comfortable tackling tasks like that you should try moving on to windowing and graphics using GLFW or the like, perhaps recreating Pong or Tetris. 

 

As you do this you'll have multiple projects under your belt, wherein you learned (hopefully) at least one new skill. As you complete each project you can look back at your code at the things you feel you'd reuse for your next project and you carry that code forward. Eventually, do this enough times, and that's your own basis for your own game engine.

 

You also should disabuse yourself of the goal to "do everything yourself" sooner rather than later. Within practical limits you are always going to be using libraries and software that other people have written for you, and you can still understand how those libraries work without having to build them yourself anyway. In fact, you're rather likely to create a disaster if you just trying to build everything yourself from scratch, because you're assuming you're going to be able invent all the same technologies that we as a collective industry have spent years building and refining. And the chance of that is rather small.

 

Instead, try to look at the decision like this: if you're talking about a component of your project that is unique and critical to the business success of your project, that's usually a good case for building a thing yourself. Things like gameplay mechanisms you'd like to show off, or maybe an incredibly novel method of non-photorealistic rendering, or whatnot. Things that do not constitute unique selling factors of your project you should consider "buying" (using existing implementations of, even if free). This frees up your time to focus on the unique aspects of your project that will make it shine, and decreases the risk that, for example, your crash reporting or analytics code will fail spectacularly because you made a rookie mistake instead of using a battle-tested off-the-shelf solution.

 

The exception would be, perhaps, things you want to be able to do unique and interesting work in but can't yet. For example, if your goal is to be an amazing graphics programmer who builds all kinds of awesome new rendering techniques or whatever, then pretty soon after you learn how the basic graphics pipeline works (by using an existing rendering API), you'll want to start tinkering on your own to develop your skills and knowledge. But if you're not interesting in pushing graphical boundaries, there's not as compelling a reason to be writing your own low-level D3D12 code to move a few hundred sprites around (for example).

Edited by Josh Petrie

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!