• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

2453 Excellent

About kop0113

  • Rank

Personal Information

  • Interests
  1. Unity or Unreal

    For complete beginners or those who do not want to code: Unreal (with Blueprints) For people with experience in high performance native software development (i.e scientific, banking, visualization industry) then Unreal (C++). For more vocational developers or those familiar with things like Java and .NET (VB.NET, C#) then Unity is useful because non-native languages such as VB.NET or C# are far less challenging than C++. For many companies, often they simply don't have any other choice but to use C++ because that is what their middlewhere requires. No point in wasting months writing .NET bindings just to use a specific native library. So Unreal (C++). I still personally recommend the C++ route if your are starting out. It still looks better on a candidate's CV.
  2. Any recommendation on GUI solutions for games?

    In the grand scheme of things, games have often quite simple GUI requirements. I.e a game I recently completed had: Text Button List Box Check Box Granted, for a RTS you might have more complex requirements but for that you will likely need custom GUI components anyway. One alternative is using a "proper" Gui library such as wxWidgets, Gtk+ or Qt. Then use that for the buttons and lists but then render the game in some sort of wxGLCanvas (if using wxWidgets and OpenGL).
  3. You can do OOP with C (check out gobject as an (over engineered) approach). Likewise you can do procedural development with C++ but still benefit from safety and convenience (i.e smart pointers, STL / vectors) Most of my middleware work is in C (eases binding to other languages and the hardware) but I would classify more than 90% of my code to be Object Oriented in design. i.e C: struct Player *p = PlayerCreate(); PlayerDamage(p, 13); PlayerDestroy(p); vs (non-exception safe) C++ Player* p = new Player(); p->damage(13); delete p; As for which one is better... people generally agree that breaking things up into objects makes a project easier to navigate because you have a common design that you can make assumptions upon.
  4. Four Questions about Visual Studio 2017

    1. Visual Studio is pretty bloated these days so there are likely going to be bugs. However, the compiler itself is pretty solid so it is quite unlikely it will "inject" errors into your code. 2. As well as the latest, I generally keep a copy of 2010 around. Purely because quite a few large projects still require it (have not been updated to fix build issues for later VS versions). For example building the UE4 engine from scratch, Emscripten, Clang etc... It also means that my users do not need to install the latest Microsoft C++ runtimes to execute my software. Before 2010 came out, I kept a copy of Visual C++ 6 for a similar reason (as did much of the world tbh). 3. Command line Git is generally a lot more flexible. https://git-scm.com/download/win Also, Git is the tool. GitHub is a commercial "cloud" service. Alternatives are assembla, bitbucket or codebasehq. Also GitHub provides subversion access too if your team use a mix of SVN and Git. 4. Extensions and Visual Studio change too much. I wouldn't bother.
  5. When To Use Pointers?

    If you passed in Objects rather than pointers to objects, they would be copies. So if you modify them or get data from them, you would be modifying the copies. The original ones (perhaps a core part of you engine) will remain unchanged. This is obviously an issue if you added (i.e) a new Physics object to the *copy* of the PhysicsComponent, the original PhysicsComponent will remain unchanged causing issues later when you query the original expecting the additional Physics object to be registered. In C#, I see a lot of inexperienced developers make the same mistake for "boxed" value types like structs. They modify a Vector3 for example, pass that Vector3 into some other class but then modify the original Vector3 again, expecting it to change the Vector3 in the other class. In C# *everything* acts a pointer apart from structs/boxed types. // C# using a library where Vector3 is a struct, value type Vector3 v = new Vector3(); player.position = v; v.x = 99; // player.position.x is not 99 // C++ (avoiding pointers) Vector3 v; player->position = v; v.x = 99; // player->position.x is not 99 // C# using a library where Vector3 is a class Vector3 v = new Vector3(); player.position = v; v.x = 99; // player.position.x is 99 // C++ (using pointers) Vector3 *v = new Vector3(); player->position = v; v->x = 99; // player->position->x is 99 Perhaps refer to the following complexity in C# to better understand how C++ handles this situation: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/boxing-and-unboxing When people say do not use pointers in C++... that simply isn't feasible. Perhaps they mean they use smart pointers with references as parameters instead? Either way, unless they only stick to OpenGL's GLuint type system, I cannot see them avoiding pointers when dealing with 3rd party C libraries such as SDL. Would be cool to be proved otherwise. Can anyone point me towards a largish project where this is the case?
  6. Honest question about C++ vs C#

    My biggest interest is in the lifespan of software and I simply cannot see C# providing here in place of C++. For a start, Microsoft has already started doing weird things with .NET Core and in my opinion not handling the *important* legacy baggage of the language gracefully at all. Try compiling a .NET 1.1 program using the latest implementation of .NET and you will likely encounter problems. Also, a game engine needs to access the operating system (you cannot avoid this). As such you will need to access C or C++ libraries. My solution is to just use C or C++ then and get on with my work. However if you choose something like Java or C#, you will need bindings. This is glue between the native code and your .NET or Java virtual machine. Bindings are always terribly maintained and unless you write your own, you will be at the whims of these bindings. We have all heard of the saying "make games, not engines" but going one step further I would say "make engines, not binding layers". And that for the most part means that C++ is the absolute best choice. However, if you just want to make a game, have fun and maybe make a bit of money then move on. You cannot beat products like Unity. In which case just learn whatever [great|terrible] language they enforce on you and get to work! :)
  7. The UE4 Editor is not intended to be run in a VM and I personally ran into a few technical issues when I tried on our build machine which is a pain. Some things you might like to consider: - UE4 engine doesn't require the editor for the code side of things, you can build the output binaries which do run fairly well in VMs if you avoid many of the newer features DX10+, GL4+. - Look at things like SwiftShader (now open-source and maintained by Google). This provides you with a drop in software rasterizer replacement of d3d9. It works with Unity quite well in a VM in DX9 compat mode. It is much slower (still quite usable on a modern machine) and along with exporting to Emscripten to test your game quickly through the VM boundary, is actually the best solution I can think of (or at least the best of a bad bunch). - Run UE4 natively on Linux or perhaps make a chroot if you do not want to spam the OS with cruft. - Developing in a VM have many benefits, unfortunately "game making kits" such as engine editors are currently a little too far in the wrong direction from professional coding practices. Perhaps look into "code only" engines that do not need tools instead. Such as Irrlicht, Ogre3D etc... Or automate the editor via scripts without needing to create a GPU context. Something like: http://www.slashgames.org/unity3dwithoutgraphics/ You may think this feels a little bit "indie" but lets face it, that is exactly what Unity is. For UE4, once the project files have been generated, they should build fine on a headless machine or a VM so the situation is a little bit better. Personally I hate the current trend of "editors" mostly for the same reason you will likely encounter, perhaps things will change in the future once Unity 5 or UE4 become obsolete in a few years and people realize the only way they can run these tools to actually compile their hard work is from within a VM.
  8. Game Engine Recommendation for Linux Users?

    I don't have any experience with CryEngine but neither of the other two work particularly great on Linux. The Unity port is not well supported at all, it doesn't have an official download page for example and released builds are quite out of date. UE4 fairs a little better in that (due to the source being available) has had quite a bit of work done to it by the community to help compatibility with the common Linux distributions. It is still very heavy though and as such there are quite a few components that can break with how UNIX-like operating systems handle updates. Neither of these bits of software work with the open-source drivers which is a pain in the backside (for users and developers). UE4 will need to be built from source and unfortunately does not use a standard build system like CMake or even autotools. Instead it uses a slightly janky custom system but overall it isn't too bad (no 32bit though because... well probably because it is quite a fat bloated mess tbh ;)) If you are happy with a lighter tool, I perhaps recommend Irrlicht but if you want a "game making kit" like Unity, perhaps give GoDot engine a try, I have had a brief play and unlike the other two, it seems a lot more supported and robust on open platforms. Unlike Unity, Godot also integrates with C/C++ very nicely which I find very important on UNIX/Linux.
  9. Question about Game Engine

    I made a simple network game a while back with a similar (but certainly more simplistic) idea for a games jam: http://globalgamejam.org/2017/games/wave-cloud-office I really just used ANSI C and OpenGL (to draw 2d images so any drawing API will be good such as SDL, Allegro). I think for this, a 3D engine such as UE4 or Unity will just get in your way. Another idea (and this may make it look more authentic), just use a GUI toolkit such as wxWidgets, Borland's VCL, Java's Swing or C#'s Winforms. These GUI toolkits will not only provide buttons and things but also a pretty decent 2D drawing APIs for anything you need to be dynamic etc.
  10. Permenantly changing authorship?

    Ownership information is stored on the NTFS filesystem metadata rather than the file itself. If your removable drive is formatted as MS-DOS than it should not retain the author metadata. Another solution could be to zip up your files (in which case individual files will not store author details). If you encrypt your zip files then your data should also be very hard to recover. If you upload to an FTP or upload site, this should also lose the NTFS author data. One thing you might want to look into is using an encrypted filesystem. I rarely need to do this but when I do I tend to use this system on FreeBSD https://www.freebsd.org/doc/handbook/disks-encrypting.html If you don't like your account name, you can either make a new account on Windows and use that. You can also remove the "RegisteredOwner" data from the registry at "[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion]"
  11. Emscripten is certainly the route I would choose. It allows you to keep with the most standard and cross platform programming language whilst also tapping into the web market. Even better that you had chosen SDL because Emscripten comes with SDL 1.2 built in and it is very easy to use with SDL 2.0. If you do need 3D or hardware acceleration, then just like on the desktop, you can use SDL to create an OpenGL rendering context in a web browser and carry on your project as usual. Emscripten also has very large companies backing it now (Mozilla but also Epic Games and Unity because UE4 and Unity now depend on it to provide their HTML5 exporters). It is also pretty future proof in that based on Clang/LLVM, it will be first in line to properly support WebAssembly which is the apparent "future platform of the web".   Yes, I am exactly the same. Stick with C/C++ and "boring" technologies like SDL and OpenGL. These will be the most likely to stay around longer than our lifespan whereas products like Flash and Unity most certainly wont ;)
  12. Yeah I know but it is simple. Sometimes simple is nice because if all else fails, I can fall back to it and maintain it myself if needed for a specific requirement / platform. Also, being simple means it is first in line for a port. I.e to Emscripten it was pretty much released with the compiler. Whereas GLFW and SDL2 came almost a year late. SFML is still not supported either. As for the main loop in Glut. Many platforms don't let you control the main loop directly (i.e again, Emscripten, Android etc...) or they become "unresponsive". Glut's janky C callback system actually works quite nice with this restriction. For timers, I just don't use them. I generate a time delta and a frame limiter just like I do when using GLFW. To be fair, these libraries are all pretty much the same. They just need to open a darn window without manually coding horrid WinAPI or X11/xcb C code ;)
  13. Use glutMainLoopEvent instead. Put this in your own while loop and you get to control the lifespan of your program more directly. I.e when you leave your loop, the application can end. Make sure to include <GL/freeglut.h> instead of <GL/glut.h> because this function is only available in the extended FreeGLUT feature set. The last commit to FreeGLUT was in 2016-02-21 so is... stable lol. Hoever work has been done on it since then to port it to i.e Emscripten / WebGL. I like that the API is simple and provides a very diciplined set of features. On platforms providing their own random APIs such as Android, Marmalade, iOS etc, I always make a Glut-like wrapper so the core of my code is very portable. So I actually recommend keeping with Glut. Also, for DirectX, check out DXUT (A clone of Glut for DirectX, used to be part of the DirectX SDK, now a separate project). For more information on FreeGLUT, check out the API docs. http://freeglut.sourceforge.net/docs/api.php
  14. Help implementing an Entity Component System

    As I recall, XNA already has it's own ECS implemented if you wanted to use that? Check out a few of these MSDN entries. https://msdn.microsoft.com/en-us/library/microsoft.xna.framework.gamecomponent.aspx https://msdn.microsoft.com/en-us/library/microsoft.xna.framework.drawablegamecomponent.aspx https://msdn.microsoft.com/en-us/library/microsoft.xna.framework.game.components.aspx
  15. Engine / Libraries / Work environment

    You are not alone in this. It makes the architecture of code very scattered which is why a lot of Unity projects are simply messy. - It also works completely against documentation systems like Doxygen which cannot hope to follow a call graph or reverse call graph through the Unity black box - It also makes going between versions of Unity difficult. Prefabs get orphaned and their data gets munged whereas code stays consistent with a clear deprecation scheme if one arises. - It also makes continuous integration awkward because a headless UNIX build server obviously cannot reliably run an OpenGL accelerated GUI. - It also makes unit testing a bit of a joke because there isn't an idea of a "unit", it is just a bunch of weirdly linked prefabs and serialized binary data. But remember, Unity is not a professional tool (and neither is Blueprints from UE4). It is targeted towards "prosumers" and as such is designed to get things done as quickly and as "dirty" as possible. That said you can do pretty much anything through code if needed. I.e:   GameObject go = new GameObject(); MeshFilter mf = go.AddComponent<MeshFilter>(); mf.mesh = ... But if you do ever work with Unity developers, the chances are they will not share the same views and so will just trash everything you do ;) Whenever I am dumped with a Unity project because of bad choices made by management earlier on, I try to think of the editor as a simple "programmer friendly" level maker and then have proper initialization code attached to some ratty game object kicking around the scene. At least then I only need to fight with .NET (UnityScript or C#) being an inflexible scripting language whilst at the same time being a retarded systems language. (Though 99% of the time I simply will not take on a contract if I smell something like Flash or Unity is going to potentially be involved further down the line haha)
  • Advertisement