Kylotan

Moderator
  • Content count

    14140
  • Joined

  • Last visited

  • Days Won

    47

Kylotan last won the day on December 28 2017

Kylotan had the most liked content!

Community Reputation

10171 Excellent

About Kylotan

  • Rank
    Moderator - Scripting Languages and Game Mods

Personal Information

Social

  • Steam
    kylotan
  1. There's only 1 video linked above. You need to get into the habit of using debug output to track down what is happening. There should be no doubt over whether the robot is repeatedly stopping and starting - you need to be able to prove that. Adding Debug.Log calls which are output when you start or stop the animation or change its values would help here. You can also have animation events call back into your code. You can also try running the game at a slower speed to help you debug it. Setting Time.timeScale to a small value like 0.1 or 0.25 makes it easier to see when things are happening and to watch log messages as they go by.
  2. Production in the AAA scene

    Once a project has been selected (depending on who holds the purse strings), management will usually select some sort of broad resource plan for the whole project, deciding how many programmers/designers/artists/etc will work on the project, and at which stages in the project lifetime. The project is often divided up into milestones, which act as checkpoints to verify that the project is being delivered as expected and on time. Less formal projects might have a handful of milestones, whereas big publisher-funded projects often have a formal milestone delivery process where the build is explicitly handed over every so often (monthly, or six-weekly, or quarterly, etc) to be assessed. Each milestone typically has a bunch of intended 'deliverables' - they are ideally working features, but can also be assets that may or may not yet be integrated into a feature. And there can be different expectations for the state of a deliverable (e.g. "prototype", "working", "finished", etc). The actual state of those deliverables, relative to what was promised, dictates whether the milestone is 'passed' or 'failed'. In the latter case the team is usually expected to fix up those failed deliverables before the next milestone is handed over. If you keep failing milestones, the publisher may terminate the project, as they lose confidence in your ability to complete it. Scheduling within a milestone is usually done via some sort of agile planning process. With a given set of deliverables in mind, the heads of each department and the project management team ("producers") come up with a list of prioritised tasks and decide who to allocate them to. Those people receive the task descriptions and implement them. The day-to-day work of each person depends entirely on their job and their task. There may be a 'daily standup' meeting or Scrum where people briefly discuss what they're working on and ask for help if they're stuck. Beyond that, they communicate via conversation/meetings/email/Slack to resolve ambiguities and discuss details. The rest of the time, they're probably at their computer, executing their current task by creating code, art, whatever.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. C++ Savegame headers?

    The first way makes a lot more sense.
  8. 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.
  9. 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.
  10. 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.
  11. 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)
  12. 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.
  13. 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.
  14. 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.
  15. 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.