A friend of mine and I are making a 2D game engine as a learning experience and to hopefully build upon the experience in the long run.

-What I'm using:

•     C++;. Since im learning this language while in college and its one of the popular language to make games with why not.
•     Visual Studios; Im using a windows so yea.
•     SDL or GLFW; was thinking about SDL since i do some research on it where it is catching my interest but i hear SDL is a huge package compared to GLFW, so i may do GLFW to start with as learning since i may get overwhelmed with SDL.

-Questions

• Knowing what we want in the engine what should our main focus be in terms of learning.
• File managements, with headers, functions ect. How can i properly manage files with out confusing myself and my friend when sharing code.
• Alternative to Visual studios: My friend has a mac and cant properly use Vis studios, is there another alternative to it?

I'm actually making a C framework with OpenGL and GLFW. So, here are my cents.

2 minutes ago, AyeRonTarpas said:

SDL or GLFW; was thinking about SDL since i do some research on it where it is catching my interest but i hear SDL is a huge package compared to GLFW, so i may do GLFW to start with as learning since i may get overwhelmed with SDL.

SDL is a larger library compared with GLFW. It isn't big to the point that will make you "overwhelmed", though. If your game engine will be exclusively 2D, it's a doable option. But, if you want something for 3D, too, then SDL is in my opinion a "waste", since some of its features are dedicated for 2D. It wouldn't impede you from making a 3D engine, but there would be that "waste" of unused features. That said, GLFW is cleaner for doing a single job.

2 minutes ago, AyeRonTarpas said:

Knowing what we want in the engine what should our main focus be in terms of learning.

Is you engine going to manage all assets? Textures, scenes, camera, meshes, animation, shaders/material? You can go with two options, let the engine manage these assets and be responsible for creating and destroying them, or give more power to the user and let the user decide the life time of assets. There's a trade-off here, which is the more power the user have, the more they have to write their own implementations.

How much of OpenGL you two know? If not much, start with "modern" OpenGL (a.k.a. OpenGL with shaders). Don't go with fixed function pipeline (old style OpenGL). OpenGL version 3.3 is a good candidate as I mentioned in other thread: 

Also, how much of OpenGL you will wrap? You certainly will wrap to a degree, since functions to create/delete textures/framebuffers/shaders/VBOs/VAOs will have to use OpenGL.

Quote

• File managements, with headers, functions ect. How can i properly manage files with out confusing myself and my friend when sharing code.

For each type off asset, have a header (.h/.hpp) and a source (.c/.cpp). Then having a central header (myengine.h/pp) that include the header of the types. If this is a possibility, it helps for who uses your engine to include only a single header.

Use git for version control. There are several workflows to work with git (for example: http://nvie.com/posts/a-successful-git-branching-model/). Some might be too complex for a team of 2 people. Check what works better for you. You will probably make mistakes with your workflow, so just start using it and learn the best approach for you early.

14 minutes ago, AyeRonTarpas said:

• Alternative to Visual studios: My friend has a mac and cant properly use Vis studios, is there another alternative to it?

He can use clang or gcc with some editor (Atom is a nice one with good integrations). I don't use Visual Studio (Linux), but it seems like it has support for CMake since 2016. Couldn't you use the CMake instead and make the work with the two platforms easier?

7 minutes ago, ferreiradaselva said:

7 minutes ago, ferreiradaselva said:

Is you engine going to manage all assets? Textures, scenes, camera, meshes, animation, shaders/material? You can go with two options, let the engine manage these assets and be responsible for creating and destroying them, or give more power to the user and let the user decide the life time of assets. There's a trade-off here, which is the more power the user have, the more they have to write their own implementations.

How much of OpenGL you two know? If not much, start with "modern" OpenGL (a.k.a. OpenGL with shaders). Don't go with fixed function pipeline (old style OpenGL). OpenGL version 3.3 is a good candidate as I mentioned in other thread: 

The engine is going to be more personal between the two we have no plan yet to share the engine unless its within the group ill be working with so i may just have the engine do it entirely.

Both of us are very fresh to OpenGL we know little to nothing, im currently doing research but still know the bare bones i would say. Still learning as i go from video tuts to some discussion. Though some website would be nice if you know some.

 

15 minutes ago, ferreiradaselva said:

He can use clang or gcc with some editor (Atom is a nice one with good integrations). I don't use Visual Studio (Linux), but it seems like it has support for CMake since 2016. Couldn't you use the CMake instead and make the work with the two platforms easier?

I use to exclusively code in Java since highschool so never really explored in any IDEs for C++ i will check out CMake if it makes it easier for us to work on two platforms.

1 minute ago, AyeRonTarpas said:

Both of us are very fresh to OpenGL we know little to nothing, im currently doing research but still know the bare bones i would say. Still learning as i go from video tuts to some discussion. Though some website would be nice if you know some.

https://learnopengl.com/ is great. And the examples are in C++, since it is what you are going to work with.

For a real deep learning purpose, I wrote my own GLFW like wrapper generator that grabbs the khronos specs from github and creates the functions/enums from the xml file that you find there. Otherwise GLFW is a good library to go for, especially for the benefit features of creating window and input handling when the focus isnt going into real cross-platform development (in this case I would also do it on my own because it is very simple to implement that few features you need for each platform using the system APIs, especially when one companion lives on a unix system)

SDL in my opinions is too heavy because it has grown for a full all-in-one solution utilizing OpenGL and DX over the years and it lacks for the learning purpose when not doing certains tuff on your own.

A good point to start is to setup your project first before doing anything else so you initially setup your code reposetory the right way. There are thousands of people doing millions of different reposetory structure so find the one that suits best for you. I have gone with a modular based approach giving each module an own sub-folder and project file so you could work in parallel on different projects that might not influence each other and setup an engine core project anything is put into that any other module is referring to. I have also written an own build tool in C# that helps me setup my project files from a single buildfile (that is some kind of mixed JSON with C++) and is able to trigger the build pipeline (compiler, linker and further steps) from the command line. I'm targeting different OS'es and also console platforms so this seemed to be a good solution for me, you might go with something simple (make for example except that it is too Unix based as it needs a unix shell emulation on Windows). That worked best for me and my engine.

You then have to decide how deep you are planning to go into engine development. One could go for years doing anything on your own with only some help from the OS APIs or a few months using any third party library you could get. It should not be the focus to get buitfull graphics very early rather than a robust and general environment as the main goal of your game engine (this is a quote from someone I couldnt find yet but he's right about that) and dont be frustrated from people telling you to "show" something when doing this. This is the most reasoned part for people quitting because they do not "see" any progress. A game engine consists of much more than graphics that is different management structures for memory, assets, render pipeline and so on, a huge ammount of math (without that you cant render anything) and some utility classes that make life easier.

I personally would also go for at least OpenGL 4 Core profile while I agree to ferreiradaselva that it dosent make any sense any more to learn the good old fixed function pipeline, it dosent make sense either to learn old/outdated GL while most hardware supports it but vendors are now stronger focussing on DX12/Vulkan (and of course VR). There are some major differences for example writing shaders using the obsolete varying qualifier type in GL3.3 vs in / out keywords in GL4+ to at least name one.

To the management point I could recommend the coding guidelines of existing successfull engines like Unreal 4 or Cry as a reference how good code should look like (except the prefix letter from unreal) So that you always choose expressive names to whatever the class/function does and name the file in relation to what is inside. A class providing streamed access to an asset file should be named AssetStream.h or <AssetType>Stream.h while I prefer to store the .cpp files in the same location, there might some project structures use different ones like Include for headers and Source for implementation files. You will loose overview in my opinion especially working on large code bases so I avoid doing this.

A last advice I could provide is to forgett about the straight class oriented model that high languages like Java or C# lead. Use classes when needed but do not wrap classes arround pure static functions while a namespace does the same trick and will provide a little more performance

namespace GL
{
    void Enable(GLenum cap);
}

//instead of

class GL
{
   public:
      static void Enable(GLenum cap);
};

//while access is still the same

GL::Enable(GLDepthTest);

Some people might disagree with parts or all of my post but this is my opinion and people out there will have there own one otherwise this questions wouldnt have been asked

Hi there,

I think you guys should try to implement by your own every module of a usable engine, this means IO, rendering, sound, input, etc. This way you will learn a lot and will have a good basis of engine development and how videogames work behind the scenes. In the meantime you will face struggles with C++ due to how write the code, dependencies among files, etc. so this will growth your C++ skill too.

I'm not quiet sure you mean in your second question, but I would say you refering how to fix the issue of working together in a same software project, so if I undertood well you both guys should learn some control version like GIT. This allows that several persons work together in same project with no (maybe some haha) issues meanwhile having a consistent track of the development.

Doesn't should a problem find some remplace to Visual Studio-like-editor in MacOS, but the important thing here is use the same compiler, It's not mandatory but for newbies won't add extra hassle in the development.

Also my two cents about SDL vs GLFW: for sure SDL is larger library with tons of functionalities, still doesn't remplace entire modules that in other way you would write by your own and also has a own 2D rendering API so you can put aside OpenGL. GLEW is just a wrapper for OpenGL functions and also offers system events.

I left you here a post I wrote recently about issues you may face at the start of development of a SDL-OpenGL engine.