Jump to content
Site Stability Read more... ×
  • Advertisement


The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation on 12/27/18 in all areas

  1. 2 points
    The Engine The engine for this project, tentatively, will be Voxyc. Links to the Android editor app, Github source and existing games are on the Voxyc project page. The editor and the games it produces also run on Windows and iOS (the Visual Studio and Xcode projects are in the /platform folder of the repo). I'm open to other alternatives, but ability to edit on mobile is essential for me. Another way would be writing a mobile editor and a voxel plugin for Godot, or merging Voxyc and Godot. All buildings will be made out of voxel blocks. This allows for easy level creation. I've already blocked out the basic outline of the landscape, the house ruins and the little hamlet (the roofs should be triangular prisms, I know; they will be). You can find main.sc scene with them in the attached project (Voxyc can open this file). As @JoeJpointed out, this will also allow for the swine creatures to break into the house by taking away blocks, which sounds awesome. The characters will be animated models. I used MakeHuman to create some of them already. The first four .dae files are included in the attached project. They are not animated yet. The engine does not yet have skeletal animation, so we may resort to .obj frame animation, like in Fateless. But I'm working on skeletal animation. List of characters: Camper (player for chapter 1), Old Man (player), Tonnison, Sister, Dog, The Swine Man, My Love Full text of the novel How To Edit And Run The Game Build On Android: Install Voxyc. Download the attached project file. Unzip the folder HouseOnTheBorderland into /Android/data/com.voxyc.voxyc/files To run the game, in Voxyc, click on File->Clear and run script->Picker and select loadch1.lua in the HouseOnTheBorderland folder. To open the main scene in the editor to edit, in Voxyc, click on File->Load Scene->Picker and select main.sc in the HouseOnTheBorderland folder. On Windows: Clone Voxyc source from the Voxyc github repo. In Visual Studio, open /platform/windows/Voxyc/Voxyc.sln. You can run the game with the following command line parameters: -m luaprogram -a <path to extracted HouseOnTheBorderland dir> -m means module and luaprogram is the module that runs lua scripts. -a sets the main project dir. The Windows port will then automatically launch load.lua there on startup (rename loadch1.lua to load.lua). You can edit the scene by pressing Tab->Load Scene Breakdown of Voxyc C++ features Here is a brief overview of important files for the C++ codebase app/main.cpp - Entry point for desktop app/VoxycApp.cpp - The engine core app file that runs different modules (game, editor, etc) and has the highest-level load/tick/draw functions app/LuaProgram.cpp - The module that runs a Lua program; the game is essentially a set of Lua scripts (load.lua, tick.lua, etc) editor/Editor.cpp - The editor; essentially one big loop with everything; needs splitting up/refactoring engine/Engine2.cpp - The engine core; main interface into the engine; any client that uses the engine calls this class engine/ShapeRenderer.cpp - Renders geometric shapes, terrain engine/ModelRenderer.cpp - Renders models engine/SpriteRenderer.cpp - Fast sprite/particle system renderer; only works on Android at the moment engine/Voxels.cpp - The voxel memory storage and converting voxels to mesh are here engine/TextureAtlas.cpp - Essential for the fast sprite renderer and the batcher; only works on Android engine/Batcher.cpp - Batcher; combines voxel meshes into one big mesh to reduce draw calls; only works on Android engine/Billboarder.cpp - Billboarder; pre-draws models as sprites for far-away rendering; does not work yet (but would be nice!) engine/ShadowMap.cpp - Shadow map for real-time shadows; used to work on Windows and Mac OS, but currently probably broken. Essential for horror, though. Feel free to ask any questions. I figured that you guys would appreciate me finally getting specific and technical instead of whining about Unity. I really hope so and I'm trying to avoid downvotes. In case, if I'm doing something wrong, please let me know as I'm new here. HouseOnTheBorderland.zip
  2. 2 points
    It's primarily a voxel engine. The reason for this is I find that making buildings and other man-man objects out of voxels is just much more straightforward. You're obviously not restricted to voxels; the terrain obviously is not voxels, and neither are imported models or other shapes. I also plan on making the voxels flexible (so they can be bent). I had this feature a long time ago, but it was Android only and it was all java code, so I had to throw that away. That's coming back, though.
  3. 2 points
    Very good point about showing why my custom engine is the proper choice. I suppose, it is not. I just really like editing on mobile and the ease of building levels with voxels. Maybe I am the only one in the world who cannot live without these things. I like how I can launch my editor spontaneously in the middle of the street, coffee shop, train, or whatever, and start editing a level within 5 seconds. I can spend 30 seconds making changes and then save. I just love it. If I couldn't do it and I was bound to a desktop or laptop, I couldn't get anything done. None of my games would have even been released yet. And the fact that level editing is built right into my editor is also essential for me. I don't have to muck around with re-importing meshes over and over, I just make the level right in the editor. I just feel that my workflow is much faster and streamlined than using a traditional desktop-only editor. Again, I may be the only one in the world who feels that way and that's fine. I'm not going to press. On the other hand, what if I (or someone else) makes a mobile editor for Godot, as well as a voxel level editing plugin? Not sure how much effort this would be, but maybe that would be a compromise for my situation?
  4. 1 point
    The thing about this code, is that I know I will eventually use it again, it just doesn't have much of a place in a tile based environment. I would have to configure my core objects to operate with or without it. Currently my game object relies on a position derived from it's physical component. So I would have to make that like, optional. Somehow :D. Refactoring sucks when there is a known deadline :).
  5. 1 point
    Your game is something I'll be buying for sure when you release. Cannot wait to see more updates!
  6. 1 point
    Thanks man! Yeah my focus needs to be on completing something right now, creating an actual tangible product with some kind of value. And this one just gets more fun as I go along.
  7. 1 point
    Best to stay the course if that is what your goals are! You've put out a lot of work already, and good quality work at that. Keep up the great work!
  8. 1 point
    Okay, I was fully intending to be posting about my designs for a dungeon crawler prototype that would serve double duty as the intro for my other macro-project. That, will not be happening. I've decided that to split my attentions yet again would be folly. I have a good game prototype that I just worked my fingers to the bone creating, so I'm going to just go ahead and spend the next couple of months taking that to its next levels while sprinkling in some work on the main project so I don't lose my place too badly.. So, here's my rough list of SlingBot Boarding TO-DOs for before the end of February(gotta give myself some kind of timeline): Some competition modes, where you have to compete in a configurable number of races/etc on specific or user selected courses. Calculations for in-race behaviors, including disqualifications for going too far off course and bonuses for perfect course maneuvers. Investigate shaders, Unity makes it pretty easy to dig into them so I'm going to spend some time on that side of the fence. I saw a pretty cool how-to vid posted here about using tessellation shaders in Unity to make snow-tracks, I watched it thinking about how cool they would look in this game.. Maybe not for the WebGL version, but still... Player leveling/achievement/skills system. Refining/completing the replay system, build in the ability to save and share replays, auto share replays for new game records. More NPC types, and better record keeping for races including standings for individual courses. Ice Road and Tube construction, for building race courses and freestyle park features. Snowball Slinging(and other much more humorous objects). Knock the competition out of your way!! Gotta put the Sling in the SlingBots.. LOTS more stuff for the store, some upgrades, but mostly comical skins, doodads, and funny objects for slinging. Adjustable camera settings, including a few other standard and easily switched follow/view modes. PC, Android, and IOS builds. Actual real live online multi-player. Begin ID@XBOX application process. Not necessarily in that order... Yeah, I think that's enough for now... It only takes me a few minutes to come up with an oppressive list of things to do for this game, I spent most of yesterday evening staring at a blank Unity project trying to figure out where I was going to start on a dungeon crawler prototype. Everything I wanted to do I somehow talked myself out of before writing a single line of code or creating a single object. Just not time to change courses I guess.
  9. 1 point
    Lol, you're a funny dude. Set yourself up a github or something like that, put your code out there, and show people what it can do. If you're just looking for collaboration, say so, I'm sure somebody will take interest if it's as nice as you say it is. You caught my attention a few posts back when you were talking about your super convenient mobile editing.. I can't tell now though because it looks like you've deleted everything..
  10. 1 point
    My collision detection is extremely simplistic. Before moving an object, I check to see if new position will be inside a filled voxel. It wouldn't be a big deal (points can be rotated if voxels are rotated), if not for sliding. It took quite a few hours to get the player to slide among walls correctly, and that took some hacking that unfortunately restricted the collision planes. This will need to be reworked in the future, but for what I'm trying to do right now, it works just fine.
  11. 1 point
    @RutinProtagonist finds himself stranded on a strange planet with no recollection of how he got there. He finds several other people on the planet (NPC). Along with them has to survive and figure out what happened that landed them all where they are. Gameplay will focus on resource gathering in the form of mining (similar to minecraft in that sense) and a story mode. Thanks for the kind words
  12. 1 point
    There are actually a lot of people here who will criticize Unity, but there's a difference between valid criticism and just bashing. A lot of the points in your previous post weren't accurate. Suggesting that all people who use Unity aren't "real developers" is just mean and unproductive. If you want help with rolling your own tech you'll find a lot of experienced people with valuable advice here. Bashing Unity isn't the way to find that help and support though. Just talk about your project, ask your questions, look for help, whatever. If you want to talk about the shortcomings of Unity accurately, you'll find plenty of supportive conversation for that too. Don't just bash it though: have an intelligent conversation, realize that some people using Unity are still good developers, and that sometimes Unity is the right answer, and criticize the genuine weaknesses rather than any use of the engine or its ecosystem.
  13. 1 point
    "I did not know that Unity was a religion around here. " "...and not your beloved Unity. " You're still doing it. Having to write a game engine from scratch is very, very difficult and time consuming. Don't berate people for using Unity. Not everyone is a programmer. I am writing a game engine in C++ using Lua also. I am impressed at what you have done with your engine. Gamedev.net and other websites can distract you when you need to be concentrating on becoming a better game programmer. This is especially true when you are generating dislikes for yourself and letting it take your focus off what needs to be done. Maybe you are self-sabotaging? Maybe the drama is better than the programming? Sorry to psychoanalyze.
  14. 1 point
    Nobody got mad(that I saw), we were just responding to blanket statements you were making that weren't really correct. I think your engine looks fascinating even though I'm just a Unity "script kid". Lol
  15. 1 point
    Hi everyone, this is my first blog here, even though I have joined last year, so I will introduce myself first. I am a software developer from Montreal, Canada, with a B.Sc. in computer science and I have some experience making games, but this is my first attempt using the UE4 engine. I knew practically nothing about this engine until very recently. I only had to read some tutorials and the UE4 docs and was able to partially create this game for the Dungeon Crawler Challenge without too much difficulty. I have some decent experience with Unity but I really feel that UE4 is a superior engine, allowing you to have much more control over your product. I was a bit overwhelmed at first by all the parameters, to be honest. So basically, my game revolves around a warrior character who is stuck in an "Underworld" type of series of dungeons. He needs to cross the 7 Soul Gates, scattered inside 7 maps, to ascend out of the world. Dante's Inferno was somewhat of my inspiration for this project. Each level has a boss to defeat. I will not say more than that. I am not sure if I will have time to make all 7 levels before the challenge ends, but it will definitely be a goal afterwards. Most of the assets were taken from the ActionRPG game example on the Unreal Marketplace. They just look awesome. I only took what I need from it and migrated it to a new project, which is a lot more lightweight. I was able to make one map, the AI for the enemies (goblin type characters), the basic game logic with all the damage taken and given, all the animation logic (state machines and such), HUD, health bars, and part of the main menu which has an animated material on it that looks rather cool (will post images later). All that remains now is creating all the loot assets, spawning loot and making the game logic for using the loot in different ways, and also for map goal reaching. Overall I am pretty satisfied with this project so far. UE4 is tons of fun to use. Much more than Unity in my opinion. I struggled a bit with Unity because some of the UI seems somewhat counter-intuitive. UE4 has a lot of nested menus though, which sometimes can make it hard to navigate and find what you are looking for. But I have adopted this engine and I will develop most of my games with it...
  16. 1 point
    I dont know exactly what you said or did, but if you look on our forums you will see that there is a lot of discussion around c++ on gd.net. I am unsure what you are looking for though. You say you want to recruit people for your project, then why are you criticizing Unity? What does that have to do with anything? If you want people for your project, why dont you tell us a bit more about it? What kind of people are you looking for? Artists? Designers? What?
  17. 1 point
    Hello all, since the Frogger Challenge I have been hard at work doing some cleanup in my "engine" and adding a few features that were missing from the first challenge. Specifically, I was able to add add in a state machine as well as figured out how to use SFML for poller based input. I decided that I didn't have enough of one type of art to fully flesh out the graphics of a dungeon crawler, they were all a bit mismatched and I decided to forego frankensteining it together, so I went over to Oryx Design Labs and got their Ultimate Fantasy Tileset! One of my first major hurdles was that I decided I wanted to use tile based movement rather than the free movement that I used in the Frogger Challenge. I'm trying to slightly mimic the kind of motion i see in Sproggiwood and Paper Dungeons Crawler. I visited the forums for a while and ended up coming up with my own flavor of tile based movement that I believe at least is a close match to what I'm seeing in these games. I wanted diagonal movement, but I wanted everything locked to the tiles. and I think I have accomplished that at this time! See Below: 2018-12-24_00-10-03.mp4 This was more of a task than I thought it would be, but here is the code that makes it work, I'm definitely open to some suggestions here! Firstly, input! if (sf::Keyboard::isKeyPressed(sf::Keyboard::W) && sf::Keyboard::isKeyPressed(sf::Keyboard::D)) { if(gameobjects[0]->getPhysics()->inMotion == false) { gameobjects[0]->setVelocity(XMFLOAT3{ float(.025) * dt,float(.025) * dt, 0 }); gameobjects[0]->nextmapcoords.x = gameobjects[0]->mapcoords.x + 1; gameobjects[0]->nextmapcoords.y = gameobjects[0]->mapcoords.y + 1; } } else if (sf::Keyboard::isKeyPressed(sf::Keyboard::W) && sf::Keyboard::isKeyPressed(sf::Keyboard::A)) { if (gameobjects[0]->getPhysics()->inMotion == false) { gameobjects[0]->setVelocity(XMFLOAT3{ float(-.025) * dt,float(.025) * dt, 0 }); gameobjects[0]->nextmapcoords.x = gameobjects[0]->mapcoords.x - 1; gameobjects[0]->nextmapcoords.y = gameobjects[0]->mapcoords.y + 1; } } else if (sf::Keyboard::isKeyPressed(sf::Keyboard::S) && sf::Keyboard::isKeyPressed(sf::Keyboard::D)) { if (gameobjects[0]->getPhysics()->inMotion == false) { gameobjects[0]->setVelocity(XMFLOAT3{ float(.025) * dt,float(-.025) * dt, 0 }); gameobjects[0]->nextmapcoords.x = gameobjects[0]->mapcoords.x + 1; gameobjects[0]->nextmapcoords.y = gameobjects[0]->mapcoords.y - 1; } } else if (sf::Keyboard::isKeyPressed(sf::Keyboard::S) && sf::Keyboard::isKeyPressed(sf::Keyboard::A)) { if (gameobjects[0]->getPhysics()->inMotion == false) { gameobjects[0]->setVelocity(XMFLOAT3{ float(-.025) * dt,float(-.025) * dt, 0 }); gameobjects[0]->nextmapcoords.x = gameobjects[0]->mapcoords.x - 1; gameobjects[0]->nextmapcoords.y = gameobjects[0]->mapcoords.y - 1; } } else if (sf::Keyboard::isKeyPressed(sf::Keyboard::D)) { if (gameobjects[0]->getPhysics()->inMotion == false) { gameobjects[0]->getPhysics()->SetVelocityX(float(.025) * dt); gameobjects[0]->nextmapcoords.x = gameobjects[0]->mapcoords.x + 1; gameobjects[0]->nextmapcoords.y = gameobjects[0]->mapcoords.y; } } else if (sf::Keyboard::isKeyPressed(sf::Keyboard::A)) { if (gameobjects[0]->getPhysics()->inMotion == false) { gameobjects[0]->getPhysics()->SetVelocityX(float(-.025) * dt); gameobjects[0]->nextmapcoords.x = gameobjects[0]->mapcoords.x - 1; gameobjects[0]->nextmapcoords.y = gameobjects[0]->mapcoords.y; } } else if (sf::Keyboard::isKeyPressed(sf::Keyboard::W)) { if (gameobjects[0]->getPhysics()->inMotion == false) { gameobjects[0]->getPhysics()->SetVelocityY(float(.025) * dt); gameobjects[0]->nextmapcoords.x = gameobjects[0]->mapcoords.x; gameobjects[0]->nextmapcoords.y = gameobjects[0]->mapcoords.y + 1; } } else if (sf::Keyboard::isKeyPressed(sf::Keyboard::S)) { if (gameobjects[0]->getPhysics()->inMotion == false) { gameobjects[0]->getPhysics()->SetVelocityY(float(-.025) * dt); gameobjects[0]->nextmapcoords.x = gameobjects[0]->mapcoords.x; gameobjects[0]->nextmapcoords.y = gameobjects[0]->mapcoords.y - 1; } } So, I had to add some information to my gameobject class. Specifically, map coordinates, and next map coordinates. Then I had to limit my input to only when inmotion is false, which will be false whenever I have successfully locked to a tile. Now, to make all the map coordinates work correctly, I needed to be able to update the next map coordinates and current map coordinates in my game object update loop, using this code: void Game::UpdateMapPosition(GameObject * object) { XMFLOAT3A objectpos = object->getPosition(); int xcount = floor(objectpos.x / map->tileSizeX); int ycount = floor(objectpos.y / map->tileSizeY); object->mapcoords.x = xcount; object->mapcoords.y = ycount; XMFLOAT3A pos = map->At(xcount, ycount); if (object->currentDirection == Facing::UP_RIGHT || object->currentDirection == Facing::DOWN_LEFT) { if (pos.x == map->At(object->nextmapcoords.x, object->nextmapcoords.y).x) { object->getPhysics()->SetVelocityX(0); } else if (pos.y == map->At(object->nextmapcoords.x, object->nextmapcoords.y).y) { object->getPhysics()->SetVelocityY(0); } } else if (object->currentDirection == Facing::UP_LEFT || object->currentDirection == Facing::DOWN_RIGHT) { if (pos.x == map->At(object->nextmapcoords.x, object->nextmapcoords.y).x) { object->getPhysics()->SetVelocityX(0); } else if (pos.y == map->At(object->nextmapcoords.x, object->nextmapcoords.y).y) { object->getPhysics()->SetVelocityY(0); } } else if(object->currentDirection == Facing::RIGHT || object->currentDirection == Facing::LEFT) { if (pos.x == map->At(object->nextmapcoords.x, object->nextmapcoords.y).x) { object->getPhysics()->SetVelocityX(0); } else if (pos.y == map->At(object->nextmapcoords.x, object->nextmapcoords.y).y) { object->getPhysics()->SetVelocityY(0); } } else if(object->currentDirection == Facing::UP || object->currentDirection == Facing::DOWN) { if (pos.y == map->At(object->nextmapcoords.x, object->nextmapcoords.y).y) { object->getPhysics()->SetVelocityY(0); } else if (pos.y == map->At(object->nextmapcoords.x, object->nextmapcoords.y).y) { object->getPhysics()->SetVelocityY(0); } } } Again, definitely open to suggestions for cleanup here, this is what I was able to throw together given my current knowledge and understanding. The end result is definitely functional though! The next thing I think I want to do is incorporate the mouse in some kind of way, but I haven't thought up any ideas yet, lets here what you think! There are a few things I like about this setup, and of course a few that I don't like. I think the code is pretty easy to read, and I like that. However, It feels a bit bloated and large for the job its actually accomplishing, definitely some room for some tidying up and optimization. Anyways I think I've made a good start for the next challenge. What's next? Maybe make some of my objects interactable, like boxes and crates and junk. Loot is, I believe, the biggest part of the requirement, aside from beating the bad guys!
  18. -1 points
    Maybe it's just my experience, but Object-Oriented Programming seems like a default, most common paradigm of software engineering. The one typically thought to students, featured in online material and for some reason, spontaneously applied even by people that didn't intend it. I know how succumbing it is, and how great of an idea it seems on the surface. It took me years to break its spell, and understand clearly how horrible it is and why. Because of this perspective, I have a strong belief that it's important that people understand what is wrong with OOP, and what they should do instead. Many people discussed problems with OOP before, and I will provide a list of my favorite articles and videos at the end of this post. Before that, I'd like to give it my own take. Data is more important than code At its core, all software is about manipulating data to achieve a certain goal. The goal determines how the data should be structured, and the structure of the data determines what code is necessary. This part is very important, so I will repeat. One must never change the order here! When designing a piece of software, always start with figuring out what do you want to achieve, then at least roughly think about data architecture: data structures and infrastructure you need to efficiently achieve it. Only then write your code to work in such architecture. If with time the goal changes, alter the architecture, then change your code. In my experience, the biggest problem with OOP is that encourages ignoring the data model architecture and applying a mindless pattern of storing everything in objects, promising some vague benefits. If it looks like a candidate for a class, it goes into a class. Do I have a Customer? It goes into class Customer. Do I have a rendering context? It goes into class RenderingContext. Instead of building a good data architecture, the developer attention is moved toward inventing “good” classes, relations between them, taxonomies, inheritance hierarchies and so on. Not only is this a useless effort. It's actually deeply harmful. Encouraging complexity When explicitly designing a data architecture, the result is typically a minimum viable set of data structures that support the goal of our software. When thinking in terms of abstract classes and objects there is no upper bound to how grandiose and complex can our abstractions be. Just look at FizzBuzz Enterprise Edition – the reason why such a simple problem can be implemented in so many lines of code, is because in OOP there's always a room for more abstractions. OOP apologists will respond that it's a matter of developer skill, to keep abstractions in check. Maybe. But in practice, OOP programs tend to only grow and never shrink because OOP encourages it. Graphs everywhere Because OOP requires scattering everything across many, many tiny encapsulated objects, the number of references to these objects explodes as well. OOP requires passing long lists of arguments everywhere or holding references to related objects directly to shortcut it. Your class Customer has a reference to class Order and vice versa. class OrderManager holds references to all Orders, and thus indirectly to Customer's. Everything tends to point to everything else because as time passes, there are more and more places in the code that require referring to a related object. Instead of a well-designed data store, OOP projects tend to look like a huge spaghetti graph of objects pointing at each other and methods taking long argument lists. When you start to design Context objects just to cut on the number of arguments passed around, you know you're writing real OOP Enterprise-level software. Cross-cutting concerns The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a class Weapon involved? Do we pass it as an argument to isHitBy or does Player has a currentWeapon() getter? This oversimplified example with just 3 interacting classes is already becoming a typical OOP nightmare. A simple data transformation becomes a bunch of awkward, intertwined methods that call each other for no reason other than OOP dogma of encapsulation. Adding a bit of inheritance to the mix gets us a nice example of what stereotypical “Enterprise” software is about. Object encapsulation is schizophrenic Let's look at the definition of Encapsulation: The sentiment is good, but in practice, encapsulation on a granularity of an object or a class often leads to code trying to separate everything from everything else (from itself). It generates tons of boilerplate: getters, setters, multiple constructors, odd methods, all trying to protect from mistakes that are unlikely to happen, on a scale too small to mater. The metaphor that I give is putting a padlock on your left pocket, to make sure your right hand can't take anything from it. Don't get me wrong – enforcing constraints, especially on ADTs is usually a great idea. But in OOP with all the inter-referencing of objects, encapsulation often doesn't achieve anything useful, and it's hard to address the constraints spanning across many classes. In my opinion classes and objects are just too granular, and the right place to focus on the isolation, APIs etc. are “modules”/“components”/“libraries” boundaries. And in my experience, OOP (Java/Scala) codebases are usually the ones in which no modules/libraries are employed. Developers focus on putting boundaries around each class, without much thought which groups of classes form together a standalone, reusable, consistent logical unit. There are multiple ways to look at the same data OOP requires an inflexible data organization: splitting it into many logical objects, which defines a data architecture: graph of objects with associated behavior (methods). However, it's often useful to have multiple ways of logically expressing data manipulations. If program data is stored e.g. in a tabular, data-oriented form, it's possible to have two or more modules each operating on the same data structure, but in a different way. If the data is split into objects with methods it's no longer possible. That's also the main reason for Object-relational impedance mismatch. While relational data architecture might not always be the best one, it is typically flexible enough to be able to operate on the data in many different ways, using different paradigms. However, the rigidness of OOP data organization causes incompatibility with any other data architecture. Bad performance Combination of data scattered between many small objects, heavy use of indirection and pointers and lack of right data architecture in the first place leads to poor runtime performance. Nuff said. What to do instead? I don't think there's a silver bullet, so I'm going to just describe how it tends to work in my code nowadays. First, the data-consideration goes first. I analyze what is going to be the input and the outputs, their format, volume. How should the data be stored at runtime, and how persisted: what operations will have to be supported, how fast (throughput, latencies) etc. Typically the design is something close to a database for the data that has any significant volume. That is: there will be some object like a DataStore with an API exposing all the necessary operations for querying and storing the data. The data itself will be in form of an ADT/PoD structures, and any references between the data records will be of a form of an ID (number, uuid, or a deterministic hash). Under the hood, it typically closely resembles or actually is backed by a relational database: Vectors or HashMaps storing bulk of the data by Index or ID, some other ones for “indices” that are required for fast lookup and so on. Other data structures like LRU caches etc. are also placed there. The bulk of actual program logic takes a reference to such DataStores, and performs the necessary operations on them. For concurrency and multi-threading, I typically glue different logical components via message passing, actor-style. Example of an actor: stdin reader, input data processor, trust manager, game state, etc. Such “actors” can be implemented as thread-pools, elements of pipelines etc. When required, they can have their own DataStore or share one with other “actors”. Such architecture gives me nice testing points: DataStores can have multiple implementations via polymorphism, and actors communicating via messages can be instantiated separately and driven through test sequence of messages. The main point is: just because my software operates in a domain with concepts of eg. Customers and Orders, doesn't mean there is any Customer class, with methods associated with it. Quite the opposite: the Customer concept is just a bunch of data in a tabular form in one or more DataStores, and “business logic” code manipulates the data directly. Follow-up read As many things in software engineering critique of OOP is not a simple matter. I might have failed at clearly articulating my views and/or convincing you. If you're still interested, here are some links for you: Two videos by Brian Will where he makes plenty of great points against OOP: Object-Oriented Programming is Bad and Object-Oriented Programming is Garbage: 3800 SLOC example CppCon 2018: Stoyan Nikolov “OOP Is Dead, Long Live Data-oriented Design” where the author beautifully goes through an example OOP codebase and points out problems with it. Arguments Against Oop on wiki.c2.com for a list of common arguments against OOP. Object Oriented Programming is an expensive disaster which must end by Lawrence Krubner – this one is long and goes in depth into many ideas Feedback I've been receiving comments and more links, so I'm putting them here: Quora: Is C++ OOP slower than C? If yes, is the difference significant? Note: This article was originally published on the author's blog, and is republished here with kind permission.
  19. -1 points
    You're actually quite right about Unity and this "is a religion" thing. But it's not only around here. Say something against Unity (no matter how solid and valid) and you've got all the fanboys over you. I've seen this many times so far. Just ignore them. By not using Unity you do yourself already a large favour. No need to apologize for anything there.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net 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!