Jump to content
  • Advertisement

Satharis

Member
  • Content count

    635
  • Joined

  • Last visited

Community Reputation

2479 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

    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.
  2. 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.
  3. 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.)
  4. 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.
  5. 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.
  6. 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.
  7. Satharis

    creating and manipulating a grid

    More like I moved on from a pointless argument when I realized you are glued to your opinion and I already said what I wanted to say on the subject, I don't need to spend 3 pages discussing why they can be confusing, especially when I can wrap them in a simple interface and make them always act the same way, regardless of what storage medium is being used behind the scenes. Hah, no, you're right, instead of saying that everyone should code the way you do you just imply that you would never code the way they do, implying you think their way is wrong. I don't tell people how to code either, all I said was negatives to certain methods. If you're really so passive and not debating over style then why did you even stop and reply to my initial post about the method I use and why I use it? I don't even get it, you act like you are not pushing your opinion on the better coding style, but you are, and you tell me to have some humility. How about have some integrity? I don't think I'm even a remotely perfect programmer, that's why I'm always open to learning new things and not just acting like my tried and true way is the best.
  8. Satharis

    creating and manipulating a grid

    There are usually much better tools to choose from than just raw arrays these days, and I already explained the issues something like vector has with being multidimensional. That's not a style thing. std::array comes to mind, which -should- be contiguous in memory with 2d array (as far as I know) but that obviously is always implementation dependent. I also would be wary of statements like "I've been using x for as long as I can remember", not re-evaluating old habits and coding styles as time goes on has historically been proven to be the gateway to bad ideas. Personally my coding style is always changing, especially as I try out new things and find caveats to them and situations where they are superior, or my tastes change.
  9. Satharis

    creating and manipulating a grid

    In memory Map[2][3] would be: [0,0], [0,1], [0, 2], [1, 0], [1, 1], [1, 2] So if you loop left to right in columns you'd actually be jumping by using [x][y] -> [col][row]. Which quickly gets confusing, though you can make it work if you reverse everything. If you use something like a vector of vectors though then the cache problem is major since you'll be jumping between elements that are probably in completely different sections of memory. In the case of containers like that a single container is much more effective. In either case your average person would expect Cartesian coordinates for the style of a grid, i.e. : [x, y]. Which is probably what you should stick to, but that means adding wrapper code to your array or accessing everything backwards, including in loops. Well, I say Cartesian, in reality its more common to address grid maps from top left and moving right and down, but you get the idea.
  10. Satharis

    creating and manipulating a grid

    I'm the complete opposite, I never use 2d arrays. They're terrible for cache and any code you write to access them ends up being written in reverse order anyway so any semblance or clarity they have is lost. I usually just wrap a 1d array in code to access it that gives it a simple to understand interface. Avoids all the previous problems and has clarity.
  11. Satharis

    Choosing programming language

    I love the whole passive aggressive attitude here that implies those of us here that think OOP works fine for games are apparently bad game programmers. Evidently most of us here are bad. Personally I think people that cling to C as some mother language are stuck in the past and unable or unwilling to see potential in other programming styles or methodologies. I hate to break it to you but the vast majority of the industry doesn't use C++ because we are brainwashed sheep, they use it because it is useful. They use it because OOP can be useful in many scenarios and simplify code and make it both easier to expand upon and easier to reason about.
  12. Satharis

    Web game getting published without permission

    Are you seriously implying that people should make money off products solely because they are providing a server that hosts the thing and that all games should be free? Why would anyone want to make things if their work goes unrewarded? I personally speak out against people that I feel are earning far in excess of what their efforts deserve but that is like the extreme in the opposite direction and is just as bad. That said I honestly doubt a lawyer would help much here, if anything it'l probably be a waste of the OP's time. History has shown us that with the ridiculous law systems we have in place it is often completely out of your favor to take legal action against someone else because if they are even someone you can take down(not in China or something) you'll probably spend more on fighting it than you would earn from winning a court case. But a lawyer would be able to give you their honest opinion at least.
  13. I haven't really run into many situations where logic was inconsistent with variable delta time. Replays can be done on games with variable timesteps, the important part is that the game needs to be deterministic, and replays are quite common on games like shooters where it most certainly is twitchy gameplay. Can a fixed timestep make it simpler? It could, it might allow you to save less data for playback, but I've never had to implement a replay system myself so I couldn't comment on the intricate details. Strategy game doesn't inherently mean not twitchy either, if its an RTS I would say input lag can be a thing at professional levels of play. But you are right it is less of an issue generally. I agree it's a thing that is project based, I never said fixed timesteps were bad, just that they have negatives just like variable timesteps do. I think variable rates should be explained to new programmers because otherwise it is easy to confuse yourself into what the time actually means and how it functions in terms of the game. I know when I first wrote a game loop it was the most confusing thing ever with (in my opinion) not nearly enough information online explaining how it works, or the pros and cons of each. It also isn't obvious to people how you have to account for things like pausing games or scaling virtual time differently than real time, or that there might even be many variations of virtual time(scaled game time vs an ingame clock with a day and night cycle or something.) But really that's a lesson that should be taught early on IMO just like the concept of rendering being decoupled from logic and that rendering is just one of many ways you can view the game state, it makes a lot of other concepts much easier to understand.
  14. Satharis

    How to impl a drm scheme?

    Are you really implying he brought that point up and it has nothing to do with the discussion at hand, that it isn't referencing that piracy causes these companies to lose enough money to lose people their jobs? Why even mention it then? I never said they didn't have enormous troves of data, I said we have differing opinions on if they are examining the data and correctly inferring the effect piracy has on their profits. You also essentially make my point for me, that information is closely guarded and unless you work at one of those offices doing work that is decidedly not game development, you'll never have any kind of proof. I don't pretend I have access to that data, if someone here has access to that data I would question why they do and they most certainly would not be allowed to share it. So what that boils down to is that we are arguing two sides here, I'm assuming companies are making incorrect decisions, or they are making correct decisions in terms of profitability but are harming their users in order to get it. Whereas the other side seems to be implying that because these companies make these decisions, that it must be the right choice, it must be accepted and it is the logical solution to follow. I made a plain statement that I do NOT support these practices, even if people's jobs are involved. It should be very obvious to not support that viewpoint means you either side with the opposite viewpoint, or are at best, complacent to it. Is that really just piracy though? I would say that more seems like an overarching problem of people obtaining software like games through fraud, that also seems far outside the norm of how piracy distribution usually works, for single player games in particular they tend to completely avoid interfacing with steam so they shouldn't even have any telemetry for those cases, for games that are mostly multiplayer its a whole other can of worms with people either connecting to real servers through fraudulent accounts or even running third party servers that avoid steam altogether. It's a complex issue. Yes but the question isn't really "is there a lot of piracy" the question is "does DRM fix the problem?" Those statistics are pretty horrifying but also not that surprising, I'd wager a lot of sources of piracy come out of countries that have little or no chance of legal prosecution against people for the activities like China or smaller European countries. Would DRM have really fixed that issues though? There's many variables in that scenario: How many people that pirated would have actually bought the game in an ideal scenario? How many of those accounts were even from piracy and not alternative illegal methods like credit card fraud? How much piracy would DRM cut down on? How much would the DRM cost relative to how much is earned back? That's just a few of the issues, and they aren't solved simply with telemetry data. Whether you meant to or not you are also displaying exactly the kind of statistics I often see people show as why piracy is harming the industry while it not actually correlating to potential sales and revenue compared to costs.
  15. Practically speaking there aren't many compelling reasons that you would need a fixed timestep outside of physics due to the fact the integration becomes much more unstable due to floating point error. I can think of plenty of engines that tick logic with a variable delta time, UE4 comes to mind. There are also many negatives to capping logic updates to a low rate like 30, it increases input lag for one, and the game isn't actually updating so the rendering is mostly wasted. You can interpolate between positions but that means the game is running one frame behind constantly and interpolation only works for linear motion. In some cases you might want locked update rate but I would say choosing to use a locked update rate should be a concern only where performance to cost is important, like say a game server. Tying game logic to rendering at all is usually wrong to begin with, vsync shouldn't even be a consideration into your game logic as it exists solely for the purpose of preventing tearing and possibly making the rendering rate seem smoother. I've seen many games that let you set an FPS limit on rendering in options but I always assumed it was simply to prevent issues like overheating or to reduce energy usage.
  • 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!