Advertisement Jump to content
  • Advertisement

Martin Brentnall

  • Content Count

  • Joined

  • Last visited

  • Days Won


Martin Brentnall last won the day on May 24 2018

Martin Brentnall had the most liked content!

Community Reputation

111 Neutral

About Martin Brentnall

  • Rank

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Good idea. I tend to overlook the possibilities afforded by operator overloading in C++, since my background (and job) is Java. C++ is just a hobby for me. Actually I think a lot of my habits from Java are probably evident in my C++ code, but that's an entirely separate issue.
  2. This is a very good point. I do already instance many of my resource types, but not everything. For example, textures and colours are not currently instanced, but I can certainly see the benefits of making everything instanced. This is an ideal situation, but how would it work technically? If my object has just received a pointer to a place holder resource, then as soon as the real one is loaded, the pointer would become invalid because it still points to a place holder that was destroyed: IModel* mModel = resources->getModel(node.getAttribute("model")); // ... some time later mModel->render(); // If the place holder is destroyed, this will crash. I could solve this by having a pointer to the pointer to the resource, so when the place-holder is replaced by the real thing, the pointer that my pointer points to now points to the real thing, but it looks super ugly: IModel** mModel = resources->getModel(node.getAttribute("model")); // ... some time later (*mModel)->render(); // This always works, but it's ugly! Fortunately my current game isn't big or complex enough to require dynamic loading and unloading of resources during actual gameplay; I just load everything at the beginning and keep everything in memory until the game ends. I guess this could change in the future though. Anyway generally speaking, it's great to see a lot of suggestions and ideas here, but I'm still not really clear on what advantages are over my current approach? Another thing: Many seem to assume that all resources will be loaded from files on disk, but many of my resources are generated programmatically, and I'm not sure if this makes a difference? As a simple example, my game defines a palette of 16 colours, and all of the game object textures are generated using colours selected from this palette. The design is intended to make it easy for a creator to change the appearance of the game by selecting different colours for the textures and/or editing the palette. Of course, a creator can also just load .png's (etc.) and use those as textures too if he prefers, but this ability is only used for some static parts of the HUD in my game.
  3. That's an interesting idea, but I'm not sure it could be accomplished in my project, since I want to include the editing tool with my game that lets users build new games, and of course that means that resources are not fixed just for my specific game, but can be loaded/unloaded dynamically and configured on demand as a player wishes. For that reason, I'd like to keep the tool as intuitive as possible for creators. Also at a deeper level, my engine implements a modular framework, so there's nothing to stop a player from plugging in their own custom DLL that generates all kinds of new resources, and I think it would be difficult to handle these in a generic way, since there's no way for the engine to know what an external module is doing internally with its resources. Another thing is that different modules may reference resources from each other too, so a game object from one module might use a model or texture generated by a different module. This is, in fact, already the case, since I already have six different modules for various different purposes.
  4. A game engine loads a game, and a game contains many resources (textures, models, sounds, scripts, game objects, etc.), and each resource may be dependent on other resources (e.g. a game object might require a model and a script). So let's say resource B requires resource A. How can we be certain that resource A is available at the moment resource B is loaded? Here are the possible solutions I've tried: 1. Only allow resource types to be dependent one-way. A game object may be dependent on a model, but a model may not be dependent on a game object. If this is strictly enforced, then we can always load the models first, so we know all the models are available once we start loading the game objects that might use them. Maybe this is all it takes for a lot of games; maybe my game just has weird requirements or a strange technical design, but I've ended up with a lot of interdependency between various resource types that make this approach impossible. 2. Sort resources in order of dependency. If resources are sorted so that a resource is only saved after its dependencies are saved, then when the project is loaded, the dependencies of a resource are always loaded before the resource that needs them. This can be a pain to implement. Aside from that, in practice I wrote a lot of my game project file by hand because my tools weren't yet developed, so I constantly had to manually sort resources. I'm also not a fan of requiring order in data files unless it serves a functional purpose (e.g. to define Z-order sorting of game objects in a 2D game). 3. Use "proxy" resources. If a resource isn't available yet, a "proxy" implementation of that resource is returned, and a reference to the real thing is added to the proxy object once the missing resource becomes available. I started doing this when I got tired of manually sorting resources as my game grew, but I hated having a lot of "proxy" classes strewn across my engine. I also doubt that constantly calling through proxy objects does wonders for performance either. 4. Repeating initialisation. This idea was to have the initialisation function on each resource return false to report lack of resource availability, then the initialisation loop would just repeat until every resource initialisation returned true. It worked, but I didn't really this solution, since repeating initialisation actions in some resources could possibly lead to bugs or unintended effects if the repetition wasn't anticipated, which made it feel very error prone. 5. Multi-phase initialisation Resources are loaded in multiple phases, e.g: All resources are created in the first phase, then all resources are initialised in the second phase. This is my current approach. It sounds very simple, but I've found it somewhat more complicated in practice. There are actually five phases in my current engine: Resources such as textures, models, and game objects and registered to the engine. Game object instances (e.g. player objects) are created and registered to the engine. This is a separate step because the context in which game object instances exist is dependent on a world resource that must be known before the world contents can be parsed. The game object instances are also regarded as resources (mostly to be used by event scripts). All loaded resources are initialised with any required resource references. The actual game content is loaded such as terrain, pick-ups, enemies, player, etc.. By this point, all types of game object, instances, and other resources have been fully initialised. Any initialisation requiring OpenGL is performed (e.g. textures, models, etc.). In order to enable the screen to continue rendering while the previous phases are performed (which may take several seconds), the loading is performed on a second thread. But since OpenGL functions can only be called on the main thread, these operations must be deferred until this phase. So the order of resources no longer matters, proxy classes aren't required, and we have full flexibility to allow any resource type to reference any other resource type. The downside is that each relevant phase must be implemented for each resource, and perhaps this isn't very intuitive for an unfamiliar developer (the engine is intended for open source distribution eventually, so I think the API design is quite important). I guess the use of multiple phases also makes the loading time slightly longer than the first three solutions, but I haven't actually measured a difference. Anyway, I original defined interface functions to be called for each phase, but in the interest of simplicity and brevity, I've settled on a solution that uses std::function callbacks, which looks something like this (extreme simplification): /** * A texture resource that is procedurally generated using two colour resources. */ class MyTexture:public ITexture { private: // Colours used by the texture. IColour* cColourA; IColour* cColourB; GLuint cTextureId; // etc. public: MyTexture(const DOMNode& node, IProjectRegistry* registry) { // Phase 1: Make "this" object available to the project as a named texture. registry->registerTexture(node.getAttribute("name"), this); // Phase 2: Only applicable to world and game object resources. // Phase 3: Callback to initialise the texture with named colour resources registry->initReferences([this, &node](IResources* resources) { cColourA = resources->getColour(node.getAttribute("colourA")); cColourB = resources->getColour(node.getAttribute("colourB")); }); // Phase 4: Only applicable to world and game object resources. // Phase 5: Callback to make sure OpenGL stuff happens in the main thread. registry->initMainThread([this]() { // Do OpenGL stuff (allocate texture, render-to-texture, etc.) }); } /***********************\ * Implements ITexture * \***********************/ void set() { glBindTexture(GL_TEXTURE_2D, cTextureId); } }; Actually, I don't normally include the "phase" comments above, since I find it clear enough without them. /** * A texture resource that is procedurally generated using two colour resources. */ class MyTexture:public ITexture { private: // Colours used by the texture. IColour* cColourA; IColour* cColourB; GLuint cTextureId; // etc. public: MyTexture(const DOMNode& node, IProjectRegistry* registry) { registry->registerTexture(node.getAttribute("name"), this); registry->initReferences([this, &node](IResources* resources) { cColourA = resources->getColour(node.getAttribute("colourA")); cColourB = resources->getColour(node.getAttribute("colourB")); }); registry->initMainThread([this]() { // Do OpenGL stuff (allocate texture, render-to-texture, etc.) }); } /***********************\ * Implements ITexture * \***********************/ void set() { glBindTexture(GL_TEXTURE_2D, cTextureId); } }; So based on my current experience, I'm pretty satisfied with this. But I still wonder if there are better or standard ways to do this? Is this a common problem? How does your game (engine) manage resource initialisation? Do you restrict resource dependencies? Also, is this a good approach with regards to API design of a game engine intended for open source distribution?
  5. Martin Brentnall

    implementing events

    The way I did this was to register all of the fixed (non-moving) objects like walls and pick-ups into a "FixedObjects" collection class, then each time my moving object moves, it calls a "FixedObjects.testCollisions(this, startLocation, endLocation)", which iterates through all the fixed objects to test if the moving object collided with any of them. Then when a collision tests positive, an action method is called with the fixed object and moving object as the two arguments. That's actually a very simplified description compared to what I really did, but I hope it gives some idea of how to get started. I didn't try collisions between two moving objects yet, so hopefully someone else can chime in if you need to do that.
  6. A funny thing happened: Last week I registered a GitHub account with the intention of uploading the source code soon. This week I deleted my GitHub account, so now I need to decide on an alternative (maybe GitLab). The project was hosted on SourceForge before, but it's been a very long time since I updated it on SourceForge. Another issue is that the game currently only works on Linux; porting to Windows is still on my "to do" list. For now, the easiest way to see the game is probably just to watch one of the preview videos on YouTube: Game: Editor: The videos are quite old, especially the Editor; a lot of the stuff shown in that video has been replaced or changed to make the overall UI more intuitive.
  7. Martin Brentnall

    Online service for UGC in a free game

    I'm nearing the end of developing a game that allows players to build their own levels. In the interest of making levels easily accessible, I'd like to enable players to upload, search, and download levels directly within the game. For this, I will need a host for the online service on which the levels will be stored. This is the strategy I currently have in mind: The server application will be developed locally. For testing, I will set up a Linux VM on my PC where the server application can be tested, using the host (or another VM) as the client. After testing, I will use a cloud service to host the server application where it is accessible to the public. These will be the basic functions of the server to begin with: Account management (register, verify, authenticate, recover password, etc.). Submit a level. Includes author (user name), timestamp of submission, level name, and the level file itself. Search for level by author, date, time, and name. Download a level. Here's are the concerns that I'm most unsure about: Development. I prefer C++ and SDL_net based on my familiarity with these as a game developer, but is it worth considering other options for the server application? I don't have any experience with web development technology (HTML5, PHP, MySQL, etc.) so I'm not sure if it would be more effective to learn something new, or do it the way I already know. Security. I know websites normally use HTTPS and SSL certificates for secure communication, but would this be necessary for my service, or could I get away with just using public-key cryptography? What's would be the worst case scenario for an attack on my service? Hosting. At a glance I found a Linux-based cloud service where a 3-year contract costs €268, which includes one CPU core, 50GB storage, 50TB data transfer, and a static IP address. The levels are typically only 100KB each after compression, so this sounds like plenty more than I need, but I've never developed a cloud-based service before. Is there anything else I should know? Better options to consider? Legal. GDPR is currently a hot topic, but how would it apply to my service and what would I need to do? Most information about GDPR refers to organisations, but says nothing about individuals and hobbyists. Are there other potential legal issues besides GDPR that I need to be aware of?
  8. The game began life in 2005 as a simple OpenGL learning exercise to render a static game scene, just to see if I could do it. The result was satisfying, and a desire to create more scenes fuelled the development of a crude editing tool, which was quickly followed by the creation of a complete game map. Not wanting the map to go to waste, I started adding gameplay elements and logic to turn it into an actual game: player character, enemies, physics, collision detection, game logic, etc.. I didn't have much game development experience, but as a CS student, I was able figure out most of what I needed to do. By 2006 I expected to release the finished game and map editor within a year. 2007 went by and my expectation proved to be overambitious. I was still getting to grips with good C++ practices, design patterns, OpenGL, etc., let alone wrapping my head around physics and collision detection. Performance was another issue; many optimisations were necessary to achieve an acceptable framerate during gameplay. By 2009, the project began to resemble a playable game, if only for the few seconds that it lasted before something inevitably went haywire: The player character glitched through map geometry, wandered along invisible surfaces that shouldn't exist, or the game just froze or crashed outright. The project was a mess and I was struggling to make it work. Aside from the game itself, the map editor hadn't been developed much beyond the crude editor from 2005. As a child, I loved level editors, so giving players a creativity tool felt like a vital aspect of the project, but there was still much to be done if that were to happen. Aside from these struggles, my ambitions grew and I started to feel dissatisfied with the rigid design of the project. I'd seen so many hobby games released over the years that seemed to be forgotten within a week or two, and that's not what I wanted for my baby. The game and map editor were no longer enough; it had to be a set of flexible and reusable components for long term use on multiple games that would enable players not only to build maps, but also to add custom assets and game logic. Nothing could be hard-coded; everything had to generic and configurable. The dissatisfaction and struggle lead to what I did next: I scrapped the entire game and started again from scratch. That's not to say four years of work had gone to waste; it was a great learning experience, but it was also clear that I needed to go back to the drawing board and rethink some of the more complex topics like optimisation, collision detection, physics, etc.. One of the first ideas for the new version was an engine design with a plugin framework for game components and logic. I hadn't done anything like this before, so seeing game objects from one module interacting with game objects from another for the first time felt like magic. But I still had a lot to learn, and the original design had some critical flaws that required a lot of reworking to make it fit-for-purpose. It was yet another learning experience. Similar learning experiences occurred numerous times over the years since as the overall engine design was continuously refined and improved. For example, scripting support was added to replace C++ game logic, interfaces were created, removed, and improved to improve generalisation and flexibility. It was always deeply satisfying to see a rigid component made generic, even when it added nothing new to the actual game. It was 2015 before I began to feel that the end was in sight, but my optimism seemed to come and go in waves. Sometimes I was certain that the end was within reach, yet other times I felt that I was doomed to work endlessly on a project that would never reach fruition. Sometimes I went weeks or even months without touching the project. Now it is 2018. The game can be played from beginning to end without any crashes or glitches. There are still a few small but essential features to be done, but otherwise the game is entirely playable. Furthermore, the components of the game can be configured far beyond the requirements of this one game, and my mind is exploding with ideas for how I'll be able to exploit this potential in future projects. The editing tools are quite a different story though. As I mentioned earlier, encouraging creativity is an important goal of the project, so I'm reluctant to release the game without an editor. But there's still a huge amount of work to be done before the tools can exploit all of the functionality that has been built into the components over the years. In order to facilitate a quicker release, I've thought about including a cut-down editor that can only create and edit maps for this game, then follow up with the release of a full editor at a later date. But such a cutback would be no better than the release I had envisioned way back in 2006. Project functionality isn't the only outstanding issue. The project is currently undergoing some major quality improvements to fix coding conventions, API documentation, memory leaks, interface designs, and several other issues. I'm currently working on the front-end (title screen, options, demo, etc.), which is the oldest part of the project, and the code is a clear sign of my lack of experience at that time, so I've ended up practically rewriting the entire module. Another outstanding issue is the use of some outdated libraries and API's. OpenGL is a big one; the project is based on version 1.x (I'm not even sure of the exact version) and I have no idea when I'll have time to learn a modern version. The project also uses Luabind to enable scripting, which seems to be dead; the last official version won't even compile on my current system and I have no idea how to fix it, so I've been relying on an unofficial fork for the last year. Smaller issues include countless "TODO" comments throughout the code documenting minor design flaws, error-handling omissions, and other small issues that should be resolved. The project also needs to be ported to Windows and packaged with an installer before I can realistically expect anyone to play it. I've tried to keep myself motivated by maintaining a list of remaining tasks, but there seems to be a never-ending stream of tasks that I've forgot to include, so the list never seems to get any smaller even though things are getting done. I feel like I haven't really moved on much from 2015; seeing the end within reach, yet having no idea of how far away it actually is. It's like I'm constantly moving forward in a tunnel, yet the light at the end never gets any closer. The game is pretty much done on the surface, yet there is still so much left to do. I've heard of "development hell", and now I feel like I'm getting a first-hand taste of it. I know software projects can often take longer than expected, and it's easy to be overambitious, but I don't think 13 years (and counting) is normal for a hobby game project. So what's the point of this post? Well, I guess I just wanted to hear views from other hobbyist game developers: How do you approach a hobby game project? How do you keep the scope under control? How far do you go to make your project useful beyond the immediate game that you're making? Do you think its worthwhile to create editors and tools and add flexibility beyond what your base game requires? Have you ever found yourself in a situation like this? What would you do in this situation?
  9. Martin Brentnall

    Was it a mistake to develop my own engine?

    I would definitely have this concern with a commercial engine. I use a lot of Java SWING in my job and even getting that to do what I want can be a pain at times. For my game editing tools, I developed my own GUI component toolkit in pure OpenGL, and while its certainly a lot more limited than what SWING offers, at least I can always easily get it to do what I want. The biggest challenge isn't the shapes or detecting the collision, but handling how the game reacts to the collisions. For example, when the player collides directly with a wall, he normally bounces back from the wall (which is what you expect). However, if the player "clips" a wall at an convex corner, then I do not want the player to bounce back. Instead, I want to adjust the player position so that he isn't clipping through the parallel wall of his movement direction, and keep his momentum and movement direction. The idea is that my game favours the ability of the player to "slide" along walls from a corner rather than bounce away from a corner. Yes, it isn't realistic, and it might sound a minor detail, but it makes a huge and important difference to the feel of playing the game.
  10. Martin Brentnall

    Was it a mistake to develop my own engine?

    I haven't tried on AMD; my current system has an nVidia GT660. I don't think performance will be a huge issue in my game though; the graphics are so simple that it's fully playable even using a software implementation of OpenGL, running on a CPU that's five years old and wasn't even very expensive when it was bought.
  11. Martin Brentnall

    Was it a mistake to develop my own engine?

    To be fair, I've found that this can happen when developing my own engine too. For example, I'm facing the possibility that the scripting library I'm using in my engine might not work for much longer. It hasn't been officially supported or maintained since 2010, and some recent updates to my system have caused the compiler to start throwing up errors when the library is included. It's lucky I was able to find an unofficial fork that worked, because I wouldn't know where to begin if I had to maintain or fix that library myself, and the alternative libraries I've looked at in the past didn't look as nice to me. Another example is that my code still uses a lot of deprecated OpenGL functions like glBegin, glVertex2f, glEnd, etc.. I could update it, but I'd rather my spend time getting my project finished on the old version of OpenGL first rather than rewriting existing code to use a new API. I know that I'll need to do it eventually though.
  12. Martin Brentnall

    Was it a mistake to develop my own engine?

    I guess the title question was somewhat hyperbolic; I never really doubted my decision to develop my own engine and tools, even if only for the experience I've gained from doing it. I guess the question I was really interested in is what could have been had I decided instead to an engine like Unity or UE4, since I am so out of touch with modern game engines. What I read of a developer blog regarding Unity seemed quite off-putting. The developer was manually placing cameras in all the rooms of his game, then setting up triggers to change the active camera upon the player entering each room. In my engine, I just defined a "Room" object type, then wrote a short script to automatically reposition the camera when the player enters based on the location and size of the room. I can't imagine having to do all that manual set up every time I create a new room, let alone imposing that necessity on end-users of my level editor! That said, I have no idea if that was a limitation of Unity, or just a develop who lacked experience or just didn't care enough to implement a better way. He also ended up switching his project to UE4 later, so presumably he stumbled upon some obstacles in Unity (I don't remember if he gave a specific reason for switching).
  13. Martin Brentnall

    Was it a mistake to develop my own engine?

    My collision detection problem isn't only related to shapes, but also the way I need to define reactions to collision in very specific ways that don't necessarily correspond to real-life physics or other games. I have no idea what kind of flexibility PhysX offers for doing that, or how easy it would be to get the exact behaviour I want. Regarding tools: My objective is to create tools that are intuitive and easy enough to encourage creativity in non-technical players, not to rival commercial engines in terms of possibilities and professional productivity. In an ideal world, my editing tool wouldn't look out of place on a games console, so it would be something more along the lines of LittleBigPlanet's level editor (although a lot simpler of course) rather than Unity, though I'll admit that it's still a fair way off from that. I still don't have any insight into how capable tools like Unity/UE4 are for developing such tools like level editors, etc.. Of course, one thing I keep forgetting is that Unity/Unreal didn't even have editors on my development platform when I started working on this project, so I didn't really have as much choice back then anyway.
  14. So I've been working on-and-off for several years on my hobby project. The project is around 90% complete. It includes a game, a level editor, as well as a general tool for adding/modifying game objects and mechanics. The engine also supports plug-ins that allow new functionality to be added via DLL's. Although I'm happy with what I've accomplished so far, I sometimes have this nagging feeling that I could've accomplished everything so much quicker if I'd used Unity or Unreal instead of starting from scratch with C++. There were a few factors to my choice: My biggest concern was uncertainty that an existing engine would give me the flexibility to do everything I wanted, especially the level editor and engine tools. I think it's fair to say that engines like Unity and Unreal are proven for developing games, but it's not clear to me if this also applies for non-gaming applications like level editors? The tools are a very important aspect of my project because one of the primary objectives is to encourage creativity in players, including non-programmers (ideally, I want the level editor to be accessible enough that even a child can use it). I also had some concerns over how much control I'd have over the precise functionality of an game itself. For example, collision detection is usually talked about in terms of cuboids and spheres, but this wouldn't have allowed me to get the exact feel I wanted in my game, and I have no idea how much leeway an engine like Unity would give me to customise something like that. I'd hate to invest months in learning an engine only to find that it can't do something I need. Now, with all that said, I should probably confess that I don't really know anything about modern game engines. I pretty much mastered the Build engine map editor (Duke Nukem 3D, etc.) in the 90's and I dipped my toes deep enough into UnrealEd to make a few decent deathmatch maps for the original Unreal, but I literally haven't touched any game engine tools since then. My only exposure to Unity comes from reading a blog from a developer who was working on a similar project. Unfortunately, that blog seemed to confirm some of my fears about using an engine like Unity. Perhaps that wasn't a fault of Unity; maybe the developer didn't have enough experience or just didn't care about doing things in the best way. So I wonder what your thoughts are on this? I'm too deeply committed to my own engine at this point to change, but I often wonder how things would've turned out if I had opted to use an engine such as Unity or Unreal. I suppose at least I've gained some good experience from developing my own engine! So what do you think? Could I have done better with an engine?
  15. Thanks for the input! Regarding component types, I'm currently only focussing on the types that I actually need for the game I'm currently developing. The requirements for that are pretty simple; just to show text/numbers, icons and panels. More component types can be added later. The engine also supports a plugin framework, so it's possible to add more component types without recompiling the base project. With regards to UI scaling, my current approach has been to define the vertical space of the screen as -1.0 (bottom) to +1.0 (top). The horizontal space is then defined relative to the vertical distance based on aspect ratio, for example 4:3 = -1.333 (left) to +1.333 (right) 16:9 = -1.777 (left) to +1.777 (right) 9:16 = -0.5625 (left) to +0.5625 (right) In this approach, (0.0, 0.0) always represents the center of the screen. The problem is that while the heights always stay fixed regardless of aspect ratio, the widths and horizontal distances between components can change. So for example, if I anchor components to the two top corners of the screen, each with a width of 0.4, there is a gap of 2.756 between them on a 16:9 screen, but on a 9:16 portrait display, the components get pushed much closer together, so the gap is only 0.325 in that case. For that reason, I'd like to be able to somehow have the components scale to become smaller as the screen becomes more vertical. On the other hand, I don't want the components doubling in size if someone decides to run the game in 32:9. Maybe I'm just over-thinking this. Everything else you've described (layout, anchoring, etc.) sounds similar to what I already had in mind, although your terminology and explanations are better than mine (not sure why I didn't think of using the term "anchoring" for example). Anyway, the topic was more about functional design rather than technical implementation. I'm really interested in what kind of functionality people expect in such an editor; what kind of features would be intuitive and what to avoid. I do have some experience in designing and developing similar tools, but it wasn't a video game related project, and the resolution and aspect ratio was typically known beforehand. Also, this past project was based on Java, whereas now I'm developing my tools in pure OpenGL. I'm not using any GUI toolkits like QT, GTK, etc., so any components like dialogs, text fields, combo boxes, etc. are being developed in pure OpenGL as required. Ideally, I'd like the end result to be something that wouldn't look or feel too out of place if running on a games console. So it would be something more along the lines of say, LittleBigPlanet rather than something like Unity. I'm not really sure if I'm heading in the right direction for that though considering what I already have at the moment is pretty heavily mouse-based, with conventional GUI components like menus, dialogs, etc. This might be something I need to look into more detail later, and just focus on finishing what I have for now.
  • 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!