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!


Nypyren

Member Since 19 Aug 2002
Online Last Active Today, 09:51 PM

#5215983 Pros and Cons Unity for Android

Posted by Nypyren on 11 March 2015 - 11:22 PM

Originally I am a C# .NET developer but I am also very comfortable with Java. So what should I consider when making this decision?


I'm the same as you - Originally a C# .NET developer (WinForms and XNA, mainly) who is currently working on Unity games.

I have not used Android Studio for much (just rebuilding some plugins that another team wrote).

Unity on Android works great and is my opinion easier to deal with than the other three mobile platforms we support (iOS, WP8 and Metro). Code size problems are not as bad as it is on iOS, but Android's primary download limitation (not counting the OBB) is only 50 megs. sad.png

For decision making purposes: If you want to just make a game, use Unity. You're not going to suddenly decide to stop using an engine one day - there are too many good ones available that save a ton of time. You won't need to worry about writing your own renderer, and if you decide to, you will have ideas from Unity to lean on.

kburkhart84 is right that Unity's runtime libraries are pretty large. Rough sizes (some are out of date since I have an older version of Unity here at home):

Android: libunity.so, libmono.so and libmain.so add up to roughly 14 megs.
iOS: Your code will be AOT compiled and statically linked to Unity's libs. Our game is HUGE and has a ~30 meg iOS executable (this includes our code so it's hard to tell how much is Unity and how much is us). This will get DRAMATICALLY worse once Apple starts enforcing their ARM AArch32/AArch64 combined fat binary mandate.
WP8/Metro: Several DLLs of different sizes and flavors (ARM/x86, debug/master) - varies between 7-12 megs or so. The current downside on these platforms is that the build process is horrifically Frankenstein'd together and will explode at the drop of a pin.

Textures will likely be your #1 size problem though for an ambitious game. We have a seriously massive codebase at work (we have about every single type of software system you can imagine included in our game), and while code size is pretty depressing, it STILL isn't as bad as textures.


#5215980 When will the new API-Vulkan, from Khronos Group?

Posted by Nypyren on 11 March 2015 - 10:44 PM

First they came for the verbs, and I said nothing because verbing weirds language. Then they arrival for the nouns, and I speech nothing because I no verbs.




#5215979 C# Interview test "failed"? Why?

Posted by Nypyren on 11 March 2015 - 10:40 PM

...and that vec3 isn't a c# thing as we have a native vector3 class.


Vector3 is a Unity-specific thing (well, other game frameworks like XNA have similar vector types).

I wouldn't call any of them native - C# and .Net's core libraries don't have any built-in vector types that I know of. The Windows-specific class libraries like WinForms and WPF have vector/point classes, but I wouldn't consider them to be native either.


#5215974 C# Interview test "failed"? Why?

Posted by Nypyren on 11 March 2015 - 10:12 PM

If you get more tests where the problem looks like it isn't correct, do three things:

- Leave a comment at the start of your answer about the question possibly having a typo in it, but don't be snarky like I was. Programming interviewers come in two flavors: Complete assholes who will resent you for pointing out mistakes, and people who like the fact that you can spot errors. Pointing out a mistake to an interviewer needs to be done cautiously since you don't know what kind of person they are.

- Solve the problem as if it were not a trick question - try to fix the question first, then solve it.

- Make sure your code compiles and runs properly! If it's a test where you have access to a computer, there's no reason not to make a working program. If it's on paper, then it's a bit more excusable. smile.png


#5215970 C# Interview test "failed"? Why?

Posted by Nypyren on 11 March 2015 - 09:46 PM

It seems like you're familiar with programming concepts, but you don't check to make sure your code actually works, and you frequently use the wrong terminology or answer things in cumbersome ways.

Throughout the interview, the questions look like they're mixing C++ and C#. They put semicolons after structs (you don't need that in C#). Problem 3 would compile in C++ but not C# (C# doesn't have "unsigned int" - it has uint - and uints cannot be cast to bools implicitly). For problem 6 they totally Frankenstein'd that struct definition - that sucker won't compile in C++ or C#.


1. Your use of terminology is off a bit. You got the heap/stack allocation part wrong.

2. Your terminology is way off but it feels like you have the right idea.

3. That function will not compile in C#. Might be an interviewer mistake or a trick question.

4. Sorting problems are too painful to eyeball quickly.

5. Your function does not compile.

6. C# structs cannot be recursively defined, the problem is possibly a trick question. If it was a class instead and actually compiled, your implementation has typos and would stack overflow due to infinite recursion. You also wouldn't need to use 'ref'.

7. Sorting problems are too painful to eyeball quickly.

8. Your code won't compile. a, b, c, up?

9. Your code won't compile. direction is not defined in your function's scope.

10a. I think they mean that the bullet's path is a one-frame line segment, and they want you to see if the player is close enough to the line segment.

10b. Sounds reasonable. XML is overkill though.


#5215762 Best programming paradigm for noobs?

Posted by Nypyren on 10 March 2015 - 08:36 PM

I think you should learn everything. If you only know how to do one thing, you'll try to use it no matter how inapplicable it might be.


#5215601 x86 / x64 and the crazy conditional moves based on flags

Posted by Nypyren on 10 March 2015 - 01:58 AM

if(x != y){ cmp x,y
a = 24 movne a, 24
}

 
Are you sure you were reading about x86/x64? Because MOVNE is an ARM instruction...


Well, x86's is (F)CMOVNE|Z, but we all still knew what he meant...


#5215458 Getting out of the industry?

Posted by Nypyren on 09 March 2015 - 12:23 PM

Definitely depends on where you work. I work in mobile game dev and haven't worked crunch in the last 5 years...


As far as crunch goes, the only way to stop it is to change it from inside. Companies that can't profit from standard work hours should be allowed to fail spectacularly. Eventually managers and creative leads will learn how to limit scope. I have no pity for the herd mentality that accepts crunch time as acceptable.

(Edit) I came back to my post and felt it deserved more details.


OK. For those of you who have managed to get inside the industry already (congratulations!), YOU are partially responsible for getting rid of crunch. Things you should attempt to do while at the job:

- Earn respect from your coworkers by kicking ass at your job. But don't overwork yourself to accomplish this. Improve your efficiency rather than brute forcing your work. Respect is necessary in order to get other people to take you seriously.

- Don't blindly implement what you're asked to. You're not a cog in a machine - your ideas matter. Think about the problem and the design and look for things to make your life easier. Discuss different approaches with the person in charge of your feature.

- Is a feature ABSOLUTELY necessary? Would it harm the product if it was removed? If not, then it's a candidate to be cut from the game, and cutting features is the easiest way to reduce crunch.

- Try to avoid features which interact with lots of different parts of the code, especially if the benefit from implementing the feature is minimal. These kinds of things cause huge maintenance headaches and are usually the source of most bugs. Fewer of these means less wasted time, and that means less crunch.

- Never work in a vacuum. Always talk with your manager/peers about things. Other people will see things you've missed before you've spent time implementing something, and can save you from going down the wrong path.

- Think up ways to make *everyone's* lives easier. Programmers aren't the only ones suffering from unnecessary crunch time. Do the artists need someone to optimize an exporter so they don't waste time? Perhaps a data validation tool for the designers can prevent costly mistakes?

- There are always hidden inefficiencies in the development process. Perhaps your builds take a long time, but everyone has always accepted that as normal. Maybe it can be drastically improved?! Try to find and eliminate them.

- If you run into some kind of annoyance in the development process (build times, compile warnings, source control hassles, etc), chances are everyone else will run into it, too. It may be worth it to eliminate even minor annoyances as soon as possible so that you save everyone more sanity.

- Voice concerns to your boss! Always try to make your criticism optimistic rather than pessimistic. Control your delivery. Avoid sounding like you're whining.


#5215235 what is the best?

Posted by Nypyren on 07 March 2015 - 10:33 PM

To crush your enemies, see them driven before you, and hear the lamentation of their women.


Dammit, I was going to use this...


#5215060 GUI help

Posted by Nypyren on 06 March 2015 - 07:06 PM

Rendering: Draw a textured rectangle and some text if the button needs text.
Input handling: Detect when the mouse is within the rectangle. Have the renderer change the rectangle's color in this situation.
Input handling: If the mouse is clicked (up->down->up) while still inside the button, treat it as a button press.


#5214609 Unity - Script Languages

Posted by Nypyren on 04 March 2015 - 08:01 PM

Unity lets you use Unityscript, which *looks* like Javascript, but is not.

Unity also lets you use C#, which is *actual* C# and not a special interpretation of it.


Beware of people that tell you that a particular language is "easy". When people say "easy" when talking about programming, they *usually* mean "easy to throw code together without thinking about writing good code" and not "easy to write good code and maintain large games".


#5214366 Game Perfomance

Posted by Nypyren on 03 March 2015 - 10:55 PM

Everything decreases performance. A profiler is the only thing that will tell you the truth in more detail.


#5214094 Saw a job listing for a gaming company, but not exactly game development.

Posted by Nypyren on 02 March 2015 - 09:22 PM

If the web site is more than just a barebones "About Us / Contact Info" site like most game studios have, then it might be worth it. If it's a huge site which hosts web games and has infrastructure for game-related activities, then definitely. If it doesn't really have anything to do with the games themselves, then I wouldn't really count it as game development experience.

Either way, if the job involves working on-site, you may be able to switch roles to a game team eventually - if you can prove to them that you have the skills they want.


#5214085 Best approach for Asteroids-style movement/physics?

Posted by Nypyren on 02 March 2015 - 07:45 PM

Any thoughts on how to approach this?


Persistent variables reused every frame
{
  Vector2D position;
  Vector2D velocity;
  Vector2D acceleration;
  float shipHeadingRadians;
  const float shipThrust = whatever.0f;
}

Each frame, only if the player is applying thrust
{
  acceleration.x += shipThrust * cos(shipHeadingRadians);
  acceleration.y += shipThrust * sin(shipHeadingRadians);
}

Each frame, regardless of whether player presses anything
{
  position += velocity * timestep;
  velocity += acceleration * timestep;
  acceleration.x = 0;
  acceleration.y = 0;
}
If you want friction, the simplest way is to multiply velocity by a constant value slightly less than 1 every frame.


#5213813 data storage in HTML5 for android

Posted by Nypyren on 01 March 2015 - 10:59 PM

One possibility is that you install your own lightweight web service on the device the user is playing on, and make 'localhost' HTTP requests to it. It seems like a hack, but this shouldn't take too much effort.

Also, Chrome on Android apparently has (had?) support for a nonstandard HTML5 FileSystem API which you could try, but I know nothing about it.

I haven't used HTML5 myself. It's possible there's something built-in which can do this for you.




PARTNERS