Jump to content

  • Log In with Google      Sign In   
  • Create Account


Something I've noticed

  • You cannot reply to this topic
19 replies to this topic

#1 CatmanFS   Members   -  Reputation: 187

Like
0Likes
Like

Posted 26 November 2013 - 02:40 PM

I see everywhere people looking to create a team that will make games and proprietary engines from scratch. This is great, it means that the community hobbyists are interested in real game development. The problem I see is that everyone wants to make a seperate team, all by itself. I'm sure that each person, or small group looking to get larger has a few good sized modules of code that are efficient and could see a future in the game engine market. I fear that as people stress on for years through the team development phase, that thousands of lines of code and effective modules will get lost in the shuffle.

 

I suggest that someone organize a pool of people looking to create an engine from scratch. We build one team at a time, seperate into specific projects that are similar where people can make some compromises in order to get some finished product created. I want to make a game engine from scratch, sure, but every bit of it doesn't have to be my own code. It would drive me crazy trying to perfect every single module, and it has been driving me crazy.

 

I work on graphics implementations. Mesh code, textures, systems that handle this data. If I could focus on that specifically, I could get alot of work done. Unfortunatly I have to split my time across all the fields, like script managment, camera viewpoints, game logic, and other misc topics. If I could get on board with a good structured team that was willing to make some comprimises I coudl see a real future doing this. I just hope that people can get past thier egos in order for the greater picture to come into focus.

 

This is my coding horror. I hope you like it. :)



Sponsor:

#2 Ectara   Crossbones+   -  Reputation: 2815

Like
5Likes
Like

Posted 26 November 2013 - 03:30 PM

Is this a coding horror?



#3 CatmanFS   Members   -  Reputation: 187

Like
0Likes
Like

Posted 27 November 2013 - 03:24 AM

It's about programming. I could go into details about the code, like the old .obj file loading implementation that found got working, the emitter and particle code that I wrote that allows for volume emitters and field constraints, the mesh and texture implementations I wrote from scratch, the fact that I refuse to use anything but openGL 1 until I have mastered it thouroughly, the windows programming that I fear is gracously out dated, the colission and detection code I'm working on, and everything else in between, but it's about coding horrors and I figured the last thing you all would want to see is more programming examples in a forum called coding horrors. I just fear that this, and alot of other indie projects end up on the cutting room floor because they can't keep up with the fast paced industry, and I wanted that fact to be known. I care about my fellow upstart programmers and I'd like to see something done about it.

 

Move it wherever you want, wherever you think that people will see it. :)


Edited by CatmanFS, 27 November 2013 - 03:32 AM.


#4 swiftcoder   Senior Moderators   -  Reputation: 9635

Like
6Likes
Like

Posted 27 November 2013 - 04:52 PM


Is this a coding horror?

When has cooperative coding among unpaid amateurs not resulted in a coding horror?

 

@OP: it's been tried more than a few times. But without a seasoned software architect and a strong technical lead, I doubt you'll get very far.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#5 Shippou   Members   -  Reputation: 1336

Like
1Likes
Like

Posted 28 November 2013 - 01:00 PM

Languages, coding styles, the idea guy , bad management, programmers' skill, no incentive .... these doom a lot of "free labor" projects to fail .


 Reactions To Technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of things.

- Douglas Adams 2002


 


#6 CatmanFS   Members   -  Reputation: 187

Like
0Likes
Like

Posted 30 November 2013 - 01:13 PM

When did this turn from being something fun and explorative like games are supposed to be into "free labor"? What, are we all just slaves doomed to repeat the process of work unfufilling jobs and pay bills? With a system that relies on the bottom line as it's sole progressive incentive, it's easy to see why there are so many games out there with little to no innovation or soul. It's sad to see so much talent get wiped out by a bunch of money hungry, back-breaking, slave laborers. This is my dream. This is my nightmare.



#7 Madhed   Crossbones+   -  Reputation: 2496

Like
0Likes
Like

Posted 30 November 2013 - 01:25 PM

There are some relatively good open source engines out there. Theoretically everyone can participate.

#8 wintertime   Members   -  Reputation: 1604

Like
0Likes
Like

Posted 01 December 2013 - 06:23 AM

I would think a project produces good results if all people involved share the same goal and someone is watching for code quality strictly. If instead everyone just wants their pet feature included and refactoring gets postponed it will probably generate a mess over time. Though that is not really related to these people being paid or not or the code being open source or not.

If you force people to cooperate on your dream engine they will just put in what they need themself using shortcuts that mess up the design. Then they will jump off, because its a mess. Then you have to clean up yourself. rolleyes.gif

There it may be easier to collect usable code yourself.



#9 BGB   Crossbones+   -  Reputation: 1545

Like
0Likes
Like

Posted 01 December 2013 - 07:38 PM

I would think a project produces good results if all people involved share the same goal and someone is watching for code quality strictly. If instead everyone just wants their pet feature included and refactoring gets postponed it will probably generate a mess over time. Though that is not really related to these people being paid or not or the code being open source or not.

If you force people to cooperate on your dream engine they will just put in what they need themself using shortcuts that mess up the design. Then they will jump off, because its a mess. Then you have to clean up yourself. rolleyes.gif

There it may be easier to collect usable code yourself.

 

yeah.

 

my usual experience with open-source has been scavenging whatever parts I need, and very rarely contributing back to the main projects (many/most FOSS projects IME basically tend to operate where only a small inner circle has direct access to the repository, and everyone else has to send in diff patches, but usually it is enough of a hassle that it isn't particularly worthwhile, especially if it is for something "weird" that probably no one else will really find all that useful).

 

sometimes ugly hacks are needed to get things to build or work, often in areas where the wider functioning or relation to other parts of the code is not clearly understood.

 

...

 

sometimes I am left to think that, preferable to using "the one true source code" for a given project, it would be nicer if all of the data/formats/... in use were adequately documented, such that it would be possible for multiple implementations of everything to exist and to cooperate in terms of shared data and file-formats.

 

for example, I am more in favor of open standards, rather than treating particular libraries or implementations as canonical.

 

now, can this be applied to games?:

I think it would be nice if people could better nail down sets of file-formats and maybe work towards a set of inter-engine de-facto standards;

ideally they should be descriptive (describing various common use-cases and file-formats and encouraging reuse when applicable, ...), rather than prescriptive ("for use-case X, use format Y");

...

 

things that could be nicer if more standardized:

representations of textures and texture metadata;

video formats and codecs which are "actually useful" to games development (such as having an alpha channel, ...);

audio formats useful for real-time mixing;

3D model formats (characters, props, ...);

world map data;

various engine conventions (coordinate spaces and units);

...

 

(elaboration removed for length reasons...).

 

but, yeah, the general idea here is that if common file-formats catch on, then hopefully the current mess that is engines and tools would begin to clear itself up, with hopefully much more interchangeable engines and tools and making it easier to move content from one game to another, ...

 

then it wont matter as much who's code is being used, ...

 

like, take for example, the relative standardization of graphics formats:

with this, it doesn't really matter as much which applications people use to create and edit the images, since the applications are largely interchangeable.


Edited by BGB, 01 December 2013 - 09:05 PM.


#10 Shaquil   Members   -  Reputation: 815

Like
3Likes
Like

Posted 03 December 2013 - 06:14 AM

I suggest that someone organize a pool of people looking to create an engine from scratch. We build one team at a time, seperate into specific projects that are similar where people can make some compromises in order to get some finished product created.

 

Don't you think that's a little crazy? That's a lot of work, and you "suggest" that "someone" does it, instead of doing it yourself?



#11 Winfield   Members   -  Reputation: 179

Like
3Likes
Like

Posted 03 December 2013 - 01:20 PM

There are roughly six million open source game engines available right now. I'm not so sure why you think adding another one is going to help.



#12 Shaquil   Members   -  Reputation: 815

Like
0Likes
Like

Posted 03 December 2013 - 04:23 PM

 

I suggest that someone organize a pool of people looking to create an engine from scratch. We build one team at a time, seperate into specific projects that are similar where people can make some compromises in order to get some finished product created.

 

Don't you think that's a little crazy? That's a lot of work, and you "suggest" that "someone" does it, instead of doing it yourself?

 

 

Although I doubt you're still reading this thread, I just wanted to be clear that I didn't mean to sound like I was piling on. I just think you should go do it. It's a retarded idea, but if you think it's so great, just do it. Suggesting that someone else does it is just pretending that you want it to happen. I mean, you posted it on a forum. At least ask someone in specific, if you really believe in it but don't want to lead. That's all.



#13 CatmanFS   Members   -  Reputation: 187

Like
0Likes
Like

Posted 04 December 2013 - 09:00 PM

I believe that there is a large group of disgruntled indivuals out there that want to see things like this fail. I mean, this forum is GAMEDEV, and you're saying that the idea of creating a game engine for specific development is "retarded". I'd love to see you accomplish anything with that mindset. The point of the whole thing is that it isn't "retarded", it encourages problem solving, creative thinking, and teamwork skills. To see people with a positive mindset find things like this makes me very sick with disappointment. It's not uncommon though, how many wannabe movie companies never make it in the "real" industry? The number is probably similar to your list of game engines out there. When I started this process back in 07 I saw how there was alot of potential, and also alot of potential problems, but I always kept my goals in mind, and never used the excuse that my work and contribution wouldn't make a difference, because I know that it has. But this defeatist attitude that so many people share has to stop. I don't have the resources to organize bunches and bunches of people into specific groups. That would have to be a moderated effort supported by experienced people that had suceeded where so many fail and wish to extend to the hopeful game developers out thier thier nich for team organization.

 

True pioneers do what they do because they find satisfaction from it. Too many people work in this industry because they just need a job. For the love of god, don't join an industry because you want to make money. Do it because it's what you love to do, otherwise you'll just end up causing more harm than good. Everybody knows that.



#14 swiftcoder   Senior Moderators   -  Reputation: 9635

Like
0Likes
Like

Posted 04 December 2013 - 10:15 PM


you're saying that the idea of creating a game engine for specific development is "retarded".

Nobody said that.

 

We did however say that setting out to build a generic game engine is not a sensible endeavour for a loosely-organised team of hobbyists with no clear lead developer.

 

And not to harp on this point, but it's an especially bad idea for someone who is still stuck on OpenGL 1.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#15 BGB   Crossbones+   -  Reputation: 1545

Like
0Likes
Like

Posted 05 December 2013 - 04:02 AM

 


you're saying that the idea of creating a game engine for specific development is "retarded".

Nobody said that.

 

We did however say that setting out to build a generic game engine is not a sensible endeavour for a loosely-organised team of hobbyists with no clear lead developer.

 

And not to harp on this point, but it's an especially bad idea for someone who is still stuck on OpenGL 1.

 

 

I guess one could try to bring up the matter of how generic the engine is, and how tightly coupled the parts are.

 

for example, "sufficiently generic to implement games within a specific genre with a particular gameplay style" vs "sufficiently generic to handle multiple genres and gameplay styles".

 

likewise for coupling:

parts are sufficiently coupled that the engine is, for the most part, a unified entity;

vs, each component is largely its own library and almost functionally independent of the others, with some certain amount of high-level glue logic holding them together (treating each as a collection of APIs or similar).

 

depending on the desired level of "genericness", there is a large difference in terms of likely project complexity.

it is easier if focusing on a single genre.

 

going beyond this likely involves a tradeoff either between trying to make everything very loosely coupled and parts being interchangeable, or trying to address everything directly (this tends to quickly devolve into "there be dragons here" territory), and/or the thing starts looking more like the offspring of an OS and a web-browser, or ...

 

 

as for the OpenGL 1.x issue: yeah...

from my personal experience in these areas, one is probably almost better off having multiple rendering backends.

 

I had the misfortune of starting off mostly with a GL 1.x feature-set, and later expanding to use lots of newer features, ...

and now the renderer is sort of an awful mess with multiple interconnected rendering paths and some amount of #ifdefs for things like dealing with OpenGL ES and similar.

at some point, the thing may need to be broken up, and probably somewhat re-engineered (as-is, it is a bit absurd in many areas).


Edited by BGB, 05 December 2013 - 04:05 AM.


#16 CatmanFS   Members   -  Reputation: 187

Like
0Likes
Like

Posted 05 December 2013 - 09:47 AM

Who said anything about being stuck? And you seem as if you have some kind of resentment for Gl1, not to say that I don't agree with you, it's not particularly the most effective, or technologically advanced system, but it's the framework for all the other resources openGl has to offer. Besides, a good developer could use something like Gl1 and still make a great game, because it's not about making sure it meets the current standards. it's about creating a compelling experience that demands interactivity.



#17 swiftcoder   Senior Moderators   -  Reputation: 9635

Like
0Likes
Like

Posted 05 December 2013 - 10:26 AM


the fact that I refuse to use anything but openGL 1 until I have mastered it thouroughly

It was a tongue-in-cheek commentary on the idea of someone wanting to 'master' a 20 year old API.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#18 wintertime   Members   -  Reputation: 1604

Like
1Likes
Like

Posted 05 December 2013 - 11:02 AM

Yeah, OpenGL1 may sometimes be convenient for prototyping something, but for serious programming its way too old. At least step up to OpenGL 2.1 and ignore all superfluous ancient cruft that got cut out for that reason in OpenGL ES 2.0 or OpenGL 3.x, since that avoids wasting time learning about the indexed color mode, glBegin+associated things, display lists, the fixed function stuff with uncounted different function calls, contrived texture combiners and so on.



#19 BGB   Crossbones+   -  Reputation: 1545

Like
1Likes
Like

Posted 05 December 2013 - 11:37 AM

Who said anything about being stuck? And you seem as if you have some kind of resentment for Gl1, not to say that I don't agree with you, it's not particularly the most effective, or technologically advanced system, but it's the framework for all the other resources openGl has to offer. Besides, a good developer could use something like Gl1 and still make a great game, because it's not about making sure it meets the current standards. it's about creating a compelling experience that demands interactivity.

 

a drawback here is that OpenGL 1.x and newer versions of OpenGL diverge sufficiently WRT how they behave (and what sets of API calls are supported, ...), that one is left essentially needing multiple versions of their renderer:

one to work well on older hardware (and some vaguely new but low-stat HW);

one to use newer features and work on newer hardware;

possibly one to deal with OpenGL ES.

 

while a person could just do a sole GL 1.x renderer, they may find:

it performs poorly on newer hardware (vs what is possible with a different rendering strategy);

it risks not actually working in some cases (such as those where many of the older API calls were dropped);

...

 

this results in portability either requiring an abstraction layer in the renderer (to support alternate targets), or creating a wrapper layer and partially emulating GL 1.x on top of newer or alternate GL versions (crufty and not terribly efficient).



#20 CatmanFS   Members   -  Reputation: 187

Like
0Likes
Like

Posted 05 December 2013 - 08:28 PM

You can find out which calls are obsolete and ignore them while seperating the renderer from the majority of the core game functions. The renderer and the hardware will always have to be updated, that's just the nature of the search for photorealism in 3d graphics. I would like to see more games re-made with updated graphics re-implemented on newer systems, like they did with halo. I know it's a complicated and expensive process, but if you really love to do this kind of stuff then it shouldn't be that big of a deal. Alot of people don't enjoy working with the resources and overcomming the obstacles because they're either too difficult or too complex. We shouldn't be spending all kinds of time worrying about rendering package backends, and all the intricacies of modern computer graphics. There are people that do nothing but that kind of stuff, and they've been doing it for years and know all the ins and outs. I don't claim to be a computer graphics genius, I just want to know the basics and be able to take an idea and turn it into a reality without too much of a struggle understanding obfiscated code developed by mad scientists spinning on gerbil wheels. Hey, that even gives me an idea for a game.







PARTNERS