A remake on Unreal Engine could also be possible. I’m currently learning about UE4, once I’m done learning it correctly, I’ll maybe try working on a prototype.
The licensing of the Unreal Engine doesn’t allow GPL (Tremulous is GPLv2+) code to be used with it, so the game would have to be made from scratch without using any of trem’s GPL code. Murnatan has been working on a game based on trem game play using Unreal 4, although its game is commercial and closed sourse. Although a new FOSS game could be built on Unreal 4 from scratch that doesn’t have a conflicting license. But another issue is that as I understand it, Unreal’s system requirements is pretty heavy (especially when compated to trem’s current engine).
4 Likes
Yea, I wouldn’t use trem’s code as it would be close to impossible to add to unreal engine. Coding a game like tremulous isn’t too bad to do anyway on Unreal Engine.
As of the requirements it’s not too bad if the code behind is good. You could easily make a game that runs super well on old computers with UE4. If the code behind the game is shit, the game will run like shit. (It applies for the models and suchs as well, if we have , let’s say, a cube with 300’000 vertices while you only need 8, it’s pretty clear where the problem is ^^.)
But yea. Making everything good at the beginning would make it way more possible to run on older computers without having too big requirements (You can even make an option menu where you can alter the graphics and remove things like shadows, AA, SAO and so on.)
2 Likes
Hello there
I’ve been playing around with UE4 for +1 years and a remake indeed seems pretty viable! Unreal’s Blueprint system is very easy and fast to work with. In fact, I’d go so far as to say that a lone guy, by himself, could make a crappy port of the game, given access to the assets and levels in the right formats, and a couple months of free time…
Which I happen to have.
But in my opinion, a remake would also require new art, new levels, new game mechanics, new music, new animations, otherwise the overall improvement will be marginal at best, or some changes would have to be made to old assets (normal maps, new lighmaps, new effects) but either way we would need some artists and sound designers on board. And of course permission and support from the old devs to use the name and the license, otherwise we might run into the same problem as rotocat.
2 Likes
Oh, and forgot to mention, Unreal’s blueprints system has built-in networking (0 lines of code needed), designed with FPS games in mind.
A 2 and a half hour tutorial series explains it all:
2 Likes
Well what I have heard, Unreal’s Blueprint isn’t the best, its pretty buggy at times if I remember correctly and a few other hitches.
Buggy?
Not at all! Well, or maybe not anymore…
At least in my experience, all bugs were either of my own making, or the result of a faulty plugin. Although UE4 Blueprints are, in theory, much slower to process then c++, It only becomes apparent if you are running waay too many of them all at once (like thousands). FPS games shouldn’t require too much logic anyway, take off some health here, spawn an actor there, no need for AI…
3 Likes
Unreal engine Blueprints are as buggy as coding in c++ directly. Blueprints are only parts of codes that you rearrange using an interface. If you have a bug, that’s because you made the bug in it.
And the fact that we can easily create blueprint-callable methods, variables and so on, makes it even more viable.
As for the models, I’ve just bought a course to help getting a good workflow and have a good knowledge about blender. (Enough to remake all the tremulous models in some .fbx’ or close to any format that I want, if not all.)
@NowhereNews, as for the blueprints, the only way you’d use it for everything is to have somewhat of a prototype to then rework in some combination of c++(UnrealScript since a lot of the methods were reworked for Unreal 
) and blueprints.
I’ve been learning C++ and Unreal Engine 4 for about two months now and I can say that it’s way easier than most think. I’d probably be able to do a remake of tremulous with the current knowledge I have. But one of the part I prefer to wait having understood correctly is the multiplayer. Adding Multiplayer to a game is not necessarly hard, but isn’t easy either.
Anyway, all that is to say that I do think that Unreal Engine could easily be viable Engine for tremulous to indeed increase tremulous graphics in any way we want, but as well keep a low-requirement on performances. (This is why I say it’s not always good to use only blueprints ^^. Some features will be harder and heavier to add in Blueprints than adding them in c++ directly and making them blueprint-callable.)
2 Likes
@avarthat
I’d love to volunteer for a Unreal Engine port of tremulous. Although I can only program in blueprints, I can also chip in with level design and maybe assets. For a 10 - 20 player game, I think blueprint-based network will be just fine, its what’s designed for.
3 Likes
For a 10-20 players, yes blueprint should work relatively fine. But if we want to get higher players like the current servers (about 64 if I recall well?) having a nice and stable network code (can still be in blueprints if really well made and thought.) is necessary.
But as I said, blueprints are literally pieces of code put together.
An integer in blueprint is the same thing as an int in c++ (It has the same type, the same utility and so on.)
A float is still the same as well.
A function has the same use and is close to the same in the making.
The main difference that makes c++ easier to work with on some ends is that you can make static objects have events/actions that you can make blueprint callable and then use it on a blueprint with curves and so on if needed.
Also, something good to keep in mind, making a curve in c++ (For things like Animations and such) is close to the same as trying to access hell with it. (It’s basically a pure shit to do.) Whilst using blueprints makes it way easier to add. That’s why I say that you should use c++ for most of the actions being required for the projects whilst the blueprints should be used for simplifying the work when adding things like animations, sounds, musics, referencing another object to connect the code to an object and so on.
Anyway, I’m still in the process of deciding if I’ll really do a remake of tremulous on Unreal Engine or if I’ll keep at my main projects. If I do end up doing that remake, I’ll surely let you all know ^^. GrangerHub is the only community I’ve really be part of and happened to be able to bring something to, this is one of the main reason that I came back, but as I do want to help, I also really need to focus on finishing my schooling and getting a job and such. This is why I didn’t really start anything big yet As soon as I get in a more stable situation, I’ll re-think about doing more, but for now I can only really do a few things when I’m here and I don’t really want to begin something too big that I wouldn’t be able to finish ^^.
2 Likes
64 clients is the max that the current Tremulous code allows for a server (that can technically even be increased when backwards compatibility is no longer a factor), but the largest number of actual players I have seen on a trem server at once in the last few years has been in the mid 30’s.
Sure I have heard that previously on 1.1 servers, there were issues with many servers reaching the full capacity of 64 players, and many players having to go to other servers because those servers were full (I don’t recall if gpp servers had that issue). But still, games can be plenty fun with just 20 players, and it might not be bad necessarily if that limit existed in some future version of trem. If that limit is reached, and there are excess players, they could always play on other servers.
3 Likes
I do agree with everything you wrote, but what I mean is that if we’re to remake it on another engine, why not allow higher numbers directly or at least make a better foundation in the initial code so it allows further change without the need of remaking everything again.
Making 64 people available on a server shouldn’t be really hard on Unreal Engine 4 to implement.
But even if we limit to 20-30 it should still be made so we can further increase the amount if the game population indeed increases. If we’re to attract new players, it might be a good thing to make sure we can handle such amounts of players without having to host 30 servers of 20 players each. (I’d rather see a couple of servers that would not require much more performance from a 20-30 player server have the capabilities of being increased to 64 or even higher if needed.)
But I do agree that we don’t need to have such high capabilities at the start. As long as we make it so we can easily increase it if needed without introducing unwanted bugs. As for the 1.1 servers, if I recall well the main problem was because of some de-synchronisations or something. Which a good and well thought code/blueprint system could probably easily overcome without a doubt. (Sure it would need some testing, but as with any multiplayer game, there’s always adjustments to do. Which is made easier to do when we have a good ground to work from.)
(Sorry for repeating myself a lot 
, I often read back my text and I find that I often say the same thing three or four times in a different way, but at least I’m made a bit clearer. ^^)
2 Likes
What’s wrong with having 30 servers or 100 servers, or more (just throwing some numbers out there), if the player base grows to require such a number of servers? With the growth of the player base will come the additional servers to support them.
3 Likes
I don’t mind having multiple servers even if it ends up in thousands, but it would still be a good thing to have a possibility to add more than 20 players to each servers, it would prevent the possibility for the players to feel a limitation in this way.
My point was not to make it so only a few servers are available, but to allow any server to take a higher amount of players than just 20 or 30 whenever they want to increase the amount of players the server can take.
2 Likes
Consideration is good, but there still is a lot of juice to squeeze out of q3 imo.
Lua scripting support on the top of the list.
Seperation of game and engine code, atleast as much as feasable would be a important stepping stone for a new engine.
Engine change will need careful evaluation which will take quite long.
Im not too hyped for unreal engine, but im not opposed in principle, i prefer free software engines.
Some of us devs think idtech 4 might be a likely candidate.
It offers superior qualities over the current, its time proven to be very powerful, perhaps not on par with current engines, but no doubt sufficient for our needs.
Though many moons back i had wanted to make a game with but i never managed to get a foothold because of build issues and lack of documentation.
But now with people around who know a lot more than i do we should certainly evaluate it.
Another alternative might be torque 3d by garage games.
It once used to be commercial, but now it is free software too.
With this one i have a bit of experience, its toolsets are quite amazing, sadly the scripting isnt yet very good, thought there are plans of shifting it to lua, then it would be amazing.
And unlike idtech4, this engine still has a quite active community.
I think once 1.3 development slows down a little, we should take each engine and try building a small template game together and see how things go.
3 Likes
I can’t disagree with anything you wrote.
As for the engine there’s a lot of possibilities.
From UE4 to Torque.
We could even end up writting our own engine. (It can be done pretty well using SDL, OPENGL and such libraries. I’ve started back about a month ago with my brother to work on a 2D engine for an RPG we want to make after learning more about SDL2.0, but the best part of it is that it’s compatible on OSX, Linux, Windows. (Pretty much any version. My brother’s Macbook is still on Mountain Lion if I recall well, and he could compile the projects we’re working on without any problem.)
As for OpenGL from what I’ve seen it should be as compatible as SDL.
I know making our own engine sounds like adding way too much work, but if allows us to release 1.3 with our own work completely, it could really help bring more modders/players as some might be more used to C++ than C. Especially on Tremulous’ super-well-coded source code
(I’d be willing to give a shot at making our own engine imo )
It sure wouldn’t be ready for a while, probably not even for 1.5. but with enough efforts it could definetely be a good thing.
4 Likes
I think we should use a poll to determine which engine would be worth doing a template on once ready.
It’s good to make a template on 30 engines, but if we use only one in the end, lets at least make it less of a pain to achieve.
Here’s a quick and small poll which you can vote up to seven choices (We then only need to see which ones are the highest and keep them. We should also set a base number to make sure not to include all of them after only one vote. (I would maybe suggest 4 or higher.)
- Unreal engine 4
- Unity
- SDL + OpenGL
- Torque
- IdTech4
- Keep the same engine
- Other (Please make a post with a suggestion and explain why.)
0 voters
4 Likes