I've tried reading books and various sources for making a game but I tend to get lost as I get more into it.

I was wondering if I could have something simple and the game still work? I don't have any code but I've been trying to think of a simplified way to think about the code, simple enough that it'll run.

class game
{
   main()
   {
      createWindow();
      gameLoop()
      {
         Update();
         Render();
      }
      closeWindow();
      return 0;
   }

   Update()
   {
      CreateObjectEntities();
      Input();
      UpdateObjectEntities();
   }
   
   Render()
   {
      //I have no idea what kind of methods go in here
   }

   CreateObjectEntities()
   {
      //Creates objects and add them to an array? I don't really know how to handle this
   }

   Input()
   {
      //Looks for input and updates player
   }

   UpdateObjectEntities()
   {
      //AI method that updates all the NPC characters
      //Method that checks if anyone was hit, killed, falling, etc.
      //Any other methods to update anything?
   }
};

If I went about making a simple game with psuedo-code as like a guideline would this be fine? Am I forgetting anything, I know I probably am? Would something need to be put in a different order? How should I go about handling rendering things? Should I put all the object/entities made that will be displayed into an array and then in the render method read from that array and render through the information given in that?

Thanks for any help.

Yes, that could work for a game, but you should start writing one, don't spend too much time thinking about it, you are already on track. If you're not confident enough to start one from scratch follow a tutorial, it's a good way to start.

Some changes I'd make are:

• Before the gameLoop you should initialize more things, not only the window. If you make, say, a basic Pong clone, you can intialize both paddles and the ball there.
• "CreateObjectEntities" in your pseudocode will be done every iteration of the game loop. I wouldn't do that, updating other ObjectEntities should be the trigger to create new ones (you update a training building and create a new soldier if a timer finished).
• 2 things about "Input()"... first, when you translate this to actual code, do not use "Input" as the name of a method, use a verb, "GetInput" or something like that. Second, your comment was "//Looks for input and updates player". The player probably should be an ObjectEntity, so the update should be done in UpdateObjectEntities with the rest, the "Input" method should only transform a generic event ("space bar pressed") to game related events ("shot key pressed").

You can use arrays to hold all the objects and sometimes you want more than one array (one for drawable objects, another for non drawable objects, etc...). But, really, start making a simple game, it's easier to learn one thing after another than everything at the beginning.

That is basically the main loop for an interactive style game.

However, if you aren't sure about those blanks, I would recommend against starting there. Classic analogies: start with baby steps, not a full-out run; start with applesauce and toast, not steak.

The first few games most people make are things like 'guess the number', 'tic tac toe', 'connect four', and similar simple turn-based games. You can learn quite a lot from them, including how to manage game states, how to develop an AI, and more. They don't require graphics, they don't require complex rendering, they don't require audio, they don't require complex input mapping. Just simple text based commands like "Type a box number, then press enter:" Do this until you are comfortable with programming, comfortable with debugging, and are ready to move on.

Graphical games are much more complex than text games. With 2D games you need to learn about graphical interfaces, about drawing and rendering contexts, about managing images and textures, and more. Often beginners in graphical games will use existing tools to build forms-based games. Often they'll remake the same 'tic tac toe' and 'connect four' style games, this time with clickable buttons using the UI builders in whatever IDE they prefer. Learning at this level also includes drawing apps where you can scribble on the screen, placing stickers or glyphs, and maybe some games like 'whack-a-mole' and 'swat the fly'. All of these games teach the basics of working with graphical resources, as well as working with events including timers and animations. They'll also teach how to work with existing libraries for graphics, for forms, and for other components.

Don't worry about getting in to components and 3D and complex architectures until you have advanced quite some ways into game development. It will come eventually, but if you don't have a solid understanding of programming and how to break down problems into useful systems, then you aren't quite ready yet.

Did you say steak.

In the famous words of Age of empires Start the game already.

One thing I've learned about beginning Game Programming: don't think about it too hard. Just start or follow a tutorial to help ha get started. Of you think about it too hard when you're a beginner you will get lost and never get done. Just start and don't worry about things too much. Your first couple games will not have the best code design at all . Just code and finish the game. Take notes about what felt like should had been easier. Can even ask for a code review here. Then in your next game try to implement those details you learned or took note of. If you keep doing this while making simple games before you know it you will have no problem knowing how a game works and how the next game you want to make should work.

To add to chad smiths comment, you can also always go back and rewrite / refactor old code of yours.

This can be actually very enlighting and a good lesson in just how much you improved since you last touched the code. It can also be quite the chore because you have to redo a lot of code, and sometimes you feel like you are "changing the running system" for no good reason.

It is only when you take some a year old, horrible code, and try to plugin some additional functionality (it is going to be a pain, if you have not written it well and with that in mind), and afterwards you rewrite the code and have the additional functionality plugged into the rewritten code effortlessly, that you see how much well (re)-written code can make your life easy.

Still, without the horrible first version, you wouldn't be able to come up with the better one, and would still have nothing. Or you would be writing the horrible version right now

Never be afraid that your code might be horrible. 1) You can always go back and rewrite, if you are not on a deadline, 2) if you are on a deadline, either you are already a good programmer and expected to churn out quality code in a short time, or it likely will not matter that your code is horrible (a lot of code in the real world is badly written, but functional, in my expierience. It is what happens when you put an inexpierienced or not highly motivated programmer under pressure, and are not expierienced enough yourself to judge to result)...

and finally 3) You learn by making mistakes. Don't expect someone to tell you all the mistakes you could possibly make, noone is inventive enough for that. Don't look for shortcuts when the only one to just invest more of your 24h per day into churning out code and learning from your mistakes.

my 2 cents as a professional programmer that is still regularly shocked at how bad his code was in this thing he coded a year ago