Advertisement

What does GDNet think about my game engine?

Started by August 21, 2011 09:50 AM
117 comments, last by Washu 13 years, 2 months ago

Lesson here is even though a car engine needs engineering before and during its construction, a game engine obviously needs no part of software engineering.

Nothing in this thread involves engineering.

Only perhaps this:
"I've only open sourced it as a favor to the indie community and I consider it just another feature. I never planned to make the engine as a commercial project so it only made sense to open source it. I'm not going to spend an excessive amount of time making the code readable to others. Right now I have no problem reading and debugging my own code."

There is a goal with means to achieve it. Engineering aspects now involve evaluating how current approach addresses the desired outcome.

The goal is to please indie community. So in order to evaluate quality of engineering, the intended target audience needs to speak about their experience in using the library to build whatever they want to. Maybe they will complain about code, maybe they won't.

Features are also binary. Either something is present and used or the engine isn't usable. Just adding features not *required* by target users is indeed a waste.

Could improving readability help with debugging and development? The question is distracting - are users using this engine having troubles? If so, are these problems related to code readability of the engine itself?

There is correlation between most of what was said in this thread with what most consider to be software engineering. But neither of those is what it seems. The purpose of software engineering is not, nor has it ever been, source code. Or anything related to source code. Or even software. Never, in history of computing has any user said: "the proper indentation of for loops proved to be the driving force behind our project, only second to properly capitalized variables".

Correlation is not causation, just applying it blindly is cargo culting.

Reason why some successful project seem to succeed because of such good practices is not that - they do so because they are composed of greatest coders who have plenty of time and mental power to focus on all tiny details.

To give an example - if notch were still following all Java best practices, his code today would be only 15 million lines of code and only 1/4 done.


I only skimmed, but I don't think anyone in this thread said: "Can I import 3DS directly? How do I build it on Mac? Why can't it do dynamic shadows?" Those are the important parts that only users who use the library for intended use can provide. The rest is gravy, unless it prevents timely delivery of said features. Such as when 700-line function requires spending 6 weeks on adding a feature when users need it in 3.
With all that said, it's a 10 year old project that's still in alpha that's been ported over several times. You don't think any sort of SE: refactoring, design patterns, readability, proper use (ie. method/class does what it states) of methods and classes is not directly involved in this? Asking "how can I make this faster" or saying "this is for the community" is pointless when eyes are bleeding. But eh. Maybe my POV is wrong.

Beginner in Game Development?  Read here. And read here.

 

Advertisement

With all that said, it's a 10 year old project that's still in alpha that's been ported over several times.

Is there a deadline?

You don't think any sort of SE: refactoring, design patterns, readability, proper use (ie. method/class does what it states) of methods and classes is not directly involved in this?[/quote]
Nope.

The best thing is that project finally saw light of day. It is one step closer towards being used.

"A boxer that wants to become a champion needs to win at least one match".

Asking "how can I make this faster" or saying "this is for the community" is pointless when eyes are bleeding. But eh. Maybe my POV is wrong.[/quote]

There is actually very good feedback on the first page, regarding lack of animations, lack of logic and the ability to load more complex geometry. Those are important questions regarding engine.

Endless rants about code are not, unless the current state of code prevents those features being added.

[quote name='Alpha_ProgDes' timestamp='1314732199' post='4855584']
With all that said, it's a 10 year old project that's still in alpha that's been ported over several times.

Is there a deadline?[/quote]
Well, I figure that he wouldn't want his incomplete engine to be older than his child or outlive him. But then again the Duke Nukem School of Project Management does work for some people.

You don't think any sort of SE: refactoring, design patterns, readability, proper use (ie. method/class does what it states) of methods and classes is not directly involved in this?[/quote]
Nope.

The best thing is that project finally saw light of day. It is one step closer towards being used.[/quote]
There have been plenty of game engine (indie) that were completed and never saw the light of day pre-release. So I don't know if being seen is actually a step in any direction.

"A boxer that wants to become a champion needs to win at least one match".[/quote]
Yeah, but his boxer can't even spar yet. **Correction: it can render. So it can at least do footwork and look pretty.

Asking "how can I make this faster" or saying "this is for the community" is pointless when eyes are bleeding. But eh. Maybe my POV is wrong.[/quote]

There is actually very good feedback on the first page, regarding lack of animations, lack of logic and the ability to load more complex geometry. Those are important questions regarding engine.

Endless rants about code are not, unless the current state of code prevents those features being added.
[/quote]
Point taken, but I don't think the comments about his code are not rants. I think it's productive. At the worst, constructive criticism. At the end, he's building an engine not a game. there has to be some architecture concerns, rewrite and some SE. Especially if he's gonna build upon it. Let me add this is my opinion which obviously different than his goals.

Beginner in Game Development?  Read here. And read here.

 


With all that said, it's a 10 year old project that's still in alpha that's been ported over several times. You don't think any sort of SE: refactoring, design patterns, readability, proper use (ie. method/class does what it states) of methods and classes is not directly involved in this? Asking "how can I make this faster" or saying "this is for the community" is pointless when eyes are bleeding. But eh. Maybe my POV is wrong.


It's 10 years because I was 12 and using Visual Basic when I started the project... Only over the last 5 years did I start learning C++ and only over the last 2 or so I actually knew how to use C++. There are fragments of code that I ported over from Visual Basic but they probably make up less than 5% of the code base. The structure of the engine has been more or less evolving. 98% of the ideas that I'm using now I had no concept of 10 years ago.

[quote name='Alpha_ProgDes' timestamp='1314732199' post='4855584']
With all that said, it's a 10 year old project that's still in alpha that's been ported over several times. You don't think any sort of SE: refactoring, design patterns, readability, proper use (ie. method/class does what it states) of methods and classes is not directly involved in this? Asking "how can I make this faster" or saying "this is for the community" is pointless when eyes are bleeding. But eh. Maybe my POV is wrong.


It's 10 years because I was 12 and using Visual Basic when I started the project... Only over the last 5 years did I start learning C++ and only over the last 2 or so I actually knew how to use C++. There are fragments of code that I ported over from Visual Basic but they probably make up less than 5% of the code base. The structure of the engine has been more or less evolving. 98% of the ideas that I'm using now I had no concept of 10 years ago.
[/quote]

Which is all fine and dandy except for the fact that in ten years still even more will be learned - and here's a golden chance to learn some of that 'more'. Look, you came here for criticism and advice - you've gotten both a plenty; what more is there? Have a nod and a pat on the shoulder for making it this far; but that still doesn't change that the code is a mess (quite natural, IMO, as it's been developed under such changing conditions during 10 or so years...) and that it's nothing new.

ApochPiQ gave you an enormously good starting point for fixing things, but it seems that is not what you came here for. So, uhm, what was the point now again? Congratulations on getting this far - now realize that you've got many many more miles to go. :)
"I will personally burn everything I've made to the fucking ground if I think I can catch them in the flames."
~ Gabe
"I don't mean to rush you but you are keeping two civilizations waiting!"
~ Cavil, BSG.
"If it's really important to you that other people follow your True Brace Style, it just indicates you're inexperienced. Go find something productive to do."
[size=2]~ Bregma

"Well, you're not alone.


There's a club for people like that. It's called Everybody and we meet at the bar[size=2]."


[size=2]~ [size=1]Antheus

Advertisement

[snip]


Why do people always need to go to the extremes? We're not claiming that "good coding practices will make your engine." And I doubt you are claiming "terrible coding practices won't have any influence on your engine." There is a lot of room in-between those two, and there is a big difference between "over engineer / premature optimization" and actually using consistent naming and using constructors.

Any engineering field has its commonly accepted practices. Even something as simple as which way you screw a screw has a logic behind. There is a reason for that. CS is no different.
Comrade, Listen! The Glorious Commonwealth's first Airship has been compromised! Who is the saboteur? Who can be saved? Uncover what the passengers are hiding and write the grisly conclusion of its final hours in an open-ended, player-driven adventure. Dziekujemy! -- Karaski: What Goes Up...
I agree with Antheus. There were some good criticisms earlier in the thread, but I feel it's degenerated into nitpicking of the code, and then misrepresenting these issues as if there was a One True Way to do things, or as if this was proof his product is useless. Code review is always a good thing, but it's incorrect to assume this is a sign that a project is doomed, or someone is experienced - even if one downloaded the code of an established successful project, you could nitpick problems here and there in the code.

A few particular points:

* I don't think source-only releases for Linux is unreasonable (given the way that platform works). Binaries are great, but I wouldn't say the lack of them implies it's not cross-platform, so long as the source compiles without changes. (I don't know if he claims to support OS X - saying cross-platform certainly doesn't imply it, unless you're going to insist anything cross-platform must work on _every_ platform. There's not an AmigaOS version either...) I refer to my games as cross-platform, meaning Windows and Linux, even though Linux is source only so far. A better more relevant question (especially if it's meant as an engine for others to use) is whether the source would compile on Linux.

* Although I personally don't include licence info in every source file, I thought doing so is pretty common practice. And not just in OSS, so I don't get that comment either. (And even if it *was* the OSS way, that's a viewpoint you hold on OSS in general, and shouldn't be a problem of this one project, which is after all Open Source too.)

* "but it does strike me as the kind of "follow the crowd" stuff that indicates you're not doing enough free thinking." - so we've all these problems where he's not doing it the standard way, but when he does do it the standard way, that's not "free thinking"? Sorry, it's a fallacy to suggest that somehow it's a sign of poor thinking. Why is following what the FSF say on their licence not free thinking, but you are expecting him to do what you say? Should he not do some free thinking and do differently to what you say, by this reasoning? :)

* Disagree that being overly verbose is necessarily a problem, more a matter of preference.

* "Also, no need to zero out the data if you are just about to overwrite it anyway, it's just wasted CPU cycles." - I would recommend generally it's good practice to be initialising variables to some value on declaration. Unless your testing actually shows it to be a performance issue. (Agree about the point on constructors though; but this kind of premature optimisation, as well as the risk of missing initialisations, is generally bad practice.)

Comments like "just sloppy" for things that are common practice, without explaining why this is bad, isn't constructive. Might I suggest focus on the actual problems (or at least give nitpick comments as constructive comments rather than claiming it as evidence that someone's thinking is poor or the project is doomed; and avoid presenting opinion as fact)?

ETA: I guess someone had better tell the FSF are being "just sloppy" too ( http://www.gnu.org/l.../gpl-howto.html ). If I'm reading source code with a view to using it, I most certainly *do* care about the licence it's under.

http://erebusrpg.sourceforge.net/ - Erebus, Open Source RPG for Windows/Linux/Android
http://conquests.sourceforge.net/ - Conquests, Open Source Civ-like Game for Windows/Linux


Why do people always need to go to the extremes? We're not claiming that "good coding practices will make your engine." And I doubt you are claiming "terrible coding practices won't have any influence on your engine." There is a lot of room in-between those two, and there is a big difference between "over engineer / premature optimization" and actually using consistent naming and using constructors.


Of course. Code itself leaves a lot to be desired for and advice given was valid.

But none of us are developing that code, so it's effectively somebody elses problem. And if author is fine with that, then it's not a priority. The original question was: "What do you think about my engine" not "What do you think about my code", it was even posted in lounge.

Adding animations (for example) would improve the engine. Renaming variables would not.

Starting with "change all the code" begs a question: how will that improve the engine? After all the changes are made, what will the new YT video look like? Will it have better shadows, better maps, dynamic lighting, ...?

Improving code might make these new features simpler or faster to implement. But there is a cost to everything, including learning different practices.

And a pitfall - the biggest flaw would be lack of tests. So any drastic change to existing code would break existing functionality, increasing the development time again. So now not only are new features not getting added, entire work goes into: learning, practicing and applying new techniques, migrating old codebase through use of manual testing (QA is a huge time sink) and dealing with unknown unknowns that result from moving into unfamiliar territory.
tbh, based on other threads appearing around the site by the OP, his lack of grasp of current generation (which he probably considers next generation) methods means he has far more to worry about then trying to effectively build a house on a pile of sand... right now he seems to be trying to build the house from the top floor down...

This topic is closed to new replies.

Advertisement