Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


frob

Member Since 12 Mar 2005
Offline Last Active Today, 06:28 PM

#5208107 What kind of math do you use to balance games?

Posted by frob on Today, 05:40 PM

Depends on the games, the company, and what they are looking for.

 

It may mean they want you to run statistical numbers, it could mean they want you to ensure every location has similar offensive and defensive capabilities, it could mean something else.

 

Many modern games include an 'imperfect balance', where even though options are different they are still evenly powered, where one option's abilities can overcome another's weakness. Exactly how you achieve that balance is unique to each situation.




#5207744 What to do for debugging

Posted by frob on 30 January 2015 - 02:09 PM


I understand what crash dumps are and I know that PDB files are generated with my build (my IDE is visual studio 2013).
But I still do not understand to actual use them. Also what if I want to run my application on OSX or Linux, will those PDB files work?
When I think about it I'm not actually sure how to actually generate a crash dump

It won't work in OSX or Linux because they don't use Windows executables.  (Well, they can if you are using WINE, but it still works the same.)

 

It is almost as easy as you wrote.

 

Create your exception handler with the signature: LONG WINAPI MyCrashHandler(EXCEPTION_POINTERS * ExceptionInfo);

 

You can put whatever popups and useful information you want, but make sure it calls MiniDumpWriteDump().  That function will write your minidump file.

 

Then in your main function, register your function with ::SetUnhandledExceptionFilter(MyCrashHandler);

 

That will capture most stuff, but there are a few situations where the system terminates your program without calling it, like fatally corrupting your heap.




#5207614 Some programmers actually hate OOP languages? WHAT?!

Posted by frob on 29 January 2015 - 11:00 PM

... assorted things found in C ...

Also, function pointers. Be prepared for them.

 

C++ and the virtual function table -- one of the things people think of as a key feature of object oriented languages -- came from function pointer tables that were and still are common in idomatic C.

 

The common features of C++'s classes stem from common naming conventions in C.  It is common to see function families in the form:  SystemFunction(SomeStruct* ...);

 

For some examples: file streams you've got fxxx family: fopen, fclose, fread, fwrite, fgetc, fputc, ftell, fseek, and on and on. Each uses a pointer to a FILE object, which holds super-secret information about the file, very often as a struct with function pointers. The string family of functions are similar, strxxx for strings (strcpy, strcat, strlen, strcmp, etc), wcs for "wide character strings" (wsccpy, wcscat, wcslen, wcscmp). Or va_start, va_end, va_copy. For threading with the Posix library you've got pthread_create, pthread_join, pthread_detach, pthread_exit, pthread_mutex_init, pthread_mutex_lock, pthread_mutex_unlock, pthread_mutex_destory... should be enough to get the picture.

 

Instead of the common C pattern of passing an object pointer to every function, C++ secretly passes a structure you call the this pointer. Instead of having a function table that lets you modify functionality you've got a (hidden from the programmer) vtable and inheritence. Instead of prefixing the names of all the functions with a system, you have a class name or namespace name.

 

The languages diverged quickly, but a great number of the C++ language features were syntactic sugar over idiomatic C.




#5207601 What to do for debugging

Posted by frob on 29 January 2015 - 08:47 PM

As for knowing when to log it, remember to check every return value.

Many people, beginners especially, will pull code from tutorials and guides where the code is meant to be an example with everything going right.

Whenever your function returns a status code you should check and verify it is correct. If incorrect, drop a log entry and handle the response.

Some people are afraid of all the if(status!=0) blocks after each major command, and if you're among them you can use the likely/unlikely flags on GCC or PGO optimizations


#5207496 Some programmers actually hate OOP languages? WHAT?!

Posted by frob on 29 January 2015 - 01:13 PM


I get that Object-Oriented Programming is clearly intended to pay a lot more attention to objects and use them as the core concept of the software's architecture, but I find it hard to imagine any kind of even somewhat blurry line that demarcates proper OOP and something like...

One reason for that is that is a lack of definition. There is no clear line because making any kind of line requires a definition.

 

I have never seen any group -- from rooms of engineers to standards groups -- define what OOP means with any clarity.  "Proper OOP" has no definition.  It means one thing to somebody, another thing to somebody else.

 

Even the name itself, "oriented", is ambiguous.  The language or design or style tends to direct toward objects. It is oriented around or toward objects. That is not a feature list or strict definition, just a tendency in a direction.

 

As Hogman, Ravyne, myself, and others are repeating, languages like C++ don't fit nicely into any particular bucket for various definitions. That is one reason C++ is often called multi-paradigm. Sometimes, some features of the language do not meet one definition's strict requirement, but they might satisfy requirements for other definitions. It all comes to definitions.

 

Some definitions are a continuum, some definitions are checklists requiring absolute adherence, some definitions are nominal scales with clusters of features, some definitions are other variants entirely.

 

 

 

When undefined terms like "Proper OOP" are used, as though a term that has no solid definition has a precise and agreed-upon definition, the argument is pointless. When even the experts cannot come up with definitions of the terms an attempt to use the term as an authority is a logical error.




#5207470 Dividing Equity/Profits in Creative Work

Posted by frob on 29 January 2015 - 11:45 AM


The nature of my work is less personal and all of my concerns has to do with monetary fairness. 

PAY, or money, is radically different from EQUITY, which is ownership.

 

Recall your question:

 

 


How do you divide up equity and profits in a creative endeavor? 

You can divvy up profits however you want.  But distributing equity is a very bad idea.

 

Usually the best option is to make distribution of funds entirely discretionary. And if your agreement restricts it to profits, well, you might as well just keep the money for yourself. Otherwise you get into a difficult situation where one person contributes a large number of buggy elements that all later get reverted or fixed by others, and another person writes a small number of compact but critical core functionality plus bug fixes to the bulk code of others. The "bulk buggy code" person can be calculated as having a large number of submissions and a large number of additions, the person implementing fixes and cleanups that submits all the changes in large submissions can be calculated as a negative number of lines submitted and relatively few commits. One is far more valuable than the other, but trying to put that into codified contractual terms will be difficult at best. 

 

Giving away equity through the development process, that's crazy talk. Let's say your contract specifies it is done by the number of commits? Great! I'll gain a 50% share of the company within a week, maybe within a day depending on bandwidth. Or maybe your contract specifies it is by lines of code submitted?  Again, I can easily gain a controlling share of the company with some simple code generation scripts. Then you can pitty the designers who spend their time working on documents and physical/paper prototypes rather than submitting code, they'll never get any equity. Any system that dilutes equity through the development process means that now matter how important and critical one person's work is, someone else can trivially commandeer that value to themselves. 

 

 

 

If you've already got a bunch of development by several contributors, one of the easier ways to correct it is to have everyone agree on a distribution at the present time and assign equity shares based on that. The shareholders become the executive board. Then in the agreement have all distribution of funds be discretionary in a manner approved by the board. 

 

Run it like a business, or not at all. If you don't then you need to get unanimous consensus from everyone who ever contributed. That may mean tracking people down from the corners of the earth.  Assuming your project lasts an extended time people will move, people will die and their assets get split among their survivors.  When you want to make a decision do you REALLY want to be obligated track down all six of Bob's surviving children and get their approval?  Or track down people around the globe to give them their $0.13 share of each product sale?




#5207239 Marketing your game

Posted by frob on 28 January 2015 - 01:36 PM

It will depend on the game and the group making it.

 

Frequent communication with your customers is good, especially when coupled with frequent additions and updates. 

 

Exactly how frequently, exactly what to include, exactly where to post, those are unique to every project.

 

If you are making a press release 3-4 times per week you better be putting out significant new content at least weekly. That level of communication is spamming pretty hard, and even customers who want to know about your updates likely don't want that much information.




#5207235 Second programming language...

Posted by frob on 28 January 2015 - 01:31 PM

Python is great for many reasons.

 

The biggest strength is not as the engine core, but as a utility. It is good at everything from "convert all these values" to "traverse the file structure and process what you find".  You can open an interactive python session window and it becomes an extremely powerful calculator and converter. You can build simple development tools quickly. 

 

In addition to the utility of the language itself, since EEletri mentioned only experience in C++, the thought process of idiomatic C++ is quite different from the thought process of Python, meaning he could learn many new techniques and patterns.

 

 

I wouldn't recommend python if the only use were to make something in PyGame. 




#5207101 Weird Thing with using PrintScreen while running my game

Posted by frob on 28 January 2015 - 02:14 AM

Likely because of hardware acceleration.

 

The printscreen keyboard shortcut takes a picture of what is present on the screen buffer. Often the hardware acceleration will leave a hole in the screen buffer and instead draw the 3D accelerated content inside that region.

 

The safest way to get a screen capture within your own app is to render the image yourself, read it back from the card, and store it in an appropriate place.




#5207010 Some programmers actually hate OOP languages? WHAT?!

Posted by frob on 27 January 2015 - 05:16 PM

As a note, many paradigms are compatible with each other and work well together.  Others are located on a continuum.

 

I already mentioned several earlier in the discussion.  Object oriented works well with event oriented paradigms. Object oriented works well with state machines and automata. Object oriented is on a continuum with functional development, one preferring verbs the other preferring nouns.

 

Many people interpret "object oriented" as inheritance trees or deeply nested commands.  While it is true that some systems do this, that is not what object oriented is about.

 

Object oriented is part of the continuum of preferring nouns or verbs.  Languages tend to prefer objects, the nouns, or they tend to prefer verbs, the functions or actions. When you crate an opaque structure and operate on it like C's FILE*, that is a noun. When you work the opposite direction, SELECT whatever FROM whatever WHERE whatever, you are focusing on verbs, that is more functional. 

 

 

Object oriented and data oriented can be orthogonal. You can have both, you can have either one, you can have neither.  I can create an object that is composed of SoA or composed of AoS, both are still treated as a composed object that represents a bunch of items in a collection.

 

Edit: It looks from doing some reading like some people are treating 'data oriented' in the same bucket as 'functional'.  If that is your interpretation of the term, and since there are no official definitions, then yes, they are both on the same continuum. But please don't use it that way, there is already a name for code that focuses on the manipulation of data as verbs through functions, it is called functional programming.




#5206987 Some programmers actually hate OOP languages? WHAT?!

Posted by frob on 27 January 2015 - 02:31 PM


Now the level of complexity has jumped so much to do the same things that it has taken all joy out of it for me.

In situations where OOP is useful, it dramatically reduces complexity rather than increases it.

 

Both Pascal and C tend to use object oriented principles. If you start with structures, and you pass the structures to functions to be operated on, you are at least partially doing object oriented development. Much of the C standard libraries follow object oriented principles by working with an opaque structure pointer.




#5206984 Clean up and what to keep in mind

Posted by frob on 27 January 2015 - 02:17 PM

One person I worked on had a fun philosophy on making mistakes.  

 

Junior engineers should make a lot of tiny mistakes. If their code isn't buggy that is suspicious. Everyone should review their code.

 

Mid-level engineers should make some mistakes, but less often. The mistakes they make should occasionally take down the entire team's productivity.

 

Senior engineers should rarely make big mistakes, but when they do, they ought to be incredible. A senior engineer might occasionally break something for 100 people, then all the engineering team can review the single change yet have nobody be able to identify what broke even though the code is right in front of them.

 

If you are a senior engineer and you aren't at least occasionally causing disruptions with your "experience gaining" events, you are slacking off and need to be more aggressive in your work.

 

While developers should aim for solid, reliable code, it is unrealistic to assume developers will write perfect code every day. Do you best, but push yourself.




#5206981 java timeout thread for connection to wrong server

Posted by frob on 27 January 2015 - 01:51 PM

In other words:

 

1. Main thread handles UI and other interactive stuff.  When they connect it launches the secondary thread.

 

2. Secondary thread in the background will connect and wait for the connection, sending events back through a listener about if the connection succeeds or fails or whatever else.




#5206980 java timeout thread for connection to wrong server

Posted by frob on 27 January 2015 - 01:49 PM

Connecting to the server blocks execution. The program will wait until that is complete before continuing.

 

If you create another thread, the other thread shouldn't have the timer; the other thread should have the connection code so the rest of your application, including the UI, can continue to do their things. You can then add a listener to the client so your main threads can get notices when something happens to the connection.




#5206978 Second programming language...

Posted by frob on 27 January 2015 - 01:40 PM


HTML5 (Javascript), Python, C#

I'd include all of them on an eventual "must learn" list. 

 
In that regard it is difficult to go wrong with any of them. None of them are bad.
 
 

Of those, Python is likely the most immediately useful with long-term value. It is convenient to pop open a python window, type in some commands, and get an immediate result. If all you know is C++ you may be surprised at just how quickly you can accomplish many tasks. 

 

After that, HTML generally is something everybody expects of developers. JavaScript less so, but if you're a developer and you cannot read the HTML source your geek credentials will be revoked and other developers will openly mock you when they discover it.  Not so much at your age, but in five years or so you'll need it. You will need to learn it eventually.

 

The transition to JavaScript directly might be a bit tough if you haven't mastered the basics of HTML markup. You'll need to to be comfortable with the DOM (Document Object Model) used behind the scenes on HTML and related markup languages.

 

The transition to C# would be easy but not very educational. If you are shaky on the basics and not comfortable with a big step, C# might be good to help strengthen some of those fundamentals.






PARTNERS