Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

  • Days Won


Aceticon last won the day on September 24

Aceticon had the most liked content!

Community Reputation

22 Neutral

About Aceticon

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

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

  1. Just to add to what others have said, you probably want to learn a bit about making assets yourself even if you go down the route of mostly buying them or working with artists, so that you have a bit more knowledge on what a good asset is when selecting assets or artists. For example, there are tons of humanoid models out there which aren't rigged and lacking thinks like extra loops in the right places so that when animated joins bend in a way that looks realistic. Similarly, a lot of models out there were sculpted and have too many vertices for use in games. So try Blender out, and if you're using Unity then they have Pro Builder free in the latest version which lets you do block modelling from within the framework, which is usually much easier to do than what you can do in Blender and often works fine for low-poly games.
  2. My solution is for w as the x-coordinate of the right side and h as the y-coordinate of the top (as I listed in the requirements at the top of the solution). However, now that you pointed it out it does sound a lot like w stands for "width" and h for "height", i which case yours is the correct solution Its a much easier to understand problem if one just thinks left, right, top and bottom
  3. Assuming that all coordinates are zero or positive values, your axis are such that x increases to the right and y increases going up, and in your members x is left, y is bottom, w is right and h is top then: x = MAX(x1, x2) y = MAX(y1, y2) w = MIN(w1, w2) h = MIN(h1, h2) if x >= w or y >= h then the rectangles did not intersect.
  4. Well, in the real world the diffuse light shinning on an object is sun + sky + light reflected and refracted from the surrounding objects. Because of just how much higher the light intensity coming from the sun is than that coming from the sky (If I remember it correctly, something like 100x stronger), that light bouncing from surrounding objects itself is mostly sun light altered by those objects' characteristics (reflected, refracted and such). However, no GI there (yet) so no fancy pantsy "shadows next to the yellow pillar are yellowed because of the light bouncing off the pillar is yellow" stuff and such, so how about simplifying by just considering that your ambient light is made up of a bounced-sunlight component plus a sky-illumination one, while (and this is the important bit) maintaining a realistic ratio of light intensity between both? So instead of using the 6, 9, 15 (overwhelmingly blue and darker) color value that your ambient color equation is producing, have you considered making your ambient light ever so slightly blue (start with 15, 15, 16) to reflect just how disproportionally much of the ambient light is bounced sun-light rather than sky-illumination? After all, in your shader the color value of a pixel which maps to an area of an object in the shadow will roughly be black + (that ambient color * albedo) thus any of-white in that color will stand out a lot, whilst in the areas illuminated directly by your sun most of the color will come from the refraction of that sun light off the object so the of-white in the ambient color stands out much less. If you look at your Unreal example, the non-shadow areas do have a slight blue tint too, so a similar effect is probably happening there.
  5. The whole point of PBR is to do Physically (that's what that P stands for) Realistic Illumination, so what you just did was make the entire space around everything emit blue light, something impossible in the real world. If you had GI you would naturally use the skybox to provide the environmental illumination (which is what replaces ambient light in PBR), just like people do in 3D renders, as real world illumination comes mostly from the sky and surrounding surfaces. From a PBR point of view you're already hacking it by using ambient light, so your solution if you really want to make the shadows look as you expect without doing it in a proper PBR way is to hack it further, IMHO.
  6. Aceticon

    Starting a new 1v1 fighting game

    Whilst I've started on my own in this industry about a year ago and can't really give you a recipe for success (anybody that can. let me know ;)), I can give you my analysis of looking at myself playing, being an Old Seadog of a Gamer Who Has Seen it All. - Which characters are fun to play? I mean, if you were playing (or example) the "American war here female soldier" and it was all kick-kick-punch-kick, would it be any fun? Would it be any more fun to kick-kick-punch-kick with an "ancient Egyptian inspired scarecrow"? Consider going from the bottom up: look at your character ideas and consider what kind of cool moves could fit each of them (and maybe some sort of unique mechanic for extra powerful moves). Maybe have a mini story (even if cheesy, cheey is good) for who they are and why they're there kicking the shit out of each other. (There's a wonderful analysis out there - sorry, lost the link - of why No Man's Sky sucks as a game because it has no story to drive the player, as analysed by an English Literature major). So look at them from the point of view of the player controlling the character and making it do its think and consider what kind of cool moves make sense for them, what kind of upsides and downsides can there reasonably be part of said character in playing terms and what would make people want to play one sometimes but a different ones some other times. Then look at them in terms of playing pairs - i.e. is there a character which would be so overpowering as being always dominant or there's always some kind of challenge on both sides for any fighting pair. Coming from that angle you'll probably trim down your choices naturally AND end up with a cool story that might even inform you on the graphical design of characters and scenery. PS: Just a suggestion. I might have no idea what I'm talking about. Take it with a pinch.
  7. Aceticon

    Entity Component Systems and Data Oriented Design

    It was one of my greatest frustrations when I moved from the wider Tech Startup world and Corporate Systems into Game Development with Unity that it was actually a step backwards in terms of the Framework helping with good Object Oriented Designed compared to things like J2EE frameworks in Java or even the Google Android API. 😕 It is possible to push some good OO practices onto it mostly by means of delegation, but not easy as the core structure on top of which your code sits is one massive Flat Injection Of Concerns Engine were exposed data is either a public variable (thus breaking containment) or ends up serialized and deserialized when it's not supposed to. I can only imagine how bad it must be for a Junior Developer still learning OO who is doing it in this anti-OO structure. So it's pretty interesting that they've finally introduced something closer to the Model-View-Controller Design model and separated Data from Visualization. Now if they created the proper slots (rather than we having to hack it) were we can hang the data in the natural hierarchy of game-wide-data, player-data, and game-level-data, in addition to the current visual-object-data, that would be great. Soz if I sound a bit frustrated!
  8. Assuming you're doing it in proper OO, there are design patterns such as Adaptor and Facade which you might want to read about. In my experience, backfitting a decoupling layer is usually a significantly larger PITA than doing things with that in mind from the beginning. You might want to start by analysing which functionaliy you use from the library and how (at it's most basic, just make a list of objects used and methods called), which is boring from the point of view of a coder but does end up paying itself by sparing you some back-and-forth time wasting that happens when one dives into coding too early and then suddenly discovers something that screws up one's approach. At the same time, you might want to set up some kind of unit testing around the whole thing so that you can test the before and after refactoring results and make sure they're the same. Also, COMMIT EVERYTHING into your source control before you start refactoring! (probably needs not be said, but hey: no harm done) Beware of implicit and non-visible dependencies, such as things like how NULLs are handled in one library vs the other, expectations in your code of getting back empty strings or empty arrays signifying NOT FOUND and now getting back nulls (or vice-versa), how objects are supposed to be initialized or not and other such expectations in the code which are not visible from simply the method signatures. Keep in mind that if your code is tightly coupled to the library, this might be a much vaster task than you expect. That analysis job at the beginning will give you a much better grasp on the size of the task and let you see if for some parts it's less work to redo them from scratch than refactor them.
  9. Aceticon

    Programming and Higher Mathematics

    For some years, I worked in mission critical distributed computing systems in Investment Banks. At one point I was responsible for the system side (the code for the distributed computing engine, data gathering and such) of a system that ran on a farm of 2000 machines and did distributed calculations of the value of custom Financial Instruments (specifically, Over The Counter Stock Derivatives) which were held in the books of Traders in a whole department of the bank (total values adding up to many millions, even billions of dollars). Each node in our farm had a calculation engine which implementated the formulas that calculated the estimated values of those financial instruments (as they where not in an open market so their values had to be estimated), said calculation engines done and maintained by a team of specialists called Quants, which were more Mathematicians than Programmers. One day, just before the crash of 2008,our whole computing farm went down. We would restart it and after a while all nodes would die. It turns out, the calculation engine in the nodes was crashing and taking down the rest of the program. The night before, the value of Bear Stearns stock had gone down massively and the whole company became worth something like 1 dollar (not 1 dollar per-stock, 1 dollar for ALL stocks), so I suggested that maybe some of the calculations used the first order derivative of the price of that stock, which because of the extremely fast and big change was basically infinity, thus causing either a crash directly or if used in the wrong side of a division would cause a divide-by-zero error which would crash the calculation engine (which was a C++ library). The Quants checked it and I was right. Their reason for not having put an exception check around the code that used that 1st order derivative was "we never thought this would happen" (Yes, the very same excuse for most of the massive losses in the 2008 crash). So THIS is what Advanced Financials is and this is also my example of how a programmer who wasn't even on the Mathematical heavy side, by knowing Mathematics saved the whole team a lot of time and headaches and possibly saved the banks millions (as that calculation engine was mission critical and it being down meant that the Traders would not know what was the right price to sell or buy certain things). That said, the bank is was working with, Lehman Brothers, went bankrupt a week later, so it didn't really matter all that much in the end 😛
  10. Aceticon

    Programming and Higher Mathematics

    THIS is the core WHY, I think. If one wants to be no more than a monkey-coder making code from detailed specifications (and I've worked with a lot of people like that), then you can get away with a limited knowledge of Maths. If one wants to actually look at a real world problem/need and be able to specify, design and code the system which addresses that problem/need, then you need all the tools you can get in your toolbox, especially Maths as for most things it has a tool or other that works or at least helps.
  11. Aceticon

    Programming and Higher Mathematics

    Well, from my perspective of 20 years which was mostly outside Game development: Computer programs are Logic constructs which is actually Maths. In fact, having gone to Uni into Physics, my very first Programming course was showing us how it could be done entirely as a Maths construct. Trignometry is essential in Games programming as a lot of what ends up as code are 2D and 3D calculations. Probability, Statistics and Queue Theory are essential in figuring out things like how much load peak load can be on a system or things like the likelyhood of system failure given the likelyhood of failure of each redundant sub-system. By analysing these things one can make appropriate choices when designing a system in terms of how much error margin to add or how much effort to devote to dealing with recovering from certain kinds of failures. A number of other Maths elements go into things like Neural Networks or Genetic Algortithms. Other complex AI techniques might involve Monte Carlo Simulations, which is a Numerical Analysis thing. Further Numerical Analysis might be used in things like finding formulas that fit desired points so that you create a continous curve that matches a set of desired waypoints. Or at least in understanding how Bezier curves work. Things like derivatives and integrals are used in simulating physical processes (so, in Game making also) as well as things like understanding how a discontinuity in the first order derivative on a surface curve would cause artifacts in specular illumination (usefull if for example you're doing mesh generation). If you're doing games which are simulations you probably want to know about positive and negative feedback loops and maybe some of the basic stuff that relates to Economics. The maths that relates to Economics is also used in things like multiplayer games which have some kind of Economy. For certain kinds of mesh/texture generation it might help to at least know what Chaos Theory is. Beyond that, if you're doing Tech in business domains other than Games, certain disciplines often turn out to be useful in understanding the Business and making software for it (just like Trignometry and Calculus, for example, are very important in most Game development but not at all in most other programming areas). More in general, to me personally it always worked well to be able to understand WHY and HOW things works rather than merely use other people's code, and for that it helps to have a deep groundwork of understanding in, amongst other things, Maths.
  12. Well, if you main concern is responsiveness there are two main ways you can go about it: You design the looting UI too look like its doing stuff whilst actually waiting for the backend. The funny thing about people is that the feeling of responsiveness is much more coupled to "seeing things happen" (anything, really) than it is to "conclusion of task". Given the round times involved in the backend (shouldn't be more that a few tenths of second) you can cover the delay with some fancy frontend animations designed to look as part of the experience. Optimize the backend speed. For example bring the decision of "who gets it" to as close to the frontend as possible (so in this case, to the game server), put some smarts in the Master Server and have it handles the low probability cases of multiple Game Servers attributing the same loot to different people - for example, by cloning the loot. (Remember, these are low likelihood events so the solutions for such data change collisions need not be perfect, just good enough that players don't get frustrated). Other optimizations can be on the placement in the network of the master server vs the Game Servers (i.e. minimize the network hops between them and the master) or improving database access patterns (such as hplus0603's suggestion of doing all the work in memory and updating the DB with a separate process),
  13. *** I completely replied to the wrong question before, sorry *** On your question: A couple of thoughts: - You adjust your data structure to make it a non-issue, for example by making the loot only looteable by the player which has opened the container or landed the killing blow on the monster. - Make the outer server take the decision and communicate it back to the client AND to the main server in parallel. If you're worried about failures of comms between the outer server and the main one, add redundancy in the middle (say, message queuing). - If multiple people can take the same loot, accept that somewhere in your design there will need to be some kind of "quirk" as there must always be a cutoff point were the system decides that "this belongs to player A or to player B". This might be the unfairness that you described (i.e. closest is most likely to win). some kind of different unfairness (player with fastest Internet Connection wins) or it might be a non-unfair but wierd system where sometimes BOTH get the loot (i.e. if outer servers made the decision and two decided "it's my player's" in parallel, then the master server might clone the loot and give it to both). - You might leave the decision to the outer servers but implement a system where the client only gets a confirmation that the player got the loot once the master server has been informed and confirmed which one gets it. This works by the master server receiving a request from an outer server and then waiting for a certain time (likely less than a second) to check if any other requests come from other outer servers for the same loot. If not, the loot gets given, if so, then both requests get compared using the OUTER server timestamps for fairness and the earlier one gets it. This not being money or something like that which is not supposed to be lost or created due to a bug, I would probably go with the "clone the loot" option if this unfairness really worried me or leave it unfair (it the time difference are usually less that 200ms, which a typical human reaction time), as the last option whilst impeccably fair is a PITA to implement, has further implications (such as keep the outer server clocks in synch) and thus is probably not worth the work.
  • 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!