Hodgman

Moderators
  • Content count

    14239
  • Joined

  • Last visited

  • Days Won

    4

Hodgman last won the day on June 27

Hodgman had the most liked content!

Community Reputation

51087 Excellent

2 Followers

About Hodgman

  • Rank
    Moderator - APIs & Tools

Personal Information

Social

  • Twitter
    @BrookeHodgman
  • Github
    hodgman

Recent Profile Visitors

64057 profile views
  1. Yeah Lua is great, but very unpalatable to begin with when coming from a C background... When passing pointers from C to Lua and back, you can either pass them as a light-userdata, which is equivalent to a void*, or use a heavy-userdata which allows you to attach a metatable that you can use for runtime type validation. Unless you actually want to write code in the prototype paradigm, you'll likely just use metatables to implement an OO-style class system and then forget about them. When writing OO style code, you can use one of two main styles: className.method( self, args... ) or self:method( args... ) If you use the first style, then it will be closer to a statically typed language, as you're constantly writing the name of the class that you expect an object to be. It's also quite a bit faster (on vanilla Lua / non-LuaJIT -- JIT'ing makes them both just as fast really).... but the first style is ugly Inside your methods, you can check the metatable of each object (including self) to see if it really is of the expected type -- the details of this depend on how you choose to implement classes/OO! You can also check whether any of your arguments are nil (which will happen if it's called with too few arguments) or whether any spurious extra arguments were passed or not. You could use a pre-processor to strip out these debug assertions from shipping builds if required. Getting a good debugger is also very useful. I'm using "tilde" at the moment, but am looking to switch to something else soon.... If you want to support runtime script reloading, then that will also affect the way you write your code. In C, you might write some code like: foo = foo ? foo : 42; // if foo is zero, set to 42 In Lua, when creating a new global table, you might write: foo = {} But when reloading your script, this will assign foo to a new table (leaving some of your code potentially still referencing the old table!). So, you can instead write: foo = foo or {} And then if you reload the code, the foo table will not be recreated.
  2. Optimization

    Profile your code regularly. Budget out your frametime -- e.g. if you want to run at 60Hz, that's 16.67ms per frame, so divide that up between different game systems and then make sure you stay within your budgets. Run / test / measure on your minimum spec hardware. Optimize for the worst case, don't worry about the average or best case. The average case behavior of an algorithm doesn't matter if the worst case will blow your performance budgets. In managed languages (e.g. C#), do not generate garbage for the GC to pick up. GC time is highly variable, so the only way to keep it in line is to not produce any garbage during gameplay - don't create/destroy temporary objects, cache them and reuse them again and again.
  3. Nothing HAS to be global. A good use for globals is extremely rare. If multiple functions need to access an object, use pointers/references. Or when you're calling into your C++ from another language (e.g. when writing a plugin) and want to make damn sure that you don't accidentally try to stack-unwind across a language boundary and crash the host application, instead of translating the error into a host-understandable error form.
  4. They do in OpenGL, and you can in D3D if you like. If you had a lot of procedurally generated content then you might prefer it, perhaps...
  5. C++

    It's a violation of OO theory, not the OOP constructs of C++ in practice. OO theory says that any algorithm that works on a base class, must also work on all derived types. You can break these rules in theory, but that means that you can't really claim to be writing "OO" code, even though you're using OOP language features... Another C++-specific solution would be to use private (implementation) inheritance, which sidesteps the theoretical rules that come with public (interface) inheritance, as implementation inheritance doesn't exist in the theory. That is confusing... however it doesn't happen for me on MSVC2015... Also I get: std::is_copy_assignable<NonCopiableA>::value == false std::is_trivially_copy_assignable<NonCopiableA>::value == false std::is_copy_constructible<NonCopiableA>::value == false std::is_trivially_copy_constructible<NonCopiableA>::value == false Can you post a compilable example and note the line that causes the compile error?
  6. Ideally shaders would always be precompiled. Shaders are pre-compiled for a particular target / shader model -- e.g. SM5 shaders for FEATURE_LEVEL_11. If you try to load these on FEATURE_LEVEL_10, they won't work... So, you have to precompile your shaders once for each target that you wish to support. e.g. if you want to support D3D10, D3D10.1 and D3D11 hardware, then compile your shaders for SM4, SM4.1 and SM5, and then load the correct set of precompiled shaders at runtime.
  7. I don't play many games because I don't have any free time any more When I do manage to find a spare hour, I usually play a multiplayer game online with a friend to slightly count towards my social needs too... My tastes have definitely changed - I used to love extremely long / slow single player games where you might waste an hour simply planning what to do next, (fallout, elder scrolls, flashpoint/arma campaigns, original R6, etc), but now prefer refined repayable multiplayer modes that are easy to fit a known experience into a particular block of time (starcraft, arma multiplayer, R6 siege, etc).
  8. C++

    A derived class can never renege on features provided by the base class; doing so is an violation of OO's LSP rule, so this approach is invalid. OO would force you to use composition instead of inheritance here. Make your own class from scratch which contains a vector within the private implementation details.
  9. One annoying thing with humanoid animation blends is that they can look terrible if you don't take knowledge of foot-falls into account. You (almost) always want a left foot-fall to follow a right foot-fall, but arbitrary blending doesn't account for this. This results in the character sliding and shuffling their feet around during blends, instead of taking believable steps. So, you need all the foot-falls in your animation data to be annotated so you can categorise the animation frames into the left/right foot phases. When blending out of an animation that's, say, 75% of the way from a left foot-fall to a right foot-fall, you should start the new animation at the same phase (after the first left foot-fall, and 75% of the way to the next right foot-fall). You might also be blending in some IK to make sure that feet actually rest on the ground properly, and some animations may delegate some parts of the skeleton to IK completely. e.g. the turn-right-after-left-step animation might ask the IK system to keep the left foot glued to the floor while animating the rest of the character...
  10. Loads of companies still use their own custom engines. Note that this isn't "not using an engine" - they're often just as big and complex as something like Unreal or Unity Unity and Unreal are both horribly bloated and aren't hard to beat in any specific area. Unreal's strength is that it covers so many areas that it's impossible to catch up. Unreal is also interesting that they give out the source these days, but many parts are simply too complicated to customise in a way that would typically be required, or doing so would lock you out of upgrading.... e.g. I've never worked on two games that have used identical rendering pipelines, but doing these changes in Unreal, while technically possible, isn't really feasible. Instead you just use what you're given. Unreal is cheap noe for hobbyists, but it's still just as expensive as ever for big games. I'm guessing that Nintendo has switched from internal tech to Unreal because- 1) management died and was refreshed 2) they've no experience writing modern engines at all. All they've ever done has been ad-hoc game-specific tricks and hardware that's totally different to the mainstream. 3) they're finally making games for other people's hardware now too.
  11. In order for them to benefit, you've actually got to bring something of value to the table, such as experience/competency/talent/money that they don't already have. An idea by itself doesn't have any value at all, so is the same as coming to the table empty handed. That's a fact that might take a while to become evident... If you want to give it to someone so they can make it, just go ahead and write about your ideas. If they're amazing, and people like them, maybe they'll end up inspiring something similar in a real product one day.
  12. Are you spinning on the query results immediately, or do you wait a frame before trying to get the results?
  13. If it's a common pattern, then make "i just destroyed myself" a core part of the signalling system, so your loop can terminate correctly.
  14. Mine are all pretty relevant to my interests - I imagine this is down to how well Google has profiled you, rather than a GDN based selection?
  15. Just, FWIW... Tech startups in the US typically budget $10k per staff member, per month. A typical AAA game or MMO probably has at an absolute minimum, 1000 man-months of work behind it.... which means you'd need $10M in funding. Any new venture that can deliver that much money from a tiny bit of investment as a sure thing, is a scam... It's probably not a good idea to try to make an MMORPG as a new and unknown company as your first product. This is just one reason why you might feel that your idea is unique -- other people may have had the same idea before, but didn't have the $100,000,000 required to actually create it... Another reason is that a lot of ideas are literally incompatible with a game being an MMORPG... The speed of light between East Coast USA and South East Asia is a hard limit -- better technology isn't going to reduce that constraint. A 5v5 FPS game doesn't care about geography like this, but an MMORPG must (or cease being massive). Game design is all about working within realistic constraints and cutting back ideas as much as possible to actually produce something good at all. You need to find a compatible mix of technology and game rules, and then condense it into something fun.