Kylotan

Moderator
  • Content count

    14138
  • Joined

  • Last visited

  • Days Won

    47

Kylotan last won the day on December 28 2017

Kylotan had the most liked content!

Community Reputation

10165 Excellent

About Kylotan

  • Rank
    Moderator - Scripting Languages and Game Mods

Personal Information

Social

  • Steam
    kylotan
  1. No. There are different skills involved but it's simply false to suggest that one type of artist is 'higher skilled' than another based purely on their title.
  2. AI Duplication Issues

    It's not clear what all your public variables are, so it's hard to be sure. If 'enemy' was the same character as the one doing the AI, its easy to see how the last line of navigation would actually do nothing, for example. Use Debug.Log lines to see which code branches are being executed, and which values the code has at that time.
  3. Sometimes it can be counterproductive to learn C# separately from Unity because the way you structure a program in Unity is very idiomatic. So bear that in mind. I am not sure what the differences between 'running' and 'building' code - Building code prepares it to be run. Running code actually executes the program. Often a button to 'Run' will check to see if it needs building, and will build it if necessary, and then run it. If you are seeing your program's output, it's running. There are several bits of jargon that keep being thrown around, without much in the way of explanation: 'Classes', 'The Main Method', 'Namespace'. - These are big, complex concepts and you're not going to get explanation from tool-tips or whatever. This is a whole programming language with books dedicated to it. If you don't want to get a book your best bet is to get used to using the online references, for example here: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/ In the meantime: class - a grouping of data with the functions that operate on that data. Objects in your program are usually instances of a class. Each class might have zero, one, or many instances. main method - the function that gets called at the very start of your program, and that then calls other functions to get everything done. namespace - a way to group classes together under a related name for ease of use and to avoid naming clashes. line-by-line explanation - why did you write it if there wasn't an explanation for it? Try finding a tutorial that actually explains what it is telling you do to. Don't get into the habit of typing code from the internet unless someone is explaining what it does. "using system" - this gives you access to a bunch of pre-defined objects in the 'system' namespace. In this case, the only one you're using is 'console' "namespace helloworldtwo" - this puts everything inside the next pair of braces into the 'helloworldtwo' namespace. In this code, this actually does nothing special, but if code in other files wanted to access the class or function in here, it would need to prefix it with "helloworldtwo", or use a "using" statement like you did with 'system'. "class Mainclass" - this denotes the start of a class called 'Mainclass'. The name is arbitrary. A class just groups data and functions (functions are usually called 'methods' when in a class), but in this case there is no data, so it's just holding the function. "public static void Main (string[] args) - " this starts to define a function. The function is public, meaning any part of your program can access it, static, meaning you don't need a specific instance of that class to use the function, it returns 'void', which is a fancy way of saying 'nothing', and it accepts an array of strings as an argument, and calls them 'args'. Note however that your function currently ignores those strings. A function is a block of code which takes some arbitrary input, does some stuff with it, and then returns some arbitrary output. In mathematics, an example of a very simple function is "square-root". If you pass 25 into a square root function, you get 5 out. And so on. In programming you can also have statements that cause side-effects - like Console.WriteLine - so your functions can do more than just return values, and this makes it practical to build entire programs out of functions. "Console.WriteLine ("Hello World!")" - you already figured this bit out.
  4. Snapshot Interpolation

    The point of this sort of system is that a state update takes some length of time (say, 'M') to reach the client from the server, and then some length of time (say, 'N') before the client fully reflects that change, to help ensure the client has received another state update from the server before the current one is reached. You can adjust N slightly on a per-message basis to account for fluctuations in M. In other words, if a message arrives sooner than expected, you might want to take longer to interpolate towards it, and vice versa. This keeps movement smooth. It is reasonable to consider decreasing N during play so that it's not too long and imposing unnecessary client-side latency. This will be determined by M and your send rate. It's also reasonable consider increasing N during play so that it's not too short and leaving entities stuttering around, paused in the time gaps between reaching their previous snapshot position and receiving the next snapshot from the server. This is determined by the variance of M (jitter) and your send rate. Often N is left at a fixed value (perhaps set in the configuration), picked by developers as a tradeoff between the amount of network jitter they expect to contend with, and the degree of responsiveness the players need to have. And if you're happy occasionally extrapolating instead of just interpolating, i.e. you are happy to take less accuracy for less latency, then you can reduce N down even further. The idea to "catch up earlier" doesn't make sense in isolation. Earlier than what? The idea is that you always allow yourself a certain amount of time to interpolate smoothly towards the next snapshot because you still want to be interpolating when the subsequent one comes in. You don't want to be decreasing that delay over time because of the stuttering problem above, unless you have sufficient information to be able to do so.
  5. C++ Savegame headers?

    The first way makes a lot more sense.
  6. If you want to self-teach yourself game programming, be aware that this is likely to take quite a while before you are at an employable level. Also be aware that the work done by designers and the work done by programmers is very different. Then the games industry is probably not for you. On more than one project I've worked on, I've been assigned tasks where that consisted of a single sentence like "Implement dialogue windows" or "Fix NPC animation" with no indication of what that truly means. The implication is that you can work it out for yourself, if you dig into it and speak to enough people. If you're really lucky there's something written about it somewhere (most likely an email thread you weren't included on, 3 months ago.) Then what inevitably happens is do you do the work, commit the work, and someone says "no, I didn't mean like that. I wanted it more like...<whatever>" Repeat until shipping day. As for tedious detail work... sorry, there's plenty of that. Type just 1 letter wrong in your code? It won't build. Or will crash. Set one value wrong on a material? It'll look wrong, and you'll have to dig through to find and fix it. Game development is complex, detailed business. You're not going to find this in the games industry, sorry. You don't get to be the ideas person without spending years in the "finalize everything" trenches. Why would we trust someone to come up with ideas if they have no appreciation of how they would be implemented? Onto your questions (though I feel the answers are now irrelevant): In your daily work life, do you feel like you are being stimulated with new task frequently, or do you mainly work on similar tasks? Depends entirely on your viewpoint. Some people in other industries are amazed that I have to work on the same project, inside the same codebase, for years on end. Every day I am "writing code", so that's the same task. Sometimes it's a more interesting feature, sometimes it is not. Do you feel like you have the possibility to innovate and bring in new ideas in your job / task? Yes, but that's because I'm a senior member of a small team. As a junior member getting into the industry your expectations have to be much lower. Do you feel that, for the most part, your position has clearly described activities, or are you mainly taking on various roles that are currently needed? Again, this is a matter of perspective. My job is 98% programming; so that is 'clearly described'. Is what I have to deliver clearly described? No, not at all. Do you get a lot of feedback on performance or progress? Or is your work mainly done 'when its done'? Both. Most developers are expected to take responsibility for monitoring their own progress and delivering tasks on time, but there will be feedback on what is delivered, at some stage.
  7. Snapshot Interpolation

    No, because that's not necessary, nor does it make sense. If the object is moving, then your local interpolated data will continually be following those positions, N milliseconds in arrears, where N is the length of the buffer you chose. If the object is not moving, then your local version will catch up to the final position within N milliseconds. There is no need to change the speed of anything.
  8. Snapshot Interpolation

    If you were seeing discontinuities in the position, then you weren't treating the currently interpolated position as the new start position, or you weren't resetting the interpolated time at that point. If you were seeing the object continually stop and start, then your updates were arriving too late to ensure that there was always a future position queued up. One good way to debug this sort of issue is to slow everything down - drop the network send rate to something like once per second, set your update rate at something like 20 or 30 frames per second, scale up all other time values accordingly, and do a lot of logging to see when things change in ways you don't expect. Get it working correctly at the slower speeds, where it's easier to debug any issues. Then ramp up the speed to what you actually need. Also, ensure you understand how to interpolate properly. If your interpolation looks like Lerp(start, end, 0.5) (or any other constant) then that is not truly interpolating linearly between the values over time. If this isn't enough information to help you, then you will probably have to show your snapshot handling and interpolation code.
  9. Unreal Memory Allocation

    I don't think you should expect to get that sort of low level access to the engine's memory management. I suspect that you will either need to use a different JPEG decoder, or find a different way to achieve your aims here (e.g. decompress the images ahead of time, use a video codec, etc)
  10. Snapshot Interpolation

    It's not clear why you didn't try the simplest solution to the original problem: when a new future position comes in from the server, you lerp directly towards that from wherever the client representation is now. In other words, the currently lerped position becomes the 'now, T=0' position and the received position becomes the 'later, T=N' position, where N is some number of milliseconds. The reasoning for using a time in the future is because of the following: if you instantly snap to whatever position the server reports then it's obviously going to look very jerky - so you want to smooth that over some period of time. (Let's call that a 'time buffer' for the purposes of this post.) You interpolate between a start position and a next position. that time buffer effectively adds more latency, because your client has that extra delay before it moves the entity where it needs to be. So you want the buffer to be as short as possible to reduce this. On the other hand, you always want to have a 'next position' queued up in the future or the entity will stop moving while it waits for the next snapshot to come in. (If you think about it, the 'instant snap' situation can be considered a special case where the interpolation is over 0 milliseconds.) So, you choose a time buffer length that is short enough to not add too much extra latency, but long enough that you always have a next position from the server queued up, even in the face of varying message ping/latency (known as 'jitter') Regarding Pong - I think this method would be fine. You have very few entities to update and therefore very low bandwidth requirements, so I'd just suggest sending messages as frequently as possible.
  11. Does a server need a gui?

    The pros and cons are exactly what you'd think they are. e.g. If you have a web interface, the pros are that you get to use your own browser, the cons are that you need to do everything via HTTP and HTML. If you have a console interface, the pros are that it's very simple text in, text out. The cons are that it's just text in, text out. You need to think about what you want from the tool - again, depending entirely on what type of server you're talking about, where you're hosting it, what kind of people need to query it, and decide on the interface you need in order to meet those requirements.
  12. Does a server need a gui?

    Yes, you do typically need some way to query the server. What you need depends on what type of server you're talking about, where you're hosting it, what kind of people need to query it, etc. You could create a specialised client, you could have a console style login (e.g. with SSH), you might have a web interface, etc.
  13. Accounting for lost packets?

    Just to add to what was said above: The 100ms server-side delay seems like the wrong thing to do. Just apply the data when it arrives. If you ever receive a message that is out of order - i.e. you have already handled message 10, but now message 9 arrives - just drop it. A client-side delay however is a useful tool to reduce the effects of varying transmission speeds (aka "jitter"). The idea is usually to treat any received data as applying to some future time, so that you will always have 1 or 2 future states to blend smoothly towards. Note that a fixed number of milliseconds after receipt is probably less optimal than a varying time after receipt, where the variance takes transmission time into account. If each message is stamped with the server's sending time, you can get an idea of which messages are arriving 'early' and which are arriving 'late', and also get a feel for how big the delay needs to be in order to cover this variation. If you're sending snapshots, and sending them less often than you collect them, bear in mind there's no point sending the earlier ones - their information is superceded by the newer data. 50 milliseconds doesn't mean '30 tickrate' unless someone changed the duration of a second recently.
  14. Unreal Learning Unreal C++ development

    When working with UE4, you practically have to use Blueprints. They're not an alternative to code, they're the backbone of the system. Even if you went the hard route and made all your logic in code, you would still almost certainly be interfacing with the Blueprint system for object instantiation, not to mention all the other parts of the visual scripting system. UE4 is not a code framework with some free graphical tools thrown in - it's a full development environment with hooks for you to add code, with C++ almost considered a scripting language. So unfortunately my answer to you is to get used to Blueprints. You can still work from examples but instead of copy and pasting you will need to re-create example Blueprints. This is actually very quick to do given that each node can be created in about 10 seconds and joining 2 nodes together takes under a second. Once you're more comfortable editing Blueprints, you could then practise extending the system - perhaps create a new component and add it to an actor, giving it some UPROPERTY values so you can set them in the editor. Then create a Blueprint-exposed function, and then call that function from within a Blueprint, e.g. from an Event. Maybe give the component a Tick and have it perform some game-loop processing, altering other components. Etc. Once a programmer is very familiar with the Unreal object model, when events are called, and how each part of the system interacts with other parts, it's possible to start converting a lot of the logic away from Blueprints and into code - but nobody is expected to start with a 'code only' approach.
  15. i need learn more about the Game Loop

    Just to take this back to a more fundamental level... At a very basic level, for pretty much any task, computers work like this: Collect input -> Process data based on input -> Display output Lots of tasks require - or at least benefit from - repeating this process so that new input can be processed, and perhaps so the user can view the output and provide different input based on it. Collect input -> Process data based on input -> Display output -> Repeat from start Real-time systems like computer games and simulations work this way, with the additional constraint that they have some sort of hard or soft 'deadline'. In a computer game, the deadlines are typically 'soft' (in that the program doesn't break entirely if they are missed) but they are quite short, e.g. 33ms for a 30fps game or 16ms for a 60fps game. So the loop is executed with this deadline in mind. Note that on personal computers it's impractical to guarantee that each loop iteration takes a precise amount of time, so you normally aim for an arbitrary deadline but be prepared to measure the actual time taken and process with that in mind instead. Collect input for next 16ms -> Process data based on input to cover the next 16ms -> Display output for the next 16ms-> Repeat from start (16ms can be swapped for any other small value, constant or variable) Each of these iterations is generally called a 'frame' because you get one iteration for every one frame rendered to the screen (generally). So, the way you would make an enemy move, in this basic system, is to recognise that a moved enemy is a type of data processing (i.e. the position data changes), and that the movement covers a certain time span (how far can an enemy move in 16ms? Or however long your frame took?) Each time though the loop, you move the enemy that tiny amount, then display the new position on the screen, and repeat.