Jump to content
  • Advertisement

Martin Brentnall

Member
  • Content count

    14
  • Joined

  • Last visited

  • Days Won

    1

Martin Brentnall last won the day on May 24

Martin Brentnall had the most liked content!

Community Reputation

111 Neutral

About Martin Brentnall

  • Rank
    Member

Personal Information

Recent Profile Visitors

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

  1. 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: https://www.youtube.com/watch?v=_Qn5nScWq8Q&t=286s Editor: https://www.youtube.com/watch?v=fFiahyVE0dU 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.
  2. 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?
  3. 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?
  4. 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.
  5. 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.
  6. 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.
  7. 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).
  8. 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.
  9. 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?
  10. 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.
  11. As part of my ongoing C++/OpenGL hobby project to develop a (free) game, engine and tools, I am beginning to develop the HUD (Heads Up Display) editing tool. Aside from delivering a game, one of my primary objectives is to encourage creativity by providing tools that allow gamers (i.e. non-programmers) to customise the game in numerous ways, from simply building new levels, all the way to modifying the game mechanics and importing their own assets (models, textures, sounds, etc.). A part of such customisation is allowing a user to design their own HUD. Please bare in mind that I'm not creating a World of Warcraft HUD or anything complex like that; this is just a hobby project for arcade style games, so I'd like to keep things relatively simple.. So here's a summary of what the HUD editor will need to be capable of: WYSIWYG viewing and editing of the game's HUD layout. Adding components to the screen. There are several different types of HUD components, such as panels, icons, decorations, and values (such as scores, item counts, time remaining, etc.). Deleting components. Arranging the layout of components, such as moving and resizing components. It would be nice to have features to make such editing easier/quicker, e.g. grouping related components. Arranging the order of components from front to back. Specifying properties of each component (e.g. fonts, colours, value to show). I guess it also might be useful to be able to view and edit properties of the component layout directly too? Define how the layout reacts to different screen aspect ratios. I think this is the most tricky part. One of my goals is for the HUD to gracefully handle different aspect ratios like widescreen (TV/PC) and portrait (phone/tablet), so I think it would be nice if the user could a design HUD that could dynamically accommodate any arbitrary aspect ratio. So rather than say "if 16:9 use layout A, else if 9:16 use layout B", etc. or just stretching a layout to fit an unexpected aspect ratio (thus distorting text, images, dimensions, etc.), the HUD should look as nice as reasonably possible when a user decides to do something crazy like running the game in a 32:9 resolution. Here are my design ideas so far: Viewing the HUD: The HUD is displayed at 100% by default. The HUD can be panned by left-click and dragging anywhere not on a component. The HUD can be zoomed in and out using the mouse wheel. Selecting "Reset View" from the "View" menu resets the view to the default. Adding components: There is an expandable panel showing the various component types that can be added. The user drags a component he wants to the screen. A new component of that type is created and placed on the screen. Selecting components: The user can click a component to select it. The selected component is highlighted. One thing that always annoys me in other apps is being unable to select a component that is behind another one. So I had the idea of holding Control while clicking to select the component that is behind the currently selected one (thus, you could do this multiple times to get to the component that is furthest back). Deleting components: Pressing the 'Delete' key deletes the selected component (alternative: Select "Delete" from "Edit" menu or right-click context menu). Moving components: The user can left click and drag to move a component. Movement snaps to a visible grid. Resizing components: Eight "Edit Handles" appear on a selected component as small squares. Edit Handles on the edge of a component can be dragged to resize the component in one direction. Edit Handles on the corner of a component can be dragged to resize the component in two directions. Ordering components: Like MS Office and other apps. Right-click, context menu, "Move Forward", "Move Backward", "Bring to Front", "Send to Back". Affects the selected component. Component properties: An expandable VB-style property panel shows properties of the selected component. Properties can be specified via usual means (e.g. text fields, number fields, check-boxes, drop-down lists, and so on). For resources like Fonts, Colours, Textures, Models, Values, etc.. the engine already has support for these things, so it should be easy to support them as properties in a generic way. I already started developing a property sheet for the game objects, so I think I will reuse that one for the HUD components too. Linking components to the screen: To accommodate changes in aspect ratio, rather than laying out the HUD entirely relative to the screen, I had the idea of supporting a mix of relative and absolute values. So for example, the user can place a square score icon in the top-left corner of the screen with an equal distance from the left and top. If the game is played on a different aspect ratio, the icon remains square (not stretched), and the distances between the left and top of the screen remain equal. For this, I thought of perhaps middle-click dragging a component to a screen edge or corner, but I'm not really sure if that's the best way to accomplish this, since I don't recall encountering middle-click drag in other apps before. Linking components to other components: Following the previous point, let's say you want to place the score component adjacent to the score icon. You could middle-click and drag your score component to the right edge of the score icon to attach it, like before with the screen. Then you just need to resize the width and perhaps offset the component slightly from the icon (in case you want a small gap between the two components). The trick here is that the offset and width are both absolute, so a change in aspect ratio won't throw the component out of whack. Copy and Paste Components: I think users will expect standard features like this to be supported. Standard procedure: "Edit" menu or context menu. Undo/Redo: Same again. I think users will reasonably expect all of the above actions to be undoable. Standard procedure again: "Edit" menu or context menu. This is what I have so far. I'd be interested to hear from others who have tackled this problem and how they approached it, or just anyone who has any ideas on the subject. I'm especially interested in how to handle the problem of variable aspect ratios and screen resolutions, but any insights into designing an intuitive and efficient editor for video game HUD's would be great! Cheers!
  12. Thanks for all the informative responses; that's a lot of good reading. :)     To be honest, the engine and its editing tools are my project, which is where my real interests lie.  The game is just a "case study", if you will, to stress and test the sanity and flexibility of the engine.
  13. The pop song recording and VLC/movie distribution examples are interesting.  However, in both of these examples, the infringing nature of the recording and the movie can be immediately revealed by existing software. In my case, my engine is currently not released, so it may be possible to approach in a different way.  How about this: Let's say I only distribute the XML file without revealing it's meaning or purpose other than stating that it is later to become a required part of a free game.  Without an engine to interpret the XML, it is not possible to reveal what the XML represents and therefore the XML cannot be shown to be infringing.  As such, the meaningless XML file must surely be legal to distribute and possess at this stage. Now, let's assume that some people download the XML file in anticipation of later using it to play the promised free game. Later, once the XML file is sufficiently out in the wild, I then release the engine to read it.  Suddenly the XML file becomes illegal copyright infringement because the engine reveals that the XML represents a remake of an existing game. What effect does this have on those who already obtained a copy of the XML when it was a non-infringing file?  Do those people suddenly and unknowingly become guilty of possession of copyright infringing content? Let's say I cease distribution of the XML file immediately before release of the engine and rely on the community to redistribute the game XML via torrents, etc.  Since the XML content was not infringing at the time that I distributed it, can I still be considered guilty of infringement? I do realise this would be kind of ridiculous in practice and I don't really anticipate legal problems in my endeavour to recreate a long forgotten obscure 1980's computer game.  I'm really more just curious.
  14. Hello!   I am a hobbyist game developer currently involved in the development of a free and open source game engine.  As the engine and it's first game are nearing completion, I'm planning to reuse this engine to remake a classic 1980's computer game.  Of course, I will not be copying any assets or code from the original game. The first half of this project will require the development of some additional C++ engine plugin modules to represent the elements of the game - simple objects such as moving platforms, enemies, terrain, etc. as well as modules to generate simple assets such as textures, sprites, etc.  All assets of the game are sufficiently simple that I don't need to load them from external files.   I believe that these C++ modules can be designed and constructed in a generic reusable way that does not imply any relationship to the remake that I will be using them in.  For this reason, I strongly believe that the C++ code on its own cannot lead to any risks of infringement. The second half of this project will require that I use my engine tools to load the C++ modules and instantiate objects from them into a configuration that mimics the mechanics, layout, rules, assets, etc. of the game that I want to remake.  The resulting deliverable of this work will be an XML file that can be read by my game engine in order to generate and run the final game. This is where things become murky.  It's hard for me to see how either half - the C++ code and the XML project file - can be infringing on its own.  As stated already, I'm certain that the C++ modules will be too generic to be infringing. The XML file may be a little more questionable.  Technically, it will represent a description of the game, but will be written in a custom format that is only understood by my engine and the required plugin modules.  The XML file is therefore meaningless outside the context of my engine and the modules that interpret its contents into a playable game. As such, it seems to me that only a combination package of both the engine containing the necessary C++ modules and the game XML file together can possibly be deemed to be infringing. So here are my questions: At what point exactly does infringement occur?   Assuming that neither half can infringe on its own, can I distribute the engine and the game XML as two separate non-infringing packages? Assuming this isn't possible, can I distribute the XML without explicitly stating it's intention to be used in conjunction with the game engine and let users figure it out for themselves? In the case scenario above, can I give the XML file a custom file extension that also happens by co-incidence to be associated with the engine executable, making it easy for players to run simply by double clicking the game XML file?  Would this change the situation? In case this would still considered an infringement, then where is the line drawn? If I create an XML file that mimics the game mechanics, but using different sprites, textures, sounds and map layout, is the project still an infringement?  How about just using a different map layout? It may be worth mentioning that the engine is distributed with the same editing tools that I use to build the game XML file and is designed to facilitate and encourage user generated content. As a consequence, this means that players can build their own map layouts based on existing project mechanics or even create games themselves from scratch. Assuming I can safely include a project with matching mechanics of the game but not with the same map layout, then it will be fairly trivial for any user to rebuild the original map layout of the game in question using my project as a basis.  Would the inclusion of this capability make the infringement problem any more difficult to deal with? I haven't found much information pertaining to remakes composed of multiple dependent parts, so any advice on this would be much appreciated. :)
  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!