Jump to content
  • Advertisement

0r0d

Member
  • Content count

    414
  • Joined

  • Last visited

Community Reputation

2012 Excellent

5 Followers

About 0r0d

  • Rank
    Member

Personal Information

  • Industry Role
    Programmer
  • Interests
    Art
    Design
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The path depends on what you want to achieve. What are your goals, what do you want to accomplish? Are you just interested in doing some hobby stuff, or do you want to become a professional developer? What areas of game development interest you?
  2. 0r0d

    Military Simulation Game

    You need to be more specific. Right now your question amounts to "how do I write the game?".
  3. Like he said, they're not mutually exclusive. You can have a design that uses both. I do that in my engine. To the question of how to know when to use these design principles, you should decide that based on what your experience tells you, what the needs of the project are, what you intend to do with the engine, what style you prefer or are most comfortable with, etc, etc. Like with anything, look at the problem you're trying to solve, and then use the techniques to solve it that suit you and the problem best. If you're not familiar enough with these things to know for yourself which to use, then us giving you advice wont help much. At best we can say "based on your goals, you should look into this technique", but then it's up to you to become familiar with it. If you just take our advice and jump into it without knowing what you're doing, you will probably do more harm than good.
  4. 0r0d

    hi i'm designer looking for a project

    Have you shipped any games?
  5. 0r0d

    C++ Gameplay in C++

    The last big developer I worked for did the engine in C++ and "gameplay" in Lua, and it was a nightmare and pretty much the opposite of what you just described. The Lua code was crap, it was hard to write so that it wasnt full of bugs, it was slow and constantly had to be ported to C++, it was difficult to maintain or even understand what it was doing, and pretty much abused at every possible opportunity. At one point the debugger we were using stopped working because of conflicts with how the project worked (dont ask me, I'm still not sure what the problem was) and from that point on debugging amounted to using logging to find the problems. Awesome! The entire project would have finished with better performance, better overall code quality, happier engineers, and way faster if all that code had been C++ instead of Lua... or at least a better scripting language. I would never willingly volunteer to ever work on Lua code again. Yes it's easy to write the code, but it will be shit code and some obvious bugs (like, you misspelled a variable) will only show up later when that code runs, and god help you if the first time it runs is after the game ships and that code path was never tested during development. If you're counting on re-writing code to C++ later, that automatically kills some of the productivity gains you think Lua gave you. Training programmer... more productivity loss. Then you lose additional productivity debugging code across the gameplay-engine interface, or just general debugging because honestly debugging Lua code sucks bigtime. And if you're relying on the Lua code to not be performance sensitive, then I hope you're enforcing that very strictly. That project I was on didnt and the result was that all the high level code, as well as most of the low level code, was all done in Lua. Oh, joy! I wish I could get back the months of my life I wasted learning, debugging, re-writing, optimizing, and porting shitty Lua code. Hey, if someone out there actually likes writing Lua code, awesome for them. Go to it. But, I would only force someone I really hated to work on Lua.
  6. 0r0d

    C++ Gameplay in C++

    I write my game code in C++, engine is also C++. If I need to allow scripting outside of IDE then I'd also still use C++ with something like Runtime Compiled C++. If your scripting is being done totally in-house, then I dont see much benefit of a non-engine language for the gameplay code. You're just creating more complexity, less performance, more difficulty in maintenance, debugging, and optimization, and basically separating your programmers into two groups that will generally not interact or understand each other much of the time.
  7. I dont understand... if this is a pixel art game, then presumably the art only makes sense at a specific resolution so that the pixels are at a certain scale, right? So why not just do like cyberpnk says and support just that resolution, and then you can scale and letterbox to support the final screen (or window) resolution? Seems like you're just making life hard for yourself.
  8. I'll re-read and digest all this when I get a chance later, but I wanted to say that what I'm currently trying is the "use the creating object's ID" approach. I'm not entirely happy with what I have now, but maybe I can get some ideas here to fix that. I should also point out that since I havent really started on the networking stuff, the reason why I'm doing this came up because I was trying to make my engine/game deterministic just from run to run in the same machine. Basically it's not deterministic in consecutive runs due to the random number generator. So, ok, I figured I could create a RNG class that objects could use internally, rather than using my global mathRand() type functions, and then set the seed for that RNG class instance with the ID of the owner object, and that's when I realized that this was a problem. No deterministic ID (because objects are created in worker threads) means no deterministic random number generation (at least with this approach I chose), and that means no determinism at all. So if anyone has ideas on how to better deal with generating deterministic random numbers, given the multithreading of object/AI updates, I'd love to hear them as well.
  9. Thanks for your input. I'm not sure whether anything I'm planning to do is unorthodox or not, because this is the first time I've ever had to implement a networking system. That's why I need some good input on this. I might have a lot of independent objects, with possibly up to thousands of AIs. So I'm hoping to keep the server and clients in sync as long as possible so I can spread out the synchronization process for things that get out of sync on the clients. So running all the logic for the AIs on the clients only seems to make sense. I cant be updating all those AIs and other stuff including physics from the server without client-side prediction. So what I'd like to do, ideally, is have new objects and components being created independently and in sync, and only deal with the occasional out-of-sync situation. If the clients and server are all creating things with IDs that they both agree to, then this would (should) work. The idea of just doing things temporarily on the client, as far as new objects/components, scares me because of all the other dependencies that would have to get fixed up... and I dont think that keeping the entire state of the game back for even a few frames will be a viable solution. But maybe I'm misunderstanding what your solution implies. It just sounds like a very problematic thing to implement.
  10. Unfortunately there are other cases where objects get created, such as by AIs or other things. Yes this occurred to me, but the problem is that in order for the client to let the server know what specific object it's talking about, it basically needs the shared ID. I mean, they both need to agree on which object the client is referring to. And whatever information they use for that, I could have just hashed into an ID to begin with, and then both would agree to it without any explicit communication. Also thought of something like this, but I think the problem is still there... they both need to know which object is which. For example, an AI on the client spawns 10 bullets, all identical in every way (including the transform) except they all have a script component attached that determines their behavior after being spawned. Then it could get worse... imagine after creation other objects are created that are watching those, and maybe other objects are keeping pointers to those bullets, etc, etc. Never underestimate the mess that a game programmer or scripter can create. I'm not even sure how to start sorting all this out and how to have the server figure out which object is which and how to sync all of that.
  11. What I need is to be able to create objects/components and assign them unique IDs in both the server and clients, at the same time (so, client-side prediction), and given that objects are created on multiple worker threads (order of creation is not deterministic) in such a way that the server and clients all agree on this ID. I want to use the ID to sync the object/component data from the server to the clients, so clearly when a new object is created they all need to (independently) come up with the same ID. But, the fact that these objects are created on multiple threads complicates things, since I cant rely on them being created in any order even within a single frame update. How is this situation normally handled in existing games? Any ideas on how I can do this? Is there a way that doesnt rely on object IDs at all? Thanks in advance.
  12. 0r0d

    Cartoon Art Style

    That isnt helpful. What are you asking? Are you actually asking how to make cartoon style art?
  13. 0r0d

    Cartoon Art Style

    Please be more specific.
  14. Of course it all depends on what your goals are, but given your stated goals and the time frame you have to work with, I'd say... stick with C++. I understand that it can be frustrating coming from Java. In order to fully get C++ you have a lot of stuff to unlearn and even more to learn new. But, you're learning those things for a reason... because C++ is more closely linked to how the hardware actually works. So to some extent there's a lot of complexity there because there has to be. And of course there's also a lot of complexity because the language has been growing over the decades. But, that's something you just have to adapt to over time as you learn and master the language. "The language doesn't matter" is a fallacy, as demonstrated by this very thread. That's like saying that the building materials dont matter when you're building a house. Of course it matters. If you want to eventually work on professional games, then you'll almost certainly need C++, unless your goal is to just work on a small subset of those games like the tools or scripting or whatever. And if you want to work on the engine tech, then you'll definitely need C++.
  15. 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.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!