Jump to content
  • Advertisement

Satharis

Member
  • Content Count

    644
  • Joined

  • Last visited

Community Reputation

2486 Excellent

About Satharis

  • Rank
    Advanced Member

Personal Information

  • Role
    Programmer
  • Interests
    Programming

Recent Profile Visitors

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

  1. Satharis

    Requesting a code review

    I always find it bewildering when someone says "you should do this, this way, because it is better" and I reply with "It depends on the situation" suddenly it becomes a religious debate that is veering off-topic. Surely the prudent answer -- especially to someone who is barely learning how to develop games -- is that they should not be afraid to try different methods and see what the pros and cons are of each? If you don't agree with that then we should leave it at that, you gave your opinion and I gave mine. As a side note I'm not really sure what you mean about Unity, it stores the delta time from the last frame and also has a fixed update function, like most engines I've seen have. There isn't anything forcing you to use a fixed timestep. There are many fully functional games out there that use a variable timestep, games have even created replays with variables timesteps. They had reasons, it wasn't just that they were bad programmers.
  2. Satharis

    Requesting a code review

    Not sure I agree, at the very least many of the most popular engines in use today don't use this method (UE4 doesn't even used a fixed physics timestep, it is semi-fixed.) Most commonly I see systems get ticked at a fixed rate if they need it (like physics usually is). Other systems tend to just be fed a float delta time, which works fine in practice as long as you don't accumulate large numbers, since those result in significant floating point deviation. Then again I could say the same for globals and/or singletons, almost every major game engine uses them despite them becoming a warzone-topic whenever mentioned here. A more useful distinction is to understand the benefits and negatives of different architectures and pick one that suits your needs. A fixed timestep for physics updates isn't a bad idea.
  3. You'll find that a lot of suggestions on how to code something better are often simply different ways of doing a very similar thing. For instance it's quite possible to write your entire game using one giant code file with a ton of variables (enums or whatever). That would work and not really be any slower, code wise. Problem is it's horrible to look at, work with and just about everything else. First I would figure out how you want the game to play, what is the interface like? Is it like a MUD or something? Do you type in text commands like "get key"? Is it a bunch of buttons you press in a graphical app? Text based doesn't tell you a lot. You can make a console game and have the interface be vastly different, rogue-likes are a good example of this. Unfortunately it's hard to just suggest a way to code it because as I stated before, there are many different ways of doing the same thing. Some are more generic, some more specific, some work well in certain situations, some in others. Often a difficult part of coding is just deciding what method you want to use to tackle a problem.
  4. Haven't used Assimp so I couldn't really comment but usually a model loading library places all the relevant data into some structs/classes for you to work with. However, that's why there's a bit of a big leap from rendering things by hand to automatically, you'll have to rewrite your code to handle rendering just about any object with only the data for it being fed in from files. I would look at sample code using Assimp and see what you can figure out, but you have the basic tools to render anything just with the draw call commands and the others that affect the settings for the draw calls.
  5. Conceptually you can think of each draw call as the minor unit of work for rendering. In the case of your cube the ideal would be as I said, use one VBO with all the vertices in it and draw or drawindexed and a texture atlas for all 6 faces. In the alternate case of what you just stated (and weirdcat mentioned), each face is essentially treated as a separate object when it comes to rendering. So yes, you'd leave the shader as is, change the uniforms(since uniforms are essentially shader inputs) and do a draw call for each face. For the VBO you could just use one and specify an offset and only draw a number of the vertices, or you could use a VBO for each face. It doesn't really matter, though having one is of course generally better due to the overhead added for each one. The benefit of a VBO usually is having all the vertex data in one bundle so the shader can gobble it all up at once, but in this case you're doing separate draw calls for each face anyway so it would be rather irrelevant from a performance point of view.
  6. You usually don't try to texture multiple surfaces at once during a draw call. Generally the reason there are multiple texture inputs and samplers to a shader is so you can combine different types of maps(diffuse, specular, normal, ao, etc). More specifically it's usually explained as one material per draw call, a material mostly consisting of the shaders to use and the textures to use as inputs to the shaders, if you have a model that requires using multiple materials to render then you are stuck doing multiple draw calls. A good example is characters, high detail humanoids will often have a shader and uv map for the skin and most of the body, the hair is then rendered as separate geometry and often the eyes are as well for a multitude of reasons. Ironically the cube example is one of the more unusual ones, if you think of something like a barrel the barrel usually has what appears to be one texture wrapping the body, one for the top and one for the bottom. In reality that's usually one uv-mapped texture atlas. You could do the same for a box if you wanted you'd just have to combine 6 textures into one, that or just use one texture and have it drawn for each face.
  7. Frankly I'm amazed they ever invented computers that can do two things at once. Music AND programming? What's next? Driving and texting? I never get how people listen to music while coding though, if I'm doing anything that requires even moderate thought it often seems distracting. Do you listen to music while doing math too? Then again I never get how people STREAM programming either, that would be incredibly distracting to me.
  8. I think sometimes people develop unreasonable expectations (or even dreams) about game development simply because they exist in the virtual world. A large game like WoW or even a game like Overwatch has what amounts to hundreds of thousands of man-hours poured into them generally. Scale wise it's like having built a pillow fort before and wanting to build a skyscraper, I think it more easily occurs to people that "I can't do this alone, or with a small team" when it comes to a skyscraper, but with a game it is much harder to see the work involved. Reality is I wouldn't set your sights that high if you want to make something for yourself, even if you get friends to help, games are an absurd amount of work. You can start on an inventory system for a game, something that seems simple in theory and even if you know -exactly- how you want to design it, you can finish it and see that you put a couple hundred hours of code into all the different functionality it needed, and that's just one tiny part of a game and one field! Most people vastly underestimate the programming work involved in something, you can click through what looks like a few pages of code and in reality in took weeks of typing and thinking to finish that. Games really are work, you can say you love them or always wanted to make them or dreamed of working on them as much as you want, but at the end of the day they are a ton of work, it's not uncommon for phone games to take people months to make even if they are designed to have quite simple functionality and game play. How long would you really work on a dream game for? A year? Ten years? Twenty years? Would you learn modeling? Animation? Sound? Programming? Design? Quality is a thing too, do you really expect to compare to people that devote their careers to the task? There are people that spend their entire lives making 3d models, get degrees in computer science and a dozen programming languages, work on many projects to acquire design experience. Each field has great depth and many things to learn. I'm not trying to be rude or a dream crusher, I'm glad that people aspire to make games, but in reality out of the many many people I see talk about the industry or try to get into it at a hobby level with big dreams, almost nobody ever even ends up completing a moderate sized game, I've never seen anyone create a notable large scale game by themselves off of sheer willpower. If they're that serious they usually find a job first, or realize how ridiculous a scale what they are thinking about doing really is. A month doesn't go by I don't see someone here asking about an MMO or something similar, these people have no idea the sheer amount of work they are talking about embarking on. I see people sometimes throw together very basic prototypes of games but then they hit a roadblock as they run out of technical knowledge or need things that libraries or engines can't readily provide. My advice would be to rethink what you want and set your sights a little lower. If you really want to make games with others out of university then work on something much smaller and much more realistic.
  9. Your code has a rather confusing design, from what I can see the update code essentially runs every tick and calls deactivate, which does nothing, unless there is a pickup in the queue. In that case it instantly activates and "deactivates" it by removing it from the queue. In reality the ball speed is already changed and it appears its the coroutine that turns it off when the timer expires. I'm not that familiar with Unity but I would assume from the behavior that you describe that the second time you call the coroutine code it essentially overwrites the timer on the first call so the ball only ever gets reset when the latest call to the coroutine finishes. I would probably change the design around to be more clear if it were me, something like activate the pickup bool and call a function that activates the effect of that pickup, then run a timer or start accumulating delta time, then once update is called and the pickup time has expired then you deactivate the effect of the old one, remove it from the queue and activate the next one(if any). Or something like that.
  10. Satharis

    On the fence with game engines

    UE4 is nice but also insanely confusing to learn. It has a lot of strange nuances and things that I feel like the developers often don't even know because it's so massive that they lose track of things. A big problem with UE4 I've found is that the engine basically exists in two levels, the code section and the run-time section. The run-time section has pretty much access to everything, it can see UMG widgets, it can see blueprint, it can see C++ classes. The opposite is not quite true, i.e. if you want to make a UI widget in the editor then as far as I can see you can't spawn it in code without defining it in code to begin with. This sort of ends up with an effect similar to the inheritance problem, you slowly end up pushing everything from the editor down into C++ code instead(so it can be called there.) Some things let you use reflection to spawn or interact with them on the fly, but for a lot of things it is awkward at best. It's nice Unreal gives you source code access, this makes for a very useful tool for looking things up and seeing exactly how they work, but it's definitely a double edged sword. The engine expects C++ files to be defined a certain way and generally added through the editor, moving or renaming files is a huge process that you can spend a non-trivial amount of time on and sometimes end up accidentally breaking content in the editor. Working with blueprint is definitely slower if you're used to coding though, I've used it for prototyping things or for certain code segments, but often you just want to be able to type down exactly what you want without lots of clicking and dragging(this gets very laggy on large blueprints as well.) I haven't worked much with Unity, so I couldn't comment on the cons of that but as far as I can tell you work pretty much exclusively in scripts for Unity so it has less of that multi-layer issue that Unreal has, but likely has worse performance as well. Both engines are big and I'm not sure I'd call them good for very accurate simulation. With Unreal at least you don't even get a lot of guarantees on the order certain functions are called in, length of tick functions, etc. It's also a very heavyweight engine and performance can suffer in some areas simply because the engine tries to be so generic(good luck making an RTS like we are billions or something with Unreal actors.) Ultimately they're both useful tools, I don't know what you mean specifically by "simulation" or what your constraints are. I wouldn't say a game like The Sims is much more of a simulation than your average game, so I wouldn't worry much about that. I would keep in mind that both engines use different pricing schemes too, if you really want full power with Unity you basically have to pay a per-seat fee for the professional version of the engine, Unreal has no licensing limitations like that but they take percentage royalties when your game is released, so the situation is pick your poison really.
  11. Keep in mind that interpolation is a blanket term that means different things in different contexts, not everything is interpolated. Rutin is specifically talking about linear interpolation between positions. If you use a 2d sprite based game for example, animation is usually comprised of distinct sprite key frames, so a 2d fighting game could have character sprite positions interpolated(they would move slightly between frames even if the logic isn't updating) but their animations wouldn't change, and no game play effects would happen. In reality games tend to vary a lot in how they handle updating, many run different logical updates at different rates as well (physics may be updated at a different rate than AI, or other systems.) Actions taking X amount of "frames" is likely just dependent on how the engine is set up, and may just be based on delta time.
  12. That's sort of vague, what do we define as math? Is logic branching defined as math? Most people use game engines these days that may have a couple million lines of code in them just devoted to maintaining basic game systems like resources, rendering, so on. A lot of that isn't necessarily linear algebra either. If I had to write down a log of math I was using when working on "gameplay" code most of it would be: arithmetic, simple linear algebra(vectors, distance, dealing with rotation and angles) and then regular algebra for composing math functions(formulas for figuring out damage or something.) Referring back to the OP though I'd say there isn't one magical skill you use all the time. Sometimes design is time consuming, sometimes math is time consuming, sometimes figuring out logic is time consuming. I've spent many hours working on code that only uses arithmetic and wasn't a design problem but it was rather hard to reason about each step it should take(a ring buffer with timestamps used for prediction on a multiplayer game.)
  13. Satharis

    C vs. C++ vs. C# (Beginner)

    They're all pretty similar and are just support libraries that handle things like translating OS events into simpler input, manage a window for you, have some basic drawing functions, stuff like that. Allegro is a bit of an odd duck, it's very old. SDL is pretty old too and more of a C library but it's very widely used and sort of the old guard. I'm not that familiar with Allegro so I'm not sure if its competitive with SDL still. SFML is kinda the new kid on the block though it's a few years old and mature too, it follows C++ style(lots of classes) compared to SDL, which is really a C library that just works with C++. None of them are engines though, you'll have to manage everything from the game loop to resource management to whatever else.
  14. That's pretty much the opposite of me, I seem to spend forever trying to figure out a design for things and very little time on the math. Although it really depends on what you are making and how familiar with it you are. I'd say by far the hardest thing is figuring out how to do something you haven't had to implement before. It's hard to really pick a math field that you use because certain systems tend into different territory. Stuff that pops up in the game world uses a lot of linear algebra, stuff that is behind the scenes ticking systems tends more towards regular algebra, or sometimes calculus for mixed systems. A lot of stuff is just arithmetic even, breadth is definitely helpful for your math skills.
  15. Satharis

    Choosing programming language

    To me that's a completely vague statement. What is it one needs to program games? Games are just software and a complete game has many sub-disciplines that go into it from physics to AI to rendering to audio to networking to.. so on. They also include a lot of non-specific fields like multi-threading, resource management, tools, UI, whatever. I wouldn't expect handmade hero to teach me how to recreate UE4. There is no golden bullet to acquiring those skills, if you make a simple arcade game then a few tutorials might be enough to let you make the game, if you're working at a studio on the next multi-million dollar large scale project then there will be many parts of the project that need people with those specific skills of a high enough depth to finish the project. Your statement is sort of like saying watching a 20 part video series on how to play guitar will suddenly make you the next rock star.
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!