Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your feedback on a survey! Each completed response supports our community and gives you a chance to win a $25 Amazon gift card!


frob

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

#5200491 Is C# in Unity3D worth learning?

Posted by frob on Yesterday, 11:56 PM

"Some people" say lots of things.

Unity is a game engine. It is great for making games. It uses programming languages. It is not necessarily the best place to learn to program. It is not designed as a programming tutorial, and it assumes you already know quite a lot. Also since Unity is an engine, it does a lot of things for you so you will never write code for those systems.

You wrote that beginner-type programming tasks are not what you want to do. A huge volume of programming effort is tedious and involves aspects that are not fun.

The job of a student is to learn. Learning takes effort, and often involves doing tasks that are not fun. But after you have learned enough to reach the basic competency levels, the whole wide world opens up to you.

If your goal is to be a student, to work on student-like tasks, to learn programming in a structured form, then no, Unity is not the best way to do it.

If your goal is to make games and learn and goof off, using your limited knowledge to cobble together things even if the results are far from ideal, then Unity can help to those ends.


#5200446 Multi-threading for performance gains

Posted by frob on Yesterday, 12:14 PM

There are also other reasons to use threads that aren't covered so much above. Threads can be great organizational units. They can be great for running scripted game objects since one thread dying can be isolated and restarted. This is even more true for games with user-enabled scripts and mods -- don't let a bug in a user script or mod crash your game.

There are also assorted caveats. Race conditions are hard and add another dimension (=another order of magnitude) to your bugs and concerns. Multithreading is not for beginners. Identifying the need for and writing rentrant code can be tricky. Unintended bottlenecks can grind performance to a halt. Simple locking mechanism intended to improve performance implemented improperly will completely destroy your performance, bringing even a powerful system to its knees as it fights over resources and waits for locks to be released. Dead-locks, soft-locks and live-locks all can degrade performance or kill your program.

In general my advice on the forums is for beginners and hobbyist developers to avoid writing their own multiprocessing code if they can help it. If it cannot be avoided it should be isolated as much as possible. In larger work environments the task of engine design is usually reserved for long-time veterans with decades of experience in systems work. Designing and implementing the system is critical to the success of the projects, and even minor bugs can cost a fortune -- tens of thousands or even hundreds of thousands of dollars -- so companies are very careful about who does that work.


#5200443 do most games do a lot of dynamic memory allocation?

Posted by frob on Yesterday, 12:00 PM

I have worked both inside games and outside games on business software, games are extremely restricted in allocations. Historically games have needed to give a lot of thought to memory management, far more than most business applications ever do. Yet games can still do "a lot" of allocations.


In all the PC-based business software I've seen, generally allocations happen all the time. Less so on carefully engineered servers, but those are becoming scarce, replaced by a bank of cheap PC servers all with sloppy code. In one project I'm working with right now, their Java code base burns through about 100MB per second and the garbage collector triggers every few seconds. It is cheaper to build the software fast and cheap then buy 10 machines at $500 each than to have the product team spend months in careful design, months in optimization, months in performance tuning, etc. They do not care about the costs of object creation and memory management, and considering their environment, they do not need to. Memory management is not a big concern.

In games, especially games on consoles or game code shared with consoles, memory management is a major issue. On game consoles you don't get virtual memory where everything is swapped to disk. You have a very small memory pool to work with, although with each generation you have a little more space. On the DS you had 4MB. PS2 had 32MB. Original XBox had 64 which you shared with the OS. PS3 has 256 and you got about half. X360 had 512 and you got about half. To manage the memory you generally pre-allocate large pools for various items. Many engines and studios had requirements that you use memory in particular ways, long-term objects allocated on the high end of memory, short-term items on the low end of memory. Pools ensure that you keep within budgets and help prevent fragmenting, pulling from different sides of memory also helps with fragmenting.

Contrast with the PC and its virtual memory. In 32-bit PC games you can use 2GB or 3GB of memory, in 64-bit games you can use far more. Unless and until you come close to exhausting your memory space you can allocate and release whatever you want when you want. Until you approach space exhaustion the OS can usually find a block large enough for whatever allocations you need.

Games are usually more rigorous when it comes to memory management because of the history in game consoles. Developers tend to prefer longer-lived objects, loading and unloading in large batches, and other rules. Even so, games generate a lot of short-lived objects.


#5200378 Success Story, need advice from here

Posted by frob on 27 December 2014 - 11:28 PM


Sorry if not proper place, but does this also mean that you can't use another payment option beside theirs? Or there is room like "you can use Paypal if buy from non-mobile version, can't otherwise" ?

 

The first is correct. It is part of those big license agreements. 

 

If you use Google Play to distribute your product, part of the agreement is that your software will not "facilitate the distribution of software applications and games for use on Android devices outside of the Store." The license also requires: "Developers offering virtual goods or currencies within a game downloaded from Google Play must use Google Play's in-app billing service as the method of payment. Developers offering additional content, services or functionality within another category of app downloaded from Google Play must use Google Play's in-app billing service as the method of payment, except: where payment is primarily for physical goods or services (e.g., buying movie tickets, or buying a publication where the price also includes a hard copy subscription); or where payment is for digital content or goods that may be consumed outside of the app itself (e.g., buying songs that can be played on other music players)."

 
There is no exception for using paypal or direct credit cards or any other funding method, apart from those exceptions of goods and services or non-app content.  Since an in-app currency or ads for another game don't fit the exceptions, you must use their store.
 
Breaking those rules is a great way to get your apps removed from the store.  Since this app is already successful it would be stupid to get the apps removed in a cross-branding effort.
 
If you sell the product through another store, like Amazon's store for Android, that version can use a different billing system. But the version sold through Google's store must only use Google for IAP. 
 
Apple has similar policies.  Any product sold on their store MUST use their IAP mechanism for anything consumed in game.
 
And naturally Amazon has similar policies, if it was purchased through the Amazon store you need to use Amazon for purchases.



#5200210 What is a rig?

Posted by frob on 26 December 2014 - 11:47 PM

For all the systems I've worked with, a rig is the skeleton with the accompanying joints, constraints, and other tool-usable options and sliders. A rig is usually paired with at least one model in order to be useful, so it is often seen as a "rigged model". You typically need both the rig and model for animation.

Sometimes a rig is designed to be used by many models, as is the case with many vehicles or characters or animals. Other times they are created with only a single model in mind.


#5199899 Is Java a good Language for Games?

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

I know not a thing about Java, but I know that if you create a game, everyone has access to the source code because you can open .jar files with Winrar (or any other program that opens rar files) and you would be able to see and edit the source code. I do not think that happens with C# or other languages.

 

That is the case with many languages and with nearly all modern languages.

 

In modern languages that compile to an intermediate format, and languages that support reflection, including Java, C#, Python, Ruby, JavaScript, Go, etc., the nature of the language is that you need to be able to reconstruct the complete details of the original object's implementation. Some portions of it may be lost, such as comments or dead code, but everything that is accessible programmatically can be reversed to make something closely resembling the original code.

 

Under the very old C and C++ compilation model, which has its roots in the 1950s and 1960s, the design was to eliminate everything that could be eliminated which makes decompiling and reverse engineering much harder.

 

If you need to make things harder for someone decode, you can use tools to compile to a final optimized executable while stripping reflection information, or you can look to obfuscators that rename everything to less-understandable names.




#5199862 Visual studio 2013 (exe release) runs slower compare to VS2010

Posted by frob on 24 December 2014 - 10:48 AM

There are tons of options, plus there are code generation differences between the compilers. Could be lots of things.

 

For anything performance related, your profiler is your best friend.




#5199771 IAP promo codes to give to Kickstarter backers

Posted by frob on 23 December 2014 - 05:06 PM

Apple is pretty strict about that requirement, especially since it is how they get their money:  Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected. Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected.

While other systems are more amenable to outside purchases, Apple maintains fairly tight control.


#5199770 html & opengl ( what should i use or should i recreate html render engine )

Posted by frob on 23 December 2014 - 04:54 PM

Just wondered if fetching data from Internet and using "common controls" instead of parsing a web page is possible (if will just be used for launcher and so) and feasible.

 

It is an option. In fact, that is exactly what REST systems are. You make a web request, you get back a response, and you interpret the response based on your own rules. 

 

There are no real technical reasons why you or the original poster couldn't do that. You could even use different HTML headers like the (Accept header) to specially indicate that your application is requesting the slightly different presentation. 

 

As was pointed out, a web browser is an amazing architectural infrastructure.  If all you need is to interpret ten or twenty markup symbols and you control both ends of the infrastructure, you might be able to handle that much easier than including an entire web browser. 




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

Posted by frob on 20 December 2014 - 09:12 PM

I use timing to control the rate of rendering and game logic updates, and a GameTime class for time management where I'm using boost::posix_time to maintain an in-game date and time system for the gameworld.

 
This is probably way overkill. Do you need time zones, leap years and leap seconds and leap microseconds? Do you need daylight saving time? Do you need rather convoluted rules for posix date string formatting and parsing? Do you need microsecond time resolution? 
 
It is also likely to cause serious problems in practice. Fix your timestep. Failing to do so is a common source of physics bugs, of animation bugs, of navigation and motion bugs, and of other both exploitable and problematic issues.
 
Without a fixed timestep players on different classes of machines will experience very different behaviors, and it is often difficult to test or reproduce the behaviors during development.
 
This is why I wrote above to not simulate real life time inside game simulator time, doing so adds an enormous amount of complexity. Keep a simple number around to represent the time since your simulator's epoch.
 
A simple counter in your code is far easier than trying to emulate the amazingly complex time system used in real life. A time system based on an approximation of the time the Earth makes a revolution around its axis but in reality is always changing with every earthquake and even every meteor strike, and an approximation of the time the Earth orbits the Sun, which is off by roughly a quarter day but also slightly changes over time.

 

- At the start of each update frame in my time management class, I set timeEnd to the value of timeStart (set during the previous update), and timeStart to the current QPC() ticks. ... then update the gameTime and prevGameTime objects like so...

 
This is a big nasty bug waiting to happen.

 

Every time you take a step it is a variable amount of time.  You may advance 6ms, 8ms, 5ms, 15ms, 17ms, 6ms, 7ms, ... and that kind of variability causes problems.

 

Accumulate time, and only advance by the time step. If you picked a time of 10ms for your timestep, if at least 10ms has accumulated, advance a single step and subtract 10ms. So in the list above, first you accumulate 6ms and that isn't enough to advance a step. Then +8ms gives 14ms so you advance one step moving to 4ms accumulated. Adding 5ms gives 9ms accumulated, no simulate. Then you get +15ms bringing the total to 24ms so you advance the simulation twice, bringing you back to 4ms accumulated. +17ms gives 21ms accumulated so you advance the simulation twice and have 1ms accumulated. +6ms brings you to 7ms accumulated so no update. Then +7ms gives 14ms accumulated so advance your step by one.

 

While it may seem bad on paper to the player it provides much smother experiences. Everything moves at regular distances, physics works the same for everybody reducing the risk of various errant polygon problems. Collisions become problematic.  Minor errors in physics systems tend to explode during long steps, giving values that jump radically out of range, forces that launch game objects across the board at incredible speed, or even launch unsuspecting items into orbit and beyond.  Animations can be skipped partially or entirely, triggered events can be missed, and audio becomes a nightmare.

 

This goes back to fixing your timestep. Variable simulation is nasty business.

 

Am I right in thinking that over half a second is a huge amount of time to pass between runs of a loop that normally runs at 40ms, and that you really wouldn't expect this to happen unless it was something wrong in my code that was causing it? .. is it possible/normal/expected that a computer, even with 4 cores, may let a program like this hang now and then for as long as 700ms when it isn't even under heavy load?

 

Minor sputters and stalls like that happen all the time. Major pauses also happen quite often, but not as frequently. Your window gets resized or switched between apps, or the user switches between apps, or an alarm goes off on the system triggering some behavior on the machine, or the user intentionally deprioritizes your process, or the user shuts the laptop lid and reopens it later, or you stop the game in a debugger, or some other situation happens. 

 

A 700ms stutter isn't the kind of thing you see every frame, but you do see them often enough. It may happen because of bugs and glitches in your game. It may happen because the user happened to do something that spawned millions of particles and your buggy particle system didn't cap it. It may happen because the user took a moment to save the game and the game stalled as everything was written. Or maybe something external happened: immediately coming to mind are other processes fighting for resources, or the user switching processes, or sleep/suspend/wake cycles.

 

That is part of why it is vitally important that you fix your time step and only advance by incremental time steps and cap the time to a reasonable maximum step. For example, with a 10ms update you may want to cap it to 40ms maximum.




#5199130 C++ how to declare something that isn't declared?!?

Posted by frob on 19 December 2014 - 12:26 PM

Can any one explain the difference between these two lines?

  TSubparticle::Ptr p1, p2;
 
  TSubparticle* p3, p4;

 

In the first line the type is a pointer type, so both p1 and p2 are pointers.

 

In the second line the type is TSubparticle and only the first one is a pointer. p4 is actually an instance of type TSubparticle, not a pointer.

 

This and a few similar small 'gotachas' are a common reason coding standards often require only a single declaration per statement.




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

Posted by frob on 17 December 2014 - 10:48 PM

EDIT3: Hmmm... studying it now and what happens seems to be that something unexpectedly causes the game to enter the update loop even though there should be tons of rendering time left before then. The only reasons this might happen are...

while( getQPC() > next_game_tick && loops < Engine::MAX_FRAMESKIP )
...if loops < Engine::MAX_FRAMESKIP (that's definitely not it), OR... if next_game_tick finds itself smaller than getQPC().
 

Go back up to my first big wall of text where I specifically said to not do that.

Then go back up to my second block of text with a code snippit repeating and showing to accumulate time.

Never use a single block, a single count. Always accumulate time as you would in a stopwatch.

Count the time since the last time you came through the loop. Accumulate it in a buffer. When that time exceeds the amount of time in a simulator step, advance the simulator a single step. If the time exceeds two or three simulator steps, advance the simulator that many times. Each time you advance the simulator step, subtract that much time from the accumulator.
Then as a safety measure, if the time step of accumulated time is too long, cap it to a value like 3 or 4 or 5 simulator ticks.

Do not rely on individual time ticks. Individually they cause no end of problems. Accumulate time, and when enough time has passed on your stopwatch then advance your simulator.


#5198886 Item Discontinuity Problem

Posted by frob on 17 December 2014 - 10:36 PM

In some games for some items that makes sense. In some games for certain patterns, there can be far more than that to a game object.

While sometimes it does make sense to reduce the object down to a minimal piece of data or a single integer count, other times it can make sense to keep a full object around, especially in games where a game object has a large number of ancillary behaviors and data points.

As counter example to the "store just a count", there are games like The Sims where a simple game object comes with a high degree of custom information; custom textures and colors, custom date and location of of purchase, custom damage/repair history, custom usage count, custom purchase cost, custom depreciation cost. When placed in an inventory the relatively small data asset is moved into an inventory. The rendering and the UI thumbnail are both handled separately from the blob of data describing the game object, so they fall off into the cache and eventually vanish even though the game object is alive and well inside an inventory.

So while sometimes it is good to just store an index and a number, other times you will want to have a long-lived blob of data. It really depends on the game.


#5198580 html & opengl ( what should i use or should i recreate html render engine )

Posted by frob on 16 December 2014 - 01:45 PM

There are tools like webkitavailable.  It is/was the core for a bunch of modern browsers and is also used in many games. 

 

Know that HTML is a surprisingly complex language when it comes to rendering. Some parts of it are easy, but trying to cover all the stuff in the W3C standards is an enormous undertaking.




#5198561 Mobile Arcade

Posted by frob on 16 December 2014 - 12:08 PM

For a $0.99 game you'll have a hard time beating that with PayPal.

 

The fee they charge is 2.9% + $0.30 per sale.  For $0.99 that would be 33 cents, slightly more than what you pay for Google Play.

 

If you are charging more or have a high volume the story will be different, but you'll have a much harder time selling on your own without leveraging a marketplace.






PARTNERS