Another thought: firms this size usually have their own M&A-team. Obviously you could buy the IP at an offer they can't refuse (but you probably couldn't Kickstart). Might sound snarky but there doesn't seem to be a market for old IP in games, which suggests they will not take your idea serious for 'normal' market value. That might be pretty economic. Big game producers need people playing new games, not having too much fun with (better) games from the old days. The hedonistic threadmill is what makes their firm the current size. Don't distort that balance by opening up the retro market.
They would try to turn it into mobile game or such.
There were a huge number of mods you could get for it from memory. Such as additional maps/campaigns to play through.
One of the first games I played online, the community was fantastic. Never managed to level up to get my crown :-( , it was a tough game to master online.
Is it possible to acquire the game on a steam like site?
- CMake, yay! These make generating build files for a variety of platforms (even Windows) a breeze. It also works with code completion stuff (CLion IDE, KDevelop both have CMake-based projects)
- I like how it splits stuff up as well (https://github.com/klaussilveira/qengine/tree/master/src/gam...).
- As for vendorizing SDL2, there is an opportunity for optimization: The shared libraries and header files can be scanned through CMake scripts. Example: https://github.com/tcbrindle/sdl2-cmake-scripts.
- I see the .clang-format file, nice! (This is for clang-format: https://clang.llvm.org/docs/ClangFormat.html)
Unfortunately, license is going to be a real barrier to most game developers. The ironic thing is this engine includes SDL 2 which prides itself on being on a permissive license. (https://youtu.be/MeMPCSqQ-34?t=405, 6:40 to 7:30)
If it's the intention to create an open source library to be helpful as possible to developers. If it's the intention to have a library just for use in the GPL ecosystem of games (which isn't bad: OpenTTD is GPL!) then this is okay.
The reason why is a private game developer want to retain control of their intellectual property, even throughout the prototyping phase.
As for open sourcing, I'd approach it in a different way: I'd release reusable components under a permissive license (e.g. MIT, BSD, ISC, zlib, etc.) and keep any creative work product code/source files private.
Similar SDL2 framework for 2D games (I made some CMake contributions a while back): https://oxygine.org/
I don't know how much the author has control here; it is derivative of id's Q2 engine which was open sourced as GPL.
The game code is very well separated from the engine, and qengine already removes a lot of non-generic game code from Q2. So all you have to do is delete a little bit more, write some glue code to tie in Lua, and you can write the entire game logic in a separate codebase, with a separate license. Also, you get moddability.
https://www.gnu.org/licenses/gpl-faq.en.html#IfInterpreterIs... also seems relevant.
stallman's portion of https://lists.debian.org/debian-legal/2002/11/msg00217.html too
(As others pointed out , oif you are looking for a loophole, game assets might be a better way to go)
While it's something cool to work with Quake II, its net-protocol has its downsides and I'd encourage anyone replace it with QuakeWorlds' networking as you'll run at a locked 10 Hz with the clients interpolating between the frames otherwise. This was done for easier handling of animations in single-player entities, but was regretted later (according to JohnC's own .plan files).
Quake 1 is nicer to work with in that regard. Also get used to wobbly model animations with the MD2 model-format as the precision of the vertex-animated models is very poor :)
It's also interesting to note that Carmack considered using a 16-bit MMX-powered SW renderer for QuakeWorld/Quake II (making it real cutting edge in 1997), but considering the global 8-bit palette was already in place, it would have resulted in a loss of precision of already paletted textures so it was decided against and they did it the old way.
I’ll likely live long enough to see the Unreal Engine of today called retro. I’ve never thought of this before, and it’s wild.
Time is cruel.
Is this how my parents felt in the 80s?
Doesn't make it hurt and less though :( .
Ps what do you expect your life span to be if you're excited that you've lived long enough to see quake 2 become retro, and will see the games of today become retro? That's only 40 years. I'm glad that it pleases you all the same.
The poor checksums on game assets in Jedi Knight, along with early multiplayer on MSN Gaming Zone made the whole gaming community an adventure. You could never be sure what kind of shennanigans you encountered, with people having all sorts of weird gameplay hacks.
My son teases me these days "Jedi Knight sucks, dad!" when he catches me working on the site (this is Brian from Massassi; it's sort of still around).
Oh man, thanks so much. That site's awesome.
Jedi Knight's one of only three online shooters I ever played much of (Wolfenstein: Enemy Territory and one of the Elite Force games, I forget which, being the others) and the only one I ever got good enough at to be accused of "hacking" at least a couple times a session (never, ever did). It has a special place in my heart. Thank you for your work in the community.
I sunk so much time in W:ET, got to a pretty good level with it, until everyone figured out the wallhacks, and every game became about trying to nail that perfect jump. For whatever reason, no matter how much time I sunk in to those wallhack training maps I could never get the knack of it, which meant I could no longer be where I needed to be to defend the base.
I had a lot of fun in your community, learned a lot and also got a great introduction to practical computer software. It might have been a critical part of my career choice later on. My nick was Gandalv the Gray at the time, just a random 15-year-old kid with recent internet access and lots of excitement for what was definitely for me, and probably for many others, a very novel way of interacting with others (online). Jedi Knight & the community at Massassi was an important part of staying sane through middle school for me, when there were no other people around me with any sort of scientific or technical interest.
I don't think I've realized until I thought about it right now, but being able to interact with smart and creative people online back then was actually a very big deal for me. I think I really wanted something bigger and more interesting than my random middle school, most of the people there had completely different interests. It would have been much more lonely if it wasn't for the online interaction on the side; it was definitely the right community at the right time for me. It's also very cool to have been present during an early period in online gaming. When things were much more chaotic, and everything was being explored for the first time.
Thanks again, and take care :)
There's plenty of good content here:
Map compiling and texture tools are included in the engine code:
The Quake community is awesome:
I'm familiar with how the GPL applies to regular system/web software, but I haven't had experience with it and game engines before. Since this engine is GPL-licensed it seems like any game built with this engine would then also need to be GPL-licensed, correct?
For PC games this isn't really a limitations, there are several games on Steam using GPL engines (mainly based on id's releases) - a known one is Quadrilateral Cowboy which uses the Doom 3 engine.
> Keep in mind that some programs, particularly video games, can have artwork/audio that is licensed separately from the underlying GPLed game.
Yes, mostly correct. In order to comply with the GPL, and distribute game binaries, you need to make the source to any game you make with it available under the same terms.
Technically that does not mean that you have to distribute the game under the GPL, but in practice that's how you would comply with the engine's license.
If you have something like the JVM, you can make a case that the program and the JVM are separate works. If you have something like Quake, I don't think that would hold up, I would consider the bytecode and Quake to form a combined work.
At best, I think you would be testing in-court what a "derived work" is or what it means for a work to be "based on" a program. The legal risk is not only the fact that your game might be considered in violation of GPL (and therefore copyright infringement), but that the case might be difficult and involve sophisticated legal arguments (which would make it expensive) and you might also experience adverse effects before successfully arguing your case (DMCA takedown notices, etc).
It's also not assets that are the problem, it's the game-specific code.
As I said, it isn't even about creating a perfect abstraction, just enough to minimize the effect of piracy.
The question at hand is whether the game you are making is a work based on the engine. If true, to comply with the GPL you must release source. Establishing communication channels so that you can put your game logic and the engine in separate processes are not a silver bullet, they don't change the question of whether your game is a work based on the engine, they mostly change the mechanics of how your game is a work based on the engine. There are a lot of difficulties in making this argument.
The court is probably not interested in hearing about whether different components are running in the same process and linked together or whether they are running in separate processes and communicating through IPC. At best, I'd say that you're running the risk of an expensive court case, and at worse I think you stand a good chance of losing it, not having enough money to fight it (because the legal arguments are quite sophisticated), and suffering from things like DMCA takedown notices in the meantime.
I think the trap that software engineers fall into, far too often, is that we try to answer legal questions using the same techniques we use to solve technical questions. The question of, "Is this an executable?" or "Does this use dynamic linking?" is something you can answer based on your definitions of what an executable is. However, legal arguments don't happen in such a mechanical fashion. Contracts and laws are written in prose, not code, and they are interpreted by humans which are basically trying to do understand some combination of "what did the author mean?" and "how would people generally interpret this sentence?"
Projects vary between “total conversions”, which give you essentially a new game with the existing engine, to things like Freedoom, which are complete sets of replacement assets for the stock game. Freedoom isn’t really a different game from Doom, but it combines the GPL Doom source with a new set of assets so it’s completely free.
Also, I’d like to complain about your terminology—I don’t think “infected” is the right term. I think it’s a bit unfortunate that the word caught on. You’re never infected by the engine’s license, because you are never forced to use the same license.
It’s also not a question of whether you are extending the source itself, but whether you are creating a work based on something which is GPL. Extending the source of an engine makes it clear and unambiguous that you are making something based on the engine, but it’s not the only way. An engine really isn’t a tool. You can’t interact with the engine and a game made with it separately. You can’t really swap out engines. There’s not a ton of case law exploring this, though.
One thing I wonder about this release is though - the Original Quake2 engine had a very fixed palette and also some odd lighting that always skewed the palette to a brown tint - does qengine fix this?
Also... Bonus... Some Quake2 maps, that I made way back: http://www.jaruzel.com/blog/my-quake2-maps
You can create your own palette using the included pcx2pal:
After that, you might want to generate the colormap:
If you enjoy the code of Q2, but also would like more modern rendering, I highly recommend quake2xp from Barnes:
Yamagi is the gold standard for all Q2 engines:
And some art help:
I can't find the website I used to download maps and skins from. It must be gone by now.
That game is so rock-solid as far as stability/system support that I would literally buy it again out of general principal =)
Huh. I suppose CPUs are fast and all, but still seems odd to replace perfectly good OpenGL renderer with SW rendering.
Not that WebGL is all that much to write home about vs. native...
Hopefully one day it'll live on in another game that would do for others what it did for me. I even have some notes scoping it out..
Just roughly speaking, maybe something something like https://github.com/waterson/purescript-asteroids and https://github.com/hdgarrood/multipac together
..But who knows what game programming might look like soon.
.. which is also quite intriguing, for those of us with a bent towards the 8-bit aesthetic...
I would not be surprised of the pressure they feel for Half-Life 3 to be great is an order of magnitude greater than what they felt with Portal 2
I suppose it's not really all that modern, but still... wow I'm old.
...those xkcd style "make you feel old" statements are quite fun to make.
Both are Q1 though. However, the gray-ish/brown-ish look is entirely dependent on the color palette that you chose to use in your game. You have 256 colors to choose from, and with the 256x320 colormap, you get 64 shades of each.
And engoo is very good; I was one of its beta testers!