Jump to content
  • Advertisement

Aceticon

Member
  • Content Count

    18
  • Joined

  • Last visited

  • Days Won

    1

Aceticon last won the day on September 24

Aceticon had the most liked content!

Community Reputation

27 Neutral

About Aceticon

  • Rank
    Member

Personal Information

  • Interests
    Business
    Design
    DevOps
    Programming

Recent Profile Visitors

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

  1. I started learning OO development ages ago from a Pascal and C background, still in Uni, because I felt my code was disorganized and hard to maintain and there must be a better way to do it. I was but a hobbyist back then, doing small projects (tiny even, if compared to many of the things I did later), but there was already enough frustration that I felt compelled to learn a different style of programming. Even for a one-person hobbyist it's still worth it because it really cuts down on complexity of the whole code allowing a single person to tackle far more complex projects and significantly reduces the things a coder needs to remember (or look up later if forgotten) thus reducing forgetfulness bugs as well as time wasted having to rediscover, from the code, shit one did some months before. I strongly recommend you get the original "Design Patterns" book from the gang of four (not the most recent fashion-following me-too patterns books) and read the first 70 pages (you can ignore the actual patterns if you want). It is quite the intro to the Object Oriented Design Principles and, already 20 years ago, it addressed things like balancing the use of polymorphism with that of delegation.
  2. I've worked about 14 years as a freelancer (contractor) Software Developer in a couple of Industries and far too often I was called in to fix code bases which had grown to be near unmaintainable. Maybe the single biggest nastiest problem I used to find (possibly the most frequent also) was when the work of 3 or 4 "coding artists" over a couple of years had pilled up into a bug-ridden unmaintainable mess of mismatched coding techniques and software design approaches. It didn't really matter if the one, two or even all of those developers was trully gifted - once the next one started doing their "art" their own way on top of a different style (and then the next and the next and the next) the thing quickly became unreadable due to different naming conventions, full of weird bugs due to mismatched assumptions (say, things like one person returning NULL arrays as meaning NOT_FOUND but another doing it by returning zero-size arrays) and vastly harder to grasp and mantain due to the huge number of traps when trying make use of code from different authors with different rules. We're not Artists, at best we're a mix of Craftsman and Engineer - yes, there's room for flair, as long as one still considers the people one works with, those who will pick up our code later or even ourselves in 6 months or 1 years' time when we pick up our own code and go "Oh, shit, I forgot how I did this!". Unsurprisingly it has been my experience that as soon one moves beyond little projects and into anything major, a team of average but trully cooperating developers will outdeliver a team of prima-donnas every day or the week in productivity and quality. (And I say this as having been one such "artist" and "prima-donna" earlier in my career)
  3. It is genuinely interesting that people who don't know how to use OO for the reasons OO exists (reduce the likelyhood of bugs, reduce the amount of information that must be communicated between developers and control complexity by reducing cross-dependencies so that very large projects can be done efficiently, to pick just a few examples) put up their own deeply flawed pseudo-OO strawman as an example "OO" and then proceed to argue that their imaginary construct shows how shit OO is and why people should stop doing it. Even more funny is that this is basically a back-to-spaghetti-code movement that reverses what happened 25 years ago, when people figured out that making everything have access to everything and be able to change everything was spectacularly bad from the point of view of making code that has few bugs and can be maintained and extended. It seems to be a sadly common thing in the Game Development branch of IT that people who have very little knowledge of how to architect large scale solutions and how to make effective and efficient software development processes, like to, from their peak certainty (and ignorance) spot in the Dunning-Krugger curve, opinionate about software architecture concerns without even a mention of things like development process efficiency in aggregate (not just coding speed, something which is the least important part of it), inter and intra-team dependencies, flexibility for maintenability and extendability, bug reduction and bug discovery and removal efficiency. Maybe it's something to do with so many developers in the Industry not having to maintain their own code (game shipped = crap code and design problems solved) and being in average more junior than the rest of the industry so less likely to have seen enough projects in enough different situations to have grown beyond being just coders and to awareness of technical design and architectural concerns in the software development process? I'm a little sad and a little angry that people who have not demonstrated much in the way of wisdom in terms of software development processes, are trying to undo decades of hard learned lessons without even understand why those things are there, a bit like saying "I never had a car accident and don't like wearing a seatbelt, so I want to convince everybody else not to wear seatbelts".
  4. I've been in a couple of industries now, doing Software Development for 20 years, and I've only ever seen an Agile process done properly twice (and as a contractor for most of my career, I've seen a lot of projects in companies big and small). The most common bits that are dropped are having Use Cases / Use Case Prioritization by Uers and User Testing at the end of each sprint. As it so happens, this is what makes the most difference when it comes to delivering something that actually serves user needs and/or business process needs which in turn is what helps the most to spare everybody the time wasting and all-around frustration of "finishing development and delivering" only to find out you actually haven't and need to hack stuff in, often core stuff. Meanwhile, ever since Agile became fashionable, pretty much everybody who thinks they "do Agile" does Stand Up Meetings, usually without understanding what they are meant to deliver to the whole process and thus going at it wrong. Most people don't know what they want until they see it (I've worked in drafting Business Requirements too, and that's my experience) and one - maybe even THE - core benefit of Agile versus Waterfall is that in the former (when done properly) you're quickly iterating with the Users or User Representatives (often Marketing) and converging toward the point that balances what they want, with what they need and with what can be done given the time and technology constraints, whilst in the latter you only find out just how badly mismatched the result is with what it should be at the end of the project. *sigh*
  5. Aceticon

    Buh-bye Windows, hello Linux!

    In my pre-Indie Game Maker career I worked in Investment Banking IT designing and developing mission critical high-performance systems and we used almost entirely Linux. Linux machines are cheaper, more reliable and waste fewer resources as you can run them without a GUI. Even when you have insane uptime requirements one can cluster them and/or setup load-balancing and fallback system designs with enough machines to achieve the reliability of all but the most specialized systems, at a fraction of the price. We had them doing everything from hosting clustered load-balanced in-memory caching systems, message queuing infrastructures and databases to being the building blocks of thousands-sized distributed computing clusters for calculating the value of non-market traded financial assets. Even before that when I was doing other server-side work (such as the server-side of web apps) we overwhelmingly used Linux as it delivers more bang for the buck and for the same hardware is more reliable than Windows. I have more than a decade of server-side and networked systems design and development expertise and have worked with other OSes on the server side (not just MacOS and WIndows but also more obscure and old OSes) and I can't see myself using anything other than Unix for the server side of things, and unless there are some special requirements for insanelly reliable hardward that comes with its own Unix, that would be Linux. So applause for doing this transition and keep on with it as it's well worth it.
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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!
  13. 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.
  14. 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 😛
  15. 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.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!