Jump to content
  • Advertisement

thatguyiam

Member
  • Content count

    8
  • Joined

  • Last visited

Community Reputation

210 Neutral

About thatguyiam

  • Rank
    Newbie

Personal Information

  • Interests
    Art
    Audio
    Business
    Design
    DevOps
    Production
    Programming

Recent Profile Visitors

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

  1. thatguyiam

    Authoritative server

    Don't call yourself stupid, thats the domain of other, pettier people. You'll get there, just keep trying to wrap your head around it and you'll grok it eventually. ps. did you play around with the demo section of gabriel gambettas articles? http://www.gabrielgambetta.com/client-side-prediction-live-demo.html
  2. thatguyiam

    Authoritative server

    Perhaps the following might help. http://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html https://gafferongames.com/ https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Basic_networking
  3. @Nypyren Thanks for your input. I understand the value of TDD, especially in application development. The whole fact you're writing code to satisfy the contract you create with the tests should provide full covereage and result in loosely coupled classes. My main concern with test first is that I've seen quite a few competent developers recently discuss disliking tdd first, even test advocates, as they consider it to impede rapid iteration of an evolving code base. I've seen some discuss data oriented programming and some suggest you should produce tests after writing hthe code merely to catch regressions. But running a suite of unit and integration tests every build would also get annoying, I suppose it would be acceptable in unity as I mainly run in editor and then build when im ready to check some things anyway. I would agree wth srp, It's the most vital of the solid principles. Really the only solid principle I'm not adhering to is dependency inversion, which a lot of people suggest is the most important one, at least following srp/seperation of concerns stuff. But there are other ways to achieve dependency inversion, such as service locator etc. ANy advice on that matter is also appreciated, I want to be good at my craft but also start finishing things for a change. At least in application development I've heard that getting used to tdd makes you faster and cleaner, but I've not really found that (though my experience is limited). I also am aware of the fact that output is traditionally very slow. Mythical man month 10 lines a day stuff (though obviously skewed by working on large bases and removing lines) the talk by Johnathon Blow where he discusses how to achieve great enough output to be able to deliver on your indie games really change my mind on a few things, though I haven't really filled in the blanks yet. I make extensive use of couroutines and when the choesion is high enough I would favour just using a monobehaviour, but I'll take that into consideration. I've read that af ew times lately actually, I'll do my best to avoid monobehaviour and scriptable objects when its unwanted. At the moment I satisfy my dependencies mostly using getcomponent or passing in the inspector. Not especially convenient for designers I iamginge, given the hierarchy thus has specific structures required. I completely avoid Find searches, though they should be fast enough on projects of this scale, I don't use them for other clear reasons. For my current project I'm using a few high level singletons. GameManager, AudioManager, etc. It's not so far been a problem but it could be done better, but I'm not sure what would be better without di. Any more suggestions on methodologies and regression catching strategies is greatly appreciated. ps. it annoys me that empty objects I use for maintaining structure and convenience in the hierarchy have transforms.
  4. For one man indies and small teams, in unity in particular - but general answers are very welcome - what are the most worthwhile development methodologies and architectural patterns worth investing your effort into. I would like to write decent, maintainable and scalable code, but I also want to work fast. In the past I've been bogged down in process, and at the moment for my current project I'm taking inspriation from Johnathon Blow and just not overthinking or optimizing in any sense before its needed. I am certainly getting quicker output but at the same time I realize that as my projects scale I will get be more likely to get bogged down, especially with no testing or other techniques to catch regressions. So avoiding rigid bindings and singletons might be advisable. I've considered dependency injection frameworks / inversion of control containers such as zenject. The code seems ugly to me and I cant see it being a fast process. I've heard mention of essentially using the unity interface for dependency injection, but I'm not sure I comprehend. What process would you recommend? tdd? di? testing after the fact? what are good ways to write clean, modular, scalable code quickly with strategies to catch regressions. Any advice is welcome and appreciated.
  5. thatguyiam

    cmyk vs real world paint mixing

    I will make a quick prototype at some point soon, I wont be able to for a day or two though. I am pretty sure this mechanic can easily be made challenging, possibly too much so, hence the error margin. The fewer colours, animated elements and the more 'dry' space (space lacking wet paint before your own trail) the easier, but the more colours, animated elements and little to no dry space and you're going to have a hard time mixing the colour you want before getting tangled up in your own paint trail. Especially if you make a mess of the colours lighter than your target then it could become impossible to solve without starting over.   The computer would use an appropriate colour space, but users would be presented with the cyan magenta and yellow as primaries and it would be using a subtractive model as in real world paint mixing. A painter of a physical medium should be able to pick up the game and mix colours in a way that's relatively familiar. Painters usually use a colour wheel, though they often for some reason use the inaccurate ryb wheel some use cmy which are more accurate primary colours.    It is essentially just a pain mixing game, where the player needs only knowledge of the colour wheel and is provided some target colour they need to mix. The point it becomes a more complicated challenge is when I forbid them from lifting the brush from the palette, so if they move the brush they paint a trail behind them if their brush is soaked and if they leave their brush in the path of some animated element then even if they don't move the brush then it will become mixed in a potentially undesirable manner.    Essentially it just colour picks from the pixel below, mixes that into the colour on your brush, then paints the pixel it read from with that colour on the brush. so everywhere you drag your brush you adjust the colour on your brush and leave a trail of new colour behind. A trail that can be used for mixing later if needed, or a trail that can become an obstacle if you're not careful. cyan magenta and yellow make sense for a painter in real world colour mixing so it makes sense to me that I should use that as my colour model.  It also seems to make sense to me that you would get rewarded for the correct value range, and similar hue and chroma/saturation etc.  
  6. thatguyiam

    cmyk vs real world paint mixing

    It's nice to hear the perspective of a print artist! I might as well explain the gist of the game so that you guys can help me understand if there would be any problems with using cmyk. Imagine that there is a palette a paint palette in the sense of a physical one, just a screen shaped holder of wet paints. There is a brush that can only move in two dimensions, perhaps because the screen is a physical block, and the player can drag the brush around by using their finger like a magnet, forcing it to follow the players trail. The players objective is to mix a specified colour and get the brush to the exit point with that colour on their brush, perhaps continuing the screen and magnet analogy the exit can be a hole which will free the brush and the pigment on it.  Some key colour will be specified as the colour of the palette itself, all other colours are wet paint. Every pixel will mix into your brush, some volume of pigment will be on your brush, maybe 5 drops of paint on the brush. So if you have a brush saturated with pure yellow hue (0,0,100,0) then you draw your brush over 5 magenta pigments you would get the red hue you'd get by mixing magenta and yellow in equal measure.    So essentially its a path plotting game through colour space. The player would get some score by getting closer to the colour, perhaps imaging the cmyk colour wheel like in this image I found on google images    if the user got withing the right block of colour regardless of whether the colour code is an exact match or not, then they'd get a top score. If they were a shade or tint off they'd maybe get a reduced score but it would still be passable etc. The only problems I can foresee would revolve around ensuring I generate solvable problems, especially in the case of independently animated sprites that would introduce a temporal element. But I can't think of any issues revolving around using cmyk.   ps. I tried to find this programme you mention for reference but googling painter and even painter software didn't help much. Any links? 
  7. thatguyiam

    cmyk vs real world paint mixing

    @JoeJ My game doesn't allow the user to manage any sliders or anything, instead they essentially have a colour mixing brush that mixes each pixel as if wet paint into their brush. So they need to be aware of course that cmyk being a subtractive model will mean that they cant mix white for example. The colour model is abstracted away and all they are presented is some pixels(wet paint) and a brush they can drag through those pixels to mix a target colour. 
  8. thatguyiam

    cmyk vs real world paint mixing

    Well, no, I know that much but I said by brands assuming that within a brand they use a specific recipe that has predictable mixing properties and thus why artists pick a brand and stick with them. I believe the point the fellow was making before was about the fact there are multiple ways you could achieve a pigment that reflects the desires spectrum and so although they look alike when you mix them you will result in potentially different reflected spectrums.  But I don't really need to worry about real world properties, only what people expect to happen, and people expect is more in line with what computers say? you mix an equal proportion of yellow and magenta and you will get a red hue. It might be that two different real world paints due to their real world recipes will mix to a different red hue or reduce shade that hue in some way or something, but that would be counter to what people imagine because people learn these theoretical colour models to begin with? so colour mixing in the real world is more art that science but what would be a problem that would arise from making a game that uses cmyk with imperfect gamut to mix colour.     I realise that computers create an illusion by using rgb, each having a type of cone in the human eye closest to that associated wavelength.  I realise that screens have a limited gamut, and even that the gamut varies by device and technology.  I hope that I'm not missing something here but so far I still can't think of a reason why cmyk would be a bad idea. 
  9. thatguyiam

    cmyk vs real world paint mixing

    From the sounds of it that is something I sort of expected, but I don't want my game to have real world colour mixing issues. From what you're saying the mental model rby or cmyk an artist might use will mix in a relatively unpredictable manner due to the fact that pigments reduce the colour spectrum reflected by an object or pigment in the real world.  Given that my game is just about mixing colour with an ideal subtractive model, and knowing that the screen can only produce a limited gamut, is there any real issue with just using cmyk? The idea of my game is that you will pick up pigment from pixels on the screen as you move your brush around trying to mix a target colour only being expected to come within a fair error margin of that colour.  Can you help me identify some of the issues that will arise? Is there a better model than cmyk? Is this problem considerably harder or less achievable than I imagine? 
  10. Hello, I have become tempted to work on a colour mixing game but I am unfamiliar with the problem domain. My first thoughts were to use cmyk but I recall having read something somewhere at sometime suggesting there were issues with using cmyk to simulate real world paint mixing. Is this just due to the fact it's an imperfect model, and that pain pigments vary by brand ever so slightly?    What am I missing?  Your guidance is appreciated.  ps. I placed it in this subforum because it seemed the most appropriate place to ask ...if I was mistaken I apologise.   
  11. thatguyiam

    Unity UNet - the problem of determinism

    That's actually what I had in mind, I would calculate the bullets server side and render them client side, the hitbox will give a bit of leeway for the player anyway and the differences will be minuscule anyway, I don't see it as being as big a problem as the player becoming desynced from the server and being snapped back due to reconciliation. I'm glad you've suggested this because I was especially worried about the possibility of having to work out bullets with fixed point, and from my understanding fixed point is typically more expensive.  I'm not sure if I could live with it or not because I'm not sure about how severe it would be. I imagine it will be really quite heavy so I probably would favour letting players render the bullets themselves and having the server be authoritative about it, it will be fast paced anyway so players probably won't notice minor issues and since I will adjust the hitboxes in their favour, all the more so.    There won't really be walls, though so even more reason to favour the cheaper solution. I would like to be able to collide bullets and for that, I think I'd probably use a quadtree. I reckon that would be "good enough" I would also like players to be able to use other players as "walls" so I suppose there are some objects that could be used for cover, but I don't think hiding behind a player but still getting shot would be as much of an experience breaking thing as being in a completely different room and getting done in!    My main issue is with applying displacement forces and if I do all that with floating point it could lead to some very different results across hardware and software architectures. If anything needs to be as close to exact as possible it would have to be the player's location, due to input and due to the effects of forces. But there will be only a handful of players compared to hundreds of bullets, so in that respect, I probably could suffer control latency.   Generally, the physics of the displacement and falling need to be consistent across platform or reconciliation will force clients to adjust their models to the servers, and due to being a fairly frequent operation, the experience would be unusable.    It would also be nice if I had the option of adding in a replay feature at a later date if there was demand for it. I think, again with that people won't be as frustrated if the bullet storms are fractions of a pixel off but if their avatar is on the wrong side of the world they will probably be frustrated. My main goal is to create a fun and engaging experience so I'm worried about this likelihood!    ps. I hope I'm understanding this right but by control latency you mean the latency that would be introduced as a result of the more computationally expensive fixed point/ deterministic calculations compared to the hardware optimised floating point?    Thanks for all your help so far, I feel like I'm getting closer to answering some of those frustrating questions that are floating around my mind! 
  12. thatguyiam

    Unity UNet - the problem of determinism

    C# also supports generated-code targets these days (similar to ngen but not at install time? Something like that.)   I'll have to read up on this, it seems interesting.   I'm not very familiar with fixed point code, especially optimised fixed point for a fast-paced multiplayer... But I have managed to source an awful lot of content to read so I'm sure I'll pick something up...   I remember stumbling onto this a long time ago, I never really read it but perhaps I should.    My game is sort of a tame bullet hell, the physics and collision could probably be pretty simple. Some gravity, some displacement forces, it's 2d so could possibly even get away with simple aabb for collision on the players and quadtree for the bullets.  The main issue here is my lack of familiarity with network programming. Since it's primarily targeting smart devices I wouldn't want to use up too much expensive mobile data. The game will probably be hosted on either Amazon Web Services or Microsoft Azure. Preferably I would be able to just send batched inputs , use prediction for the players own character, interpolate between most recent positions for all else and still remain consistent with the approved server state.  I'm not sure I would want to go the only solution I so far understand, which would be to make the players authoritative over their own positions... I'm not keen on that idea but if I did that and did some sanity checks server side, then it wouldn't matter that the clients own model might calculate differently than the server, as it would be approved by the server and everyone else would just interpolate between the two points the server said were believable.    It does seem to make it far easier to cheat, though... and I'm extremely ignorant about this topic so I could be missing a much neater solution. In fact, that might not even be a solution at all for all I know, which is troublesome.    It's late where I am so I'm going off for now, thanks for your help so far and I'll check back tomorrow to see if anyone else has some suggestions or if you yourself have responded.    Much appreciated and goodnight :-)
  13. thatguyiam

    Unity UNet - the problem of determinism

      Yes, I know this but from the very start I'm targeting multiple architectures so I can't have predictable results. Actually that's something I'm not certain of, since c# compiles to bytecode is it even possible to consistently get the deterministic results on the same machine across builds?   I thought that might be the case, which is a bit troublesome. Can you suggest some reading and some code samples that might help me learn how to write deterministic network code?  I already have a few resources open but so far they haven't been enough help that I have wrapped my head around the whole issue.     I don't know how to deal with it though, that's the main problem I think. I will use an authoritative server but I don't want to have to transmit the complete state for everything, but if I use client side prediction as I plan then when the server sends back saying I'm not where I should be the player will be snapped back. Unless I perhaps allowed an error margin that would prevent such minuscule desync issues... but then over time my characters state on my prediction will be sufficiently different that a snap back would occur anyway, so all I've achieved is a reduction in the snapping?   If I didn't force the players prediction to adjust to the server simulation then the game would become unplayable for everyone... and if I don't do client-side prediction/ entity interpolation then it will be even worse... 
  14. Hello, I am new to network stuff but I have a project in mind and I have become concerned about the problem of desynchronization, due to the difficulty in predicting the results of floating point calculations from client to client. I will be using a client-server architecture , client-side prediction and entity interpolation and server reconciliation. My main concerns are related to making deterministic calculations on each client when the results of floating points can't be guaranteed.    I am aware of packages like Decimal but those seem too slow to solve the concerns.  Perhaps my worries are misguided, I would greatly appreciate if someone in the know could help me understand which features of unity I should ignore, how I should go about solving the problem and if it is even as much of an issue as I worry, perhaps for small, fast-paced matches as I envision for my game it won't be such a major issue if there is a tiny discrepancy. I appreciate that it would be more likely to grow into a much more  problematic situation were it a p2p real time strategy or something, as there would be potentially hundreds of actions and tiny discrepancies could accumulate.    Am I overthinking this? If not what should I do? My project will mainly target smart-phones and tablets, but also desktop and potentially webgl 2, I would prefer to sort players by input type rather than platform. I can't have easily-deterministic floating point so the results will vary. Would I have to implement my own physics and collisions in fixed point? Does unity offer a solution to this that I am just not aware of ?        I don't want to have to have players snapping back all the time because the server decides the predicted state is incorrect, it would be quite troublesome. 
  • 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!