• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Sacaldur

Members
  • Content count

    47
  • Joined

  • Last visited

Community Reputation

932 Good

About Sacaldur

  • Rank
    Member

Personal Information

  • Location
    Berlin
  1. The problem about this is: you might be able to use this for Image-Components of the new UI System ([tt]UnityEngine.UI.Image[/tt]), but you'd need to create a sprite on the fly, which is more expensive.
  2.   Yeah, that worked, thanks :) No, that value is not the top edge of the camera, but it is its center. If it results in the desired behavior, the problem lies at another place. The camera in use might not be the main camera, resulting in [tt]Camera.main[/tt] returning the wrong camera. The spawned object might not be "centered" properly, meaning its position is not in its center. Without further knowledge about the GameObjects in the scene and the other code, I can't say with certainty what the reason for this actually is. Btw: you're better of not using [tt]Camera.main[/tt], since it probably makes a search for the proper camera by the Tag "MainCamera" every time you want to retrieve the camera. Depending on how often you use it, this could affect the performance of the game. Also, by not searching for the object you want to use, but by getting it assigned from outside, your code is getting rid of dependencies. (See "inversion of control".)
  3. 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 [tt]horizontal size = vertical size / height * width[/tt]. Since the aspect ratio is already calculated with a [tt]aspect ratio = width / height[/tt], you can shorten the calculation to just [tt]horizontal size = vertical size * aspect ratio[/tt]
  4. 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.
  5. While you're creating the UI, you know what you're using. In general, this should be Image (those are using Sprites). In some special cases, e. g. when the content is generated on runtime (e. g. once a second or more frequently), then the RawImage should be used, and only then. (If the Image is generated very seldomly, you could generate a Spriteout of it, but since its a somewhat costly operations, you can't do it to frequently, since this would have a huge impact on the performance.) Right now, you might still have some GUITextures, but since you're starting to use the new UI system, you should get rid of anything done in the old UI system as fast as possible. Once that is done, you don't need those tightly-GUITexture-coupled anymore. In the end, if there is no reason to do otherwise, you should _only_ have 1 Image component in use. And even if you'll need to use RawImage additionally for some special cases, you will know if it is a generated Texture (-> RawImage) or a predefined Sprite (-> Image). So you know the proper type and you won't need abstraction. Btw.: you have 8 tightly coupled scripts. What are those scripts doing?
  6. 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 [tt]_imageIndex[/tt] with something like [tt]this._imageIndex = (this._imageIndex + 1) % this.sweepingFrames.Length;[/tt]
  7. But sadly, this was the problem, since the accepted solution is: SomeType result = null; if (somecondition) {     result = something; } return result;Personally I'm not a huge fan of that, since it forces the reader to track the state of "result" as they look through the code, but it's used in many other places in our codebase, and consistency adds value. Regarding the Name "GetSomething": properties in C# should never have a "Get", or "Set" as a prefix, so the name is wrong in any case. But let's say, in order to get the value you want, you would need to do some calculations (the "magnitude" in Unitys Vector2 and Vector3 as an example), would you call a Method to get this value "GetMagnitude" or "CalculateMagnitude"? Does it matter for the calling site, whether or not the value is cached in a variable, or calculated on the fly? In my opinion, "GetMagnitude" would be more suitable, since it doesn't define how the magnitude is retrieved. A "GetMeSomething" method doesn't imply the return of a member variable, and it shouldn't. You can see it this way: if you have a Vector and you want to get it's magnitude, you call it with "give me your magnitude" (assuming you can talk with your Vector, which I honestly can't do), what translates to the method name "GetMagnitude". Before you respond, you should keep in mind: for me, object orientation isn't that much about the manipulation of data (member variables), but it's more about objects and their interactions.
  8. As I tried to state earlier: "someCondition" is probably neither a member, nor a parameter, nor a local variable, nor a property. It's very likely just a placeholder for the real condition, as well as "something" is probably a placeholder for an evaluation/calculation.
  9. @kytoo: If all components are assigned to the same GameObject, you should instead use the RequireComponent-Attribute. public class SpartanKing : PlayerShape { } public class PlayerData : MonoBehaviour { } [RequireComponent(typeof(SpartanKing))] [RequireComponent(typeof(PlayerData))] public class Player : MonoBehaviour { void Start() { } }Unity will automatically assign the required components, as long as it's possible to assign them. Otherwise - an abstract class is required, such as "Collider" - you'll get an error message while trying to assign the component to a GameObject.
  10. @Graelig: It really depends on the "somecondition", and we just don't know, what it actually is. If it's a simple null-check for "something" and "something" is just a private or protected member, just returning it would be the most simple thing. But if you're not just returning a member or if the condition is more than a simple null check, you can't omit the condition. And by the way: it's a (C#) property, not a method. The name GetSomething is misleading (it should be called GetSomething instead), but you still can't call/invoke it. ;) @JohnnyCode: What do you mean by "not reevaluating the condition"? As soon as the value of the property is requested, the "get"-code is executed, thus the "somecondition" is evaluated. (And we can assume it's not just a variable, but a shortening of the real code.)
  11. 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.
  12. 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;instead of return !isValidCondition ? null : valueI 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".
  13. 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?
  14. You should, whenever possible, assign the required GameObject instead of searching for it in the scene. This way, some one else could see the dependency in the inspector, since you have to assign the GameObject. (And it should be faster this way.) If it's not possible (the GameObjects are in difference Scenes), you should make the GameObjet's name editable through the inspector. Besides that: why are you using Keycodes? You can use the Axes of the input system as buttons as well, and you should do so. Furthermore you check for inputs in the "Player" and in the "SpartanKing" Component, with the Player forwarding the informations to the PlayerShape (and thus to the SpartanKing). Only one of them should handle the input. (So you would only need to replace the "Player-Input"-Component by a "AI-Input"-Component.)