Jump to content

  • Log In with Google      Sign In   
  • Create Account

frob

Member Since 12 Mar 2005
Offline Last Active Yesterday, 08:27 PM

#5298482 Dear people who actually work at videogame industry:

Posted by frob on Yesterday, 07:57 PM

I have no idea about your location in the world.  Perhaps in your city university education is not a necessity.  Perhaps in your region few people finish their primary education.  But in that case, it means people in your area are not technically advanced.

 

When I review applications -- which I do frequently -- nearly every person has at least a bachelors degree. Some have links to a portfolio, many list their hobby projects.

 

You do not compete in a vacuum.  If there are other people who look better on paper or on the job application your portfolio will never be looked at.  

 

There are some people in the forum who live in regions where formal education is less important, or who did not get college degrees.  If you happen to live in one of those places where college or university studies are not required you should still finish your regular school education. 

 

 

 

I was thinking in leaving school, and then read books, forums and take classes of digital arts online, with books and forums like this, with the internet maybe i can learn more, and learn what i really want to, what is going to actually be useful in my future.

 

That is a terrible idea. Stay in school. Get the most education you reasonably are able. 

 

Stay in school AND read books AND read forums AND read technical papers.  If possible for you in your region, also go to university or college studies.

 

While you are reading material online and in books, talk to your school teachers and ask them to help explain topics as you encounter them.  

 

Take advantage of the opportunity you have been given.




#5298412 Best way to showcase C++ programming experience

Posted by frob on Yesterday, 11:08 AM

Yes, apply anyway for entry level work.  Don't apply for the senior roles they are advertising.

 

Most entry level positions are not advertised since there is no need.  A little word-of-mouth discussion to key people and plenty of qualified applicants apply, plus unsolicited applications are always coming in.  They may drop the word at some nearby college campuses and online groups, but there is no need to pay for advertising for the position due to high applicant interest. 

 

It is better for you to work your social network if you can, find the friends or friends-of-friends who work in the industry and ask them about jobs and send in your application.  Even so, continue to submit your application to every company nearby.

 

You didn't state your location on the globe, but you might also consider moving to a game development hub if you aren't there already.  Companies usually do not pay to relocate entry level workers. Location is one of the first things observed when reviewing a job application.




#5298342 Have I been aged out of the industry? And where else can I go?

Posted by frob on Yesterday, 01:05 AM

No kidding - I over-simplified and omitted a large part of my intelligence-gathering operatus to avoid confusing you or boring you. ... The only help I need is to hack the minds of humanity so I can get past their prejudices. But very few psychologists are willing to share their knowledge in an offensive capacity.

 
With that, I take it we're all done with the "aged out of the game industry" and "looking for other fields where game development skills are useful" topics.
 

 

 

If the discussion here is even remotely similar to how you act in the workplace, I can assure you it isn't your age or software development skills that are keeping you unemployed.  Please seek professional help.




#5298338 Is using one the switch statement better then using multiple if statements?

Posted by frob on Yesterday, 12:39 AM

... Duff's device ...

 

Duff's Device was an interesting optimization about 40 years ago when different conditions existed.

 

On today's hardware it introduces essentially the worst case pipeline stall.  All major compilers take steps to detect the thing and replace it with alternatives that fit better with today's hardware.

 

All optimizations depend on details of the system. Last year's details are different from this year's details, and next year's details will be different again.  

 

Many optimizations that were once fast now introduce problems.  Duff's Device, the XOR Swap, they're terrible on deeply pipelined processors.  Fancy memory tricks are terrible on new processors, while memory is faster than it used to be every new chip is relatively more faster, meaning memory access is more and more costly as time goes on. Calculating trig functions like sin() and cos() are faster than lookup tables thanks to relative speed differences, though the reverse was true on most processors about 15 years ago. Decrementing loops to continue when equal to zero hasn't been an optimization on x86 for two decades. Low memory addresses are no longer faster than higher ones and haven't been for nearly three decades. Writing to shared objects in continuous pools is absolutely terrible for cache coherency on multi-core processors, and hasn't been viable for speedups since the 1970s.  Manually marking every little function for inline compilation is usually a terrible decision in modern C and C++, it is typically better to provide information to the compiler and allow it to decide what works best with the target caches and memory performance for the target architecture.  (That last one is so bad most compilers now completely ignore the inline keyword unless you force them to.) Etc., etc., etc.

 

Yet all these little tips and tricks are still found in books and occasionally taught online as though they were gospel truth for modern software performance, never mentioning that the conditions that made them true have changed, and now they slow processing down.

 

... what prevents you from (options)? Too much more conforming or not? If not, why?  I am not bashing switch as is, I am just saying that an impotent c++ feature recomendation based on performace blasphemy is too ridiculous?

 

The performance difference in the general case is so small it doesn't really matter in the real world. 

 

If a programmer is in a situation where the performance of this condition is critical --- and I honestly cannot fathom such a case --- then they would probably not be using C++ switch statements for the code.

 

The famous quote applies here:  Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. -- Donald Knuth

 

This is part of those enormous amounts of time.

 

Much has been written about this quote but it withstands the test of time.  Don't do stupid things that introduce inefficiences, don't introduce pessimizations, but almost always this is something you shouldn't bother with. If you have additional knowledge that the compiler doesn't, such as knowing that a specific path is highly likely, then do something that uses the knowledge. In that rare case, do something.  If you know you can avoid nearly all the work with a simple test, then do the simple test.  But don't worry about it.

 

The best advice I've heard for optimization is:  

 

Beginner: Don't optimize your code.  

Advanced: Don't optimize your code yet.

Expert: Don't optimize your code until you have proven with instrumentation that it needs improvement, then verify and document the changes for those who come after.

 

 

The vast majority of the time it just doesn't matter.  Your compiler is smart, and can find smart ways to optimize this.  The compiler may use jump tables, or a branching if/else tree, or a series of conditionals, or even a binary search. Next year's compiler may have additional techniques available and it may do something different.  Profile-guided optimizations may allow your compiler to recognize even more advanced things. ... But none of that typically matters to the programmer.  

 

I'm not saying make intentionally bad code, don't write bad code if you can help it. If you know something specific is a concern then write the simple version with a comment of //TODO: This is probably slow, measure it with a profiler someday.

 

If a person has chosen to use C++ then they need to let the C++ compiler do its job. That job includes optimizing the code.  Let your compiler do its job.

 

 

If (1) you are using C++ for you code and (2) you are concerned about the performance of a single switch statement, one of those two things is a flaw. Most likely you can find far bigger performance gains in other areas of the code by swapping out algorithms or fixing up data structures and access patterns.  Alternatively, if the performance is absolutely critical in this section and the implementation of a switch statement is paramount, then the development should be done in assembly language where you can control it rather than c++.

 

 

And since we're off track enough at this point, let's get back to the original with all these debates in place:

 

 

 

(1) I am currently learning C++ and I was just wondering if using the switch statement is better and/or a better and more efficient way of using multiple if statements?

(2) Is there advantages to using multiple if statements?

(3) If there is what are they?

(4)Are switch statements good in game development?
 
(1) Switch statements are a tool in the language.  There are many tools available for alternating behavior. See the above discussion. The efficiency of a switch statement is not typically a performance concern in the real world.
 
(2) If a switch would have worked but the programmer choose a series of if statements, that decision would be about specific control. If you have specific knowledge for a situation against it, a switch statement may not be the best solution. When the problem naturally fits a switch statement, use a switch statement. Note that a compiler might rearrange your if statements according to the optimization rules as allowed by C++, and might even implement it exactly the same as it would have implemented a switch statement.  Again, this is not typically a performance concern in the real world.
 
(3) There are many others options. Jump tables, function pointer tables, branching if/else trees, binary searches, conditional operations, virtual functions, hand-coded assembly with code tuned for specific processors, to name a few. Various options fit different problems more naturally than others. The compiler is programmed with all kinds of details about the target processor and the optimizer can pick and choose between many different options when it encounters a switch statement.  Exactly how it is implemented internally doesn't matter, that's an abstraction in c++.  However, this situation is not typically a performance concern in the real world.  
 
(4) Yes, switch statements are used all the time in game development.  As are branching is/else trees, jump tables, virtual functions, and the rest.  You should generally use the tool that your problem suggests as a solution.  In C++, if you've got a bunch of potential routes of code and the decision of which branch is based on an integer value, then a switch statement is a natural fit.  If there are other similar situations, those may be a better fit.  If instead of branching based on an integer value you want to select behavior based on the type of an object, a virtual function is probably a better fit.  If instead you are branching based on the value in a string, a series of if/else branches may be better.  If you have some other situation, a different solution may be a more natural fit for it.
 



#5298250 Best way to showcase C++ programming experience

Posted by frob on 27 June 2016 - 09:51 AM

Game studios know that recent graduates have very little experience they can showcase.

 

If you don't have a big collection of demos and showpieces, provide what you have got. If you've had an active github account, consider showing it.  If you've got some finished coursework, consider showing it.  It will not be impressive, but it will be something that provides evidence that you can program.

 

Apply for jobs now, work your social network now.  Don't put it off until working through an additional certification.  You just finished a certification, your computer science degree.




#5298063 Have I been aged out of the industry? And where else can I go?

Posted by frob on 25 June 2016 - 07:52 PM

There are far more former game developers than present-day game developers. 

 

Also as I wrote a big list on the first page of the discussion, there are many fields that absolutely love former game developers on their teams.  Even if you feel 'aged out' of games, there are other industries where the skills directly transfer.  Military simulations are probably the biggest of those.

 

Many of those fields pay better than game studios will pay by default, as most game studios struggle to pay employees.

 

 

 

junior web developer at 40?

 

You don't need to apply to a job as a junior web developer. I don't know if you wrote that as hyperbole or because you honestly believe you need to restart your career from the beginning.  There is no need to reset your career.  If you've got two decades of experience you can apply the experience in other jobs.  Lateral career moves take some thought, but are done quite often.




#5297904 Have I been aged out of the industry? And where else can I go?

Posted by frob on 24 June 2016 - 01:15 PM

I'm interested in getting a paycheck in an environment where I won't be immediately ostracized.
...
What I was hoping for was that someone who had additionally more out-of-industry experience could tell me what area of the computer programming field in general my skills would fit best in if I needed to change direction, and what other skills I would need if I chose to follow that path.
 
You may not be able to tell me where I should go, buy maybe you can tell me where I can go, where my skills are most wanted - and then I can choose from there.

 

Given these further updates, I STRONGLY recommend reading (or re-reading) a recent edition of the book "What Color Is Your Parachute?".  Three specific things in the book I'll call out:  First, the book talks about how to effectively engage in a "non-traditional job hunt", since the current idea of a "traditional job hunt" is generally to spam out resumes. These are more important as you get older since they help you overcome age discrimination and other factors. Second, the book has a segment called the Flower Diagram, where you follow some guides to figure out what transferrable skills you have, but also aspect about employers that you really want. Figuring out your passions is important, it turns your career into much more than just a paycheck.  Third, the book discusses ways to transition your career from one industry to another, or from one job title to another. This sounds like something you want to do as well.

 

Working through the exercises in the flower diagram takes some time, but it really is worth it to identify where your passions are, and then letting them serve as a guide to your future.
 
As for non-game areas that use game developer skills, there are quite a few:
 
* Military simulations (many former co-workers are working as government contractors for simulating all kinds of environments)
* Medical imaging (many co-workers moved to the industry, including some using Unity and LibGDX for medical displays. Medical scans use lots of images and volumetric data but need programmers who understand how to work with the data)  
* Related media like TV and movies (I spent nearly two years working on TV news display software)
* Education and training software (I spent a few years on interactive meeting polling software)
* Graphics editors and tools (several former co-workers now working for Autodesk and for Adobe)
* Property remodeling visualization or architecture visualization, such as "bring in your kitchen measurements and we'll make a simulated remodeled kitchen".
* Oil companies want visualizations and simulations, I was once surprised to learn they relied heavily on former game developers and game technologies.
* Chemical companies run all kinds of scientific simulations, but executives and marketers want interactive mini-game style simulations based on the scientist results.
* Law firms often contract out certain presentations for game-like visualizations of crime scenes and walkthroughs of virtual environments.
* etc. 
 
There are many industries that use the same tools and technologies as games.  There are industries that use the same techniques but different tools.  There are even the industries that create the tools and equipment games use.
 
If you work through the "What Color Is Your Parachute?" book flower diagram you may discover there are many industries that are not games but still lie within your "fields of fascination" as the book calls them, or as some of us around here call it, following your passions.  You may discover that while you like simulations and AI, you may also enjoy something else like auto engines, then realize you might look for a job in future auto technology.
 
I know someone who loved digital signal processing and mechanical data processing, and he was also interested in construction.  He ended up co-creating products where heavy chains are dragged across a bridge by a vehicle and hammers hit the structure at various locations. The sound, vibrations, and other digital signals are processed to analyze structural integrity of the bridge, discover weak points, and provide all kinds of engineering data.  He took the things he enjoyed and was passionate about and built it into a successful product.
 
You write your main thing is to get a paycheck and I completely understand that.  The paycheck is the primary reason for working, and if the paychecks stop I immediately begin looking for new paychecks.  But there is also your life energy and your passion and your life fulfillment, these are important too.




#5297778 Have I been aged out of the industry? And where else can I go?

Posted by frob on 23 June 2016 - 09:23 PM

Ravyne just hit the ones I was thinking.

 

Unfortunately yes, age discrimination is rampant.  Some people interpret "culture fit" as "young white male", instead of "intelligent, creative, and passionate".

 

The good news for you is that studios with age discrimination also tend to be terrible places to work, with late hours, hard crunch, and poor work-life balance. Working at places where everyone has a spouse and children tends to mellow out the worst offenders, and encourage people to think about things like time off, insurance plans, retirement plans, and other benefits.

 

 

USE YOUR CONTACTS.  You've got 10 years in the industry so you know people. Hopefully you've taken the opportunity to grab email addresses, facebook contacts, linkedin recommendations, and more. Spam your facebook account, google groups, linkdin account, and any social networks where your former co-workers work. 

 

The number I've heard from recruiters, business web sites, and books like "What Color Is Your Parachute?" is that one hour of working your social network is worth about ten hours of spamming resumes and blind applications. That doesn't mean don't send in applications that way, but when you have a choice between the two prefer the more effective one.  You have a much higher chance of finding a job.  For me with a recent job change and far more than a decade of experience, I made a single facebook post with "Hey former game co-workers, I need a new job!" and within the day I had several interviews lined up.  This works best if you live in a game development hub.

 

Make your resume specific for the individual job, and let them know you are flexible.  If they're looking for a senior software engineer, adjust it for that.  If they're looking for a team lead, adjust it for that.  If they're looking for tools or gameplay, or build system, customize it.

 

The higher up you look, the smaller the pyramid. If you're focusing on senior positions and lead positions there will be fewer openings.  Consider taking a lower job, and trimming your resume accordingly.  Also, consider using recruiters.  

 

While some places in the world have a custom of including every job you ever had in your life, other places just look for relevant stuff.  Generally it is okay to let stuff drop off the end, and omit the graduation year if you want. Rename it to "relevant experience" if you wish.




#5297763 Hundreds of timers...

Posted by frob on 23 June 2016 - 06:36 PM

5000 integer compares? If they're in a linear array, and on an x86 chip (with its out-of-order core and clock-speed multiplied integer comparisons) you could probably reach about 6 per clock cycle, or under 300 nanoseconds.

Implement it cleanly and you'll spend more time in cache misses looking up a single item in a spatial grid than you will traversing that entire collection linearly.

If the collection uses something like a priority queue kept inside a ring buffer, the time drops to just checking the first few elements in a linear array, in practice meaning just about the cost required to load the first few elements into memory.  It is about as close to a zero-cost as you can get with actual work.




#5297731 Theory: programming a Combo system

Posted by frob on 23 June 2016 - 01:32 PM

Many different ways.

 

The first in my mind is to leverage an event broadcasting system, if you've got one.  On completing a move, broadcast the event.  Have a listener pick up the event and the time.  If there is a previous event in recent time, call it a combo.  

 

So maybe require that two consecutive damage events within 100ms are considered part of a combo.

 

Pseudocode:

 

OnDamageEventListener(DamageEvent e) {

  if( e.timestamp <= previous.timestamp + ComboTime

&& e.damageSource == previous.damageSource

&& e.damageTarget == previous.damageTarget)

{

  ++comboCount;

  BroadcastEvent( event_combo, comboCount, e);

}

else

{

  comboCount = 0;

}

 previous = e;

}




#5297662 What maximum amount of flood fill can a dijkstra handle?

Posted by frob on 22 June 2016 - 11:47 PM

Dijkstra's minimum path between a pair of points routine is the famous algorithm you are probably writing about, he had several major algorithms so you might mean another.

The single pair algorithm potentially takes quite a lot of memory when implemented naively, on the order of N^3 sounds correct. Most games use the A* (A star) algorithm, which is Dijkstra's single pair shortest path algorithm plus a small heuristic value to speed up the search a bit, at the cost of potentially not being optimal.

Since you mention "flood fill", I'm guessing you are talking about an all-pairs shortest path algorithm? Those exist, but are much more memory intensive for anything other than just storing a binary reachable status. Using the single pair shortest path over and over for all pairs is a bit extreme.

You might also mean having a path that follows a space filling curve across an entire board. That can take as much resources as your path requires, entirely dependent on your implementation.

Finally, there are many implementations of these algorithms online, some quite efficient and others are terribly inefficient. Can you share what implementation you are following?


#5297628 Should all gameobjects be stored in the same data structure?

Posted by frob on 22 June 2016 - 02:26 PM

You're in Python, which makes some of this a little less obvious than languages like C or C++.

 

Generally it is best to have a single instance of the objects in one location.  Everywhere else have references to those objects. 

 

In Python with reference counted objects, it can be trickier because the actual instance is hidden from you, items become a strong reference.

 

Python complicates matters if you don't understand object lifetimes, as what seems like creating new references is sometimes actually creating new instances, and sometimes when you think you create a new instance you get a shared instance with a reference count. 

 

> Is it okay to have two data structures that contain the same objects for different purposes?

 

Yes, if you are talking about references to the object.  I may have the 'real' collection of game objects in an object pool.  Then I have a spatial container that uses references to those real objects.  When building a return value of nearby items, I build a container and put references to the real objects into that, then return the container. I may have a container that uses references to the items in a player's inventory, or for the minimap display, or for something else.

 

Those should generally be shared through references as Python does with reference-counted instances.  They should not be new, duplicated instances broken off from the original.

 

The rest of the questions have answers that fall from that.

 

> have another data structure containing all the path blockers/targets indexed by their location?

 

Sure, you can have a collection that references the objects if you want. Or you can have a collection that contains their indexes, although that is slightly more risky in the event that indexes change.

 

This is up to how you implement your pathfinding.  You may have logic that allows for multiple conditions.  Some games build pathfinding and account for temporary/movable objects on the path by ignoring them, only computing paths based on immovable objects. When the character approaches a movable object they might request the movable thing get out of their way if that is an option, or might find a short path around the object. Or in some games the two units may co-exist in the same cell or move through each other or squeeze by their friendly companions. Or in some games, perhaps you've got a tank with a move request through enemy soldiers, it will just drive over them. 

 

In other games with more complex routines, moving units are considered differently so they will automatically handle choke points during path finding. They may identify a narrow gap and be programmed to handle it with more logic, following each other if going the same direction, queueing up and taking turns from each direction, or other more complex behavior.

 

You may have a pathfinding routine that accepts several different flags, searches only for immovable objects, or does something else. 

 

The task of pathfinding over a navigation mesh is relatively easy compared to the work of navigating the mesh with all the other moving parts on the map.

 

> should I just have one structure that can serve multiple purposes?

 

Probably not, the structure often provides information by its nature. However, you might decide that for whatever it is you are doing the one structure provides what you need in many different cases.  With good abstractions a collection of items can be generic enough to be reused everywhere.  I mentioned SOLID above.  Alberth gave an application of SOLID by telling you to work with abstract actions rather than specific values. Those still apply.




#5297484 Peer-to-peer Massive Multiplayer Game

Posted by frob on 21 June 2016 - 01:49 PM

 

The architecture itself is really just a small modification of a star topology


Based on my experience with distributed systems and networking, that sounds a lot like "just a little bit pregnant" to me.

 

 

In simpler terms:  It either is, or it is not.

 

EVERYONE talks with the hub, and only with the hub, then that is a star.

 

If connections are talking to each other, that is not a star.  It is more likely a partial mesh, which is not a star.  Even if most communications happen to go through the hub, it is still not a star. 

 

If you modify a star topology and make it something other than a star topology, it stops being a star topology.  Continuing to call a non-star topology a star is the wrong name.  Hence the analogy to "slightly pregnant". You either ARE or your ARE NOT. There are no modifications that change that fact.  You either are a star topology or you are not.




#5297465 Should all gameobjects be stored in the same data structure?

Posted by frob on 21 June 2016 - 10:31 AM

Would it be appropriate to define some gameobject features based on what list it is in? Is this a valid approach?

 

It can be, depending on your game.

 

You mentioned lists for enemies, another for game items, another for immovable items.  This lets you search whatever collections you are interested in.  If you're interested in the map, search the immovable map items and the movable map items.  If you are interested in enemies on the map, you can search that.  If you are interested in all of them, search all of them.

 

Given that you already have that arrangement of multiple lists, it seems an alternate approach would be a selective search function.  You might have a method that searches both immovable and movable map points.  You might have another method, or a different parameter set, that lets you find all visible/discovered items. You might have another method that lets you find both friendly and enemy units.

 

Assuming you are adhering to SOLID principles, with dependency inversion creating some common interfaces for all the different types of things you need an it for should not be too difficult.  As long as your items are true substitutes for each other and you don't waste time finding the actual concrete type, then adding a value that shows what kind of thing it is would be fine. If they're not true substitutes for each other then they probably shouldn't be merged into a single collection.




#5297416 Should all gameobjects be stored in the same data structure?

Posted by frob on 21 June 2016 - 01:00 AM

Looks like the multiple containers concern is well handled.

I'm not using any spatial partitioning scheme currently for collision detection, but I may want to implement this in the future.


Depends on the game. Iterating through a linear collection is an extremely fast operation, and tends to be cache friendly. Jumping around objects that are blocked off by spatial positions is not cache friendly.

Spatial partitions can be useful for some things, such as "find me any objects within 3 spaces of here". But until you have many thousand objects you won't see any performance boost over a direct data traversal. Once you do reach that point, you'll want your spatial tree to only reference the other objects rather than be their primary container, so you only need to hop around in memory infrequently.




PARTNERS