[Candescence]

Well, I think we've established that we'll be using C++ and OpenGL. We should allow this engine to run on more than just Windows, and last I checked, OpenGL was just as good as DirectX.

[Knucklesdood]

I have a number of additional questions about the underlying engine:

• What kind of build system will be used? Will there be some sort of premake solution that can generate different kinds of projects for different platforms, or will there be separately maintained projects?
  
• Will the STL be used? Boost? Many games avoid the STL or Boost because more highly optimized and use-specific code can be custom-written for the game engine.
  
• Will a math library be brought in or custom-made? (GLM was brought up earlier)
  
• Will a custom memory manager be needed?
  
• Is OpenGL the graphics library of choice? How about GUI APIs? APIs for editors and tools perhaps.
  
• How will fonts work?
  
• Which model/animation formats will be supported?
  
• How will input be handled? Which library or libraries will be needed to handle all forms of input?
  
• Debugging tools? AntTweakBar is useful.
  
• How are resources loaded in and handled by the engine? How does some high-level code (such as script or GUI interface) load in a renderable mesh?
  
• Will strings be allowed or forbidden in the engine? GUIDs?
  
• How are objects serialized? Binary serialization? XML? JSON?
  
• What form of script binding will the engine use? Lua, javascript, etc.
  
• How do systems operate and interact? Message-driven and/or event-driven?
  
• What is a game object? Is it a bunch of components? What are the core components that need to be implemented for pre-alpha?
  
• Where is the game loop? What does it do?
  
• Will any systems need to be multithreaded? (common candidates are resource loading or rendering; threads where "jobs" can be queued and worked on)
  
• Overall, what does the engine architecture look like? Is it layered? Is it based on a series of managers (for graphics, sound, etc.)? Does everything talk through a core? Or do systems communicate with messages?

Note that what also needs special consideration when choosing low-level APIs is that it's a goal of this project to be multi-platform, so the platform layer of the engine has to be able to run on all supported platforms using all of the listed APIs.

This post has been edited by Knucklesdood: 06 March 2012 - 06:12 AM

[Elratauru]

I'd gladly like to postulate to help after the groundwork of the engine has started with basic 2D stuff, I'm a professional web developer and graphic designer and while my programming knowleadge is limited to web-stuff (PHP, AS3, and CSS shit) I'm pretty good at 2D textures, from HUD's to menus and similar stuff. Also I'm interested in the fonts question that Knucklesdood asked.

I know that first comes a lot of stuff, but I'm following this throughly and well I must admit I like the whole concept/idea of having an engine made by the community for the community.

[Falk]

If it helps any for the prototyping stage, I can actually throw together packages for both fmod and Wwise for comparison's sake. They essentially both spit out dlls and .h includes that you plug in and call.

p.s. Wwise still handles music a bajillion times better than fmod lalalala closing my ears and I can't hear your argument.

[Gen]

Knucklesdood, on 06 March 2012 - 06:03 AM, said:

I have a number of additional questions about the underlying engine:

• What kind of build system will be used? Will there be some sort of premake solution that can generate different kinds of projects for different platforms, or will there be separately maintained projects?

I'd opt for cmake here. Trying to maintain separate build files for each platform would be a pain in the ass.

Quote

• Will the STL be used? Boost? Many games avoid the STL or Boost because more highly optimized and use-specific code can be custom-written for the game engine.

This is one of those things that deserves a bit of discussion on its own. STL's iterators and vectors (which really, are just dynamic arrays at the end of the day) can be nifty, but may be worth implementing as a separate light weight array class that provides the same functionality. Boost is within the realm of stable now days, and may be worth looking into to assist with threading at the very least (as well as possibly JSON or XML parsing).

Quote

• Will a math library be brought in or custom-made? (GLM was brought up earlier)

I don't see any need to write a custom math library when something like GLM already exists, and will generally fulfill most if not all vector math needs (and can be extended for cases where it doesn't).

Quote

• Will a custom memory manager be needed?

Would be nice I think. In the long run, if we want scalability, we'll be needing a memory manager that can handle allocating and deallocating resources in a fairly efficient way for the purposes of streaming content much later on down the road, to allow for larger levels.

Quote

• Is OpenGL the graphics library of choice? How about GUI APIs? APIs for editors and tools perhaps.

OpenGL will be the graphics library of choice. GUI, editor, and tool APIs are things that need to be discussed.

Quote

• How will fonts work?
  
• Which model/animation formats will be supported?
  
• How will input be handled? Which library or libraries will be needed to handle all forms of input?
  
• Debugging tools? AntTweakBar is useful.
  
• How are resources loaded in and handled by the engine? How does some high-level code (such as script or GUI interface) load in a renderable mesh?
  
• Will strings be allowed or forbidden in the engine? GUIDs?
  
• How are objects serialized? Binary serialization? XML? JSON?
  
• What form of script binding will the engine use? Lua, javascript, etc.
  
• How do systems operate and interact? Message-driven and/or event-driven?
  
• What is a game object? Is it a bunch of components? What are the core components that need to be implemented for pre-alpha?
  
• Where is the game loop? What does it do?
  
• Will any systems need to be multithreaded? (common candidates are resource loading or rendering; threads where "jobs" can be queued and worked on)
  
• Overall, what does the engine architecture look like? Is it layered? Is it based on a series of managers (for graphics, sound, etc.)? Does everything talk through a core? Or do systems communicate with messages?

These are all things that need to be discussed still. At least some ideas should be thrown out there for consideration.

Personally, I'm a fan of having a series of managers. But ultimately, the biggest factor that'll influence the engine architecture will be what threading approach we take. On that note, it'd be pretty awesome if we could handle issuing calls to OpenGL on a separate thread (which is more or less what constitutes a "multithreaded renderer").

Quote

Note that what also needs special consideration when choosing low-level APIs is that it's a goal of this project to be multi-platform, so the platform layer of the engine has to be able to run on all supported platforms using all of the listed APIs.

Agreed.

EDIT: One thing I've been looking at, are different GUI frameworks that could make it easier to develop GUIs for the engine. One that comes to mind is Awesomium, which allows for GUIs to basically be written with a combination of HTML and javascript, and even allows for browsers to be embedded within a game. They offer a non-commercial license. Something similar to Scaleform would be kinda cool too, since it'd basically allow people to create UIs in flash, and directly export a SWF to the engine for inclusion with a game. Any Open Source alternatives that can provide similar functionality would be pretty awesome.

This post has been edited by Gen: 07 March 2012 - 02:45 AM

[Elratauru]

Gen, on 06 March 2012 - 03:59 PM, said:

EDIT: One thing I've been looking at, are different GUI frameworks that could make it easier to develop GUIs for the engine. One that comes to mind is Awesomium, which allows for GUIs to basically be written with a combination of HTML and javascript, and even allows for browsers to be embedded within a game. They offer a non-commercial license. Something similar to Scaleform would be kinda cool too, since it'd basically allow people to create UIs in flash, and directly export a SWF to the engine for inclusion with a game. Any Open Source alternatives that can provide similar functionality would be pretty awesome.

Well, Awesomium like you said, is free for non-commercial stuff and for cheap indie companies and I think that its capabilities are just perfect. HTML5, JS, CSS and AS3 is just the perfect combo for creating UI's to a web developer, and not just that... It actually renders stuff using WebKit and that makes it even better along with its multicore-capability if needed. I'd vote for it, unless there is any other open source alternative with the same features.

[StreakThunderstorm]

Would be nice to have a GUI editor. I just hope the whole engine doesn't become entirely web based. Try not to do what construct 2 did.

This post has been edited by StreakThunderstorm: 07 March 2012 - 02:59 PM

[Gen]

StreakThunderstorm, on 07 March 2012 - 02:58 PM, said:

Would be nice to have a GUI editor. I just hope the whole engine doesn't become entirely web based. Try not to do what construct 2 did.

Fuck WebGL.

[StreakThunderstorm]

Thank you. Lol.

[Candescence]

Hardly a fair comparison, two entirely different projects with entirely different goals in mind. :p

[Aerosol]

I took a cursory glance towards the LGPL and GPL licenses, and I'm leaning towards LGPL right now. I'll give them a more thorough read when I'm not dog-shit tired. Maybe that should be the next poll, since we're not using my awesome non-suggestion for the project name?

I'm kidding

[Conan Kudo]

Knucklesdood, on 06 March 2012 - 06:03 AM, said:

• What kind of build system will be used? Will there be some sort of premake solution that can generate different kinds of projects for different platforms, or will there be separately maintained projects?
• Will the STL be used? Boost? Many games avoid the STL or Boost because more highly optimized and use-specific code can be custom-written for the game engine.

As far as the buildsystem goes, I'd be willing to pitch in and help maintain CMake scripts. I'm pretty good at it, and my work can be seen in the open source Lugaru and ProSonic projects on Google Code. It's flexible and lets you generate project files for various IDEs and makefiles for Linux, Mac OS X, and Windows.

I'd recommend trying to use standardized libraries because we can take advantage of well-tested code that we know works. Being able to maximize code reuse through the STL and the Boost library kits is probably a good idea. It also opens us to using C++11 features that may be helpful in developing the engine. Finally, using these libraries mean that static and dynamic analysis through clang, valgrind, and gdb will be extremely useful for debugging purposes because if issues crop up from usage of those, we can catch and fix them quickly.

This post has been edited by Conan Kudo: 08 March 2012 - 11:02 AM

[Gen]

Conan Kudo, on 08 March 2012 - 10:59 AM, said:

Knucklesdood, on 06 March 2012 - 06:03 AM, said:

• What kind of build system will be used? Will there be some sort of premake solution that can generate different kinds of projects for different platforms, or will there be separately maintained projects?
• Will the STL be used? Boost? Many games avoid the STL or Boost because more highly optimized and use-specific code can be custom-written for the game engine.

As far as the buildsystem goes, I'd be willing to pitch in and help maintain CMake scripts. I'm pretty good at it, and my work can be seen in the open source Lugaru and ProSonic projects on Google Code. It's flexible and lets you generate project files for various IDEs and makefiles for Linux, Mac OS X, and Windows.

I'd recommend trying to use standardized libraries because we can take advantage of well-tested code that we know works. Being able to maximize code reuse through the STL and the Boost library kits is probably a good idea. It also opens us to using C++11 features that may be helpful in developing the engine. Finally, using these libraries mean that static and dynamic analysis through clang, valgrind, and gdb will be extremely useful for debugging purposes because if issues crop up from usage of those, we can catch and fix them quickly.

Maybe we should have a recruitment thread somewhere.

Also, that would be very awesome.

This post has been edited by Gen: 08 March 2012 - 05:26 PM

[Sofox]

In terms of pre-alpha, here are my thoughts.

A character (doesn't need to be animated), in a 3d location (maybe NOT Green Hill? Just suggesting...). You can move the character and jump. If you jump over some ridges you can reach a goal and get a "Act Completed" sign. The program then reformats the users computer

There, we keep it simple and we focus on the aspect that we're making something for games. Just implement what's needed for the above, and then plan out each new release with a demo that has something new for the engine to support.

[Rolken]

There's something to be said for shipping, but it's also true that planning out separation of responsibilities (in code) and architecting things properly from the outset can save you a lot of trouble later. Where to split the difference there largely depends on how much experience and knowledge you have.