In Case of Emergency, Release Raptor
Arcen Games, LLC Developer
Arcen Games, LLC Publisher
2016-08-29 Release
Game News Posts:
34
🎹🖱️Keyboard + Mouse
🕹️ Partial Controller Support
🕹️ Partial Controller Support
Mostly Positive
(86 reviews)
The Game includes VR Support
Public Linux Depots:
- Raptor Linux [2.26 G]
All right, let's get this over with: August 17th is the new release date.
I want to make sure there's enough content right at launch that people aren't skeptical of how this might develop during early access.
I want to make sure that we're completely positioned well so that I can spend my time adding content in an efficient manner -- DAILY during the week -- and not chasing bugs or whatever other issues that are less exciting to players.
I want this to be as smooth and bug-free an experience as possible, and so I haven't been just going "eh that's good enough" when something is even a little off. Those "little things" add up when someone is getting a new first impression.
We need to ensure coverage by "new media" to some extent, and that means twitch and youtube folks. These people are excited about the game in a lot of cases, but there isn't enough in there for them to be making hours-long videos showing off their cool antics. That's a problem for us, because without that sort of coverage it's too easy to fall into obscurity on launch.
[/olist]
So what has the holdup been, in a nutshell?
Lighting Getting lighting just right has been a real passion of mine. It ties everything together and makes everything feel cohesive and awesome. It's the most visually distinctive thing about the game in a lot of way, and it makes all the assets it touches look better. But it comes at a cost! Specifically a cost on the CPU/GPU. Most AAA games use "lightmap baking," which basically is a way of having some computers churn out some detailed precomputed data about a level that says what the light should look like at every point. This process is not remotely realtime: it can take tens of minutes on even a midsize level. So with procedurally-generated content, you can forget about that sort of thing. The "deferred shading" pipeline that we use in Raptor is a nice and modern approach that lets us do a lot of cool things with lights, but it doesn't work with traditional antialiasing (but we fortunately have an excellent temporal antialiasing solution in the form of CTAA). So there's a ton of stuff that we can do that the older "forward" pipeline can't do, and tons of games make use of this (though almost no VR games at the moment, because of the lack of temporal antialiasing in most engines at the moment). My main challenge was to find the sweet spot between brightness and spread of lights versus the performance cost that incurs. All lights in deferred shading are "pixel lights," which means that they are way higher fidelity and light based on the pixels they touch rather than the crude way of lighting based on the vertex (yuck). Aside: it lets us do other cool things like have very low-poly models that have excellent occlusion and normal maps and thus look far more complex than they actually are. It's another very modern way of pushing a lot of detail to your screen without bogging down your GPU on a bajillion vertices.
Anyway, the problem with lights in deferred shading is that there is a cost per pixel illuminated by them. So if you use lights that are too huge, then your performance tanks. Or if you use too many lights, your performance tanks. My goal is to have > 60 frames per second on any reasonably-modern GPU with most of the visual settings high up (I'm benchmarking things on a 980M if you're curious), and so finding the lowest light ranges I can while getting the visual effects I want has been a challenge. Not a technical one per se, but more of an artistic one. A lot of the way that lighting is handled here has heavily to do with the post-effects pipeline that we're using. We're rendering in HDR (high dynamic range) in the newer linear lighting pipeline (as opposed to the older gamma one), and so a lot of awesome lighting and depth information is available to us after the initial render of the camera. This then lets us do a lot of post-work to brighten and tone the scene in ways that you could not do if you were to try doing it in something like photoshop (because you'd be missing that extra key metadata about each pixel).
Anyway. The point is, it was important to me to really nail that. I wanted things to be well visible at all times even in the absence of lights (since you can destroy lights), but I wanted dramatic contrast. I wanted large-range-seeming lights with great quality, but without the performance costs of taking a naive approach to that problem. I wanted this to still look killer and shadowed even with shadows turned OFF (!?). Also relevant: I wanted to get all of those things figured out and done in a variety of physical spaces BEFORE we did too much level design, because lights play into level design and I didn't want us to have to go back and re-light everything later. That would cause a huge delay in content development further down the line, so it's better to spend the time upfront in this case. I am happy to report complete success on this. It took me longer than I had anticipated, but it's done, I'm happy with it, it performs great, and I'm sooo glad to be done with it. ;)
Furniture And Props We started out just doing our level design with floors and walls and doors and similar, which was a really fun challenge because we had to make each space interesting even without anything in it. Blue and Brandon and Craig and Misery did a great job on that. I feel like a lot of games lean on having a boringly-shaped space that is filled with interesting things, and the overall effect is something that is ultimately kind of blander than it should be, if that makes sense. It's hard to explain, but it's one thing that really bugs me in level design and gives a subconscious feeling of "something isn't right here." So to start out we stripped away all that, and that's become our standard way of making levels here now. No furniture or props, just designing the space itself. If the space isn't interesting without something in it, then it needs more work. Boy did we have a lot of success with this! I was super happy with how this was coming along. And while the level designers were working on the actual physical spaces, I could then focus on those pieces of furniture, props, and so forth that would then populate those spaces and bring them to the next level.
Well... that took longer than expected. If you want the whole hoary story, those release notes are probably the best place to do the reading. Suffice it to say that it is extremely mind-numbing and tedious work getting those ready, but also something that requires a lot of focus because small mistakes echo outward and then require later rework. So it gets exhausting. That took longer than expected on my first pass through, and I added a few hundred props and pieces of furniture. I need to get way more in there, but we're off to a good start for what we need right now. I had to make sure that everything was fitting in stylistically and had the quality it needed, and in many cases I had to adjust shaders and material properties to do that. In some cases I put in completely new textures, but in all cases I heavily optimized the textures. In some cases I adjusted geometry or optimized it. I made things have physical presence, be destructible in a lot of cases, and so on. I learned a lot going through that process the first three times, and I have a lot of more times of that in my future for this and other games. So one of the things I spent some time on was developing out a toolset to make it more automated to do frequent tasks, and to make it less mind-numbing for me. And to catch the inevitable errors that I make, and in some cases actually auto-fix them. It's vastly faster for me to add new content of that sort now than it was in the recent past, so that's extremely exciting. But it did come at some up-front costs of figuring out what the pain points were and then coding custom tools to work around those.
Aside: Toolchain Development In General I don't regret that time spent at all, but it has been a learning experience. With our 2D pipeline we had about 7 years' worth of things that we'd built out to make our lives easier. In our 3D pipeline I've had to invent a bunch of new tools for us since February. Some of our 2D-pipeline tools carried over, but a lot of them didn't. And a whole new set of tools has been needed in the 3D realm. But I really have no desire to ever go back to 2D pipeline at this point. I have a long personal history with 3D going back to 1998 (though arguably my personal history with 2D game work goes back to 1991, but still), and personally the only sort of art I'm good at is "technical art." I can do things like lighting, I can do certain forms of modeling, I have an eye for texture work, etc. But I can't draw for ****.
In the prospect of a scaled-down Arcen, the actual only path for me where I can do all of the work to a reasonable degree is 3D. And there are a LOT of things that I always wanted to do in 2D that I couldn't, but that are possible in 3D. For instance, procedurally-generated ships in AI War, let's say. In 3D? Absolutely. The underlying data and design we could always do, but it visually would not have looked good -- or performed well. But we can make use of static and dynamic batching in 3D, and do a variety of awesome things to have better visuals meet better performance (paradoxically). Keith and I have both been thinking about an AI War 2 at this point, but from very different perspectives. Whether and how the two of us come together to work on that, and how we divide the labor, remains to be seen. Most likely he would take simulation and AI, I'd take display and networking, and we'd divide interface and procedural generation. Probably. I haven't spoken to him at all about this in quite a while, so he might be reading this going "what the heck??" ;) He has a ton of ideas on how to make the AI and the simulation more efficient and more effective, though, and he has an all-new concept of the GUI in general. I have a lot of ideas on how to make the visuals both better AND more efficient, and a lot of new knowledge on how to make the GUI more efficient. I also have some fairly crazy ideas on the networking front that would make the computers less lock-stepped and make use of a wider variety of independent ports and so on. I think we also both have some nutty ideas relating to multithreading based on things we've learned in SBR and Raptor and so on. Wow that was a tangent. Anyway, back about Raptor...
Thoughts On Further Slippage So how do we know that this won't just keep slipping and sliding away into the future indefinitely forever? That is an excellent question, and to a large extent that's what happened with SBR and why that became such a money sink and caused so many rippling problems into the future of Arcen. So I'm certainly not blind to the possibility of that sort of thing. Here's the difference: SBR is complex and requires a lot of moving parts to even determine if it was fun, and we were building all those parts and not finding it as fun as we wanted at any point. We're getting closer on that now (well, Keith is), but there's a fundamental issue of "finding the fun" there. With Raptor, that's never been the problem: at a very basic level it has been freaking fun right from the start. But what has to be done is making it so that you have more than just a tiny bit of content, and that involves both more varied enemies and objectives, and more places to go. In some respects it is the opposite of the SBR problem, because the fun was there from the start but the content was not. We've had all the content for SBR for over a year now, but are still trying to find the fun. That's a strange thing, no?
Anyway. Where schedule slippage tends to happen is when there are a lot of future work items that need to happen that have an uncertain amount of time to them. If I estimate wrong on some or all of them, or I don't budget in enough extra time for whatever unseen things come up, then we get slippage. When there are a fewer number of things, and/or those things are very familiar activities that don't cause strange and new risk (aka, making more apartments to explore doesn't somehow cause the schedule to slip -- but adding a new game mechanic can, because it can introduce new bugs and so forth). Right now we're getting down to the point where there are a few things that are still uncertain enough that they might blow up on me, but there is a HUGE buffer time this time around. I'm not pushing back by a day or two this time (after doing that repeatedly). I'm pushing back by half a month. I mean business this time, schedule! And then beyond that there is a fair list of "nice to haves" that we can focus on in the extra time IF there is any. During that time we can have people testing, twitch and youtube people streaming it, and put out any fires that crop up. OR if the earlier stuff slips, then that time disappears but the release date hopefully doesn't slip. That's the plan, anyway.
The Current Project Plan So here's what's going down at the moment: [olist] I'm working on a few last things with doors, and then a few other bugs.
I have to finish the procedural assembly of levels sufficiently for it to use the new content.
Blue and others are working on finishing furnishing their existing level pieces.
I have more robots to get in place, including father brain.
The voice acting needs to be put in place for the robots, and more needs to be recorded for some of the new robots.
There are some secondary mechanics (fuse boxes, fire alarms) that I want to get in place, but it's not dire. Also elevators that... well, that's a surprise actually.
I want to get more testers in place starting sometime next week so that we can continue to find whatever bugs exist BEFORE we go into early access.
Oh, I need to make a new trailer and screenshots and all that jazz, and update the description stuff for the game.
[/olist]
That's all the stuff that HAS to happen. Beyond that we should hopefully be able to add more content of various sorts while press and streamers and youtubers are checking it out. The goal is for that to lead to a smooth launch that then transitions into folks new to Arcen being amazed at how fast we add new content.
Used to waiting weeks or months for major content updates? Heck, we do that sort of thing every 2-3 days most of the time.
But if things aren't tidy enough at launch, then we can't really do that at the same time we're putting out a bunch of unexpected fires. Let's put out any fires first. ;) Okay, that's enough rambling, but I figured you folks deserved a reasonably full explanation. I think that there was more I wanted to say, but I can't remember what it is. I guess one more thing. I've been incredibly stressed and that's a whole story in itself, but my son made me a little thing to keep with me today to make me less stressed. I just thought it was too cool not to share, sorry for being a geeky dad at this point.
It's the anti-worry tongue. He's six, so I have no idea why exactly it's a tongue. But he was drawing monsters and I think giving me the tongue of one was some sort of ward? I didn't get a chance to really fully ask, as he surprised me with it. I'm not sure if it's the a-w tongue or the new release date, but my stress is down a bit today compared to the last few days, at least. ;) Cheers! Chris Click here for the official forum thread on this post.
[ 2016-07-28 16:42:45 CET ] [ Original post ]
But I do come bearing gifts, at least. Hope you enjoy the screenshots! Additionally, if you want to see what insanity we've been up to lately, then the voluminous release notes might be interesting reading. They give some pretty good insight into what the delays have been.
Here's a TLDR of my four biggest concerns right now:
[olist]
Lighting Getting lighting just right has been a real passion of mine. It ties everything together and makes everything feel cohesive and awesome. It's the most visually distinctive thing about the game in a lot of way, and it makes all the assets it touches look better. But it comes at a cost! Specifically a cost on the CPU/GPU. Most AAA games use "lightmap baking," which basically is a way of having some computers churn out some detailed precomputed data about a level that says what the light should look like at every point. This process is not remotely realtime: it can take tens of minutes on even a midsize level. So with procedurally-generated content, you can forget about that sort of thing. The "deferred shading" pipeline that we use in Raptor is a nice and modern approach that lets us do a lot of cool things with lights, but it doesn't work with traditional antialiasing (but we fortunately have an excellent temporal antialiasing solution in the form of CTAA). So there's a ton of stuff that we can do that the older "forward" pipeline can't do, and tons of games make use of this (though almost no VR games at the moment, because of the lack of temporal antialiasing in most engines at the moment). My main challenge was to find the sweet spot between brightness and spread of lights versus the performance cost that incurs. All lights in deferred shading are "pixel lights," which means that they are way higher fidelity and light based on the pixels they touch rather than the crude way of lighting based on the vertex (yuck). Aside: it lets us do other cool things like have very low-poly models that have excellent occlusion and normal maps and thus look far more complex than they actually are. It's another very modern way of pushing a lot of detail to your screen without bogging down your GPU on a bajillion vertices.
Anyway, the problem with lights in deferred shading is that there is a cost per pixel illuminated by them. So if you use lights that are too huge, then your performance tanks. Or if you use too many lights, your performance tanks. My goal is to have > 60 frames per second on any reasonably-modern GPU with most of the visual settings high up (I'm benchmarking things on a 980M if you're curious), and so finding the lowest light ranges I can while getting the visual effects I want has been a challenge. Not a technical one per se, but more of an artistic one. A lot of the way that lighting is handled here has heavily to do with the post-effects pipeline that we're using. We're rendering in HDR (high dynamic range) in the newer linear lighting pipeline (as opposed to the older gamma one), and so a lot of awesome lighting and depth information is available to us after the initial render of the camera. This then lets us do a lot of post-work to brighten and tone the scene in ways that you could not do if you were to try doing it in something like photoshop (because you'd be missing that extra key metadata about each pixel).
Anyway. The point is, it was important to me to really nail that. I wanted things to be well visible at all times even in the absence of lights (since you can destroy lights), but I wanted dramatic contrast. I wanted large-range-seeming lights with great quality, but without the performance costs of taking a naive approach to that problem. I wanted this to still look killer and shadowed even with shadows turned OFF (!?). Also relevant: I wanted to get all of those things figured out and done in a variety of physical spaces BEFORE we did too much level design, because lights play into level design and I didn't want us to have to go back and re-light everything later. That would cause a huge delay in content development further down the line, so it's better to spend the time upfront in this case. I am happy to report complete success on this. It took me longer than I had anticipated, but it's done, I'm happy with it, it performs great, and I'm sooo glad to be done with it. ;)
Furniture And Props We started out just doing our level design with floors and walls and doors and similar, which was a really fun challenge because we had to make each space interesting even without anything in it. Blue and Brandon and Craig and Misery did a great job on that. I feel like a lot of games lean on having a boringly-shaped space that is filled with interesting things, and the overall effect is something that is ultimately kind of blander than it should be, if that makes sense. It's hard to explain, but it's one thing that really bugs me in level design and gives a subconscious feeling of "something isn't right here." So to start out we stripped away all that, and that's become our standard way of making levels here now. No furniture or props, just designing the space itself. If the space isn't interesting without something in it, then it needs more work. Boy did we have a lot of success with this! I was super happy with how this was coming along. And while the level designers were working on the actual physical spaces, I could then focus on those pieces of furniture, props, and so forth that would then populate those spaces and bring them to the next level.
Well... that took longer than expected. If you want the whole hoary story, those release notes are probably the best place to do the reading. Suffice it to say that it is extremely mind-numbing and tedious work getting those ready, but also something that requires a lot of focus because small mistakes echo outward and then require later rework. So it gets exhausting. That took longer than expected on my first pass through, and I added a few hundred props and pieces of furniture. I need to get way more in there, but we're off to a good start for what we need right now. I had to make sure that everything was fitting in stylistically and had the quality it needed, and in many cases I had to adjust shaders and material properties to do that. In some cases I put in completely new textures, but in all cases I heavily optimized the textures. In some cases I adjusted geometry or optimized it. I made things have physical presence, be destructible in a lot of cases, and so on. I learned a lot going through that process the first three times, and I have a lot of more times of that in my future for this and other games. So one of the things I spent some time on was developing out a toolset to make it more automated to do frequent tasks, and to make it less mind-numbing for me. And to catch the inevitable errors that I make, and in some cases actually auto-fix them. It's vastly faster for me to add new content of that sort now than it was in the recent past, so that's extremely exciting. But it did come at some up-front costs of figuring out what the pain points were and then coding custom tools to work around those.
Aside: Toolchain Development In General I don't regret that time spent at all, but it has been a learning experience. With our 2D pipeline we had about 7 years' worth of things that we'd built out to make our lives easier. In our 3D pipeline I've had to invent a bunch of new tools for us since February. Some of our 2D-pipeline tools carried over, but a lot of them didn't. And a whole new set of tools has been needed in the 3D realm. But I really have no desire to ever go back to 2D pipeline at this point. I have a long personal history with 3D going back to 1998 (though arguably my personal history with 2D game work goes back to 1991, but still), and personally the only sort of art I'm good at is "technical art." I can do things like lighting, I can do certain forms of modeling, I have an eye for texture work, etc. But I can't draw for ****.
In the prospect of a scaled-down Arcen, the actual only path for me where I can do all of the work to a reasonable degree is 3D. And there are a LOT of things that I always wanted to do in 2D that I couldn't, but that are possible in 3D. For instance, procedurally-generated ships in AI War, let's say. In 3D? Absolutely. The underlying data and design we could always do, but it visually would not have looked good -- or performed well. But we can make use of static and dynamic batching in 3D, and do a variety of awesome things to have better visuals meet better performance (paradoxically). Keith and I have both been thinking about an AI War 2 at this point, but from very different perspectives. Whether and how the two of us come together to work on that, and how we divide the labor, remains to be seen. Most likely he would take simulation and AI, I'd take display and networking, and we'd divide interface and procedural generation. Probably. I haven't spoken to him at all about this in quite a while, so he might be reading this going "what the heck??" ;) He has a ton of ideas on how to make the AI and the simulation more efficient and more effective, though, and he has an all-new concept of the GUI in general. I have a lot of ideas on how to make the visuals both better AND more efficient, and a lot of new knowledge on how to make the GUI more efficient. I also have some fairly crazy ideas on the networking front that would make the computers less lock-stepped and make use of a wider variety of independent ports and so on. I think we also both have some nutty ideas relating to multithreading based on things we've learned in SBR and Raptor and so on. Wow that was a tangent. Anyway, back about Raptor...
Thoughts On Further Slippage So how do we know that this won't just keep slipping and sliding away into the future indefinitely forever? That is an excellent question, and to a large extent that's what happened with SBR and why that became such a money sink and caused so many rippling problems into the future of Arcen. So I'm certainly not blind to the possibility of that sort of thing. Here's the difference: SBR is complex and requires a lot of moving parts to even determine if it was fun, and we were building all those parts and not finding it as fun as we wanted at any point. We're getting closer on that now (well, Keith is), but there's a fundamental issue of "finding the fun" there. With Raptor, that's never been the problem: at a very basic level it has been freaking fun right from the start. But what has to be done is making it so that you have more than just a tiny bit of content, and that involves both more varied enemies and objectives, and more places to go. In some respects it is the opposite of the SBR problem, because the fun was there from the start but the content was not. We've had all the content for SBR for over a year now, but are still trying to find the fun. That's a strange thing, no?
Anyway. Where schedule slippage tends to happen is when there are a lot of future work items that need to happen that have an uncertain amount of time to them. If I estimate wrong on some or all of them, or I don't budget in enough extra time for whatever unseen things come up, then we get slippage. When there are a fewer number of things, and/or those things are very familiar activities that don't cause strange and new risk (aka, making more apartments to explore doesn't somehow cause the schedule to slip -- but adding a new game mechanic can, because it can introduce new bugs and so forth). Right now we're getting down to the point where there are a few things that are still uncertain enough that they might blow up on me, but there is a HUGE buffer time this time around. I'm not pushing back by a day or two this time (after doing that repeatedly). I'm pushing back by half a month. I mean business this time, schedule! And then beyond that there is a fair list of "nice to haves" that we can focus on in the extra time IF there is any. During that time we can have people testing, twitch and youtube people streaming it, and put out any fires that crop up. OR if the earlier stuff slips, then that time disappears but the release date hopefully doesn't slip. That's the plan, anyway.
The Current Project Plan So here's what's going down at the moment: [olist]
But if things aren't tidy enough at launch, then we can't really do that at the same time we're putting out a bunch of unexpected fires. Let's put out any fires first. ;) Okay, that's enough rambling, but I figured you folks deserved a reasonably full explanation. I think that there was more I wanted to say, but I can't remember what it is. I guess one more thing. I've been incredibly stressed and that's a whole story in itself, but my son made me a little thing to keep with me today to make me less stressed. I just thought it was too cool not to share, sorry for being a geeky dad at this point.
It's the anti-worry tongue. He's six, so I have no idea why exactly it's a tongue. But he was drawing monsters and I think giving me the tongue of one was some sort of ward? I didn't get a chance to really fully ask, as he surprised me with it. I'm not sure if it's the a-w tongue or the new release date, but my stress is down a bit today compared to the last few days, at least. ;) Cheers! Chris Click here for the official forum thread on this post.
[ 2016-07-28 16:42:45 CET ] [ Original post ]
- Be a velociraptor.
- Feel like a velociraptor -- this is our central design goal.
- Procedural levels: a pleasing blend of hand-crafted locales and randomization.
- Fight robots! Tear giant ones limb from limb, pounce on small ones, and try not to die.
Sell Me The Idea In One Sentence
If I have to convince you why being any form of dromaeosaurid is freaking awesome, then I'm not sure we can be friends.
This game is carefully crafted to give you the closest possible feeling of being one of these glorious monsters -- then turning you loose to do fun stuff. That means you don't get (or need) "frickin lasers," health upgrades, or character progression.
That said, as we know from historical documents, it's hard to be a raptor in a futuristic dystopia. Robots have guns, and you don't. Despite the fact that you're an incredible hunting machine, you've got your work cut out for you if you want to master the game.
What’s The Point?
- 1. For the pure fun of the thing. In 1993, a certain game let you be a raptor. The controls were iffy. The levels were short and static. It's very dated. Yet many of us still dust it off periodically -- just to be a raptor. Release Raptor gives you a far more satisfying, modern, dynamic experience.
- 2. For the challenge. Brutal Mode approximates what a real theropod might experience when attacked by robots. Aka, if you get shot by a rocket that's the end. You'll need to use all your raptor skills to tear your foes to shreds.
- 3. To play with kids. I want to be able to play this with my 5 year old son, but still have dismemberment (because that's cool). How to do that without blood or gore? Robots! Little robots = pouncing targets; giant mechs = dismemberment targets.
- 4. For a power trip. Brutal Mode is only fun for some. So we have Power Trip Mode, where you're on an invincible rampage. It's not about IF you can do it, but how WELL you do it. Speedrunning is encouraged. Your performance is scored and rated (avoiding hits, etc), so mistakes still have consequences.
- 5. For daily runs — maybe. My hope is to build out some daily leaderboards for both play modes, but no promises on that yet.
- 6. For the strategy of it — probably. The idea is to make these branching mazes kind of like AI War: Fleet Command maps in terms of how they provide you with opportunities. Each opportunity may increase the heat you take while moving forward, but at the same time net you some good things (thematic secondary goals like blowing up part of the facility, etc). I think I have figured out how to avoid excessive backtracking or frustration with this, but I don't want to state that as a definite feature until I have it prototyped in.
NB: Yes, we know that’s not a velociraptor (and there should be feathers).
MINIMAL SETUP
- OS: Ubuntu 10.10 or later. although other unsupported distros may work
- Processor: Dual Core 64bit CPU (2.2+ GHz Dual Core CPU or better)Memory: 4 GB RAM
- Memory: 4 GB RAM
- Graphics: GeForce 8xxx+. Radeon X2400+. or Intel G45+
- Storage: 5 GB available spaceAdditional Notes: Important: final specs may substantially differ. but this is our best guess for now.
- Processor: Any Quad Core or 3.0+ GHz Dual Core CPUMemory: 5 GB RAM
- Memory: 5 GB RAM
- Graphics: NVIDIA GTX 660 2GB / AMD HD 7870 2GBAdditional Notes: Important: final specs may substantially differ. but this is our best guess for now.
GAMEBILLET
[ 6245 ]
GAMERSGATE
[ 2274 ]
MacGamestore
[ 1878 ]
FANATICAL BUNDLES
Time left:
356317 days, 10 hours, 9 minutes
Time left:
2 days, 17 hours, 9 minutes
Time left:
17 days, 17 hours, 9 minutes
Time left:
18 days, 17 hours, 9 minutes
Time left:
17 days, 17 hours, 9 minutes
Time left:
18 days, 17 hours, 9 minutes
Time left:
2 days, 17 hours, 9 minutes
Time left:
24 days, 17 hours, 9 minutes
Time left:
15 days, 17 hours, 9 minutes
Time left:
17 days, 17 hours, 9 minutes
Time left:
10 days, 17 hours, 9 minutes
Time left:
16 days, 17 hours, 9 minutes
Time left:
356317 days, 10 hours, 9 minutes
Time left:
24 days, 17 hours, 9 minutes
Time left:
30 days, 17 hours, 9 minutes
Time left:
52 days, 17 hours, 9 minutes
HUMBLE BUNDLES
Time left:
10 days, 11 hours, 9 minutes
Time left:
12 days, 11 hours, 9 minutes
Time left:
22 days, 11 hours, 9 minutes
by buying games/dlcs from affiliate links you are supporting tuxDB
