Jump to content

  • Log In with Google      Sign In   
  • Create Account


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

#5196505 Intros

Posted by frob on 05 December 2014 - 03:25 PM

As a prime example of this, the nvidia Physx public license has this wonderful section:

6. Attribution Requirements and Trademark License. You must provide attribution to NVIDIA.

A. You will include a reference to the PHYSX SDK and NVIDIA in any press releases for such Game that relate to NVIDIA, or in-game physics, and will identify NVIDIA as the provider of "PHYSX" (or such other term or phrase as indicated by NVIDIA from time to time).

B. For Games, Demos, and Videos that incorporate the PHYSX SDK or portions thereof, the NVIDIA
logos must appear:

a. on the back cover of the instruction manual or similar placement in an electronic file for the purpose of acknowledgement/copyright/trademark notice;
b. on external packaging;
c. during opening marquee or credits with inclusion of “NVIDIA”;
d. must appear on title marketing feature list with a specific call-out of NVIDIA PHYSX Technology
e. on the credit screen; and
f. in the “About” or “Info” box menu items (or equivalent) of all Physics Games or Applications using any portion of the PHYSX SDK.

C. Provide a quote citing the Licensee’s integration of the PHYSX SDK into the Game or Application for NVIDIA’s use in press materials and website.

D. Refer to NVIDIA’s PHYSX SDK in all press coverage referring to the use PHYSX in the development of any Game or Application.

Failure to provide attribution pursuant to this Section shall be considered a material breach of this agreement.

#5196504 Intros

Posted by frob on 05 December 2014 - 03:20 PM

They play them because they got some sort of contract allowing a benefit from the company and part of the deal was that the game developer would advertise.


Commonly that could be early access to hardware and to drivers, and direct support from the driver development teams.


The game company doesn't say "I really want to play the nvidia logo on my game".  Instead they have some specific thing they want to take advantage of and the logo becomes part of the contract for that access.

#5196287 C++: Easiest way to implement an in-game Time/Date system?...

Posted by frob on 04 December 2014 - 12:10 PM


...  maybe a real-life second is an in-game minute or some such, and time acceleration allows it to progress faster...
Is it just me or posts here are assuming the in-game time  will increase at a more or less constant rate?


If you plan to run the simulation for a lot of time with "time scale" changes, I suggest against using a single reference point in time. In the past I've had some nasty things with accumulation errors and I cannot be completely sure the new frameworks solved them. Keep around a list of "time speed" changes and reset your time reference to last time multiplier change.



That is an (important) implementation detail.


If you have simulation clock based events, you need to make sure all the simulation clock events trigger.  It doesn't matter if the rate is one simulator tick per wall-clock second, or a thousand simulator ticks per wall-clock second, or a "skip two weeks" debugging cheat code, your implementation needs to ensure that anything tied to the clock is handled "properly", for whatever your game's definition of that means.


For example, if you've got an event that a player's buff gets cancelled after 525600 ticks, and you jump your simulator clock by a million ticks through a cheat code, you will need to ensure the important action is triggered. Other things like ensuring a particle system has the particles updated at a constant rate are probably not be important events, and those could be skipped over.  That is all game specific implementation detail.

#5196274 Accurately estimating programming cost?

Posted by frob on 04 December 2014 - 10:38 AM

An alternate way of estimating costs is to compare it to rough costs and to find comparable titles. You say you want to start with FTL - Faster Than Light, plus a lot of features.


FTL started as four people with multiple months in their basements (we'll simplify to 1.5 FTE) followed by $200,000 kickstarter money in Shanghai, China. Combined with everything it took them over a half year, if I'm reading that correctly. In the US you need to estimate 10,000 per man-month.  I'm not sure what that will buy you in China, but Google suggests it is about 20% cheaper.  200000/8000=25 man months. It took four people about six months, so that sounds about right. 


Then you are asking to roughly double the size in new features, so we'll double that to 90 man months. Plus since your project is larger there will be more experimentation and more administrative costs, making it about 120 man months.  


From my own experience in smaller games, that number sounds about right for a FTL style game. You can look up various similarly-sized games and see if that feels about the same scale to you.


The game would have a very simplistic feel to it, and may or may not be fun (that is up to your design and implementation). 



You want it in the USA, so the 120 man months is around 1.2 million dollars for your simple little game, if you are paying for it.


If that means the development team is you and your nine other close friends, all of you willing to work about 2000 hours on it as a full time job, it would take about a year.  

#5196136 First big game. Which engine and how to handle multiplayer?

Posted by frob on 03 December 2014 - 03:24 PM

So you want a game engine that runs on 8 different major platforms with all their variants, plus web play, with screen sizes ranging from 4-inch 640x480 to giant screens having 4k and 5k resolutions, plus has solid network play across all kinds of networks from 3G phones to corporate LANs, and all with minimum installation requirements, all with a single shared source code and asset base.


Is that all? happy.png


Really that means Flash-based engines, Java-based engines, and Unity. If you remove the web requirement you can also chose Unreal. I know that doesn't help much for decision making. Try several, pick whatever best fits your design and programming style.


There are many engines capable of doing what you describe. The harder question is if you are capable of doing what you describe. No matter what engine or tools you pick this will be a big undertaking.  Among other things you'll need an army of QA in order to reasonably cover all the operating system variants and hardware variants on each OS. That will not come cheap.




The multiplayer aspect is more an question of design than engine choice. You'll need a design that functions well with the latency and network propagation time. You'll need a design that packets can play well on many different types of networks, including cell phone networks with their crappy connections.


Just writing "...sandbox[sp],co-op[mp],competitive[mp]..." is really not enough to go from. You will need (in your design) to go in great detail before doing much with code no matter your engine choice. You'll need to figure out your protocol, you'll need to figure out how you will handle servers and matchmaking and connections, you'll need to figure out how to handle latency and delays and stalls and drops, you'll need to figure out how to resolve conflicts and what is authoritative, you'll need to figure out how to correct things when they inevitably go wrong. You'll need to figure out what is significant and gets transferred versus what is unimportant or what is computable and does not get transferred. Those details give each game their own unique feel.


If you go with Unity, the networking aspect means you need to design carefully about what features matter for networking. The simulator does not support a "rewind time and insert this event" that is currently popular in fast-paced games. You can run a mini-simulator within the engine that handles that type of work, but there is a significant development cost. The built-in physics engine and other GameObject state can get a little wonky and slightly different if you let each machine do its own simulation, so your design needs to be flexible enough for that, or you can work hard to overcome that kind of drift inside the implementation details. 


If you go with a Flash or Java engine -- and there are many to choose from -- you're going to have similar design concerns. 

#5196117 Weird stuff happening when stepping through a threaded code

Posted by frob on 03 December 2014 - 01:36 PM

Sorry about not deleting it. It helps allows other people to learn.


That is what gives this site -- and so many others -- their value. Imagine if the major programming sites like StackOverflow or StackExchange deleted questions once they were answered.  Instead of deleting them, sites provide resources with millions of little snippets of code for common mistakes.

#5196078 Contracting Devs/Studio?

Posted by frob on 03 December 2014 - 09:26 AM

1a. What's the best way to contact a major team of developers for projects under contract, or at least at a point where you can determine what the budget should be for that particular game while using that specific development team?
1b. Should if be the team's project manager that I contact, a desk associate, or someone else?
1c. How should I contact them; by phone or email?
2. What should I expect and look for in a team besides their work history and portfolio? I know contacting a large studio like Volition is highly unlikely, but what about a mid size one like Dark Side Games? What would they expect me to have upon my presentation beyond a product outlook, profit expectancy, market value analytics (if necessary), etc.?
3. Finally, are there any best practices I should use to stay in good favor with my prospects should I not have everything I need upon my first pitch or presentation?

1a-c. Find a contact phone number. Usually it is on their web site if they are serious about contract work. Initial conversations in the business world are still primarily handled by phone, then transition to email. They go by various titles, "development manager", "account manager", "project coordinator", the business owner, VP of whatever, and more. Eventually you'll likely be working with a "producer" on their end, but that is after the business contract stuff is taken care of. Usually just follow the "Contact Us" button, it will have a phone number, call during business hours. You'll get a secretary, briefly state that you are looking to discuss a new contract and would like to speak with someone about that, and they'll transfer you.

After a small number of phone contacts it will quickly move to emails. Then it will move to discussions with your business lawyer to draw up the contracts. There will likely be one or more in-person meetings, on the last one contracts will get signed, which is frequently a financial milestone. With luck the lawyers will never be involved again because the business relationship will be amazing, hopefully.

Be prepared with budget numbers in advance. If you're approaching a development house have your budget known in advance, is it a $200K quick project, a $2M longer project, a $20M large project? If you are approaching individuals, are you willing to pay at a low-end $50/hr with milestone completion bonuses, or a more professional pay rate of $150 or so per hour plus milestones and certain expenses? (Or perhaps you are looking to outsource to Pakistan or Russia or Peru or someplace cheaper than these rates?)

2. Work history and portfolio is mostly it, but if you have other business contacts you can ask for recommendations for that type of game and you can ask the company for references. You want people or a company who has developed similar games under contract before. You mention Volition, they are not really a contract development studio. Exactly what type of business or individual you want depends on your needs and desired game. Sometimes you can hire a single individual, sometimes you need to hire a larger team, sometimes you need to contract out to a moderately large business. Cost scales accordingly. They typically do not care about YOUR profit expectancy for the product, YOUR product's market value analytics; they care about ensuring they can make the product agreed to by the contract and verifying that you will be able to pay the bills at the milestones.

3. Stay in contact. Be open about both the good and the bad. You will be working with them a lot. At first you will work closely with them to establish all the fine details. Many meetings will be at the beginning establishing what exactly they will be doing and what you will be doing, what you will be providing, what you will be expecting, how it will be delivered. Usually fewer meetings and contacts in the middle, perhaps down to twice weekly or once weekly, but I wouldn't go that low unless you have a strong existing relationship as too much can go wrong. At the end it will move back toward daily, then near constant communication as you finish up. Depending on both your and their location on the globe you may have multiple in-person visits as well.

/edit: Ninja'd by Tom as I had to take my kids to school in the middle of the reply.

#5195973 C++: Easiest way to implement an in-game Time/Date system?...

Posted by frob on 02 December 2014 - 05:34 PM

One elapsed second == 1 simulator minute is a fairly common value in life simulators. You'll find that value in major games like The Sims. One simulated day lasts just under a half hour, giving enough time for players to control their characters.


But be very, very careful about figuring out real life time.  DO NOT USE THE CURRENT CLOCK TIME, the OS provides elapsed time stopwatch values you should use instead.


Real life time skips around. It is not always consecutive, sometimes jumping a few seconds or microseconds, sometimes jumping hours or even days. Sometimes it moves backwards. The most obvious examples are things like daylight saving time and leap seconds to adjust the clock. Slightly less obvious are the usually minor clock adjustments on your system clock when it re-synchronizes with time servers. A user could alt-tab out of their game, adjust their system clock forward or back several years, and resume playing the game.


So be careful in converting real life time into simulator elapsed time. A person playing at 2:00 AM on daylight saving adjustment day may be upset when their clock switches, either because now they need to wait for two simulator days for the real life clock to catch up, or because the game suddenly launched forward two simulator days. 


But assuming you correctly compute the elapsed real word time, keeping the simulator time is straightforward.



Use a simple counter preserved at the simulation. The epoch, the beginning of time, is zero. Every minimum time unit is +1. Do not tie that to real life time. Simulator time 0 could be midnight starting the Sunday of the week 0 of the game, but you could start a new game as 7:30 AM on Tuesday of week 1, a simulator clock time of 691650.  A player might speed up time making a simulator minute take one second or two seconds or ten seconds, a player might slow down time by making a simulator minute take twenty seconds, or even making a simulator minute take one clock minute.


Make sure animations and effects and motion and other elements are based on simulator time, not real-life clock time. If the player fast-forwards the game you want animations to play completely but quickly, if they slow down time you want them to move correspondingly slow.  Always remember to base game content like animations and effects and potentially even sound on game simulator time rather than player update clocks time.


So if you were building a life simulator and decided a simulator tick equals one second, all it takes is a bit of division to get time of day and other factors. You've got:


CurrentSecondOfDay = SimTime % 86400;

CurrentHour = CurrentSecondOfDay / 3600;

CurrentMinute = (CurrentSecondOfDay % 3600)/60;



You can build a bunch of similar functions to get the current day of the week or the current year of the calendar. I strongly recommend you also simplify time to a 28 day month for easy calculation, but you can make it as complex as you want.


Then you can work with whatever time-related simulation values you need.  Light of the sky may change based on the current second of the day, certain triggered events may happen at certain minutes, in-game events can happen on computed days of the week or computed weeks of the year.

#5195943 Browser game development: Flash or HTML5?

Posted by frob on 02 December 2014 - 02:32 PM

I think that will mostly have caught HTML5 up to Flash
For the desktop, perhaps.


On mobile devices HTML5 is still a slideshow on most devices. It is also prone to running out of memory as the devices do not provide gigabytes of virtual memory to processes.

#5195831 C++ 64 bit void */int conversion addressing questions

Posted by frob on 02 December 2014 - 12:25 AM

Pointers are never smaller than integers (at least I'm not aware of any architecture where that is the case!), and since you store an integer inside a pointer (not the other way around), that will always work, ugly as it is with that cast.

Not always.  Go back a few decades.


My first exposure with C++ was back in 1989 on the PC. The compilers for MS-DOS compatible systems had "near", "far", and "huge" pointers available. Other systems also had their own pointer variants. Both far and huge pointers had more bits than an int.  If you attempted to store a regular integer value in a "huge" pointer you would almost certainly get a different value out, since they were re-normalized every time they were assigned in order to maximize their spread for sequential runs.


Today most of us get to enjoy "flat" pointers that are 32 bits and we don't need to specify any fancy modifiers for them.

#5195651 I am all prepared to get into game development, how do I start then?

Posted by frob on 01 December 2014 - 02:16 AM

I think the advice about the app stores is relatively sound.


Many beginners jump in and assume the app stores operate much like they did back at launch.


Back in 2008 when the apple and android stores were new, they were quite sparse. You could put up a motion-sensor app that draws a brown fluid-like screen with bubbles that makes it look like you are drinking something, and sell millions of copies.  You could have 30 different recordings of burping noises and again sell a million copies. No matter how bad the game was you could still expect to be paid reasonably well.  Even crappy homemade games could reasonably receive several thousand dollars.


The 2014 app stores are radically different. Both Android and Apple ecosystems have roughly 1000 new apps added every day that you must compete with, plus you must compete with several years of existing products, many that have six-digit, seven-digit, and sometimes eight-digit production costs. Rovio's Angry Birds franchise is in the multi-billion dollar category, quite considerable considering the humble beginnings of an inexpensive simple slingshot game.


The Windows RT marketplace is certainly more sparse than the Apple and Android marketplaces, but it is rapidly filling up with the same cross-platform products.



Make games because you enjoy making games. Trying to make games in the hope to get rich quick is a bad idea, most products never make it to market. Most of those that make it to market never turn a profit. Most of those that turn a profit only recover a tiny amount of money.


Getting back to what the OP can do, the best thing is to just start. Figure out where you are, figure out where you want to go. Then figure out a plan to move from one place to the other. Be realistic in your plan, you are a single individual with limited funds,not a studio of hundreds of people making a multi-million dollar venture.


Don't waste much time on the best. The best is the enemy of the good.  You can spend months writing the best pathfinding algorithm, or hours writing something that is good enough. You can spend months on the best rendering algorithm, or a short amount of time making something that works okay. You can carefully evaluate the pros and cons of every editor out there, or you can just pick any of the popular ones and go from there. Don't get paralyzed looking for the best and ideal. As this is "For Beginners" with a hobby project and not "Production and Management" for a large project, if your plan is realistic and it progresses you on your goal from here to there, then go for it. If there is an actual problem you can always change course later.

#5195649 C++ 64 bit void */int conversion addressing questions

Posted by frob on 01 December 2014 - 01:57 AM

Trying to look at the bigger picture, it may be time to split the dual-use variable out of existence. Make one for the integer, another for the pointer.


It was fairly common to do that sort of packing when you didn't know the underlying types of data to be moved. You could just make an arbitrary packet and move data around. Normally that meant a union with a bunch of types. The nice thing about when people used unions is that when code migration came around you could convert it into a non-union struct and then use a bunch of testers to shake out the bugs.


Since it is C++ you could do some engineering work if you don't want to split it out. Perhaps create a base class with several explicit conversions that block execution, then overrides with explicit conversions to int or to various pointers.  Basically a bunch of lines in your class: explicit operator int() const { Message("wrong conversion used") ... }


But that seems like more work than simply splitting it out to proper classes everywhere and removing all the broken casts in the code.

#5195542 Return value

Posted by frob on 30 November 2014 - 02:37 PM

That's the same pointer version from before, not a reference.

If you are asking for permission, you can do it however you want. That way is functional.

The design you use depends on your actual needs. In the case you just gave you're returning a null pointer, which often works for designs but sometimes not. If your system is built so that it detects null pointers coming from the function, and everywhere you use it you always test for a null result, then it works.

If you really need a reference to an object, some designs will use a special "failure object". It is not a null pointer, instead it is a valid object with a bunch of special features. It can be useful in systems like creating a game object from an object factory in a large data-driven game. Creating a failure object in this kind of game will pull up some dialog boxes on debug builds and test builds so QA can log it, but the failure object can be gracefully used as a valid game object by all the game systems.

#5195408 Distributed transaction & message queue

Posted by frob on 29 November 2014 - 05:12 PM

The one problem i have is that this does nothing to prevent a double spend exploit.

Sorry, but it really is a solved problem.

It was solved centuries ago in the physical world with escrow services, and was solved decades ago in the electronic financial industry with a variety of different algorithms, including the one presented in my post above.

You have two different systems, each with the potential to fail, or not satisfy the requirements at the time of transaction, or be fraudulent, or be cancelled in the future. Transactions like {buy ticket on ticketing system, transfer funds with banking system} happen all the time around the globe. Others like {remove item from inventory tracking system, transfer funds with banking system} happen thousands of times every second at major retail chains.

You start with both systems using databases that satisfy ACID requirements, then you use your own intermediate system with idempotent transactions that handle duplicate events, auditing, and enable implementing product returns or mid-transaction exceptions.

This is very much a solved problem. It requires quite a few small steps, but done correctly the steps can be safely re-run multiple times, safely be interrupted and resumed, safely be cancelled mid-process during an exceptional process like insufficient funds or discovery of fraud, and can safely be cancelled through a second later transaction. It can also generate audit trails adequate for everything including government investigation and insurance investigation.

#5195308 programming a 3D board

Posted by frob on 28 November 2014 - 10:19 PM

Using an engine such as Unity (there are others as well) you remove a lot of tasks.

It already has a complete graphics pipeline (getting the art and models and animations into your game) and a renderer. It already has a complete audio pipeline and audio support. It already has input support. It has support for visual effects. It also has support for features like collision detection and mouse picking and more.

The benefit is that you don't need to spend your time building all those parts and debugging it on bunches of systems.

The potential drawback is that using a major game engine typically comes with implicit requirements that you have a skilled team. It isn't required, but missing artists often means ugly textures, missing modelers often means ugly models, missing animators often mean ugly animations.

Note that there are already some games similar to what you described, such as Cubistry which was written with Unity.