You're barking up the wrong tree with Bungie - you need to contact 2K Games...and good luck on that. I know some people who have tried, both with Myth and with Oni.
Ok , thanks for that information, sincerely. Let's find some friendly agent to assume control of this 2K company then. Thank you. Actually, when there is Unity3D around, what is the point of them keeping it closed. They could still keep the Movie and Art rights, if someday Hollywood wants to make a movie of it or whatever dream they have of milking it somehow in the future. They might very well loose the value of the Art and Story itself when someone makes a similar Unity3D game with a passable Art and Story that buries their value, and now it buries for real. Can't understand what is the point of their reasoning keeping it frozen.
Take Two is the owner of 2K Games. Take Two has a USD 12.4 billion market cap. Take Two refers to 2K as a principal office. Quite the endavour for your friendly agent. Best bet would be to found a startup that greatly enhances revenue on old games by, say, automatically remastering them and them pitching to Take Two. You can't clever your way around 12 billion.
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.
I see. Thanks. So they kill it, cut out it's head and bury on a salt desert so people will forget it exists and buy their new game instead. Still feels that something isn't quite right in this being the only reason, it's strange. But yeah, you are right, would need to call more than one friend to get 6B USD just for fun money, to risk on the game industry because of a personal caprice :D Your ideas were better, thanks.
They are big enough that they don't care unless you offer them _a lot_ of money or you know just the right people to talk to and have the correct connections.
Also in stupid „triple AAA” economy publishers consider tactic games too niche to be viable product.
They would try to turn it into mobile game or such.
Fantastic game, brilliant first player campaign.
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?
1997 was exactly the Year when the game Myth The Fallen Lords was released. 'til today I think is the best game ever made. Please if there is anyone who works for Bungie or whatever company owns this abandoned game, whose community have worked hard for years to keep alive, without any help from the Owner, even reverse-engineered the server, because they prefer to keep the game dead and it's tomb abandoned then release the servers code, Please guys just Open Myth already, It's been 20 years! It is considered "retro" now, did you read that headline? The community must still be alive, even. seems that there is still a multiplayer server running. And it is a damn good multiplayer game to play even today, with very good chat interface for team communication. Maybe the best I ever saw in a game. Imagine what was this for a youngster in 97 to hear the sound of the 3.6 speed Dialed Internet Conection, after a long minute of making weird sounds, finally makes the rrrrr sound that you knew it means you are on the Internet and can Play this unbelievable thing...back then it was jaw-dropping.
> 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.
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 license can be a problem for some studios, specially ones with uncomfortable contracts with publishers. If you are in that situation, I highly recommend writing a LuaJIT integration layer.
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.
I think using Lua scripting like that still counts as "dynamic linking" from the point of view of the GPL.
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
The Lua interpreter itself would still be under GPL but the code that the Lua interprets would not since as far as the interpreter is concerned the script is data. The GPL even has a section on this:
Lua is MIT licensed. The point is that if you have a GPL game engine and use lua scripts to turn it into a full game then you also need to license the scripts as gpl if you want to distribute the game.
(As others pointed out , oif you are looking for a loophole, game assets might be a better way to go)
But the Lua scripts would be bound to the underlying game engine. I would all come down to whether or not a judge would see it as a derivative work.
Never thought of that. What if code is compiled to VM bytecode first?
The examples in the FAQ imply that they consider separate binaries that share “complex” data structures to be parts of the same program, blurring the line for what counts as dynamic linking.
Another one for SDL2/Lua is LÖVE: https://love2d.org/
This is a cool project!
- 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/
The repo is basically Quake II's software-renderer and game-logic module merged into the engine binary. Yamagi Quake II ships with an additional OpenGL 1.3 and 3.X renderer which I'm sure could be ported over if SW was undesired.
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.
Came here to say the same; it’s like the first time I heard Nirvana on a “classic rock” station.
“Nevermind” is longer ago from today than “Rubber Soul” was from “Nevermind.”
Time is cruel.
Holy crap you just made me feel completely ancient. I had never made that realization before.
Is this how my parents felt in the 80s?
Ofcourse XKCD has it's own category for you to read:
I was barely at legal age to get into Nirvanas Concert, and I look rather younger than I am, so when I tell young people I have seen Nirvana Live, and was arrested for weed at their concert, many probably think I am just talking bullshit.
I wish they released UT99 under the GPL.
Would be really nice, id has been cool about this (at least while Carmack was around).
Epic MegaGames could do a gpl UT99 release, lol specially since fortnite is making bank for them right now. Doesn't seem like a big loss
Reading around, retro seems to be about 20+ years old, which fits.
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.
About the same as anyone else, but let's not tempt fate
Full with tutorials/plugins to emulate artifacts caused by temporal anti-aliasing, old-school shadow maps and heavy usage of screen space reflection and ambient occlusion in modern engines
Unreal Engine 1.x is retro
This is really cool, and I can’t believe I’ve lived long enough to see Quake 2 be called “retro.”
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.
Hello, you could say that. I love JK and I played the thing with the software renderer for years because my s3 virge card wouldn't render the game correctly.
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).
> this is Brian from Massassi
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.
> Wolfenstein: Enemy Territory
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.
Haha, wow, the one and only! Really cool to see you here on HN 16 years later, this is the kind of response I was hoping for :D Thanks so much for all the effort you've put into Massassi over the years.
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 :)
Oh wow yes! I had the same experience reading Massassi, hanging out on MSN Gaming Zone, and reading through .cog files. It was my first experience looking “under the covers” of a game and planted a seed in my mind to explore game development in the future (now doing that professionally). I was more involved in the “hacking” scene than the modding community proper; apologies if I made any of your matches an unexpected adventure.
For those who haven't seen it Jonathan Clark has been working on a open source version of the Jedi Knight: Dark Forces engine over at https://github.com/jdmclark/gorc and has even been active recently.
played and loved both of those games -- i really miss community made maps in FPS games.
Was anyone here at HN into Dark Forces II / Jedi Knight back in the day? The retro graphics of this post made me a bit nostalgic. The in-game scripting in Jedi Knight was my first exposure to software, and the modding community at Massassi was an incredibly creative and lively place.
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.
I think the easiest way to get started is mapping. This is a very cool map editor for Q1 and Q2:
There's plenty of good content here:
Map compiling and texture tools are included in the engine code:
The Quake community is awesome:
Thank you for this!!!
Even for all the hours I poured into the MP part of Q2/4 and Q3 I could just not get into the theme/mood/lore of those games. Q1 on the other hand... played the original and extensions back to back many times, and creatively tinkering with the editor to the limits of the engine, as well a hacking terrible things in QuakeC. Although more limited, QuakeC was so much more approachable than the later "real" C++ stuff, and incredible fun to tinker with!
Get started at making games? I feel like there might be easier paths out there these days other than relying on 20 year old engine.
I know this will probably get buried here, but like - I want to try this. I was a huge fan of Quake 1 and 2. How the hell do I get started? (Note: I'm not a programmer, I'm a marketer. I know just enough PHP/JS to be stupidly dangerous.)
If you dig software rendering:
Mandatory reading: Michael Abrash’s Black Book, available freely and legally online at https://github.com/jagregory/abrash-black-book
Thank you, that list is awesome!
Irrlicht still has 2 software renderers. A simpler one without clipping and a more complex one called burnings renderer.
Just a few days ago I was searching on how to implement a software renderer.
I remember enjoying the software rendered of quake much more than the opengl version.
Yes the code needs to be GPL, but that does not apply to the assets of course since the assets (including any scripts, although Q2 does not use scripts) are just "data".
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.
Interesting thing about the scripts being considered data. Sounds like it would be a very grey area, are there legal precedents here?
I'm not aware of any legal precedent (GPL isn't contested that often in courts), but this is mentioned in the GPL FAQ: https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
Yes. If you want a business model for a game with GPL licensed libraries, the best model seems to be to sell the binaries, give away the source (which would also be licensed GPL), and plead others to not distribute binaries. It might also be possible to lock down the artist's assets as long as you comply with the GPL for distribution.
According to the FAQ on gnu.org, it's fine to distribute non-free artwork with a GPLed game:
> Keep in mind that some programs, particularly video games, can have artwork/audio that is licensed separately from the underlying GPLed game.
> Since this engine is GPL-licensed it seems like any game built with this engine would then also need to be GPL-licensed, correct?
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.
It depends on how the game engine works. If your game code is directly linked with the engine in the same executable (or a shared library) it would fall under GPL. If the game engine provides a virtual machine that executes bytecode compiled from game scripts I don't believe that would count.
That's an argument, but I belive it wouldn't stand up in court.
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).
FWIW, the source to Quake's bytecode (progs.dat, written in QuakeC) is available under the GPL. I think, since the bytecode source was distributed separately from the engine source, you could get away without distributing later bytecode source as long as you start from scratch.
The key difference about the bytecode is that the sources are available under terms other than the GPL, but the SDK license they use does not permit commercial exploitation. I think you could distribute an open source Quake + open source progs.dat, but I don’t think you could really mix and match (distribute open-source Quake + your own closed-source progs.dat, as one product).
Could just release the game engine binary with a separate loader for assets and license check... Utilizing steam for distribution and in game features could help too.
You can't link a GPL engine against the Steam library (Steamworks SDK is proprietary) and then distribute binaries without violating the GPL.
It's also not assets that are the problem, it's the game-specific code.
You could separate the rendering logic from the game logic and create messaging channels for them... Also, the game specific code is rarely worth anything without the assets... that's why Id has released these codebases, so that people can learn/adapt... the assets retain copyright, etc. Also, you can separate out the game runtime from launcher parts... the launcher can contain other communication channels and be responsible for delivering assets.
As I said, it isn't even about creating a perfect abstraction, just enough to minimize the effect of piracy.
I think when engineers answer these questions it's easy to get bogged down in issues like whether something is a single process linked together or whether you have multiple processes communicating with one another. I don't think these arguments have serious legal merit.
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?"
In either case, the game isn't much use without assets... and those can be copyrighted separately from the executable.
That’s not really true, you can swap out the assets for your own. People do this. You just have to swap out all the assets.
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.
Wouldn’t a game engine have the same role as gcc? As a tool, unless you’re extending the source itself, you shouldn’t be infected by the engine’s license
Depends. In this case the engine is just a blob of code that you clone, and you modify it in order to make your game. You'd have to comply by the rules of the GPL.
GCC explicitly has exceptions in the license for code that it inserts into your program during compilation.
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.
Super cool. I always loved that mid-90s 3D look.
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?
From my perspective, that odd lighting and tint is part of the aesthetic that makes it great. You can learn more about how the renderer works here:
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 think I remember playing these maps! (or else confusing my shades of grey) I'll need to boot up that computer and see if they're on there.
I can't find the website I used to download maps and skins from. It must be gone by now.
I recall from somewhere that the team behind Carmack (Tom Hall, Romero, etc) chose the brown palette since it looked best within the theme, given the color constraints. I have no source, sadly.
Cool maps, btw. :)
This is great. I remember back to the late 90s when I was busy hacking gamex86.dll to customise my Quake2 Death-matches with my friends.
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
Factorio, a recent relatively popular indie game, was developed on Allegro.
They're moving off of it last I heard. Sounds like it's a legacy solution at this point.
Huh, I wonder what that'll mean for cross-platform compatibility. As they say in the post, Allegro supports a lot of platforms, whereas if they end up just targeting DirectX 11, that pretty much locks out everyone other than Windows and Xbox, doesn't it?
I believe they support Linux as a first-class citizen, even with removing Allegro! I've had VERY good luck with Factorio running through Steam, on Debian Linux (both 8 and 9). I have also ran it on Mac OSX and Windows 7 without any issue.
That game is so rock-solid as far as stability/system support that I would literally buy it again out of general principal =)
They're getting it working on OpenGL first. "We are using OpenGL 3.2 for now, but DirectX 11 support is definitely coming before we release it."
FYI, Factorio still runs just fine on OS X.
Those Megatouch coin operated games you can find at bars and such run Linux, and use Allegro. Not sure how recent they are, though.
Is allegro still maintained, I thought it was as of a few years ago. You can develop like its 1997, or 1987.
Anyone else remember Silent Death Online? https://www.youtube.com/watch?v=3BvgxDCbZxE
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.
The software renderer of Quake 2 has a very unique look that is hard to reproduce with shaders. Limitations are part of the fun. Games can use the existing Q2 palette, create their own, or use the palettes from Doom, Duke Nukem or Q1.
Considering this, I wonder why the choice of Quake 2 instead of Quake 1 since the main thing Quake 2 introduced has over Quake 1 was colored lighting but that was only available in the OpenGL version.
The MD2 model format is considerably extended over MDL, in size limits, vertex resolution, and features like texture animations. And while Q1 had the split between Netquake and Quakeworld networking, Q2 has a single system. Those kinds of refinements can make the difference.
I don't like QuakeC or the QuakeC VM.
Agreed... I'm a little surprised they wouldn't adapt to work/build to wasm+webgl target. It seems to me that could make a pretty good cross platform base.
Having no OpenGL makes an HTML5 port even easier.
Emscripten has an OpenGL 1.x implementation and Quake 2 uses pretty much OpenGL 1.1. Some years ago i ported my engine that has a GL1.x-only path to Emscripten and had an SDL backend (i removed it since then) and it took just a couple of hours to "port" (the two main problems i had were that i was doing some unaligned pointer accesses - casting a byte array to a float array to read vertex data - that Emscripten didn't knew how to handle so i wrote a slower path for Emscripten and that the OpenGL 1.x implementation wasn't that great and i had to write some workarounds).
How so? emscripten already supports WebGL
Wouldn't opengl be closer to webgl?
Emscripten has an SDL implementation so you can just SDL_BlitSurface inside a <canvas>.
What about the performance? Not that it's going to be huge on some modern hardware, but thinking a 4-5yo tablet or raspberry pi 2-3 level support.
Not that WebGL is all that much to write home about vs. native...
> Removal of OpenGL
Huh. I suppose CPUs are fast and all, but still seems odd to replace perfectly good OpenGL renderer with SW rendering.
And for those who'd prefer it were 1983 and we had the tooling then, that we have now, there is 8-bit Dude's engine, 8-bit unity:
.. which is also quite intriguing, for those of us with a bent towards the 8-bit aesthetic...
https://github.com/kduske/TrenchBroom is the new cool
Ooh, I fondly remember late '90s nights tinkering in QERadiant. These days I'd be able to tinker way harder than just editing levels.
With only two commits, which are several months old, this project doesn't look very healthy.
If you want something more general purpose that can load lots of different 3d formats including Quake 3 maps, take a look at Irrlicht.
People in their early 20's don't even know Half-Life (released at the end of 1998, over 20 years ago now), let alone Quake. We're definitely getting old!
Half-Life has been dormant (2007-2019) for longer than its release timeframe (1998-2007).
Blame Valve's lack of interest in maintaining their franchises for that one.
i lowkey kinda feel that the pervasive gamer hype about half-life 3 (for example the "hl3 confirmed" meme was extremely pervasive) made valve feel like it would be impossible to match the hype, and any flaw would be hyper focused. maybe now that it's faded a bit there won't be as much pressure. or i could be wrong about that mattering.
The book "The Final Hours of Portal 2" has a section where they explained how much pressure they felt to try and have Portal 2 live up to Portal 1. Even effectively shutting down development of of other games for 2 months so the whole company could focus on prototyping experiments for new gameplay concepts that could be incorporated into Portal 2.
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
Team Fortress 3 when
To be fair if I was in their shoes and had the cash cow that is Steam, I probably wouldn't care too much about maintaining franchises either. Games are expensive to build and profit isn't guaranteed; a distribution platform that is being used by everybody has much better economics.
PS2 and GameCube are retro at this point.
That's how I feel. I misread the title as "1987" and conjured up ideas of Zelda and Mega Man... and then I see Qauke 2 in the screenshot and I immediately thought "A modern game engine?"
I suppose it's not really all that modern, but still... wow I'm old.
Quake 2 was released closer to the Star Wars release date than the present day.
...those xkcd style "make you feel old" statements are quite fun to make.
Quake 2 is retro? Shit, I'm old.
Why not just use GODOT
* Use OpenGL 3.x or OpenGL 4.x
* 8 player offline LAN support
* Split screen coop
* 8 player coop online vs bots
WTF has this quake engine REMOVED OpenGL , thats not like 1997, that IS more like 2007
There's two other cool engines with a software renderer that support colored lighting:
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.
Even GZDoom (A Doom port) has software color lighting now, so I'm shocked this doesn't have it, that's all.
And engoo is very good; I was one of its beta testers!
PRs are welcome! :D
This needs true-color rendering with colored lighting at the very least. It's not fun when everything is grey/brown pixel smudge.