Like Tree3Likes

Encrypting reusable code

This is a discussion on Encrypting reusable code within the C++ Programming forums, part of the General Programming Boards category; Well, the main reason I find that advice valuable is that a beginner has no way to know what to ...

  1. #16
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    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.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  2. #17
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    Quote Originally Posted by phantomotap View Post
    Talk about broken logic; if trying and failing is valuable in that one can learn from the experience, the learning experience is always valuable.
    I think that's a common misconception. Most of our learning does come from failures, but that doesn't imply that most failures lead to learning.

    To learn from failure, one needs to have a clear picture of what success would have looked like - the learning comes not just from failure, but from the ability to critically compare your failure to an accurate picture of success. Without a clear idea of what constitutes success, failure doesn't teach you much, if anything. That's why reaching just a bit beyond your grasp gives the best learning - the problem is close enough to your skill level that you can understand what success means, and yet it still challenges you.

    Some kinds of failures can teach you a lot. Others will teach you nothing at all.


    Actually, no, such a process does not force you to consider the separation of mechanism and abstraction, of implementation and design; it fails to hit such a useful goal for a simple reason: if you don't concern yourself with such considerations from the very start you can not possibly generalize and abstract what you learn during the development process of the games you build; you will ultimately and only be trying to reuse code; those two things aren't even in the same universe.
    I would argue you can't understand the abstract without first really understanding several concrete examples of how that abstraction will be used. To build a tool for game development, you need to have experiences with game development just to understand what problems your tool is attempting to solve.
    Last edited by Cat; 05-11-2013 at 12:30 PM.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  3. #18
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,230
    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

  4. #19
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,230
    [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

  5. #20
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by joejoepie View Post
    Thanks phantomotap, and yes, that would be a better approach

    For Neo1, i started programming when i was twelve, i've fully mastered Unity, i've used UDK and i've used CryEngine.
    I have studied Java, C#, C++ and C. And i'm not saying that this means that i can do this, but it also doesn't mean that i WILL fail, like you so gently say.

    This DirectX thing is a preperation for the college i want to go to. It's a school dedicated to making games, and the content of it.
    I've heard and seen that the school is very hard, so i'm preparing myself. The reason why i choose making a game engine, is because i need an objective.
    Taking a hard objective means that i will have a very hard time, and that i will have to do a lot of research, which means that i will learn a lot, and THAT'S my actual goal.

    It's nice that you want to help people on these forums, but you should not "kill" the dreams of new programmers. I've already written a small 2D game engine in java, so i'm taking the step to 3D.

    Greets
    My intention was never to discourage you, it seems you've managed that quite well on your own :-) I just wanted to point out that with the attitude that you've so far shown us, you won't be able to complete this project. Since it seems you have a fair amount of experience, i don't quite know why you're doubting yourself so much?

    Anyways, i would recommend you inspect the code and interfaces of existing open source game engines before starting, a lot of work has gone into most of them, so there is likely a lot to learn.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  6. #21
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,543
    Quote Originally Posted by Neo1 View Post
    ...I just wanted to point out that with the attitude that you've so far shown us, you won't be able to complete this project. Since it seems you have a fair amount of experience, i don't quite know why you're doubting yourself so much?
    It's less about the attitude and more about the will.
    Not setting too high expectations for oneself is a good thing™, and having a pessimistic outlook is a great way to do that.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #22
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by Elysia View Post
    It's less about the attitude and more about the will.
    Ah well, semantics. Maybe attitude was a poor choice of words, it seems joejoepie was expecting to fail, maybe even planning for it, which doesn't seem like a great way to not fail :-)
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  8. #23
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,543
    Expecting to fail makes it less hard on you when you do fail. Don't expect it to work on your first try, not even for experienced developers. Game engines are not trivial.
    In fact, it one would have the attitude that if one tries one succeeds, then one might throw too much work into something that will ultimately fail instead of putting time and effort into something else that can help one grow.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #24
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by Elysia View Post
    Expecting to fail makes it less hard on you when you do fail. Don't expect it to work on your first try, not even for experienced developers. Game engines are not trivial.
    In fact, it one would have the attitude that if one tries one succeeds, then one might throw too much work into something that will ultimately fail instead of putting time and effort into something else that can help one grow.
    Being prepared to fail is fine i suppose, being certain of failure even before one has started is no way to approach a task.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  10. #25
    Registered User
    Join Date
    May 2013
    Posts
    6
    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

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Encrypting with User-Given Key
    By BrieRose in forum C++ Programming
    Replies: 3
    Last Post: 05-04-2013, 09:29 AM
  2. Encrypting passwords
    By FlyingIsFun1217 in forum C++ Programming
    Replies: 23
    Last Post: 12-01-2006, 01:48 AM
  3. help with encrypting plz
    By wimpman in forum C Programming
    Replies: 9
    Last Post: 03-31-2004, 02:29 PM
  4. Function not reusable?
    By mart_man00 in forum C Programming
    Replies: 3
    Last Post: 09-07-2003, 09:02 PM
  5. Encrypting still
    By bitWise in forum C Programming
    Replies: 1
    Last Post: 10-15-2001, 07:26 PM

Tags for this Thread


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21