Karsten_Member Since 19 Jul 2011
Offline Last Active Yesterday, 04:02 PM
- Group Members
- Active Posts 444
- Profile Views 8,894
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Posted by Karsten_ on 21 June 2016 - 03:57 AM
No matter how much we (effectively the consumers in this context) prefer our own different languages, sooner or later we all depend on a C library that could potentially be made safer by using Checked C.
So things like Rust a C++ would still potentially benefit from Checked C. And that I think is pretty cool.
Rust is written in ~1.6% C (which is a massive amount of code, larger than many games in fact)
The Clang compiler is written in ~21.6% C (again massive and that's forgetting the standard library wrapping a lot of C)
If Checked C can alert us to bugs in these projects, then everyone's a winner
Posted by Karsten_ on 17 June 2016 - 03:02 AM
It also most definitely does not include anything even close to weak_ptr.
Are you sure? When reading it through, it looked like ptr<T> was designed to NULL out when the original data was invalid. That is the functionality from std::weak_ptr<T> that would be very nice.
No. This doesn't solve anywhere near enough real problems compared to just using modern C++.
C++ can't solve this issue because it itself is based upon potentially dangerous C libraries. As a library consumer, C++ (even Java and C#) seem better than C but remembering that underneath all their hoods, the same dangers can (and almost certainly do) still lurk, it removes all the fun ;). Plus these languages end up running more C than a C program due to their additional layers written in C so they are still not ideal.
Checked C aims to remove these issues at a much lower level than possible by just bolting on another random language.
Posted by Karsten_ on 08 June 2016 - 09:10 AM
The Wavefront .obj format does not support animations but it does support "parts". You could write your own animation system to perform keyframe based animation (probably with interpolation). However you would also have to develop your own tool to create the animations. Personally this work is worth it since keyframe animation is really simple and fast and for small models (especially on mobile it looks quite good).
I wrote a tool that does this a while back that I can dig out for you if you would be interested in it (might take a couple of days to find it ;)). Here is a video of it:
I also provide an API for OpenGL that reads in the data and displays it you can use as a reference for the engine you are using.
You might also want to look at other file formats such as fbx or COLLADA which do embed animation data into them. It also means that you can do animation using Blender, Maya etc...
Some links to stuff:
http://www.autodesk.com/products/fbx/overview (FBX SDK to help load the FBX animation data).
http://threejs.org/docs/#Reference/Loaders/ColladaLoader (Example COLLADA loader for Three.js).
Posted by Karsten_ on 17 May 2016 - 05:30 AM
Develop for Linux because that's the only platform I want to buy games for. ;-)
Heh, I agree but preferably also provide source code so it is possible to support the many Linux distros, now and in the future with a newer libc and kernel.
But anyway, with cross platform development like Unity, why do you need to worry about the platform until you have made a few games and actually have a product to sell?
Unity provides a massive worry about cross platform support. If you want to support a platform that Unity doesnt support (older or newer Linux distros), there is very little you can do and will need to change engine.
Not to mention the Linux support provided by Unity is only really Ubuntu :/.
Also, after porting a Unity 2.x project to 4.x, I realized I would rather port to an entirely different engine!
SDL and C++ is such a better option here.
Every time I get comfortable with something, the market makes me move. I learned the bulk of what I know in XNA. Microsoft abandoned it. I learned DX11. Microsoft is pushing me to Linux; so now I need to learn OGL4.5.
After your experience, why the heck would you recommend the OP locking himself into Unity? ;)
Its not like Unity is going to be around for any great period of time (Game Engines are often short lived). I actually started working on an open-source Unity to soften the blow (in a similar fashion to MonoGame). But then realized that there were better engine designs to use haha.
Posted by Karsten_ on 17 May 2016 - 03:06 AM
The "hip and trendy" money making platforms change a bit too fast to really simply choose one and be done with it. Ideally you should write your games in such a way that they can be ported to a new platform in a short time span. This is not actually too hard but what it means in reality is not to lock yourself down to vendor specific languages or tools.
Remember that being locked into things like Unreal Engine and Unity will mean you will miss the boat when a new platform comes out because thay do take a long time to port their chunky engines across.
What I generally recommend is what you are using. C++ and SDL (and OpenGL if you need 3D). However learn to avoid Visual Studio because it will make you more flexible to port to other platforms. Some platforms that it does already support is:
Android: Using NDK and SDL, a game can often be ported in a couple of days
iOS: SDL has been ported. iOS apps can be written in C++ (and C which SDL is written in).
Windows: Standard platform
Linux: Standard Platform
*BSD: Standard platform
Mac OS X: Standard platform
Remember that 99% of software is still written in C. This really does make C the most portable language. Unfortunately it is a bit hostile to write games in so that is why I recommend C++ because it trades in a slight loss of portability with a very nice language (if you ignore the manky bits ;).
There are also hundreds of custom C and C++ compilers available (including C++/CLR that outputs to .NET IL like C#) making it very unlikely to lock you into a specific language or platform.
As for really locked down platforms (and I predict future platforms will be like this), Emscripten will likely be able to run your SDL / C++ game at about 70% speed. You can do this by using whatever crap they force you to write in to develop a very minimal http server (~20 lines of code) and open up the platforms web browser pointing to "localhost". Its a bit hacky but it gets your game out there
Posted by Karsten_ on 08 May 2016 - 09:17 AM
Remember that with Unreal Engine 4, they are allowing developers full access to their source code of *everything* (engine, editor, build system, test framework etc...).
At first, this may not mean too much to hobby developers just looking to use the engine for their own games but rest assured this will guarantee that Unreal Engine 4 will keep on being available forever. Whereas since Unity is closed source, it is very likely that it will fade out of popularity and existence like products before it (XNA 4.0, Adobe Flash, etc).
Developers who are willing to improve the Unreal Engine will port it to newer technologies (such as alternative operating systems like FreeBSD and less known distributions of Linux). This cannot happen with Unity. This is also the reason why UE4 could output to Flash and HTML5/WebGL almost an entire year before Unity could even though UE4 is a much more complex engine to port.
Also researchers trying new things out will gravitate to Unreal Engine 4 to try out new and innovative technologies (such as I am attempting to do for my own PhD). This means that Unreal Engine will just be more interesting to everyone in the long run. I actually see prosumer software like Unity as a product rather than as real development tools.
Not to mention, C++ is simply a more portable language than C#(any .NET language) so will remain available well beyond our lifetimes . Like Microsoft VB6 (and Java to some extent), C# will become "uncool" one day and simply no longer be used for many things (especially in the game industry).
As for "getting into", UE4 has blueprint which is very friendly but a little bit inflexible or C++ which is very flexible and as long as you only use simple features (like you would in C# anyway), can be fine for beginners. Typically a mix of both Blueprint for the general flow and C++ for more involved logic are used and seems to work well.
I personally find that with Unity, you are thrust into a pretty much lifeless game world after dragging in a bunch of models and there is not much fun to be had until you get used to the design of the code and have followed at least a couple of video tutorials.
Posted by Karsten_ on 12 April 2016 - 05:55 AM
Just because C++ has been around for a long time doesn't guarantee that it will be around forever. Just about every survey I can find shows that C++ usage has been declining for years.
Other languages are almost always written in C or C++. So whilst C++ popularity may be declining (which it honestly isn't), it doesn't mean the technology is going away... ever.
Yes, it may not be cool. I remember the day when people told me that C and C++ was already obsoleted by Java 1.5... Haha did I have the last laugh ;)
The fact that C and C++ both have hundreds of compilers available to them whereas languages such as Java and C# have only a few does speak very highly for how critical C and C++ is for software development and how much they are "the" standard technology that all others are based upon.
For a beginner, it may not be relevant but for any technology have a look at its dependencies, such as what the runtime requires, what the compiler requires etc... This will almost always be C or C++ but also gives you a good idea of the lifespan of the language.
Posted by Karsten_ on 31 March 2016 - 02:54 PM
IMO, you should use Unity since you already have working knowledge with it, your goal is to get up and running asap
Unity isn't always the best choice when trying to get up and running asap. Especially in a 2D project where there are much simpler (and more flexible) solutions. I would probably suggest MonoGame over Unity.
Using a framework or developing your own is likely going to help learn more about game play programming than just hacking around with Unity (which will only really teach about very Unity specific coding practices).
Posted by Karsten_ on 22 March 2016 - 12:47 PM
Github has actually been working on a git extension for large data files. They support it on their system, as well as on Gitlab. I don't know about whether Bitbucket supports it though.
You can find the git large file support extension here: https://github.com/github/git-lfs
I'm not 100% convinced to the benefit of this. Its not like a diff or a merge can be done effectively between large binary files (I know perforce can do it between images but its rarely useful). Our artists often put the raw data (i.e photoshop sources) on a versioned rsync server instead. Only the output assets (i.e png files) and code should really be on a version control.
rsync is faster and more scalable than any version control can be I suppose.
Posted by Karsten_ on 22 March 2016 - 04:17 AM
From a slightly different point of view, some notes on maintenance of servers:
Git - A pain to set up a multi-user Git server such as GitLab and managing multi-user Git directly is quite awkward. Most people just use GitHub which is not ideal.
Perforce - Easy to set up server but works horribly with continuous integration (Jenkins / Bamboo). We changed from this because of this.
Perforce Git Fusion - A massive faff to set up but allows perforce to work nicely (via git) on Continuous Integration systems (and OpenBSD).
Subversion - My personal recommendation. Provides a single binary server which is very easy to set up. No thrills, just works. Text file config but you can use SCM Manager for web config (https://www.scm-manager.org/). SCM Manager Supports Git too but has too many more extra steps its not worth it. Works great with Jenkins and Bamboo.
Also, my friend helps run CodeBaseHQ (https://www.codebasehq.com/). You might want to check out their free hosting offers before you do decide on GitHub.
Overall, I highly recommend subversion, I actually find its branch system a bit more structured than Git. Rent a bare VPN server and just manage the svn server yourself. You can then take snapshots of the VPN virtual machine to make backups of your entire repo too.
Posted by Karsten_ on 21 January 2016 - 06:57 AM
The C# language isnt outdated. I believe the implementation of C# (old version of mono) that Unity uses is quite outdated though.
XNA is obsolete, you will want to look into MonoGame (open-source re-implementation) instead. This can use the most modern implementation of C# (both Mono and Microsoft .NET).
Posted by Karsten_ on 23 December 2015 - 02:21 PM
Whilst not 100% accurate, I generally say a game architecture uses an inheritance based system if a game object inherits from more than one ancestor. I.e Object <- MovableObject <- Enemy <- BadMan
If minimal inheritance is used, i.e the architecture prefers composition to inheritance such as Component <- Position and then a position component is added to multiple objects, then I would suggest this one uses the component entity system.
That is in C++. In C, I find the best way for OOP is the component entity system since large chains of inheritance can get complex.
Posted by Karsten_ on 23 November 2015 - 06:23 AM
Unreal 4 is open-source.
Nope it is not. For such an engine you would need to get Torque 3D MIT an engine running on Linux and Windows PC. Read more here.
That is an open source game engine.
UE4 offers you the source code and the game engine as a tool as long as you agree upon the UE4 license. An open source game engine under the MIT license demands nothing and you are free to use the tech as you wish.
Yes your exactly right. Unreal 4 does not use an open-source licence. Its entire source is available however to anyone who will accept the Epic Games license unlike Unity.
Updated my original post.
Posted by Karsten_ on 22 November 2015 - 04:27 PM
Look into C++ and SFML that is a good starting point for you. Learn C++ and make pong using SFML. I suggest C++ because
1.High performance networking code is usually in C++ and in your other thread I think you mentioned an MMO.
2.Unreal engine, at least coding is in C++... but like mentioned in the other thread there is also blueprints.
3.Professionals use C++.
So do you reccommend Unreal? I was told unity is easier to use and learn.
The Unreal 4 source is available (but not under an open-source license). For my purposes that makes it a lot more valuable than Unity.
C++ is also the most portable programming language I know with the most libraries available to it making integration with other technologies a lot easier than when dealing with .NET.
However, I find Unity a bit easier for beginners to learn and seems more polished (because it was a product from inception as opposed to an internal development tool like Unreal).
Posted by Karsten_ on 13 November 2015 - 04:55 AM
Perhaps provide a couple of different systems:
CPack for Win32 setup.exe
RPM for Linux
Deb for Linux
DMG for Mac OS X
Then... (because some players cannot have admin rights) provide a .zip for Win32 and a .tar.gz for more exotic Linux distros.
The difficulty with Linux is library versions so make sure to statically compile, or provide a bunch of .o files and provide a script to link them against their current version of libraries the first time they run it.
These 4 setup types can be scripted pretty easily and added to your build pipeline without much trouble. Basically it is pretty much on par with creating an APK for Android, a bit fiddly but once it is done, should keep on working (for a while ;)
My experience has taught me that many Linux / BSD users are able to extract (and often prefer) a simple relocatable .tar.gz file as a method of installation since it doesn't risk conflicting with system files.