Advertisement Jump to content
  • Advertisement

Search the Community

Showing results for tags 'Education'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Audio
    • Music and Sound FX
  • Business
    • Business and Law
    • Career Development
    • Production and Management
  • Game Design
    • Game Design and Theory
    • Writing for Games
    • UX for Games
  • Industry
    • Interviews
    • Event Coverage
  • Programming
    • Artificial Intelligence
    • General and Gameplay Programming
    • Graphics and GPU Programming
    • Engines and Middleware
    • Math and Physics
    • Networking and Multiplayer
  • Visual Arts
  • Archive


  • Audio
  • Visual Arts
  • Programming
  • Writing


  • Game Dev Loadout
  • Game Dev Unchained


  • Game Developers Conference
    • GDC 2017
    • GDC 2018
  • Power-Up Digital Games Conference
    • PDGC I: Words of Wisdom
    • PDGC II: The Devs Strike Back
    • PDGC III: Syntax Error


  • Audio
    • Music and Sound FX
  • Business
    • Games Career Development
    • Production and Management
    • Games Business and Law
  • Game Design
    • Game Design and Theory
    • Writing for Games
  • Programming
    • Artificial Intelligence
    • Engines and Middleware
    • General and Gameplay Programming
    • Graphics and GPU Programming
    • Math and Physics
    • Networking and Multiplayer
  • Visual Arts
    • 2D and 3D Art
    • Critique and Feedback
  • Community
    • GameDev Challenges
    • GDNet+ Member Forum
    • GDNet Lounge
    • GDNet Comments, Suggestions, and Ideas
    • Coding Horrors
    • Your Announcements
    • Hobby Project Classifieds
    • Indie Showcase
    • Article Writing
  • Affiliates
    • NeHe Productions
    • AngelCode
  • Topical
    • Virtual and Augmented Reality
    • News
  • Workshops
    • C# Workshop
    • CPP Workshop
    • Freehand Drawing Workshop
    • Hands-On Interactive Game Development
    • SICP Workshop
    • XNA 4.0 Workshop
  • Archive
    • Topical
    • Affiliates
    • Contests
    • Technical
  • GameDev Challenges's Topics
  • For Beginners's Forum
  • Unreal Engine Users's Unreal Engine Group Forum


  • Community Calendar
  • Games Industry Events
  • Game Jams
  • GameDev Challenges's Schedule


There are no results to display.

There are no results to display.

Product Groups

  • Advertisements
  • GameDev Gear

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



About Me







Found 149 results

  1. Hodgman

    OOP is dead, long live OOP

    edit: Seeing this has been linked outside of game-development circles: "ECS" (this wikipedia page is garbage, btw -- it conflates EC-frameworks and ECS-frameworks, which aren't the same...) is a faux-pattern circulated within game-dev communities, which is basically a version of the relational model, where "entities" are just ID's that represent a formless object, "components" are rows in specific tables that reference an ID, and "systems" are procedural code that can modify the components. This "pattern" is always posed as a solution to an over-use of inheritance, without mentioning that an over-use of inheritance is actually bad under OOP guidelines. Hence the rant. This isn't the "one true way" to write software. It's getting people to actually look at existing design guidelines. Inspiration This blog post is inspired by Aras Pranckevičius' recent publication of a talk aimed at junior programmers, designed to get them to come to terms with new "ECS" architectures. Aras follows the typical pattern (explained below), where he shows some terrible OOP code and then shows that the relational model is a great alternative solution (but calls it "ECS" instead of relational). This is not a swipe at Aras at all - I'm a fan of his work and commend him on the great presentation! The reason I'm picking on his presentation in particular instead of the hundred other ECS posts that have been made on the interwebs, is because he's gone through the effort of actually publishing a git repository to go along with his presentation, which contains a simple little "game" as a playground for demonstrating different architecture choices. This tiny project makes it easy for me to actually, concretely demonstrate my points, so, thanks Aras! You can find Aras' slides at - ECS-DoD.pdf and the code at I'm not going to analyse the final ECS architecture from that talk (yet?), but I'm going to focus on the straw-man "bad OOP" code from the start. I'll show what it would look like if we actually fix all of the OOD rule violations. Spoiler: fixing the OOD violations actually results in a similar performance improvement to Aras' ECS conversion, plus it actually uses less RAM and requires less lines of code than the ECS version! TL;DR: Before you decide that OOP is shit and ECS is great, stop and learn OOD (to know how to use OOP properly) and learn relational (to know how to use ECS properly too). I've been a long-time ranter in many "ECS" threads on the forum, partly because I don't think it deserves to exist as a term (spoiler: it's just a an ad-hoc version of the relational model), but because almost every single blog, presentation, or article that promotes the "ECS" pattern follows the same structure: Show some terrible OOP code, which has a terribly flawed design based on an over-use of inheritance (and incidentally, a design that breaks many OOD rules). Show that composition is a better solution than inheritance (and don't mention that OOD actually teaches this same lesson). Show that the relational model is a great fit for games (but call it "ECS"). This structure grinds my gears because: (A) it's a straw-man argument.. it's apples to oranges (bad code vs good code)... which just feels dishonest, even if it's unintentional and not actually required to show that your new architecture is good, but more importantly: (B) it has the side effect of suppressing knowledge and unintentionally discouraging readers from interacting with half a century of existing research. The relational model was first written about in the 1960's. Through the 70's and 80's this model was refined extensively. There's common beginners questions like "which class should I put this data in?", which is often answered in vague terms like "you just need to gain experience and you'll know by feel"... but in the 70's this question was extensively pondered and solved in the general case in formal terms; it's called database normalization. By ignoring existing research and presenting ECS as a completely new and novel solution, you're hiding this knowledge from new programmers. Object oriented programming dates back just as far, if not further (work in the 1950's began to explore the style)! However, it was in the 1990's that OO became a fad - hyped, viral and very quickly, the dominant programming paradigm. A slew of new OO languages exploded in popularity including Java and (the standardized version of) C++. However, because it was a hype-train, everyone needed to know this new buzzword to put on their resume, yet no one really groked it. These new languages had added a lot of OO features as keywords -- class, virtual, extends, implements -- and I would argue that it's at this point that OO split into two distinct entities with a life of their own. I will refer to the use of these OO-inspired language features as "OOP", and the use of OO-inspired design/architecture techniques as "OOD". Everyone picked up OOP very quickly. Schools taught OO classes that were efficient at churning out new OOP programmers.... yet knowledge of OOD lagged behind. I argue that code that uses OOP language features, but does not follow OOD design rules is not OO code. Most anti-OOP rants are eviscerating code that is not actually OO code. OOP code has a very bad reputation, I assert in part due to the fact that, most OOP code does not follow OOD rules, thus isn't actually "true" OO code. Background As mentioned above, the 1990's was the peak of the "OO fad", and it's during this time that "bad OOP" was probably at its worst. If you studied OOP during this time, you probably learned "The 4 pillars of OOP": Abstraction Encapsulation Polymorphism Inheritance I'd prefer to call these "4 tools of OOP" rather than 4 pillars. These are tools that you can use to solve problems. Simply learning how a tool works is not enough though, you need to know when you should be using them... It's irresponsible for educators to teach people a new tool without also teaching them when it's appropriate to use each of them. In the early 2000's, there was a push-back against the rampant misuse of these tools, a kind of second-wave of OOD thought. Out of this came the SOLID mnemonic to use as a quick way to evaluate a design's strength. Note that most of these bits of advice were well actually widely circulated in the 90's, but didn't yet have the cool acronym to cement them as the five core rules... Single responsibility principle. Every class should have one reason to change. If class "A" has two responsibilities, create a new class "B" and "C" to handle each of them in isolation, and then compose "A" out of "B" and "C". Open/closed principle. Software changes over time (i.e. maintenance is important). Try to put the parts that are likely to change into implementations (i.e. concrete classes) and build interfaces around the parts that are unlikely to change (e.g. abstract base classes). Liskov substitution principle. Every implementation of an interface needs to 100% comply the requirements of that interface. i.e. any algorithm that works on the interface, should continue to work for every implementation. Interface segregation principle. Keep interfaces as small as possible, in order to ensure that each part of the code "knows about" the least amount of the code-base as possible. i.e. avoid unnecessary dependencies. This is also just good advice in C++ where compile times suck if you don't follow this advice Dependency inversion principle. Instead of having two concrete implementations communicate directly (and depend on each other), they can usually be decoupled by formalizing their communication interface as a third class that acts as an interface between them. This could be an abstract base class that defines the method calls used between them, or even just a POD struct that defines the data passed between them. Not included in the SOLID acronym, but I would argue is just as important is the: Composite reuse principle. Composition is the right default™. Inheritance should be reserved for use when it's absolutely required. This gives us SOLID-C(++) From now on, I'll refer to these by their three letter acronyms -- SRP, OCP, LSP, ISP, DIP, CRP... A few other notes: In OOD, interfaces and implementations are ideas that don't map to any specific OOP keywords. In C++, we often create interfaces with abstract base classes and virtual functions, and then implementations inherit from those base classes... but that is just one specific way to achieve the idea of an interface. In C++, we can also use PIMPL, opaque pointers, duck typing, typedefs, etc... You can create an OOD design and then implement it in C, where there aren't any OOP language keywords! So when I'm talking about interfaces here, I'm not necessarily talking about virtual functions -- I'm talking about the idea of implementation hiding. Interfaces can be polymorphic, but most often they are not! A good use for polymorphism is rare, but interfaces are fundamental to all software. As hinted above, if you create a POD structure that simply stores some data to be passed from one class to another, then that struct is acting as an interface - it is a formal data definition. Even if you just make a single class in isolation with a public and a private section, everything in the public section is the interface and everything in the private section is the implementation. Inheritance actually has (at least) two types -- interface inheritance, and implementation inheritance. In C++, interface inheritance includes abstract-base-classes with pure-virtual functions, PIMPL, conditional typedefs. In Java, interface inheritance is expressed with the implements keyword. In C++, implementation inheritance occurs any time a base classes contains anything besides pure-virtual functions. In Java, implementation inheritance is expressed with the extends keyword. OOD has a lot to say about interface-inheritance, but implementation-inheritance should usually be treated as a bit of a code smell! And lastly I should probably give a few examples of terrible OOP education and how it results in bad code in the wild (and OOP's bad reputation). When you were learning about hierarchies / inheritance, you probably had a task something like: Let's say you have a university app that contains a directory of Students and Staff. We can make a Person base class, and then a Student class and a Staff class that inherit from Person! Nope, nope nope. Let me stop you there. The unspoken sub-text beneath the LSP is that class-hierarchies and the algorithms that operate on them are symbiotic. They're two halves of a whole program. OOP is an extension of procedural programming, and it's still mainly about those procedures. If we don't know what kinds of algorithms are going to be operating on Students and Staff (and which algorithms would be simplified by polymorphism) then it's downright irresponsible to dive in and start designing class hierarchies. You have to know the algorithms and the data first. When you were learning about hierarchies / inheritance, you probably had a task something like: Let's say you have a shape class. We could also have squares and rectangles as sub-classes. Should we have square is-a rectangle, or rectangle is-a square? This is actually a good one to demonstrate the difference between implementation-inheritance and interface-inheritance. If you're using the implementation-inheritance mindset, then the LSP isn't on your mind at all and you're only thinking practically about trying to reuse code using inheritance as a tool. From this perspective, the following makes perfect sense: struct Square { int width; }; struct Rectangle : Square { int height; }; A square just has width, while rectangle has a width + height, so extending the square with a height member gives us a rectangle! As you might have guessed, OOD says that doing this is (probably) wrong. I say probably because you can argue over the implied specifications of the interface here... but whatever. A square always has the same height as its width, so from the square's interface, it's completely valid to assume that its area is "width * width". By inheriting from square, the rectangle class (according to the LSP) must obey the rules of square's interface. Any algorithm that works correctly with a square, must also work correctly with a rectangle. Take the following algorithm: std::vector<Square*> shapes; int area = 0; for(auto s : shapes) area += s->width * s->width; This will work correctly for squares (producing the sum of their areas), but will not work for rectangles. Therefore, Rectangle violates the LSP rule. If you're using the interface-inheritance mindset, then neither Square or Rectangle will inherit from each other. The interface for a square and rectangle are actually different, and one is not a super-set of the other. So OOD actually discourages the use of implementation-inheritance. As mentioned before, if you want to re-use code, OOD says that composition is the right way to go! For what it's worth though, the correct version of the above (bad) implementation-inheritance hierarchy code in C++ is: struct Shape { virtual int area() const = 0; }; struct Square : public virtual Shape { virtual int area() const { return width * width; }; int width; }; struct Rectangle : private Square, public virtual Shape { virtual int area() const { return width * height; }; int height; }; "public virtual" means "implements" in Java. For use when implementing an interface. "private" allows you to extend a base class without also inheriting its interface -- in this case, Rectangle is-not-a Square, even though it's inherited from it. I don't recommend writing this kind of code, but if you do like to use implementation-inheritance, this is the way that you're supposed to be doing it! TL;DR - your OOP class told you what inheritance was. Your missing OOD class should have told you not to use it 99% of the time! Entity / Component frameworks With all that background out of the way, let's jump into Aras' starting point -- the so called "typical OOP" starting point. Actually, one last gripe -- Aras calls this code "traditional OOP", which I object to. This code may be typical of OOP in the wild, but as above, it breaks all sorts of core OO rules, so it should not all all be considered traditional. I'm going to start from the earliest commit before he starts fixing the design towards "ECS": "Make it work on Windows again" 3529f232510c95f53112bbfff87df6bbc6aa1fae // ------------------------------------------------------------------------------------------------- // super simple "component system" class GameObject; class Component; typedef std::vector<Component*> ComponentVector; typedef std::vector<GameObject*> GameObjectVector; // Component base class. Knows about the parent game object, and has some virtual methods. class Component { public: Component() : m_GameObject(nullptr) {} virtual ~Component() {} virtual void Start() {} virtual void Update(double time, float deltaTime) {} const GameObject& GetGameObject() const { return *m_GameObject; } GameObject& GetGameObject() { return *m_GameObject; } void SetGameObject(GameObject& go) { m_GameObject = &go; } bool HasGameObject() const { return m_GameObject != nullptr; } private: GameObject* m_GameObject; }; // Game object class. Has an array of components. class GameObject { public: GameObject(const std::string&& name) : m_Name(name) { } ~GameObject() { // game object owns the components; destroy them when deleting the game object for (auto c : m_Components) delete c; } // get a component of type T, or null if it does not exist on this game object template<typename T> T* GetComponent() { for (auto i : m_Components) { T* c = dynamic_cast<T*>(i); if (c != nullptr) return c; } return nullptr; } // add a new component to this game object void AddComponent(Component* c) { assert(!c->HasGameObject()); c->SetGameObject(*this); m_Components.emplace_back(c); } void Start() { for (auto c : m_Components) c->Start(); } void Update(double time, float deltaTime) { for (auto c : m_Components) c->Update(time, deltaTime); } private: std::string m_Name; ComponentVector m_Components; }; // The "scene": array of game objects. static GameObjectVector s_Objects; // Finds all components of given type in the whole scene template<typename T> static ComponentVector FindAllComponentsOfType() { ComponentVector res; for (auto go : s_Objects) { T* c = go->GetComponent<T>(); if (c != nullptr) res.emplace_back(c); } return res; } // Find one component of given type in the scene (returns first found one) template<typename T> static T* FindOfType() { for (auto go : s_Objects) { T* c = go->GetComponent<T>(); if (c != nullptr) return c; } return nullptr; } Ok, 100 lines of code is a lot to dump at once, so let's work through what this is... Another bit of background is required -- it was popular for games in the 90's to use inheritance to solve all their code re-use problems. You'd have an Entity, extended by Character, extended by Player and Monster, etc... This is implementation-inheritance, as described earlier (a code smell), and it seems like a good idea to begin with, but eventually results in a very inflexible code-base. Hence that OOD has the "composition over inheritance" rule, above. So, in the 2000's the "composition over inheritance" rule became popular, and gamedevs started writing this kind of code instead. What does this code do? Well, nothing good To put it in simple terms, this code is re-implementing the existing language feature of composition as a runtime library instead of a language feature. You can think of it as if this code is actually constructing a new meta-language on top of C++, and a VM to run that meta-language on. In Aras' demo game, this code is not required (we'll soon delete all of it!) and only serves to reduce the game's performance by about 10x. What does it actually do though? This is an "Entity/Component" framework (sometimes confusingly called an "Entity/Component system") -- but completely different to an "Entity Component System" framework (which are never called "Entity Component System systems" for obvious reasons). It formalizes several "EC" rules: the game will be built out of featureless "Entities" (called GameObjects in this example), which themselves are composed out of "Components". GameObjects fulfill the service locator pattern - they can be queried for a child component by type. Components know which GameObject they belong to - they can locate sibling componets by querying their parent GameObject. Composition may only be one level deep (Components may not own child components, GameObjects may not own child GameObjects). A GameObject may only have one component of each type (some frameworks enforced this, others did not). Every component (probably) changes over time in some unspecified way - so the interface includes "virtual void Update". GameObjects belong to a scene, which can perform queries over all GameObjects (and thus also over all Components). This kind of framework was very popular in the 2000's, and though restrictive, proved flexible enough to power countless numbers of games from that time and still today. However, it's not required. Your programming language already contains support for composition as a language feature - you don't need a bloated framework to access it... Why do these frameworks exist then? Well to be fair, they enable dynamic, runtime composition. Instead of GameObject types being hard-coded, they can be loaded from data files. This is great to allow game/level designers to create their own kinds of objects... However, in most game projects, you have a very small number of designers on a project and a literal army of programmers, so I would argue it's not a key feature. Worse than that though, it's not even the only way that you could implement runtime composition! For example, Unity is based on C# as a "scripting language", and many other games use alternatives such as Lua -- your designer-friendly tool can generate C#/Lua code to define new game-objects, without the need for this kind of bloated framework! We'll re-add this "feature" in a later follow-up post, in a way that doesn't cost us a 10x performance overhead... Let's evaluate this code according to OOD: GameObject::GetComponent uses dynamic_cast. Most people will tell you that dynamic_cast is a code smell - a strong hint that something is wrong. I would say that it indicates that you have an LSP violation on your hands -- you have some algorithm that's operating on the base interface, but it demands to know about different implementation details. That's the specific reason that it smells. GameObject is kind of ok if you imagine that it's fulfilling the service locator pattern.... but going beyond OOD critique for a moment, this pattern creates implicit links between parts of the project, and I feel (without a wikipedia link to back me up with comp-sci knowledge) that implicit communication channels are an anti-pattern and explicit communication channels should be preferred. This same argument applies to bloated "event frameworks" that sometimes appear in games... I would argue that Component is a SRP violation because its interface (virtual void Update(time)) is too broad. The use of "virtual void Update" is pervasive within game development, but I'd also say that it is an anti-pattern. Good software should allow you to easily reason about the flow of control, and the flow of data. Putting every single bit of gameplay code behind a "virtual void Update" call completely and utterly obfuscates both the flow of control and the flow of data. IMHO, invisible side effects, a.k.a. action at a distance, is the most common source of bugs, and "virtual void Update" ensures that almost everything is an invisible side-effect. Even though the goal of the Component class is to enable composition, it's doing so via inheritance, which is a CRP violation. The one good part is that the example game code is bending over backwards to fulfill the SRP and ISP rules -- it's split into a large number of simple components with very small responsibilities, which is great for code re-use. However, it's not great as DIP -- many of the components do have direct knowledge of each other. So, all of the code that I've posted above, can actually just be deleted. That whole framework. Delete GameObject (aka Entity in other frameworks), delete Component, delete FindOfType. It's all part of a useless VM that's breaking OOD rules and making our game terribly slow. Frameworkless composition (AKA using the features of the #*@!ing programming language) If we delete our composition framework, and don't have a Component base class, how will our GameObjects manage to use composition and be built out of Components. As hinted in the heading, instead of writing that bloated VM and then writing our GameObjects on top of it in our weird meta-language, let's just write them in C++ because we're #*@!ing game programmers and that's literally our job. Here's the commit where the Entity/Component framework is deleted: Here's the original version of the source code: Here's the modified version of the source code: The gist of the changes is: Removing ": public Component" from each component type. I add a constructor to each component type. OOD is about encapsulating the state of a class, but since these classes are so small/simple, there's not much to hide -- the interface is a data description. However, one of the main reasons that encapsulation is a core pillar is that it allows us to ensure that class invariants are always true... or in the event that an invariant is violated, you hopefully only need to inspect the encapsulated implementation code in order to find your bug. In this example code, it's worth us adding the constructors to enforce a simple invariant -- all values must be initialized. I rename the overly generic "Update" methods to reflect what they actually do -- UpdatePosition for MoveComponent and ResolveCollisions for AvoidComponent. I remove the three hard-coded blocks of code that resemble a template/prefab -- code that creates a GameObject containing specific Component types, and replace it with three C++ classes. Fix the "virtual void Update" anti-pattern. Instead of components finding each other via the service locator pattern, the game objects explicitly link them together during construction. The objects So, instead of this "VM" code: // create regular objects that move for (auto i = 0; i < kObjectCount; ++i) { GameObject* go = new GameObject("object"); // position it within world bounds PositionComponent* pos = new PositionComponent(); pos->x = RandomFloat(bounds->xMin, bounds->xMax); pos->y = RandomFloat(bounds->yMin, bounds->yMax); go->AddComponent(pos); // setup a sprite for it (random sprite index from first 5), and initial white color SpriteComponent* sprite = new SpriteComponent(); sprite->colorR = 1.0f; sprite->colorG = 1.0f; sprite->colorB = 1.0f; sprite->spriteIndex = rand() % 5; sprite->scale = 1.0f; go->AddComponent(sprite); // make it move MoveComponent* move = new MoveComponent(0.5f, 0.7f); go->AddComponent(move); // make it avoid the bubble things AvoidComponent* avoid = new AvoidComponent(); go->AddComponent(avoid); s_Objects.emplace_back(go); } We now have this normal C++ code: struct RegularObject { PositionComponent pos; SpriteComponent sprite; MoveComponent move; AvoidComponent avoid; RegularObject(const WorldBoundsComponent& bounds) : move(0.5f, 0.7f) // position it within world bounds , pos(RandomFloat(bounds.xMin, bounds.xMax), RandomFloat(bounds.yMin, bounds.yMax)) // setup a sprite for it (random sprite index from first 5), and initial white color , sprite(1.0f, 1.0f, 1.0f, rand() % 5, 1.0f) { } }; ... // create regular objects that move regularObject.reserve(kObjectCount); for (auto i = 0; i < kObjectCount; ++i) regularObject.emplace_back(bounds); The algorithms Now the other big change is in the algorithms. Remember at the start when I said that interfaces and algorithms were symbiotic, and both should impact the design of the other? Well, the "virtual void Update" anti-pattern is also an enemy here. The original code has a main loop algorithm that consists of just: // go through all objects for (auto go : s_Objects) { // Update all their components go->Update(time, deltaTime); You might argue that this is nice and simple, but IMHO it's so, so bad. It's completely obfuscating both the flow of control and the flow of data within the game. If we want to be able to understand our software, if we want to be able to maintain it, if we want to be able to bring on new staff, if we want to be able to optimise it, or if we want to be able to make it run efficiently on multiple CPU cores, we need to be able to understand both the flow of control and the flow of data. So "virtual void Update" can die in a fire. Instead, we end up with a more explicit main loop that makes the flow of control much more easy to reason about (the flow of data is still obfuscated here, we'll get around to fixing that in later commits) // Update all positions for (auto& go : s_game->regularObject) { UpdatePosition(deltaTime, go, s_game->bounds.wb); } for (auto& go : s_game->avoidThis) { UpdatePosition(deltaTime, go, s_game->bounds.wb); } // Resolve all collisions for (auto& go : s_game->regularObject) { ResolveCollisions(deltaTime, go, s_game->avoidThis); } The downside of this style is that for every single new object type that we add to the game, we have to add a few lines to our main loop. I'll address / solve this in a future blog in this series. Performance There's still a lot of outstanding OOD violations, some bad design choices, and lots of optimization opportunities remaining, but I'll get to them with the next blog in this series. As it stands at this point though, the "fixed OOD" version either almost matches or beats the final "ECS" code from the end of the presentation... And all we did was take the bad faux-OOP code and make it actually obey the rules of OOP (and delete 100 lines of code)! Next steps There's much more ground that I'd like to cover here, including solving the remaining OOD issues, immutable objects (functional style programming) and the benefits it can bring to reasoning about data flows, message passing, applying some DOD reasoning to our OOD code, applying some relational wisdom to our OOD code, deleting those "entity" classes that we ended up with and having purely components-only, different styles of linking components together (pointers vs handles), real world component containers, catching up to the ECS version with more optimization, and then further optimization that wasn't also present in Aras' talk (such as threading / SIMD). No promises on the order that I'll get to these, or if, or when...
  2. Hey everyone I am looking for JAVA DEVELOPERS & WEB DEVELOPERS! 🤓 Project Summary: Basic Requirements: (you'll be further tested once established) Why do I need a web developer?: CONTACTS:
  3. Andres Gomez

    Looking for Teachers

    Hello all, I'm almost to launch a live education platform for game dev enthusiasts (Think a Live Udemy Course) to either learn or teach. It will be a closed group where only members can enter these live sessions. I'm hoping to help new game professionals gain a name and followers by directly teaching/interacting with others instead of only making videos and tutorials, and newbies to have live access to an expert instead of having to wait for his comment replies. We haven't launched yet but we are at the stage of looking for teachers who wish to join us on the beta launch of this project. Only 5 will be selected for the beta test so if you are interested in helping us achieve this or have further questions before anything please email me at, well set up a live session to talk. Cheers, Andi
  4. mlamanna_music

    FREE This Week On The App Store

    Our children's app Abigail's Tales: First Day Butterflies is free to download this week on the iOS Store. If your child enjoys our app please leave a review.
  5. Dear everyone, this is my newest game, please check out and give me feedback. Thanks for your consideration. Overview: Cross n Puzz is a creative and addicting word puzzle game. It not only challenges your brain but also improve memory and other types of cognitive function. For IOS: For Android: Game trailer: Crossword Puzzle Image Trailer Official.mp4
  6. Hi! Is there by any chance you can give me an idea/concept that's different but related to the game Tower of London? (Is it called Tower of London?) Can you show me some reference images, games or videos related to the same? I've attached a reference image. Thanks!
  7. I have taught that the elements are: space, obstacles, goals, mechanics and rules. I know there's no agreed upon set, but other than balance, what other principles might complete the set?
  8. Admittedly my algebra skills are pretty darn poor. Never were particularly great either but I do remember really enjoying solving quadratics at school (a long long time ago). Does anyone know of any decent free online resources to "skill up" a little? Nothing serious, it doesn't need to be an online course as such, no qualifications required (managed to do alright without anything but basic maths skills most of my life) but it would be nice to improve a little at least.
  9. Hi there! How are offers decided? and when should they be shown to the player? I've seen offer pop-ups presented to the players during festive seasons, for example 'Get 50% off this Christmas', etc., Any tips? Examples?
  10. Kenneth R

    Unity 2D RPG tutorial

    RPG tutorial Atm I'm working on a Unity 2D RPG tutrorial. You can watch the introduction to the course in the video below, and read about the different things we will be implementing through out the course. Player movement and Animations, complete worldmap with layer sorting and camera follow. Health & Mana bar Spell book and action bar for spells Casting bar Target unit frames and health bars Keybind menu A complete inventory and item system Tooltips Lootable items Player equipment Bank storage Vendor Questing system What will we include in the future? Keep in mind that this tutorial is still a work in progress, if you feel like the tutorial is missing some features, then please feel free to let me know. If it's a great feature I might include it. Crafting Talent trees Dialogues Main menu Pathfinding Character selection Ranged enemies
  11. I'm 20 yrs old and I already have a full time job as a technology programmer in AAA company, I'm completely self taught and I love what I'm doing, the problem is that I just don't like college, I already tried to go to university and because I've put too much pressure on myself during high school, when I started living by myself for the first time I started partying too much, now I spend at least 8 hrs a day (usualy more) at work and when I come back I study a lot, recently I started part time college and even tho I have classes only every 2nd weekend I feel like having just 4 free days a month is not enough and my youth is just disappearing, I'm ambitious but I've never felt like a degree is rly worth it and I don't want to wake up in few years feeling like I chased career too much and I didn't have any fun time, do you think I should force myself anyway and get a degree from some private, paid university that didn't teach me anything useful or something that I wouldn't teach myself on my own, or having years of experience and huge shipped titles in my cv will be enough if I'll ever want to change job for whatever reason(current company is very very good, growing rapidly and I see myself staying there for a lot of years)
  12. JoAndRoPo

    Daily Bonus Logic

    Hi! I have a doubt regarding the Daily Bonus. Let's say 7 days. Player receives Daily Bonus in Day#1, Day#2, Misses Day#3, Plays on Day#4, and so on. What happens when the player misses a day? Does the Daily Bonus reset back to day#1? or does the player miss the reward of the missed date and continue to receive the reward on the next day? Can you name me some games that have used a unique daily bonus logic?
  13. I'm very often facing one small problem when trying to learn some new stuff - hard to choose what to learn next. Even if the problem seems to be small it has a very huge impact on the final result I think. And because Game Programming offers so much to learn, I'm always feeling that I'm missing something important and wasting my time learning something not important or unneeded. Or usually, I'm afraid to focus on something specific and huge for a long time, because I think that I'll spend all my time on that particular filed and will not be able to solve another problem. So I've tried to fit all my thoughts in this questions. 1) Are you trying to cover all the aspects of Game Programming? Or you trying to focus on some specific aspects like physics, animations, or networking etc. 2) What is your way to find a new theory or whatever else for your learning process? (Manuals, Courses, Books, Documentation? etc.) 3) When you trying to learn while practicing, are you search for learning because of a problem that appears, or because you wants to try new things? How do you choose this new thing? And finally, Which of this two approaches was the best for you if any? Not actually in the scope of the topic, but I'm also very interested to hear your thoughts on this. What is Game Programming for you? How would you describe what should Game Programmer able to solve?
  14. DabbingTree

    Education Join the 1st TribaJam!

    TribaJam is going to be a 3-month game jam lasting from December 1st, 3PM EST to March 3rd, 3PM EST. At 3PM, December 1st, I will release the theme on a blog post on my IndieDB account, DabbingTree. When you learn the theme, you are allowed to start your game! I will also release how you will send your game in that blog post. RULES: 1. You must use the theme. 2. You are not allowed to start it before the jam starts. All finished entries posted in the first 7 days will be instantly disqualified. 3. No using copyrighted material AT ALL! 4. No advertising in your entry. After the jam, do whatever you want with your game. But no advertising in the entry. 5. Only one entry per person. No throwing together 40 games and entering it. 6. You are allowed to team with any number of people. Supported Systems: Xbox One Windows/MacOS/Linux iOS Android WebGL Your game entry will be all yours. We will not take the winning game or any others. I invite game developers of every kind to come and make a game!
  15. I am trying to understand calculating normal vectors in my game engine book. I am having issues understanding a specific section about using gradient to calculate the normal vector. I have attached an image of the page, basically i am unsure where the gradient is coming into play, or just really anything thats going on, on the page. Any help would be appreciated.
  16. Greedy Goblin

    Look what I found....

    Haha! Take a look what I uncovered the other day while digging through my books.... It even came with a good old floppy disk! (I couldn't even use it if I wanted to now)... This book was my very first on 3D graphics programming, before 3D graphics card were even a thing (for the mainstream masses anyway). Published in 1994, it's a book that served as a really good primer to understanding 3D geometry and programming even if I never bothered with the later chapters on curved geometry. All the code samples were in C (not even C++) and there was no such mention of things such as texture mapping (although it did cover shadows, reflections and refraction!). It took you right from the beginning; from the equation of a straight line, translations, matrices etc to projections (viewing pyramid) and clipping algorithms. Great stuff! I still find it useful now as I re-read the introductory chapters and refresh myself on a few basics. My other go-to book is "Real Time Collision Detection" by Christer Ericson - an absolute diamond of a book! Do you guys and girls have any books that you rely on or hold in high regard for your game development? It would be interesting to know if anyone has ever seen or read the Georg Glaeser book above. Anyway, I'll soon have another update on The Berg, but it's bed time for me now. Night all.
  17. JoAndRoPo

    Store Values

    Hi! Question#1 - Is it OK to take another game store values for my game? Will, there be any issues of any kind? Question#2 - How are store values calculated? For example, the below values is taken from Clash Royale... 80 Gems for $0.99, 500 Gems for $4.99, 1200 Gems for $9.99, 2500 Gems for $19.99, 6500 Gems for $49.99, 14000 Gems for $99.99 How are 1200 gems calculated for $9.99? and so on...
  18. Hi all, I'm looking for a career change as the job that i currently do is neither a passion or something that i really want to be doing for the rest of my life. I would ideally like to begin a career in the gaming industry as like most others i have a strong passion for gaming and all things related. I have been looking into a junior test analyst QA job and was wondering if this is the correct place to start. I'm a dedicated worker so don't mind working my way up and I love being hands on with things. I was wondering if anyone had any advice regarding this or how i can go about gaining experience in this field to give myself the best chance. I'm more than willing to do either weekend work or free work to get my foot in the door so if there is any advice or help anyone could give me that would be great. Thanks for reading, Dan
  19. Hi I have been googling for the last half an hour to find no result in what I'm looking for. Racing games have the technique called rubber banding. I just want to know what the same kinds of techniques are called for RTS games. I would give more examples but that's the only one I know of. I'm curious as RTS's are my favorite genre and plan on making them in the distant future. Thanks in advance
  20. bencinStudios

    Science Game Jam Weekend Project

    Over the weekend of September 8th and 9th, 2018, our team participated in a Game Jam hosted by the Nashville Game Developers and The Adventure Science Center in Nashville, TN. The event kicked off on Saturday morning with introductions and our challenge for the weekend: create a science-based game with an educational spin. Given that The Adventure Science Center had dedicated September as "Make It Month," creating a video game based on the science of water seemed perfectly in sync with that idea. Through a bit of brainstorming and ideation, we came up with our theme: Water. Water is one of the most interesting substances in the universe with a host of properties and uses. We wanted to use our game to teach about the 3 main phases of water - solid, liquid, and gas. The player would be tasked with navigating a 2D puzzle environment using game mechanics to heat or cool their water character to make it through obstacles and finish the puzzle. Following a ton of online research on water, we all got a little bit smarter about how water acts, what it can do, and why it's such a versatile substance! Now, to make that into some interesting and educational gameplay. We knew we wanted the experience to include the player having to change between the various phases of water to complete the level. The challenge became how to do that in an educational, yet fun way. We decided to utilize the idea of a Bunsen burner to heat the water into a gas to be able to float. We would use a freezer to turn the water into an ice cube to be able to break through obstacles. And we'd use the idea of time and friction to turn the gas or ice back into water to navigate grates in the floor. From there, the team began pulling together assets, coding, and building the game level. By the end of Day 1, you could start to see the results of the team's work. For Day 2, our goal was to put out a finished game that would be fully playable start to finish, while also providing some polished visuals and gameplay. One of the aspects added during Day 2 was our water molecule character, Mo L. Cool, who would serve up interesting facts about water or helpful hints to get the player through the puzzle. Seth, our artist, came up with a very cool, unique take on the water molecule, showing the hydrogen atoms as headphones on the "head" of the oxygen atom. Mo L. Cool would live on the game screen and pop up with info every so often throughout the game, triggered by keys the team placed in the level. By mid-Day 2, we had some Adventure Science Center guests come through to see what we were working on at the Game Jam. We decided it would be a perfect time to get some outside opinions on the game and let them play test the current version of the game. With an Xbox controller in hand, the 2 guests gave the game their best shot while providing us some helpful insights into where we could make adjustments and fixes to make the experience even better. By the end of Day 2, we had our completed prototype game, which we dubbed "Mind Over Matter." While we were able to build a complete game level and experience, there are still a few tweaks we'll be making for the final product. We'll be putting it out on our social channels plus this and other gaming sites for folks to download for free to play (very soon). It was great to see at the end of the weekend what all the other developers at the Game Jam had been working on. Each of them showed off their science-themed gaming creations to the group. Some had been working solo on their project, while others also worked in teams. Everyone had amazingly creative ideas and were able to get completed game experiences built over 2 days. We thoroughly enjoyed ourselves and look forward to future game jams! Here's a gameplay video showing our completed prototype from start to finish (that first part is tricky)! ASC Game Jam 9_17_2018 2_14_17 PM-1(4).mp4
  21. So im starting to build game for me and my friend to play but if it ends up good then i want it to be easily expandable. My question is ... Where do i learn how to set up a server? how to run code on my server? how do you open your server to the outside world. Not only your home/pc. I want to program my server in java because i'm fairly comfortable with java. I've decided i want a tcp server. Do i need separate server to handle log-ins, registers etc.? I've done a lot of googling and i still can't find any decent tutorials.
  22. Hi, I recently published a book focusing on cloth simulation for computer graphics. Details can be found here:;products_id=1295 and on Amazon: Abstract: I hope you find it interesting! Thanks, Tuur
  23. Hi, I recently published a book focusing on cloth simulation for computer graphics. Details can be found here:;products_id=1295 and on Amazon: Abstract: I hope you find it interesting! Thanks, Tuur View full story
  24. Hi there I'm creating this topic as an introduction to who I am and why I have found my self here. I'm a mature student(26) from England. I have just started My second year at college. So far I have learned a lot about making 2D games from my previous year. This second year is going to be involving more 3D stuff and using engines such as unity and 3DS max. which at the moment I have about an hours experience with. However I'am thoroughly enjoying it, even though I'am only on day 2 of my second year.I just have a few questions that I hope some of you lovely people can help me with. I Love Love Love video games, always have always will. I'm so excited to actually start making some games. How ever career wise I'm unsure as what path I should follow, Artist,animator,programmer ect, they all appeal to me. I've always wanted to set up a business and never new what until about a year ago when I first started studying. So I hope that in the future I will be an indie dev.Think I have rambled on enough now. I will list my questions. 1. What is the best career path to follow? I mean what is the industry lacking? 2.whats the best engine to start off with? so far I have only used construct 2. 3.Is programming as difficult as it sounds? whats the best language to use? 4.How can I get ahead of my fellow students? 5. what is your favorite game and why? I have more but I'll leave it be for now.
  25. Hi, I’d like to show you my current video project “Game Audio Lookout”. It is not a game itself but a series on YouTube about how music and sound design in games work. There is three episodes I produced within the last month and I’m planning to release them on a regular basis! Currently I made 3 episodes so far: Enhancing Gameplay with Music in Celeste - On the surface, “Celeste” is a brutally hard 2D platforming game about climbing the imaginary Celeste Mountain but it is much more than that. It narrates a compelling story of main character Madeline fighting with her demon doppelgänger. Gameplay-wise, super tricky levels combined with tight controls let you fail and re-try over and over again. But what it makes it even more enjoyable is the wonderful soundtrack composed by Lena Raine we’ll have a look at in this episode of “Game Audio Lookout”. EarthBound - A Quirky Artistic Synergy of Story, Art and Music - In fact, there’s many ways how the three elements writing, artwork and sound can play together. There’s AAA titles with cinematic writing, photorealistic graphics and epic orchestral music on the one hand. Another good example is the “Super Mario Odyssey” world “Steam Gardens” with its funky vibes due to a coherent artistic feel of character design, graphics and audio. But today, we’ll go back to the Super Nintendo era to have a look at one of the strangest games Nintendo ever created: “Earthbound” Deconstructing a Musical Level in Rayman Legends - Rayman Legends has found its way into many “Best Platformer Games of All-Time” lists. Though it closely fails to beat the uncrowned king Super Mario, it found a safe place next the Nintendo mascot. The Rayman series was created by French game designer Michel Ancel and started in 1995 with the 2D jump’n’run Rayman. It was followed by two 3D platforming games: Rayman 2 and Rayman 3. But the series went back to 2D sidescrolling with Rayman Origins in 2011. Origins was also the first Rayman game using the UbiArt Framwork which also was adopted by the 2013 release “Rayman Legends”. In this episode we’ll deconstruct one of the incredible musical stages in Rayman Legends. Playlist link to all episodes so far: Link to my channel:
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!