Jump to content

  • Log In with Google      Sign In   
  • Create Account

frob

Member Since 12 Mar 2005
Offline Last Active Today, 03:05 AM

Posts I've Made

In Topic: Should I pursue game Development?

Today, 02:24 AM

You mention programming and design disciplines. You also mention playing games.
 
Playing games and making games are quite different.  Much like there is a difference between eating delicious food and working every day as a master chef, a difference between enjoying a concert one evening and working every day as a concert violinist, a difference between driving high performance cars and working every day as an automobile engineer or as an auto mechanic.
 
For programming, you dropped out after one programming class.  That doesn't bode particularly well.  Games are software, they're a specific kind of high performance software. Consequently, game programmers should generally love making software. Do you spend your time reading about programming languages and algorithms? Do you enjoy studying the differences between different data structure performance, or learning about various sort algorithms and their fundamental differences? Or do you enjoy working with data formats as they move between systems, or compilers, or tools? Do you enjoy working with the math of 3D worlds, comfortable with matrix and vector manipulation, using linear algebra to find how things move in 3D space, and using calculus to turn motion and continuous change into formulas and algorithms? Do you spend time talking with other people about source code, about programming issues, and about the craft? If so then you might be a great game programmer.
 
For design, you mention a little more. It is far more than just appreciating and lamenting as you describe; any concertgoer can appreciate and lament a concert, any driver can appreciate or lament a vehicle, any diner can appreciate or lament a meal.

Do you study how game mechanics work? Do you look critically at games that are fun and figure out exactly why they are fun? Do you break down the fun components and figure out why they are fun, and explore what happens when they are changed, or used in isolation, or used in combination with other mechanics?  On the flip side, do you look at mechanics that are not fun, and figure out why they are not fun? Do you figure out what happens to those non-fun mechanics when they are changed, used in isolation, or used in combination with other mechanics?  You mention you played Magic the Gathering, but is that all you did? Do you modify existing rule sets? Did you build your own cards, printing cards that fit within the game universe but modify it in material ways? Do you then experiment with those rules? What about other games, such as building your own D&D campaign with your own custom unique objects and unique monsters that fit in to the existing game?  Or modifying rules to tabletop games like Settlers of Catan, modifying the board markers, or introducing your own resource types and rules for them? For game levels, do you analyze why decisions are made, why powerups are placed where they are instead of somewhere else, why Mario has all the platforms in the locations they are placed, what specific item each Portal level introduces and why it is placed at that location and not earlier or later?  Do you have a broad base of knowledge and real life world experiences? Outside of games, do you have a wide range of stories and ideas you want to share with others? Are you skilled at communicating these ideas to other people, even when those ideas are different from your own? If so then you might be a great designer.
 
 

Am I being selfish entertaining this idea? In your opinion how good are my chances of making any money with my current plan? If it does not seem like a good way to break into the industry, is there a better way?

 
 
 
If those are your passions then by all means follow them. Many people enjoy these things, and it works well for a career.   Just like some people enjoy the study of aircraft and have great careers working for Boeing or Airbus; some people enjoy working with food and have great careers in culinary arts; some people enjoy getting their hands greasy and working with engine parts and have great careers in automobile repair and maintenance. 
 
Unfortunately there are sometimes people who don't realize that making things is different from enjoying things.  There are people who enjoy movies and dream about living a movie star life, but they have no inclination to study the craft of acting. There are people who enjoy music and dream about living as a rock star but have no inclination to study the craft of making music on stage.  And there are people who enjoy playing games and dream about having built amazing new games, but have no inclination to study the craft of building games.  They may even push hard to get the job they think they want, only to discover after years of effort that it really isn't their passion, and they want to do something different.
 
If you love it and it is your passion, then great.  In that case do what it takes to make your passion your career. You mention you already have a philosophy degree. That may work for a game designer, but for a programmer it probably means getting a degree related to the field you want. If you are serious about the career it means moving to a location with game studios.  

 

If you love it but don't make it your day job, that is also an option. As a hobby you are unlikely to ever make any serious money from it even if you devote thousands of hours to the process. Your hobby game is unlikely to be seen by millions of people, unlikely even to be seen by hundreds of people. Even so, people do that, and everybody needs hobbies. 

 

If you love playing games but aren't really passionate about making games, that is fine too. People who love making games will make them for you to play, just like people who love designing aircraft will make your jets, and people who love designing automobiles will make your next vehicle. Those who create them will get their satisfaction knowing you enjoy using them.


In Topic: Unit Testing multimedia classes

Today, 01:54 AM

I am developing a library, which provides facilities for cross-platform game development. My way of testing 'till now is/was like that: Does it display (or play the sound) as I expected, then it works. How would one test for these kind of results? I.e. how do I know, if I have a window actually being displayed on the screen?


There is a great book called XUnit Test Patterns, also available as a web site although I'm on mobile right now so no hyperlink. Edit: Now enhanced with hyperlink, go read, the reference has about 1000 printed pages covering everything you ever wanted to know about unit tests plus some other kinds of tests.

Unit tests for multimedia depend on the unit being tested.

If you would call a system to give it data, pass in a mock object and known data and verify that it makes the right call with the right data. If you expect to give the object a StreamingVideoPin object called svp, then you expect svp->drawframe(data) with specific data, provide a mock object and validate the results.

You may provide a mock object that ensures a windowing system has a window object as part of a unit test, but creating an actual window is part of an integration test if it is automated by screen scraping or similar, or a manual test to see if there is a window on the display.

You may have an audio stream and provide a mock object that represents the audio player as part of a unit test, but ensuring the sound is hitting the audio hardware is an integration test or a manual test to see if the human hears the sound.

Generally for automated tests everything except the final presentation can be covered by unit tests. That last layer of actual hardware doing the hardware jobs doesn't get unit tests, but may have integration tests if you really want it, or you can wait until QA or people complain. That last layer is usually a really tiny shim, and if you've done everything well then everything up until that layer has full automated tests behind it.


Finally, remember the actual results of unit tests isn't to ensure the results are correct, but to ensure the results do not change. Consequently tests usually are best for data being transformed into other data, where the tests validate the transformation. Next best tests are data in motion, where you can write tests that verify data moves through the pipe as expected.


In Topic: Google Analytics shows avg. session duration, sometimes 00:00:00 sometimes true

Yesterday, 11:48 PM

You didn't include a link to your source code so all we can do is guess.

Generally missing session length values can happen when you miss a step.  Double-check everything, starting here, then here, then here. Double-check that your application manifest is correct, that your resource files include the app_tracker.xml file properly configured, Also make sure your program actually sends events from time to time since duration is based on the time between the first event and the last event.  Remember that putting code in finalizers isn't guaranteed to be called, so don't put your telemetry tracker code there.  Make sure the DryRun flag is set to false.

 

Although it doesn't sound like the problem you are having, you should know that their telemetry is designed to lose data occasionally.  They try to upload all the data but sometimes for various reasons they don't.  Maybe their phone died, or cell signal went away, or wifi was turned off, whatever. Telemetry data is imperfect and is generally missing a chunk of data.  It shouldn't be half of all sessions, though.


In Topic: Cleanup and return from main in case of a crash or just display error message...

Yesterday, 09:21 PM

Going along with some of the above, there are many options, not just those two.

 

 

 

My question is how should I handle crashes in my engine code?

 

You fix the issue. If the code is crashing it is a critically serious A-level red-flag bug.  

 

How you get around to fixing the issue is up to you.

 

Game engines should never crash when used as designed.  If the person violates the design, perhaps passing invalid pointers or garbage values, the code's response should vary.

 

 

Leverage the fact that debug builds, testing builds, and final builds are different and can contain different error handlers.

 

DURING DEVELOPMENT

 

If this engine crash is during development you want it to fail noisily and provide all the information needed to the development team.  This typically means a crash dump and a big ugly message. Write crash handlers for all the ways the program can die and make them create minidumps, and make it very easy for the person to get that minidump to the developer.  

 

In most of the professional world, a crash bug is a critical bug that prevents shipping.  If your game is being released on a game console then any crash will automatically fail the game certification process. When discovered this way the cost to a studio for a single crash is thousands of dollars. It costs time and salary to fix the bug, time and money to go back through certification, and possibly money if shipping dates are missed or in jeopardy.  Of course, a console game crashing in the wild can end up destroying the entire product, so don't do that.

 

Note that an engine non-crash condition doesn't deserve that same response.  During development you can provide big feedback to the developer that they are doing it wrong, abort the action, then attempt to continue.  It may be a big warning "Error parsing data file <whatever.json> line 123", or "Code is using graphics functions after D3D11 surface was already reported as broken. FIX IT! Ignoring graphics call."  During development you want these conditions to be called out visibly.

 

 

DURING MAINTENANCE

 

If the engine crash is during a product's maintenance cycle then you want it reported with all information needed to fix the bug. For game clients this typically means a crash dump and auto-uploading so you can correct and fix it.  For servers this often means a bunch of emails auto-generated to the dev team with the dump attached or referenced.

 

For non-crash conditions during maintenance your engine should attempt to fail gracefully.  This means you start logging the issues and provide a way to upload them.  This is commonly done by games that have a checkbox like: "Report anonymous usage statistics to make the game better"  If you don't run a server or can't run such a server in practice, this can be done with an exit handler that politely says "Problems were detected during gameplay, please email this log file to the developers" or something similar.

 

 

After you're done with product maintenance it doesn't really matter what you do.

 

 

 

Lets say D3D11 fails to initialize how should I handle that?

 

That is a known failure path, and it can happen for an enormous number of reasons. That should never be a crash by itself.

 

If your program is crashing due to this known and expected condition, that crash is a serious critical A-level red-flag bug.  Identify your bug and fix it.

 

If someone else's code is crashing due to this known and expected condition, if your engine has the ability to detect and stop the behavior it should do so as described above. During development that means hard-to-ignore messages that get the defect fixed, and after development it means providing methods for the program to be patched.

 

For known failure paths generally a return value is sufficient. That is how DirectX itself handles it, and how most other major libraries handle similar events.


In Topic: Need clarification regarding "user commands" in client/server archite...

28 September 2016 - 02:32 PM

Q1: Should the server queue up user commands and execute them in order or should it only execute the newest command recieved?  Assuming it does queue them, how fast should the server execute them (e.g. should it execute them all in one tic or spread execution out over multiple tics)?
 

 

Depends on how you implement your world.  

 

Generally the server doesn't get behind, and if there is a queue it is very short.  In many fast-paced games the server operates with a small window of time. It examines the time stamp of an event, and if the event is within the time window it inserts it within the simulation, often seen as "rewinding" time. If the time stamp is older than the window it is expired and discarded. If the time stamp is newer than the window then it is in the future so the person is a cheater.

 

The server generally lives in the future relative to what the clients see on screen.  What the player sees as "now" was actually around 10, 20, or even 100+ milliseconds in the past as far as the server is concerned. The article describes how it works around this in part 4.  The "rewinding" aspect kicks in and the simulation is processed as though the event from the past were part of the timeline.  

Fortunately for most games simulation processing is extremely fast, it is the rendering and similar tasks that consume the most time. Assuming the developers keep all the simulation data around in a sane format it can be rewound and replayed quite easily.  If the developers don't, it is much harder.

 

Q2: If the server runs out of user commands for a client (e.g. due to lag), then should player logic continue to execute with the last user command recieved or do nothing?  My assumption is to do nothing.  This question comes from the idea that the buttons last pressed might still be pressed during the next tic.

 

If it is within the server's window of available time you can insert it.  If it is outside the window of time you dump it.  

 

Q3: Should the client send its entire history of user commands that have not been acknoledged per-tic or should it only send the very latest user command per-tic.  This assumes when a user command is acknoledged, then it and all older entries before it will be removed from the clients history.

 

There are many common patterns.

 

In UDP, a common pattern is to repeat until acknowledged. It looks similar to TCP's sliding windows except it resends the data every time instead of when  So packets transmitting events look like this:

 

--> {#1}

--> {#1}{#2}

--> {#1}{#2}{#3}

--> {#1}{#2}{#3}{#4}

<-- {Ack #3}

--> {#4}{#5}

--> {#4}{#5}{#6}

<-- {Ack #5}

--> {#6}{#7}

 

If your game is very chatty you may accumulate five or ten small items, in which case you may want to revise your protocol. In practice games usually have either nothing or a single item in the queue, occasionally getting two or three during busy times.

 

That isn't required, just a common pattern for UDP transmission. Other games use more of a TCP model of sliding windows, assuming that data went through properly but reserving them in a buffer until acknowledge in case retransmission is needed.  

 

Generally modern networks work quite well and desktop boxes seldom have packet issues at UDP's layers.  UDP can still have issues, it just is quite infrequent.  One system may run for months with no issues, a second system may run reliably for hours with no issues, then have a few odd packets, then return to reliability. A third system may exhibit frequent instability. What is invisible to you is that the first one is talking between computers in the same corporate office building, the second is cross-country to a home computer, the third is someone on their laptop in a train using cellular wireless.


PARTNERS