Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Mar 2005
Offline Last Active Today, 07:11 PM

#5292353 How should I organize Java Classes?

Posted by frob on 18 May 2016 - 04:03 PM

While you are still learning and a beginner, order them in any way that makes sense to you.


Big code bases tend to subdivide code by broad feature areas (simulation, world, physics, assets, math, rendering, network, etc) then subdivide again, sometimes multiple additional layers, by functionality other criteria. 


The exact details are unique to every project. Naming things is a hard problem in computer science.

#5292302 Need mentorship from a veteran programmer

Posted by frob on 18 May 2016 - 10:28 AM

My resume-reading:


After glancing through it, some of your ordering seems strange.  It is hard to figure out exactly what you are looking for.


I see a "skills" section followed by an "education" section with an anticipated graduation date in two years.  That tells me you are a beginner still in school and unlikely to be hired full time.


Then I see a list of work experience at two places, one for 17 months, another for six months overlapping right in the middle, and both overlapping the middle of your schooling.  Since schooling is typically the highest priority, my interpretation is that you've got some side projects under the "Y Games" label and you are trying to make yourself look better, and "X Game Studio" is probably a previous summer internship, but those are guesses.


Then I see your list of self published games, and I'm wondering why you are doing this at all if you've already got a million downloads across four games ... but those were mostly 2013. What happened there, why did you start to succeed and then give up?


Then I look at your awards section, and figure I'm confused at your goals and figure I'd rather pick someone who can communicate more clearly, and advance in the stack of job applications.



Cut the skills section.  Self-assessed skill levels are useless, and keywords are better when attached to where you actually used them. If you feel you must keep them, put them in the bottom and label them "skills keywords" or something.  I've been told by people who advocate for them that the skills keywords section helps with automated resumes scanners.  Personally I don't care for them.


Your self published games section should be FIRST.  That is your strongest evidence that you've got that you can make games. 


Some of the elements in there seem a bit odd.  If you were the sole developer for a game with a half million downloads, why is it "added localization"? Your development points should be basically the same bullet points you used on your product advertisements.  Clean those bullet points up, and use the words that you had listed in the skills section. 


Since you are still in school, education should be SECOND. Your anticipated graduation date of 2017 is going to be your weakest point, and the strongest reason a studio won't hire you. ... at least, not until spring of 2017.  As long as you are going to school full time, I do not expect that you can work full time.


I'd add details to the schooling, indicating the same type of bullet list for topics and projects you have done or found notable.


Your work experience should probably be cleaned up and made honest. I'm guessing your "Y Games" is your own self-publishing stuff. If you have been running it as a business you probably should not list yourself as "game developer" but instead list it as your own company started for the self-published games you've built. Don't start a company and then pretend you were a work-for-hire wage slave at the company. The other looks like a real job, and it seems to fit what a real job does.


The certifications and awards I would cut. It doesn't really help.  The data analytics and AMCAT stuff might help if you are applying for a job at a big bank doing financial analytics, but in the game world they mean practically nothing. The "certificate of recognition" is easy enough to come by that it isn't really a thing to boast about.


I would consider adding an objective line, particularly if you are looking to work in a specific topic of games. It helps HR sort your resume into the right stack, like a gameplay programmer with an emphasis on networked gameplay, or whatever it is you happen to prefer doing most of all.

#5292135 Difference Between 2D Images And Textures?

Posted by frob on 17 May 2016 - 01:57 PM

But as I asked, what about 1080p? I don't think current generation consoles support 4k.


Are you targeting those consoles? Do you have a license with Sony and Microsoft? If you don't, then don't worry about what the consoles are doing.


For the hardware, both XBox One and PS4 are physically capable of generating 4K graphics signals, but AFAIK neither has enabled the mode for developers to use. Netflix wrote their movie viewer to support it whenever it gets supported.


You can make images whatever size you want.  By the time you add all the interesting bits that make them beautiful in today's modern shader-based computing environment you are looking at some really big textures. They are not so big to prohibit their use, but they are still big.


The methods involved for displaying images still work. That has not changed. The images are bigger, but the hardware is also bigger and can handle it.


The problems they solved are no longer typical concerns, that part HAS changed.  

#5292117 Game Prices on Steam: should there be regulation/guidelines?

Posted by frob on 17 May 2016 - 12:57 PM

Artificially specifying price is a dangerous thing. In most real-world scenarios when it happens, there quickly arise some external markets that allow arbitrary prices again (both low and high), and often the overthrow the controlled-cost groups.


is my believe that if a 12 hour RPG with mediocre graphics garners very positive feedback, the price of 5$, maybe even 10$ ... Game length is 25% ... given a 60$ price for an AAA RPG, that would make 15$ a fair price. ... "RPGMaker shovelware" ... 5$ ... Might 10$ be too much given the RPGMaker looks? ... still made at least as much as the same game at 5$, with a better base price for sales and future price reductions. ...


Those are completely arbitrary numbers that discount things like the reality of salaries, paying the game creators, paying the distributors, and making some profit so future games can be made.


If all you are looking at is cost then quality will decline rapidly. If we descend to a world where all games are $0.99, and the distributors take a third, and no developers are permitted to make more, then you will see quality plummet.  A blockbuster game with 10M sales would have a budget that matches today's "shovelware". In order to produce it, you are talking about offshoring all the labor to the cheapest markets in the globe using the lowest cost development houses, which won't be pretty.


Major games cost so much because they take thousands, even tens of thousands of work years to create.  Budgets are in the hundreds of millions of dollars, and the risk involved means all games need to be priced high so the successes can cover the cost of failures and research.  The AAA game costing $70 still needs to sell 10M copies just to break even, let alone making a profit and to start funding future products.


Games that go the "free" route are often ad-based, "freemium" or "pay to win". A small number work on donations. You can only play for a short time before payment is demanded, or players are expected to make in-game purchases. Others the payment is advertisement, effectively you are paying a fraction of a cent for each ad you are shown, and those ads come frequently.  Rare are truly free as in "we give you this game as a gift of our time and efforts, asking nothing in return."

#5292105 Difference Between 2D Images And Textures?

Posted by frob on 17 May 2016 - 12:39 PM

which would be more efficient?


There are many ways to measure efficiency.


For most modern games, it comes down to people.  Do you have the people needed and the time to make the pre-rendered views in many angles? Or do you have the people needed to make a bunch of small parts and have level designers position them in a level editor?


One big reason for the switch to 3D worlds is that animation and modeling are less effort to modify arbitrary views and animations.  If you decide you need a different animation it is not difficult for an animator to adjust a curve in Maya where the curve is used for 36 game characters. It is harder to redraw the 12 frame animation sprites for 36 game characters, meaning 12*36=432 art changes.  It is easy to modify a single texture that gets applied to the object everywhere in the game, than it is to redraw every one of the hundreds or thousands of image with the item, now with the slightly different color.  


A level designer can take a palette of world items and place them in a level rather easily.  They can move items, modify triggered effects, add and delete world objects, and otherwise manipulate their scene easily. For an individually modeled world it means a small data change. For a hand-drawn scene that means an artist drawing everything again, potentially from scratch. 


Even though it takes more processing power to render 3D worlds, it is generally more efficient use of the humans building the game.

#5292083 Difference Between 2D Images And Textures?

Posted by frob on 17 May 2016 - 09:58 AM


For Resident Evil 2 and Final Fantasy 7? Yes, even they likely had more data in models than environments. But that is not a product today, that was hardware and software from 1997, not 2016. The games that worked 20 years ago on the 33 MHz playstation will run just fine on a 4x4GHz machine today.

What if someone were to make new games with prerendered backgrounds today, using current hardware (1080p resolution)?

From time to time, I come across comments from people who really want to see newer games to have prerendered backgrounds because they couldn't get enough of the novelty, so I got curious and wonder about the pros and cons of fully rendered environment vs prerendered.

As I mentioned, I'm fully aware of the part where you can't turn the camera if your character is in a prerendered environment but some people don't care about that.



What about them?  Yes, you can display a 1080p image just fine on modern hardware. You can even go beyond 1080p to whatever the monitor's actual resolution is, and even make bigger ones than that.


Some terms to search for where you mix the pre-rendered or hand-drawn worlds with the 3D characters is "Depth Images", "Layered Depth Images", "LDI", and "Depth Maps".  They were in use by a few games in the 1995 era when 3D games were just starting to be feasible for a few characters but not the whole scene, and were in a bunch of active research papers around 1996-2000 time frame.


Teams I have worked on have used the techniques in many games.  Basically you have artists provided big backgrounds and also a z-buffer for it.  You can use more complex items, like adding in a rendered tree, by layering in several of them, perhaps an animated tree with its depth image layered over a background with its depth image.  Then when your really-3D character runs around with a 2D backdrop, the depth test will clip the 3D character so it looks like they go behind the tables, behind the bushes, behind other objects, even though those objects are rendered as a single 2D image rather than a bunch of 3D objects.

#5291994 Difference Between 2D Images And Textures?

Posted by frob on 16 May 2016 - 11:37 PM

For Resident Evil 2 and Final Fantasy 7? Yes, even they likely had more data in models than environments. But that is not a product today, that was hardware and software from 1997, not 2016. The games that worked 20 years ago on the 33 MHz playstation will run just fine on a 4x4GHz machine today.

#5291876 Difference Between 2D Images And Textures?

Posted by frob on 16 May 2016 - 10:45 AM

Is mipmaps the only difference between textures and images?


As he wrote, it depends on the context.


For some contexts they are the same thing.


For other contexts they refer to data formats. Highly compressed formats like png and jpg need much memory and space to be decoded before going to the video card, some formats such as S3/DXTC and PVRTC are supported directly by different video cards, so some systems call one pictures and the other textures.


For other contexts it is the contents of the data, already mentioned were the presence of mipmaps.



Generally textures are images, you can open them in Photoshop or your other favorite image editor and do with them whatever you will.

#5291667 Which AP (Advanced Placement) course should I take for Game Dev ?

Posted by frob on 15 May 2016 - 12:55 AM

The ones you are interested in.


No specific courses or activities will guarantee you a job in the field.  There is no course that will make employers say "Well they didn't take that class, there is no way we're ever hiring that person!".

#5291654 Indie studio company shares

Posted by frob on 14 May 2016 - 10:06 PM

Generally ownership shares are a small business's most valuable asset.  If the company does well, you'll get a potentially huge value.


There's the old story of the painter who did murals for Facebook's first studio and he was offered either cash or shares; he took shares and at the IPO his shares were worth $200M. More typically if the company does well the shares will be worth $50K, $100K, maybe something on that scale, depending on what shares they offer.  It doesn't happen often, but it does happen.


But if the game studio does terrible -- and most that are not run as careful businesses will fail -- then they are worth nothing.


Most small businesses fail, and in that case the shares won't be worth the paper they're printed on.  


With actual shares rather than options to buy shares, there is a slight if the company is not operating in a business-like manner and mixing business funds with corporate funds, if the company takes on debt, even if you did not guarantee the loans there is a slim chance if they declare bankruptcy that someone might go after you instead.  So make sure you never mingle their money.

#5291648 What does a C++ Programmer need to get the job?

Posted by frob on 14 May 2016 - 08:16 PM

From the description, location is probably your biggest killer.  You need to be local to the game studios, it is rare for a studio to pay to relocate an entry level worker, and if you are willing to move on your own money it is still unlikely they'll interview if you are not local.


Go through the forum FAQ for some ideasto help break in, but being blunt, you need to be where the employers are, or look for a different route to follow your passions.

#5291451 Ways of Buffering Data to be Rendered?

Posted by frob on 13 May 2016 - 01:46 PM

More buffers need more time, which delays the player.  PS2 hit about the limit that players are willing to tolerate, having effectively four buffers before hitting the players is a LONG time, and programmers needed to do quite a lot to keep the games feeling smooth.


The nicest thing I've found so far showed a quickie implementation using macros which I nearly barfed at. .. So I am curious if anybody knows of any *modern* resources about this stuff


The process is not that hard to do and doesn't require any macros or anything.


In both D3D12 and Vulkan it is configured with your swap chain settings, which establishes a queue of buffers. The D3D12 stuff is documented on MSDN, the Vulkan stuff is buried in the specs, search for vkCreateSwapchainKHR to start the search but it basically works the same.



Generally with triple buffering you have the currently displayed buffer, the fully-drawn-but-pending buffer, and the one you are filling up. It provides a slight time buffer beyond what double-buffering gives you, but typically at a cost of an additional ~16 ms lag, putting the game 45-60 ms behind the player's input. Personally I don't think it is worth the benefit, you gain a small amount of processing smoothing at the expense of display lag, but your game might be different.


For competitive network games and twitch games, when you couple it with network lag often that adds another delay the additional buffer lag is often unacceptable to competitive players. They're the same players who will turn off vsync and prefer torn images with the split-second information benefits over the visual quality.

#5291437 when to use concurrency in video games

Posted by frob on 13 May 2016 - 11:53 AM

Concurrency is when two threads of execution can both make progress. Basically, concurrency is the equivalent of "is there more than 1 thread" while parallelism is "can more than 1 thread actually run at the same time." Parallelism is for performance while concurrency is for correctness.


While this can be true, for modern environments it is generally not compelled to be true.  


If I launch four threads to do a task and I have four CPUs on my machine, I generally presume the operating system will put one task on each thread.  But unless I take specific steps to ensure they are mapped that way, the OS has many scheduling options available.


The OS can run them sequentially on a single CPU and swap them out when they do blocking operations, or run them sequentially on multiple CPUs, or it can time-slice them on a single CPU, or time slice them on any number of CPUs. It can move them from one CPU to another CPU mid-execution. It can schedule them among other processes in any way the scheduler chooses.


You can take steps in most systems to require that the OS map a processing thread to a specific CPU, but even then the scheduler won't guarantee they are run simultaneously on different hardware at the same instant except on a small number of real-time operating systems for hardware that doesn't apply here on gamedev.net.


The parts about performance and correctness I feel is nonsense.   Code should always be correct or you are writing bugs.

#5291436 Polymorphism in C

Posted by frob on 13 May 2016 - 11:40 AM

My question is, would you use something like this? My biggest concern is in the implements macro.


Not particularly. Interfaces in C already exists and works well.


What you describe already has an implementation in idiomatic in C, and has existed since the '70s.  


The virtual functions in C++ was a way to automate the process with a standardized seven letter keyword and a standard structure called a vtable that can be made static rather than the more common dynamic structure, but otherwise the practice is common in C and has been for decades. 


Many of the "opaque pointers" in C such as the FILE structure contain a collection of function pointers that are specialized for whatever the underlying file connection happens to be. The functions the programmer calls in the library, fread(), fwrite(), fclose(), and so on, were often implemented as what C++ calls virtual dispatch. Instead of doing the work directly, they call the FILE structure's internal read function, or write function, or close function, and those functions are assigned when fopen() figures out the details of the stream it will be working with.



You might have a CreateFoo that returns a pointer to a FooStruct. You can state that FooStruct contains function pointers for your push, pop, peek, and size operations. Or you might have the FooStruct have a guaranteed member called SmallStack that has a function table with those function pointers in it so you can implement multiple interfaces that way.



Trying not to be too harsh, but it looks like all you did is wrap up some virtual function assignment with a macro specific to your individual functionality. Since everyone is going to write their own version for any new functionality they write, it doesn't seem to be much of a helper.  With idiomatic C you write that in your factory method already, and it is not a difficult or tedious task needing a macro.

#5291336 when to use concurrency in video games

Posted by frob on 12 May 2016 - 03:27 PM

Concurrency and parallelism are different names for basically the same thing.  You want to do multiple things at the same time. Various people have their own individual definitions but they are not standardized. Someone might think the work between tasks must be interrelated or independent. Others will want the tasks to be run by a particular pattern. Some might require that two different pieces of hardware are working at the same time versus an operating system running a task scheduler that could potentially put multiple processes on the same hardware in time slices.  The difference between concurrency and parallelism is a religious war more than anything.





To get to when and the why you need to understand a lot of details first. 


You need to know the machines you are on and their parallel abilities. If you know your machine has three parallel x86 processors, that's important.  If you know your machine has 6 SPE processors each with 6 parallel execution units, that is important too.  You need to know what the hardware looks like.  If you want to do something in parallel that is beyond what your target hardware supports you will get terrible support. If your write code expecting 8 hyperthreaded processors and you only have 2 non-hyperthreaded processes, that is not good. If you are working on parallel code for a graphics card, you need to understand what hardware is available there, instead.  Understand your minimum hardware.


You need to know what problems you are interested in doing in parallel.  Parallel searches, parallel sorts, parallel effects, parallel physics, parallel simulations, you need to understand the problem.  Understanding the problem also includes understanding the size of the problem. A sort of 100 data elements can be quite different from a sort of 100,000 data elements.  Know your problems.


Then you need to break down your processing in your game. You have core work that must get done. You must run your simulation. You must run physics.  You also have optional work that is not necessary but can be nice. Giant particle systems, visual effects, audio effects. They are nice to have, but not critical to your game.


You mentioned AI, but most AI systems should be core work.  You don't want someone on a high-end machine having a more powerful AI than someone on a low power machine. 



Parallel processing for core architecture works great only as far as your minimum spec goes.  If your minimum spec is for two processing threads it must work for two processing threads and any extra threads are a bonus.  If your minimum spec is 6 SPE threads then it must work for that, instead.  The minimum spec is important, and the difference between the minimum spec and the target ideal spec is important.


Once you've identified those, you need to look at algorithms that fit your architecture. Some problems have specific parallel algorithms.  Parallel searching, parallel sorting, parallel independent tasks, these have straightforward parallel algorithms that are well-studied. Other concurrency like asynchronous calls for I/O are also well-studied. But not everything can be concurrent, some algorithms are inherently serial processing like numerical methods used in physics. Once you understand them you can  each physics interaction is inherently serial, but you can do many of them side by side. You need to partition your problem into pieces that can be studied and eventually mapped to a target number of processors.  Then typically you break down communications patterns between them, bundle them into groups of work, and map them to the actual CPUs for work.  But that is more how rather than when.


We are closer to figuring out when.  With this information you can figure out how to partition, agglomerate, and map the work, and you can estimate the kind of speedup you get. That is, you have problems that can be done in parallel either with a superlinear speedup (like parallel search) or with a roughly linear speedup (like compartmentalized work tasks) are great for parallel processing. If your problem can be readily broken down into either one, and the problems are large enough that the effort makes sense, it is a good candidate. 


That leads to asking: how much should it be broken down?  You should break down what you must do into at least as many minimum processing nodes as your system has, but you also can break it into more of them if that makes sense for your architecture.  If you are developing on a game console where your hardware is fixed you know exactly the number of processors you will be mapping to.  You can fine-tune to run on six parallel processors or whatever is in the console box.


That is what makes it tricky for PC development.  If your minimum spec is 2 processing threads but you happen to be running on an Intel 8870 with 18 CPUs (36 HT processors), you'll have far more processing power available but no additional core work to do. You can write algorithms that take advantage of the core work you must do, but once that is done, you'll have time for optional work. If you write code that naturally breaks work down into too many tiny pieces it will add extra overhead.  If you break the work down into hundreds of tiny pieces and only have two workers you add overhead for each tiny piece.  But on the other hand, if you break it down to many pieces and have many workers available they can do the task more quickly.


So after you've figured out all those things, what you must do and what is optional, and you know the hardware you are doing it on, and you know the scope of the problems and what tasks it could be broken down to, you have enough information to make a business decision to answer the question of when to do it. You need to look at the cost of implementing it and the benefit you get from doing it. And you need to look at the costs of not implementing it and the benefits of not implementing it.  If the effort is large and the benefit is small, it probably is not worth it.  If the cost is small but the benefit is big, it makes sense to do it.  But when the cost is big and the benefit is moderate, you need to decide on your own if it is worth while.  When the business decision says yes, or the business decision says no, that is the choice you should make for when to do it or not.