• Advertisement

0r0d

Member
  • Content count

    400
  • Joined

  • Last visited

Community Reputation

2006 Excellent

2 Followers

About 0r0d

  • Rank
    Member

Personal Information

  • Interests
    Programming
  1. Modular 3d Engine Idea Feasability Question

    You dont need a brand new engine just to support new rendering techniques. An engine is a lot more than just rendering 3d meshes, and generally you can add new shaders, effects, or whatever to an existing engine with little trouble. Professional game engines are typically already written with a certain degree of modularity in mind, but you also have to keep in mind that a game engine has a lot of parts that all need to communicate and work with each other and it has to perform as efficiently as possible. This means that there's always going to be a lot of coupling between systems.
  2. It's hard to say. Question: Are you planning to make another game? Reason I ask is that if you are planning to do another game, especially one that has many similarities with the current game, then that's one of the best ways to pull out the common code that can be encapsulated from the current one. I mean, if you just have one game, especially when you're new to game development, it can be hard to know what parts are reusable and which cant. But as you try to make another game you will quickly see all sorts of things that are in the old game that you want in the new one. But instead of copy-paste you can then think of how you can pull that stuff out, in a non-game-specific way, into a set of libraries that can be your common core engine.
  3. Memory fragmentation is not really an issue, but creating and destroying threads that often might be a performance problem. I'd recommend having a thread or pool of threads to which you give work as needed. You'll need some synchronization mechanism so that the threads wait for work and then signal your main thread when they're finished.
  4. Like always, it comes down to what your ultimate goals are. But in general I'd say yes. Refactoring code is usually a good learning experience, especially when you're doing so with the goal of making it more cross-platform compatible or you're factoring out engine components to use later. You will end up with a set of tools that you can reuse, and you'll understand better what the different parts are and how they relate to each other.
  5. Leaving a company at a critical moment

    It sounds like you have several good reasons to accept the new job. It's up to you to consider what "committed to a 3-month long project" means, as in what type of commitment you made. You dont tell us. So, it's your call as to whether you're breaking some moral code of yours. But generally I'll say that if the company put all their eggs in one basket, so to speak, by having a new project that relies so heavily on just one person, then they are the ones who put the "company in that position" and not you. But again, I dont know what commitment you made to them. Maybe you just accepted the project, or maybe you gave your word that you would be there until completion. Those are different levels of commitment. Assuming your "commitment" was just to accept the project, then I'd say you should take the new job because of all the reasons you gave. You need to do what's best for you and your family, and let the company do what's best for them. If the tables were turned and the company thought it would be best to let you go, they might feel very badly about it, but at the end of the day I'd expect that they'd do what's best for the company. You can also offer to help them with the transition to a new engineer on the project. I'm not sure what the specific details of that would be, but maybe it's something to consider. Maybe you could even work for them on a freelance basis for a while to help them transition, and ask the new company if they'd allow you to work there part-time while you do that. I dont know, you have to think about it. But there might be some way to mitigate the transition for your old company if you really want to.
  6. Try this: https://msdn.microsoft.com/en-us/library/hh873197.aspx
  7. Production in the AAA scene

    I think you need to be more specific in what you're asking.
  8. Why A.I is impossible

  9. Why A.I is impossible

    None of this makes any sense.
  10. Gaussian based Weights

    This might help: http://dev.theomader.com/gaussian-kernel-calculator/
  11. Then maybe someone who has expertise with Unity can comment on this. My guess is that Unity should have decent input handling latency, but that's just a guess based on input handling not exactly being a difficult problem for an engine to deal with. I'd be more concerned if you had hundreds of AI or physics objects all flying around, because those might bring Unity to its knees. If the objects have fairly simple behavior, then even Unity should do a good job with it.
  12. Well, I'm not that familiar with Unity in practice (I just have general knowledge of it) or how they deal with input, but can you tell us why you think it wont work? If you're making a 2D game on PC, I'd imagine that Unity should be adequate to handle any number of objects moving around on the screen with minimal input lag. Can you be more specific about what you're talking about? How many objects? What code are they all running? What framerate do you want to achieve? Have you dont tests with Unity (or other engines) to determine what their limitation are?
  13. Over-ambitious projects

    This
  14. By "small projects" I didnt mean small games, I meant small coding projects to learn the language. Right now you dont know a programming language, so trying to make a game is like trying to build a wooden house when you dont know any carpentry. You need to first learn the tools of the job and practice using them before you tackle something like a game. Reading books will help, but only if you practice by applying what you're learning. But if you try to practice by immediately trying to build an entire game, you will likely just get frustrated and overwhelmed. C# will be easier to learn and you can apply what you're learning if you're using something like Unity. Playing around with Unity and building scripts would be a good way to learn how to build a game, as long as you take it a small step at a time. C++ is the industry standard in the games industry, but it's also a very complicated and powerful language. It's not impossible to start off with C++, but it will just be more difficult. Also, you can start with C# and a lot of what you learn can later be applied if you then learn C++. The general programming and problem solving principles will be the same. If you did decide to learn C++, then trying to learn C now thinking that you need to do so before moving to C++ is a bad idea. Just learn C++ and forget C. If you go that route, I'd recommend getting a good book on modern C++ (C++11). It will be easier to learn because modern C++ has a lot of great stuff to make your life easier.
  15. I'm assuming from the question that you dont know how to program in any language? If so, then the first step is to learn some language and do some small projects with that until you know it decently well. After that you can start to work on a game with an engine. I'd recommend you learn C# because it should be easier to handle than something like C++, and then you can start with Unity (if you're making a 3D game).
  • Advertisement