Thread: Encrypting reusable code

Well, the main reason I find that advice valuable is that a beginner has no way to know what to design.
(Other than if he reads a spoon feeding book at the very beginning, which I think is more harmful.)
I think your perspective is a little bit skewed on this because of your experience in designing stuff from scratch.

For example, just a few days ago, I was very puzzled about how to design a scene like hierarchy of objects.
The first time everything clicked into place is *after* I managed to write some ugly and unstructured code about using "assimp" to import a scene from .blend files.
After that the design went comparatively smoothly.

>you will ultimately and only be trying to reuse code
I agree that would be dangerous, but have avoided doing that more than once.

>you only learn that you need a camera system, but to actually refine a camera system, one must exist.
Exactly my point and the same one made by the article.
If you try to make a 'well designed' camera system without knowing how view matrices work, it would be a rather unusual camera. :P
Designing and learning computer graphics at the same time doesn't work very well for me, so I have successfully managed to break the process into interleaved pieces.

I think your perspective is a little bit skewed on this because of your experience in designing stuff from scratch.

O_o

My perspective is indeed skewed by my experience so I'll share a little of it with you.

I love "shmups"; I cherish them, and not to brag, I'm generally very good at playing them; I've developed many and played hundreds.

Can you guess what problems my early engine had? What if I told you that my reference to the camera system was intentional?

Yes. My early engine, especially the early version as some camera problems still exist, was heavily flawed because I borrowed the camera framework from my early demos many of which were "shmup" and several "platformers" as well. The camera system had a very rigid definition of "third-person follow" making it almost completely unusable by any other genre without using a different "third-person" mode and specifically coding "follow" semantics. I spent a couple or three years putting bandage after bandage on the camera system. By the second major rewrite I had far too many, nearly fifty I seem to recall, different camera modes; every mode was rigid, and every mode sucked for almost everything.

I knew I needed a camera system, and I certainly knew I was to lazy/stupid to recreate one every new game. (I suck at algebraic manipulation, by the way, which as you may imagine causes me problems in a lot of mathematics.) The problem was, I had never set down and started designing a general purpose game engine; I didn't refactor the cameras to fit a generalized purpose; I developed specific models of the idea of cameras only to generalize those specific forms of those ideas of those camera. I was just throwing bandage after bandage at my code "filling the need" of different cameras with vastly different code and mechanisms.

The problem wasn't that I wasn't generalizing the camera system or coding and developing a general interface. I was focused on generalizing the purpose of cameras in games instead of just generalizing cameras themselves. I finally threw every single line in the trash and rewrote the camera system while generalizing the interface, instead of the purpose, for cameras. I still have a couple too many camera systems, but each one is far more generalized. It was only when I finally put myself at the other end of the development line that I was able to develop a few but significant set of components which reasonably fit all game genres.

Crucially, each current camera system is more difficult to use than the original versions. Placing myself in the seat of game developer, I would have never considered, not at that time, that a system of components each having a much more complex interface would be actually easier to use for game development. The work done by the original versions was seemingly a necessary part of the abstraction for each form of camera. That work must still be done, but now, the camera system offers a more complex interface forcing the client to do the work, but the new systems are also more complete allowing the client to do that work in only a few lines of code.

I'm not saying that one must set out to build a game engine, whatever you may wish to call it, from scratch "wholesale", or however the articles refers, to be successful. I'm not saying anything of the sort. I'm saying that one must pursue a game engine from both directions.

Well, the main reason I find that advice valuable is that a beginner has no way to know what to design.

O_o

That isn't the advice the article gives.

Starting with a blank slate, beneficial or not, doesn't factor in my problem with the article.

For example, just a few days ago, I was very puzzled about how to design a scene like hierarchy of objects. The first time everything clicked into place is *after* I managed to write some ugly and unstructured code about using "assimp" to import a scene from .blend files. After that the design went comparatively smoothly.

Well, you didn't follow the advice of the article now did you?

You were obviously interested in structuring the code so that you could manipulate scenes through the manipulation of the component scenes with a focus on clean, structured components. That, regardless of what you or anyone else wishes to call it, is the process of developing a game engine.

Exactly my point and the same one made by the article.

O_o

No. You either didn't understand my point or the point made by the article.

To create a game engine, you must build game engines. You can try and build them "wholesale"; you will fail, but you can try, and if you devote yourself to that failure the experience will be invaluable ultimately yielding fruit in the form of, yes, a great game engine. You can also build them "piecemeal" refining the engine over many generations of games, yet you will still fail many, many, many times, but in the end, if you devote yourself to those failures, you'll still have a great game engine. One way or the other, you will never build a game engine without significant focus and dedication to building a game engine.

Soma

[Edit]I decided to separate this from my other post in the event that a moderator decides to remove it and/or me. There is little reason not to make such cleanup easy if so desired thanks to what insult had been posted.[/Edit]

I think that's a common misconception.

There is nothing in what you quoted that could ever be construed as a common misconception for your own lack of insight into your own failures is not a common thing.

Most of our learning does come from failures, but that doesn't imply that most failures lead to learning.

I said nothing of the sort, but strangely, I'll stand by it for you all the same: if you are willing to fail, and learn from the failure, then all failure will lead to learning or death.

Others will teach you nothing at all.

Do not place your small view in your own self upon others; if you fail and learn nothing, so be it; it is you who are at fault for being incapable of finding value in your failure and so have truly failed in the worst way.

Without a clear idea of what constitutes success, failure doesn't teach you much, if anything.

[Edit]I've removed the direct insult. Sorry if you were so exposed. I have little patience for people who'd aim low for fear of failure, but still it was grossly inappropriate for such a vulgar attack.[/Edit]

How do we delve into areas yet unexplored? We find value in the adventure! The failures of finding answers will always grant us insight into what questions we may yet ask!

I would argue you can't understand the abstract without first really understanding several concrete examples of how that abstraction will be used.

What you may argue in that direction is entirely irrelevant to what you quoted.

I'm left to conclude that you are either trolling, foolish, or afraid of failure.

Soma

Thanks all for your replies.

DirectX isn't the first graphics api i've worked with, also OpenGL. And I know i have the programming skills to make a small engine.
That means: i understand code enough to make it happen. I just need a lot of tutorials (i'm busy with the Rastertek tutorials, i think they're great)
and a lot of searching.

I asked about encrypting code because i was interested in the matter, but i didn't find sufficing info on Google, so i asked here.

I'm glad i got so much responses, but i think my question is answered already so this topic is closed, i guess
I actually have no idea if i can close this topic