Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Feb 2007
Online Last Active Today, 11:09 PM

#5289991 A question for how game engines build their game code for game logic -_-?

Posted by Hodgman on Today, 07:16 PM

anyway I wonder how q3 vm codes are made of.

The code is available: https://github.com/id-Software/Quake-III-Arena
But these days you'd just use Lua instead of making your own language/VM :P

#5289834 Best game engine?

Posted by Hodgman on Yesterday, 11:50 PM

Without having been given an objective criteria for measuring this bestness metric, I will make a whole bunch of assumptions about your situation and declare: Unity :P

#5289813 Use which kind of generic string?

Posted by Hodgman on Yesterday, 07:20 PM

I avoid ever using wide characters - UTF8 is much better IMHO.


There's no string class in my engine (except GUI as below), because you should never be working with strings :lol:

In some places there's debug-helpers that use const char*'s which are assumed to point to string literals, or other immutable allocations with longer lifetimes than the pointers themselves.


The only place that strings are used is within the GUI stuff, were some 3rd party library decodes UTF8 char streams into a series of glyphs to be rendered, and passes a stream of textured quads back to my renderer. Any char container is suitable for this.

#5289712 Is using the Factory or Builder pattern nessesary?

Posted by Hodgman on Yesterday, 06:09 AM

Yeah, that ^^ :D


Patterns should never be a play-book for writing code. Patterns are, well, patterns in code that just so happen to have been repeatedly reinvented, at which point people recognised the pattern and assigned a name to them to make discussion easier. You should look at lists of patterns more like a traveller's dictionary, and less like a cookbook.


A software engineer should strive to be comparable to a chef who writes cookbooks -- not a machine that only knows how to follow them.

#5289674 Is making game with c possible?

Posted by Hodgman on 01 May 2016 - 10:19 PM

why we always use c++?

We do?

Shhhh you're not part of this clubhouse. Go back to your coffee beans or whatever it is :wink:

#5289667 Use Buffer or Texture, PS or CS for GPU Image Processing?

Posted by Hodgman on 01 May 2016 - 09:49 PM

Interesting :) Well, now you're probing the undefined internal behaviors of your vendor's specific d3d driver logic :lol:

Converting from the initial data format into the optimized "unknown layout" has a cost associated with it -- drivers must make a guess whether they'll pay this cost at all (in order to make later memory accesses perform faster) and if so, at what point they will pay that cost. You've discovered that your driver is deciding to perform this transformation sooner if the user is performing their own memory management, and later if the user asks the driver to perform the memory management... I guess that the driver is making the guess that a placement resource will be longer lived than a driver-managed resource?


BTW, yes, those numbers you posted do seem like some kind of Morton order / z-order curve, possibly unique to your GPU.

#5289666 Question about Open World Survival Game Engines

Posted by Hodgman on 01 May 2016 - 09:42 PM

And most of the time at larger companies it's not actually the programmers who decide what they're working on either (that's like assuming that a McDonalds cook decides on the menu) -- there's someone like AirborneAR who's job is to talk to the customers and find out what they need

It doesn't matter who's doing it, the management, the programmers, the janitor.....lol  The point is, nobody is finding out what the customers want.  Programming skill gets wasted on things the players don't care about, or worse things the players hate.  In the end it all boils down to unhappy customers and less money.

That's not a fact. That's your opinion, formed without knowing how the internals of any game company anywhere in the world actually functions.

You're literally invoking the Dunning-Kruger effect here.

#5289665 I need a Game Artist!

Posted by Hodgman on 01 May 2016 - 09:39 PM

Recruitment posts must be made in the classifieds section: http://www.gamedev.net/classifieds/category/5-hobbyist-projects/

#5289653 Question about Open World Survival Game Engines

Posted by Hodgman on 01 May 2016 - 06:45 PM

The main problem in the industry isn't the programming or the programmer's vision.  It's that the programmers don't actually take the time to find out what the customer wants.

That... is terribly wrong. That is the whole notion of software engineering. Programmers need to find out -EXACTLY- what the customer wants. There's a whole list of procedures that we follow in order to make sure that this does happen. And it's actually -very- effective.

And most of the time at larger companies it's not actually the programmers who decide what they're working on either (that's like assuming that a McDonalds cook decides on the menu) -- there's someone like AirborneAR who's job is to talk to the customers and find out what they need :lol:

#5289645 What is the relationship between area lights and reflections (SSR/local/global)

Posted by Hodgman on 01 May 2016 - 06:08 PM

Compared with the specular one, the diffuse area-lighting is relative simple. It's view-independent

That depends if you're using Lambert BRDF or not :wink:

Does the linearly cosine transform base fit more complex function than uniform polygon? My be it can be used for environment map specular integration

Yeah, in the paper they extend it to include a good approximation for textured polygons.
However, they split the calculations between light intensity (which receives the Blinn-esque skewing at glancing angles) and light colour (which doesn't)... So unfortunately, while this does reproduce the shape of Blinn/GGX/etc BRDF's quite well in general, this accurate reproduction doesn't apply to the way that the texture-colours are blurred.

I have been reading about the various reflection techniques in the Frostbite paper (planar, SSR, local cube map, global cube map) and just when I think I have everything sorted out I see this:
So, to my eyes that looks just like some of the reflection techniques I am studying (especially distance-based roughness in the FB paper).  Does the usage of area lights remove the need for the reflection techniques I mentioned above?  Or are the authors just using these additional techniques and not mentioning it?

At the heart of the rendering equation is the BRDF. This is a function for each surface/pixel/etc, which defines how it reflects light.
Light sources emit light, light bumps into surfaces, the BRDF then says how much is absorbed, how much is reflected, what direction(s) it's reflected, and what kind of colouration occurs.
Typically in games we make our BRDFs by glueing together the Lambert diffuse BRDF and the Blinn-Phong specular BRDF, to create a function that captures a range of surfaces from rough to smooth, and dull to shiny.

When we calculate the reflections that are caused by photos that have directly come from a light source (light->surface->eye), we call it direct lighting. For these, we calculate the irradiance/illuminance - the amount of light arriving at the surface from the light source -- plug that value into the BRDF along with the eye direction, and we calculate the radiance towards the eye.
We can do direct lighting for point lights, spot lights, directional lights, etc -- and recently good techniques have been invented for computing direct lighting from area lights quickly too.

With only direct lighting calculations, shadows are too dark and bumps in a surface have too much contrast. Everything looks very fake.
Traditionally in realtime graphics, we use a hacky solution of an "ambient light", which just adds some constant lighting everywhere to fill out the shadows and stop them from being black.
What we really want though is to calculate the indirect lighting -- this is the photons that have have been emitted from a light source, have bounced off multiple surfaces before reaching the eye (light->surface->...->surface->eye). This is where other techniques that you've been researching come in. Planar reflections, cube-map reflections (a.k.a. environment maps, or nowadays: IBL) and SSR are all ways to capture a second bounce of light. Using these techniques we first compute light->surface->eye as usual, but we store the results into this environment map. Later on, we can compute environment->surface->eye, which gives us a good approximation of light->surface->surface->eye.
Often these techniques are tied to a particular kind of BRDF -- e.g. planar reflections work best for perfect mirrors, or the Phong specular BRDF. Only recently have decent approximations for the Blinn-Phong BRDF been invented for use with cube-map reflections, etc...

#5289561 Why does GLSL use integers for texture fetches?

Posted by Hodgman on 01 May 2016 - 07:17 AM

First up, GL is extremely abstracted from the hardware, and is often internally inconsistent to boot... so the realities of AMD hardware are pretty irrelevant, especially as GLSL is from 2004 and GCN is from 2011.

so, is there any reason the texture coordinates are not unsigned?

As a guess - a lot of software project guidelines actually recommend to avoid using unsigned types completely. Only having a single integer type can make APIs and code simpler, as there's no need to think about what kind of integer you're working with. Similarly, certain languages just have a single 'number' type that encompasses both integers and floats... I'm personally not a fan (I use uint x as a shorthand for assert(x >= 0)), but I understand the argument and have worked on some code-bases that use this guideline.


It's interesting that some of the older system values are unnecessarily signed - e.g. int gl_VertexID -- but some newer ones are unsigned -- e.g. uvec3 gl_NumWorkGroups -- but that this trend is not consistent -- e.g. ivec3 gl_MaxComputeWorkGroupSize... :(


You can always just cast freely between int and uint though.

#5289396 Multithreading exercise - Bouncing particles

Posted by Hodgman on 30 April 2016 - 02:25 AM

What about combining #2 and #3, so that the simulation is multi-threaded and can also overlap with the rendering :)

#5289376 Question about Open World Survival Game Engines

Posted by Hodgman on 29 April 2016 - 10:34 PM

The problem is I don't have a team yet.  And if I randomly assemble a team without choosing the engine first..........I'll get 3 unity guys, 4 unreal engine guys, 2 cryengine guys, and 1 guy who works on some smaller indie engine.

That's really not a problem that you'll have to worry about any time soon, as it relies on the assumption that you'll actually be able to recruit 8 startup-worthy programmers in the first place :P Consider that in the US, the rule of thumb is that a tech-startup needs $10k per team member per month.

Most people cannot afford to work for no pay. The group you'll most likely be able to recruit are students who still live with their parents, as their expenses are minimal and their free time higher than a working professional. However, you can't launch a AAA game with a student team. You also end up with the issues that you're worried about, where they can't work together, can't tolerate other technologies, have unreliable work ethic, and are over-eager to sign up to projects but unlikely to deliver.
At a professional workplace, adding a junior programmer to the team actually increases the amount of time that your project will take, as you need to waste a percentage of one of your senior programmer's time to mentoring them and helping them develop into an intermediate / independent worker.

The people that you need for a start-up are the core staff of these professional teams. The ones that can transmute a graduate programmer into a senior games programmer over the course of a few years.
Those guys are worth $100k a year. For them to give up that kind of salary and gamble on some entrepreneurial adventure they've got to be a an extremely rare kind of crazy.

So your recruitment audience covers the inexperienced and the extremely-rare talented entrepreneur.


The former category will give you all the strife that you're worrying about, and don't actually have the AAA background that you're looking for anyway... So no matter how good your own secret sauce is, your project will also be a flop.

The latter category can actually build you this game... but seeing you're not bringing cash to the table, they can also do it just as much without you. You need to realize that you need these people waaaaaaay more than they need you. Even if your claims of ensuring a hit are 100% true: without you they can build and ship an inferior product, but without them you're stuck. 

In a partnership with people who can actually build your product, you're the one who's value is suspect. Assuming you can actually find AAA game veterans who would be willing to quit their paying jobs and go unpaid for a year or more on the chance of producing a hit game, these people are much more likely to set up their own studio by themselves. Usually new triple-I ("triple-A indie") teams tend to be made up of people who have worked together before -- e.g. 3 people who all leave a AAA studio at the same time, who were able to do a lot of the business planning while in a safe job (while also spending 40 hours a week in the perfect environment to meet other talent) before making the decision to go independent.

Imagine the tables are spun 180º from your proposal. Imagine a group of AAA veterans have just quit Activision and formed a new studio to make a survival horror game in your town. Now imagine that you go and knock on their door, resume in hand, and propose that they bring you on as some kind of consultant to ensure their game will be a hit, and all you want is half the equity in the company, or equity equal to the three founders who will actually be building the product. That's a tough pitch. You would want to have one hell of a sales speech backed up with some amazing data to win them over. With no track record or experience in game design, it's a really hard sell.

That's a tough challenge to take on.

But you're proposing to take on more than that -- you're trying to convince these people to form a new studio in the first place, without having the benefits of networking that comes from working at a large studio, or experience to prove your worth, or money to fund it. That's the above challenge x10.



Soo.... if I were you, I'd put this plan on the backburner for a while and focus on something more achievable: a non-profit venture to test the waters. When there's no money to be made, so many problems fade away.

You're not offering money? You're not making money - it's a hobby / passion project!

People get excited and join the team but don't contribute? No worries, you're not paying them!

Can't figure out a fair way to divide the spoils? The spoils are bragging rights - a credits list. Way less drama!

Can't convince AAA veterans to quit their jobs? Maybe they can spare a few hours on the weekend for a hobby they're interested in.

Can't afford to get the engine you want and all the basic assets, such as worlds / props / animations / sound effects required to boot-strap the project? Make it as a mod for an existing game!


e.g. DayZ started as a free mod for Arma 2, leveraging probably a million dollars worth of assets that existed in that game already. Once the mod became extremely popular, they were able to secure the financial backing required to form a team and produce an actual stand-alone game.

#5289260 Question about Open World Survival Game Engines

Posted by Hodgman on 29 April 2016 - 10:21 AM

If you were trying to design a game like DayZ, WarZ, Rust, or H1Z1 from scratch, which engine would you use?
I understand that it's suggested I put this in "for beginners" but I'm not looking for beginner advice.  I'd like to know what the pros would use.

It's not the most useful question -- what the pro's use is only the right choice for them because of their situation. Do you have a team of a dozen senior engineers who you're paying $100k a year, and a budget of $10M to spend on your game? If not, then the right choice for you will be different to the choices made by "the pros".


Personally, I'd probably build one from scratch specific to these requirements :P
...But I've spent 8 years working as an engine programmer, so I've got a lot of reasons to make that choice. If your team didn't have an experienced engine programmer, it would be a much more crazy choice to make.


If your team all have 5 years experience with Unity, then that would be a sane engine to choose. They're probably able to bend Unity to their will enough to pull off a DayZ.


If you've got experience with Unreal, that would be a good choice.


If you're an experienced Arma modder, then you could copy what DayZ did and start out as an Arma Mod!


A pro team would evaluate all their options and weigh up the pros/cons specific to their situation. One of the biggest weights in this is how much experience their team has with each of the engines. If engine B is slightly more popular in this genre but the team has previously shipped 5 titles using engine A, they're very likely to just continue using engine A and to perform any customization/extension required to make this next game.

#5289252 About Embedding Lua in Android

Posted by Hodgman on 29 April 2016 - 09:59 AM

I'm not an iPhone/Android dev, but --

Closed platforms often don't allow dynamic code generation -- e.g. JIT'ing.

So vanilla Lua should be fine, and LuaJIT with the JIT component disabled should be fine. LuaJIT with JIT enabled *might* be allowed...


I've used Lua on a bunch of PS3/Xb360 games, which have quite a weak PowerPC CPU in them, and performance with LuaJIT (with the JIT feature disabled to keep the gatekeepers happy) was good enough for most of the game to be written in Lua.