Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1368046 Posts in 64191 Topics- by 56125 Members - Latest Member: Morgarten

October 20, 2019, 12:45:42 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsJobsCollaborationsEngine project looking for collaborators
Pages: [1]
Print
Author Topic: Engine project looking for collaborators  (Read 526 times)
lostastronaut
Level 0
*


View Profile
« on: September 26, 2019, 09:33:00 AM »

Hi,
I'm a professional software developer and a graphics enthusiast.  Earlier this year I left Smith Micro as the lead developer of Poser 3D Character Animation Software.  This famous piece of software had its heyday in the mid-90s, and is responsible for a lot of the technologies behind content that made it into console gaming in the 2003 era.  I also released a game engine and ran a series of tutorials for it called Pixitron that outlines an approach to multiplayer game making on the web. https://lmgtfy.com/?q=pixitron

This other engine, a 12-year epic, is largely ground up but yes it does rely on WinAPI, OpenAL and some other optional libraries, but most of the code is essentially "from scratch"

Anyway, now that I've moved on from my job at Smith Micro, it's back to moonlighting as Lost Astronaut (lostastronaut.com) ... I picked up my old game engine a few weeks ago and decided I needed to take things in a new direction.  However, I've spent 12 years on it and for a long time I held on to it with white-knuckle strength.
For the 10th time over the past few years, a few hours ago I thought about releasing the 12-year-old project as open source.

Every time I go to release this engine, thuogh, I worry no one will see it, and if they do see it, they'll just run away.   I know it has some serious value (there's a reason I haven't released it yet), but it's locked into a certain technology level (Windows, 32-bit) and as I've started to move features into Qt to support a wider array of platforms, I guess I realized it's going to be entirely different but I'd like to release the 32-bit version of my engine if it gets some traction.
So, I'm wondering what you think about this?  The engine is written in C++, uses OpenGL, builds readily on Windows in free versions of Visual Studio 2017, and may be too big for Github but I'm not sure yet.  I spent the 1990s writing MUDs and the 2000s doing all sorts of different things in and out of gaming, but mainly made money on the Web until 2007 when I went all-in on my graphics hobby and set out not only to write a game, but also to build "the encyclopedia of graphics routines" in what became a massive 1900 class super monster codebase that, to this day, builds with an almost flawless execution, and can do a very wide range of things using OpenGL, OpenAL, and about 80 other libraries that I explored.  It's the "ultimate" starting place for a C++ Win32 OpenGL project complete with multiple UIs, image processing, texture uploads, vbos of varying flavors, GLSL, graphics systems, 3D file support, you name it. I released some of the shaders from this engine (and some of the source graphics used in the shaders) (modified for GameMaker) as a pack called GML-Pro https://github.com/h3rb/gml-pro a few years ago, but it got buried when GMS2 came out.

I used my engine to launch a moderately successful 3D printing company, some of it made its way into Poser, and it's just a lot of accumulated work not only by me but some very famous people who I collaborated with years ago when building the engine in the early days.  It also has a commonality in the code that is powerful, but also many approaches with different results for everything from color manipulation, to fonts, to the way you organize worlds in 2D.

My questions for you are:
1) As a reader of these forums: Are you interested in this at all?  Do you want to learn more?  Is this a project you'd contribute to?  How would you contribute to it?  Does it have value?
2) Do you have any idea how I might avoid it hitting the bin?   How can we keep this open source from being just another pile on the heap?  How can a community form around it?

Part 1




Part 2


« Last Edit: September 26, 2019, 10:41:44 AM by lostastronaut » Logged
fluffrabbit
Guest
« Reply #1 on: September 28, 2019, 06:11:45 PM »

If it's open source, I won't contribute to it. I've seen what happens to these types of projects, and by the sound of it, your chances aren't good. Better to just make games with it and throw it away when you're done. I could identify issues based on your description, but fixing them won't be enough.
Logged
miki
Level 0
*


View Profile
« Reply #2 on: September 28, 2019, 11:59:27 PM »

In addition to closed or open source, can the engine, as you have built it, be sold as a commercial product? I mean, if you are asking people to invest their time into something it might be good to know that in advance. Makes sense?

Also, (OT a little but still kind of relevant) 1900 classes? If each day of the year had its own unique name it would take me personally few years to learn all of those. And we are talking less than 400 days here. So again, 1900 classes? How do you count that - will the end user have/need access to them all? How many lines of code to maintain is that exactly?
Logged
fluffrabbit
Guest
« Reply #3 on: September 29, 2019, 03:31:49 AM »

Technically, all open source software (in the strict sense of the term) can be sold as a commercial product. Copyleft licenses such as the GPL do allow this as long as source code is also distributed. There are different details and stipulations. GPLv3 disallows bundling on proprietary hardware while GPLv2 permits it. AGPL prohibits proprietary cloud SaaS.

And yeah, it sounds like a lot of bloat. If the community is expected to participate, I'm not sure about this.
Logged
lostastronaut
Level 0
*


View Profile
« Reply #4 on: September 29, 2019, 07:30:05 PM »

In addition to closed or open source, can the engine, as you have built it, be sold as a commercial product? I mean, if you are asking people to invest their time into something it might be good to know that in advance. Makes sense?

I have not yet decided on a license, but something commercially-viable would be OK with me.  I would probably require in a license that credit be given to either me or the project, or Lost Astronaut Studios, or some combination of the above.  It has actually been helpful as a closed source project because private companies are more interested in using it if it hasn't been released to the public, but I'm feeling now that maybe I could part with it.


Also, (OT a little but still kind of relevant) 1900 classes? If each day of the year had its own unique name it would take me personally few years to learn all of those. And we are talking less than 400 days here. So again, 1900 classes? How do you count that - will the end user have/need access to them all? How many lines of code to maintain is that exactly?

In Part 2 I describe the "core" of the functionality.  

It depends on what you are trying to do.  The answer is not a simple "yes or no" but rather it is highly dependent on what you want to do.  Most games, for example, won't need the image analysis and convolution tools, but a graphics tool might. Some of the code is there and doesn't need any changes, yet is counted as lines.  The GLSL shaders take up 100 of the classes and thousands of lines of code, yet all you need to do is use the classes and not make changes to them.  The GLSL is also embedded in them as strings.  So, do you need to read all 400,000 lines?  No.  

You can quickly:

Create a new window
Use a combination of about 30 classes to:  create a 3D scene, 2D scene, or simple menu system, or an entire game
« Last Edit: September 29, 2019, 07:44:40 PM by lostastronaut » Logged
lostastronaut
Level 0
*


View Profile
« Reply #5 on: September 29, 2019, 07:37:39 PM »

And yeah, it sounds like a lot of bloat. If the community is expected to participate, I'm not sure about this.

People call things "bloat" when they feel like there is too much to learn or too many things that they aren't using for a project, but since this isn't a DLL those lines are going to get optimized away from the final executable.

I will admit some of the features could be cut, but not as many as you might think.  And why cut something that is moderately useful?  An example of one feature I cut was a series of DL-list related features, but I left the classes in as a placeholder for a future shader to replicate the functionality, but have yet to require it.  That would eliminate maybe 5-10 classes, yet some of the classes were used to create other effects, so they got reused if I remember correctly -- so things were removed over time, but the things that are in there now served some purpose or were going to be refactored.

I guess what I would hope for from the community (aside from some cool projects being made with it) is expanding its reach to other systems, like Linux and/or 64-bit OS, but each has its concerns.  Large-Address Space is being used, so you can use up to 4GB ( I think ) and beyond?? in 32-bit.  The gain is only in calculating double precision.  The loss is all of the features that are baked into 32-bit DLLs on which it depends.  That's where much of the project "bloat" is, because I've left the DLLs in the project even if I didn't use them, with a few exceptions, but the actual folder has a lot of data in it now (about 80 libraries).  I did cut this back slightly but, for example, at one point I was using pthreads and then simply use #if !defined(USE_PTHREADS) to turn off that code and turned on windows-native threads because they proved to be more reliable.   So, there is still support for that library even though it is turned off.

Also, I have no reason to document it.  I have not documented it except minimally and only when absolutely necessary.  I do keep in some useful hints and short comments, but you have to read the code to understand it and I've been putting a lot of effort into readability and relative easy of use, rather than documentation, though I'm not against adding documentation to it.

Logged
fluffrabbit
Guest
« Reply #6 on: September 29, 2019, 08:07:04 PM »

Just some drive-by comments here.

* I haven't touched Windows in several years.
* Qt is not the lightest or most permissively licensed cross-platform abstraction you could ask for. You could try wxWidgets, SDL, and SFML.
* The thing about bloat is that it discourages people from reading your source code. If they don't understand how it works, they're less likely to contribute.
Logged
Schrompf
Level 6
*

C++ professional, game dev sparetime


View Profile WWW
« Reply #7 on: September 29, 2019, 10:51:40 PM »

Previous comments did feel condescending to me, so I wanted to chime in. But I noticed I'd say something similar:

a) nobody licenses engines anymore. Nobody.
  a1) people who are able write the custom part they require
  a2) people who are not use Unity, Unreal or any of the other free, opensource engines
  a3) ok, there is an occasional smaller AAA studio using a high-tier industry engine. But you won't get into that bussiness. Full stop.
b) graphics algorithms are not what someone looks for in an engine. It's only about tooling anymore.
c) Nobody goes for a monster of 2k classes to start to learn graphics coding.

Personally I could contribute, but I won't, because I don't see a use for a general purpose engine anymore. There's still Ogre and all those out there, but they struggle to keep a following because they lack the tooling. I code gfx for fun, but I already do this at home at my spare time experiments.

So good luck but I think you overestimate the value of your code to someone else but yourself.
Logged

Snake World, multiplayer worm eats stuff and grows DevLog
fluffrabbit
Guest
« Reply #8 on: September 30, 2019, 12:59:48 AM »

There are still studios in need of people to fix their old broken DirectX engines. Surely OP could contribute in that area. Not to condescend or anything, I think anything that is inherently tied to Windows is unwise. So there's my two cents.
Logged
Daid
Level 3
***



View Profile
« Reply #9 on: September 30, 2019, 01:47:45 AM »

Also, I have no reason to document it.  I have not documented it except minimally and only when absolutely necessary.  I do keep in some useful hints and short comments, but you have to read the code to understand it and I've been putting a lot of effort into readability and relative easy of use, rather than documentation, though I'm not against adding documentation to it.
And that is where you are wrong.

Documentation is important, it's key. It's one of the reasons Unity and other things are successful, and why so many open source project fail to get traction.

It's not just documentation, it's the kind of documentation that you need to provide. You are just thinking of detailed documentation. And, frankly, screw that. Developers don't need detailed documentation. They need general documentation, starter points, knowing what the important bits are and what the "fluff" is.

Exhibit 1: Libdbus, library to communicate with the dbus on linux.
https://dbus.freedesktop.org/doc/api/html/
This is what they have that passed for documentation. And frankly, it's useless.

Pretty much the first line it says:
Quote
Caveats aside, you might get started learning the low-level API by reading about DBusConnection and DBusMessage.
And then sends you to 2 pages that have more functions then you can map in your mind.

Exhibit 2: SFML, library to get stuff on the screen and input from devices. Aimed at games.
https://www.sfml-dev.org/learn.php
Now, this is a good example. As it has tutorials there. And those tutorials explain the basics, what are the important classes, and what not.

Also, almost every single important class documentation starts off with a usage example:
https://www.sfml-dev.org/documentation/2.5.1/classsf_1_1Shader.php#details

And thus, surprise surprise, people are using SFML, even with it's bugs and quirks.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
fluffrabbit
Guest
« Reply #10 on: September 30, 2019, 02:34:40 AM »

Yeah, SFML is an interesting case. It lags a couple years behind the state of the art and the devs are notoriously unhelpful, yet it "just works". It's designed to be beginner-friendly, with tutorials, books, and all the other information one might expect from a big project like Unity.
Logged
lostastronaut
Level 0
*


View Profile
« Reply #11 on: October 06, 2019, 12:45:32 PM »

a) nobody licenses engines anymore. Nobody.
...

All software is licensed.  MIT, LGPL, GPL and BSD are licenses.

b) graphics algorithms are not what someone looks for in an engine. It's only about tooling anymore.
c) Nobody goes for a monster of 2k classes to start to learn graphics coding.
...

I don't really agree with "b" .. and its not just graphics algorithms, but you've decided to focus on that part... also it really depends on what you are doing.

As for 'c' that's a blanket statement and I'm not really sure what your point is.  I'm not here to educate.

Personally I could contribute, but I won't, because I don't see a use for a general purpose engine anymore. There's still Ogre and all those out there, but they struggle to keep a following because they lack the tooling. I code gfx for fun, but I already do this at home at my spare time experiments.
...

Not sure what you're talking about "tooling" .. you mean "edit-in-engine" or "engine-editor" ?  Like Unity?  Unreal?  That's not what I'm making here.  That's not what I made.  Why did thousands of people download and learn OpenGL and Windows in 2009-2016 and today?  I still see the videos and blog posts.  I took that demo and turned it into a useful, commercial code because of necessity.

So good luck but I think you overestimate the value of your code to someone else but yourself.

Well, it did get me $1M in funding and I was at one point offered $100000 for it.  So, it seems to be appealing and useful.  Durr...?
Logged
lostastronaut
Level 0
*


View Profile
« Reply #12 on: October 06, 2019, 12:47:11 PM »

Yeah, SFML is an interesting case. It lags a couple years behind the state of the art and the devs are notoriously unhelpful, yet it "just works". It's designed to be beginner-friendly, with tutorials, books, and all the other information one might expect from a big project like Unity.

So how did SFML start?  Who started it?  How did they gain traction to get people writing books about it?
Logged
lostastronaut
Level 0
*


View Profile
« Reply #13 on: October 06, 2019, 12:49:32 PM »

Documentation is important, it's key.

I don't need it if I'm not releasing it.  Now I'm thinking about releasing it.  I planned to make tutorial videos, maybe document it using doxy.  Not sure yet.  But it's also philosophical.  You seem to value comprehensive documentation, but not everyone does.  

Documentation makes more sense when you cannot 'Go to definition', in this, you can because its not a library, not a DLL, no black box, it sits right in your project.
Logged
fluffrabbit
Guest
« Reply #14 on: October 06, 2019, 01:15:23 PM »

I kind of agree with the comment about tooling.* You clearly know the business. I have a lot more film background than games background; this is really just a hobby for me, so I think it's great that you can make this work. I am confident in you, regardless of my confidence in yet another game engine.

I'm not a heavy SFML user, I just use it as a GL context initializer and keyboard/mouse input abstraction layer. From what I do know, the books were written by the SFML guy (the "sell the manual" business model) but unlike e.g. Inkscape, it also has tons of free documentation online by the same guy. He loves writing documentation, apparently. And most SFML users are idiots, so they need it.


* I'm not saying I know what "tooling" is, but it's a more appealing concept than graphics routines. Graphics routines are educational while "tooling" sounds like it can help you hit the ground running.
« Last Edit: October 06, 2019, 01:48:19 PM by fluffrabbit » Logged
Schrompf
Level 6
*

C++ professional, game dev sparetime


View Profile WWW
« Reply #15 on: October 08, 2019, 04:00:42 AM »

a) nobody licenses engines anymore. Nobody.
All software is licensed.  MIT, LGPL, GPL and BSD are licenses.
While you're technically right, I'm pretty sure you understood the actual point I was making: you will not get anyone to pay you a considerable sum for your engine.

b) graphics algorithms are not what someone looks for in an engine. It's only about tooling anymore.
c) Nobody goes for a monster of 2k classes to start to learn graphics coding.
I don't really agree with "b" .. and its not just graphics algorithms, but you've decided to focus on that part... also it really depends on what you are doing.
That's where we have different opinions. I think today's success of frameworks is largely how quickly you can get something running on it. It's about iteration times. So while you might have a codebase, large parts of its quality are also dependent on how quickly my artist can do a fireplace in it.

As for 'c' that's a blanket statement and I'm not really sure what your point is.  I'm not here to educate.
Except you claimed that yourself: 'I [...] set out not only to write a game, but also to build "the encyclopedia of graphics routines"'.

Not sure what you're talking about "tooling" .. you mean "edit-in-engine" or "engine-editor"?  Like Unity?  Unreal?  That's not what I'm making here.
Pretty much like that. Plus reliable importers, plugins for Maya, 3DSMax, you name it.

So good luck but I think you overestimate the value of your code to someone else but yourself.

Well, it did get me $1M in funding and I was at one point offered $100000 for it.  So, it seems to be appealing and useful.  Durr...?
Great, me too. Yes, such were the times, back when there were fewer alternatives and completely different demands. These days, you're running up against Unreal, Unity, or even Godot as fully opensource engine including scene editor, asset pipeline, lightmap baker and others.

You can still do this, probably, but I assume you'll have an uphill battle. So good luck.
Logged

Snake World, multiplayer worm eats stuff and grows DevLog
fluffrabbit
Guest
« Reply #16 on: October 08, 2019, 09:38:43 AM »

Godot is super buggy but also high-profile. What we don't have a lot of are genre-specific game engines. Sure, Unreal has been used to make a lot of FPS games, but something with more groundwork laid in advance might appeal to some people.
Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic