# Sacaldur

Member Since 25 Mar 2013
Offline Last Active May 21 2017 10:16 AM

### #5317329Trying to spawn boxes just outside the cameras viewing rect

Posted by on 30 October 2016 - 04:20 PM

The value stored in orthographic size is just the "vertical size". Since the camera is most certainly not showing a perfectly rectengular view of the game, the "horizontal size" is a different value. You can calculate that by horizontal size = vertical size / height * width. Since the aspect ratio is already calculated with a aspect ratio = width / height, you can shorten the calculation to just horizontal size = vertical size * aspect ratio

### #5317226Trying to spawn boxes just outside the cameras viewing rect

Posted by on 29 October 2016 - 06:33 PM

He mentioned he is using an orthographic camera, so the depth shouldn't be a problem.

Take a look at the (orthographic) size of the camera. This value is half of what the camera whill capture on the vertical axis. If you add/subtract it to/from the y-position of the camera, you'll get the upper/lower edge. To get the left/right edge, you'll have to multiply it with the cameras espect ratio, and add/subtract the result to/from the x value. The property "aspect" should be the one you can use for that, otherwise you can calculate it by deviding the viewport width by the viewport height.
After you got the the corner, you'll need to add/subtract half the objects size you want to spawn in order for it to be just outside the cameras view.
(All this assumes your camera is not rotated. If it's rotated in 90° steps, you'll just need to swap some angles or invert some values. If it is another angle, you'll need to do some more math, but the basic calculation should be the same.)

Btw: The C# tag is visible in the topic overview, the Unity tag is not. You might want to change the order of the tags, since Unity is the most important information in this case.

### #5316514Unity Software Architecture - how to make reusable UI classes that inherit fr...

Posted by on 24 October 2016 - 02:59 PM

As others pointed out already, it would be better for you to just direclty use the methods and properties already available. Hiding an Image should be done by deactivating the game object. (This way, it also doesn't matter if it is an image, a text, or a composition of multiple UI elements.)
Same goes for setting the image: just assign it directly, unless you want to apply some special logic that really needs to be encapsulated in another component.

Besides that: You should store references to components you're using multiple times. Searching for them every time using "GetComponent" takes more time. If it is done once a frame, it's really worth the refactoring.
Also, you should calculate your _imageIndex with something like this._imageIndex = (this._imageIndex + 1) % this.sweepingFrames.Length;

### #5237650what is best way to check a code is more effiecient and runs faster than others

Posted by on 30 June 2015 - 02:54 AM

By "i work with it as unity script" you mean you're using C# as scripting language in Unity, right? "UnityScript" is what the guys behind Unity call "JavaScript", without actually being JavaScript.
Then you should just take a look at the Unity Profiler first. I guess it's available for free, now that Unity 5 contains all engine features in the "personal edition" (in the free version).
Including any other profilers could be troublesome, since you don't have a Visual Studio solution to run the entire code yourself.

### #5237632If-else coding style

Posted by on 30 June 2015 - 01:25 AM

I prefer to handle the regular/good case in any kind of code first, and exceptions afterwards. So I'd do
`return isValidCondition ? value : null;`
`return !isValidCondition ? null : value`
I also know some people who do handle exceptions and break conditions first, and they write code like
```foreach (MyType value in values) {

if (!handleValueCondition) {
continue;
}

//
// doing stuff with the value
// .
// .
// .
//
}```
On the other hand, I never omit braces for if and else (given a proper indentation, it's less about readybility, but more about not having to place them as soon as more code is required), and I always place an else, if possible. As an example, the code you currently use would be more like
```SomeType result;
if (somecondition) {
result = something;
} else {
result = null;
}
return result;```
(Don't get me wrong, I still prefer the initial solution or the solution including the ternary operator, depending on the complexity of the condition and the calculation.)

And in my opinion, when I look at the content of a method or a property, I first want to know what it's doing, and not what it's not doing. If you have many conditions for execution (or the other way around: if you have to many break conditinos), your code is just "complex" and you're probably better off simplifieng it, instead of hiding the complexity.

And you really should name properties the same way as vairables - without a preceding "Get".

### #5236891Setting up a basic engine: Rendering + Physics

Posted by on 26 June 2015 - 04:51 AM

1. How many of the big engine developing companies (the guys behind Unity, Unreal Engine, Source Engine, Havoc, PhysX, and so on) went bankrupt, or suddenly changed their terms and conditions to the worse? For all I know, using their engines got even cheaper over time with much less restrictions.

2. I don't think I need to be able to implement an optimized physics engine in order to use it - no matter whether I'm using it directly or my engine already includes it. Don't get me wrong: having knowledge about how it is implemented is beneficial, but you certainly don't need to implement it yourself. (And by the way: what's a "complex game" in your opinion?)

3. What is flexibility? In almost any good engine, the limits you have are fairly small. Even if an engine doesn't support you with certain aspects of your game (voxel handling), you're still able to implement it yourself. Why games are crappy is not only a matter of opinion, but there are many things involved. And engines are not even a minor reason. A good developer chooses his tools (engine or custom stuff) based on the design, not the other way around.

4. Many times the GPU is the bottleneck for your games, at least that's true - even though it depends on the implementation of the game. But in order to make things look good, you need people to make good looking assets (models, textures, shaders, animations, and so on). Since many programmers aren't good at creating these assets, the statement "It's not hard to make things look good" is just not right, even if the programmer could implement the entire rendering system. (And a genius can do things in more efficient ways, or just much faster.)

5. I already met many people who used Unity, and I can't remember anyone of them to "change Unity" in some way, or to switch to a selfmade "engine" entirely, just for a single game.

Maybe you just used the wrong tools? The reason for using already existing tools and libraries is to reduce the required workload to finish a game. At least in the real business, it's all about making games, not about making engines. Why should you e. g. write your own physics engine instead of using already existing ones? Why wasting hundreds of hours instead of a fraction for tweaking the physics values?

### #5232331Salary expectations when relocating to other countries

Posted by on 02 June 2015 - 02:48 AM

The location within Germany is very important. The difference in salaries e. g. between Berlin and Bavaria is huge, since the costs of living (like rents) are different.
I don't know in which city the company is located, but it's very likely one of Berlin, Hamburg, and Munich. You could try to find some informations about average salaries in different regions, or try to estimate what you'd need based on your future expenses (rents, public transportation, ...). If you can't find any numbers for gamedev related positions, you could still take a look at other IT jobs (but I heard many times, salaries in gamedev are lower compared to regular IT salaries).

### #5220460how compeletely free games,apps,services,sites, libraries make money?

Posted by on 31 March 2015 - 05:11 AM

Some projects are completely free and the developers do it just because they love coding cool stuff.

Another reason for making a game completely free (of payments, advertisement, sold user data, and so on) is ones portfolio/reputation. Having a good piece of work on his/her portfolio could give a good impression to potential employers, clients (e. g. contract work), or investors. The Android App Timely is for all I know a good example, since the company was bought after releasing this app (without any previous releases). Another one is Öffi, which is developed by a freelancing developer.
A developer could also aim to get some media coverage by making a game related to a hot topic. An example would be "Abbruch Bayer" (which translates to something like "Bavaria demolition", in contrast to "Aufbruch Bayern"/"upswing Bavaria", the original game made by a political party about some numbers and values of Bavaria). Sadly, the linked article is only available in german, since the covered topic only has a local significance.

These are reasons a person, team or company could consider, but there are much less games (and applications) release with this intent, instead of "free" ones with some kind of monetization.

### #5219330Unity3D and open source project

Posted by on 26 March 2015 - 09:13 AM

I'm sorry if my post was a bit misleading. I didn't want to accuse you of demanding openness of the engine. But if you would need to upload (Git/SVN/...) something related to the engine, i. e. the engines source code or standard scripts/assets, in order for your project to be executable, you would implie these files to be open source licensed (and thus demand the engine to be open source).
If this is not a problem, you would still need to list exactly what licenses apply to what files.

Making your project openly available is not a problem, as long as you don't publish something you're not allowed to publish.

### #5211652Making small ideas work

Posted by on 19 February 2015 - 04:19 AM

Don't confuse small ideas with small execution. Small ideas rarely works. Also don't confuse number of features with a deep & complex gameplay.

Check my "WizTowerSim": http://www.silverlemur.com/minigames/
Is this game simple or complex? How long would it take you to implement something like that?

You can make a complex & interesting game in a few days/weeks. If you use dirty tricks of course

It's funny because the little game I have right now looks a bit like this or I should say has the same basics. It's some stuff where you build your base and every random amount of times you get a random attack and you have to survive it. At least that's the final goal but it's not finished yet (almost tho when it comes to programming).

I think the main idea is not bad but random events part of it sucks, I wanted to make it multiplayer but I am not good enough at coding networks. So this is the kind of thing that pisses me off a bit.

Do not escalate   No multiplayer, you are not looking how to add yourself more work but how to remove some work
If you have a working concept, go for it. Do not add unneeded things.

"No multiplayer" isn't a good general advice. It should be more like "no networking"!
"Multiplayer" doesn't automatically imply networking, since local multiplayers are possible, too. Also, many multiplayer games are much easier to create, since you don't have to implement an AI, you most likely won't need that much content, but the game could still be fun to play.
You can overwhelm yourself with a multiplayer game to big for your current skills, but you can do the same with singleplayer games. But in the end, it depends on the game.

### #5211142Making small ideas work

Posted by on 17 February 2015 - 03:29 AM

If you didn't play some smaller games, you should just play some of them. You should have played games like simple platformers, tower defenses, pong, snake, breakout, puzzle games, and other mini games.
Another problem about your ideas is: they are just ideas, but you can only find out for sure if your game idea is fun, when you're able to play it, e. g. by having a playable prototype. Also it's possible to make almost any idea fun, just by iterating over it and searching for aspects to improve on.

Keep in mind: a game isn't necessarily "fun" because it implements a "good idea", but most games are fun to play because it feels good to play them. In this regard you should take a look at e. g. the Talk "Juice It or Lose It" (by Martin Jonassan and Petri Purho) or the talk about game feel (by Jan Willem Nijman). By listening to the talks you should recognize: you can make almost any game a fun to play game.

Posted by on 13 February 2015 - 09:09 AM

There are already comparable articles, but you maybe took a slightly different approach. It would be interesting to see your article about this topic, as well as the differences between your approach and e. g. the approach described on redblobgames.com. Even if there are no differences at all, you still could make an article about how to implement it, or how to use specific (language) features to implement it.

### #5209057Programmer vs Artist

Posted by on 06 February 2015 - 08:26 AM

The programmer should have the most knowledge about the targetted platform, and thus has to give requirements to the artists, e. g. regarding the texture resolutions, polygon count, shaders, file formats, and so on.

The artists (2D and 3D) either want to integrate their graphics and models into the game, or give them to the programmer. Letting the artist integrate his assets by himself would be the best option, since this way the artist would not only be able to embed all assets in the game, and to adjust some settings on them, but he would also be able to check, in what way he might has to rework his assets.
If you're not already using tools for the game to integrate the assets, the programmer either has to integrate them, or he has to build the required tools. The artists will either have demands for the tools, or they will find new requirements during their daily use of the tools.

If the 2D artist creates textures for the 3D models, the 2D artist will either give the textures to the 3D artist to include them in the model files, or the textures will be combined by the programmer or using the mentioned tools. The 2D artist needs to know, how to create the textures - how they are mapped onto the models.

That's at least what came to my mind right now, so there still could be some more aspects.

### #5208179When you realize how dumb a bug is...

Posted by on 02 February 2015 - 07:13 AM

I once did something (in JavaScript) like:
```function Category() {
//...
}
Category.prototype.entries = [];```
And I wondered, why all elements created with "new Category()" contained the same entries.
As a hint, this one works:
```function Category() {
//...
this.entries = [];
}```

Since it was a test with a new framework (AngularJS), I almost started to blame the framework for not doing it right. It didn't took to long to figure it out, but it's still embarrassing...

### #5207112Best Way to Save Player Information?

Posted by on 28 January 2015 - 03:21 AM

There are Libraries for a huge variation of languages for both, XML and JSON. For the latter one, just take a look at json.org for a list of librearies for JSON parsing and serialisation. It's not hard to use these libraries, but it could require lot's of code. There are also more advanced libraries to not only parse and store XML or JSON, but they also analyse your data structures, e. g. by checking for annotations, and automatically generate and read XML or JSON, just from your data structures. At least in my opinion the problem about this automatic serialisation is the generated structure. Some libraries generate a child node for each list/array, containing the child nodes themselfes, even though there is only 1 list and all entries could be put into the element itself. A simple example:
```<playlist name="My Playlist">
<tracks>
<track [...]/>
<track [...]/>
</tracks>
</playlist>```
```<playlist name="My Playlist">
<track [...]/>
<track [...]/>
</playlist>```
But still: these libraries reduce the amount of code you have to write.

You can store any kind of Text in a properties file. This way, you're able to store numbers as well, but you need to store them as text - just as you have to do with every other text based file format - and you would have to parse them yourself - by calling Integer.parseInt().
Also: the order of the entries in a properties file shouldn't matter at all. You're reading the values using the keys, but you don't have to know the exact order.

Besides Properties, XML, and JSON, there are INI files as well. They are comparable with Properties files, but have some more features (e. g. sections) by default, but the set of features varies depending on the implementation.
And you could use your own file format, but since you would need to implement the file parsing yourself, you should just stick to one of the mentioned file formats.

If you don't know, which format to use for your files: just stick to what you already have (properties I guess) until you encounter some seriour issues regarding the format. Then you'll be able to make a better decision, since you know what problem you'll have to solve with another.