Dec 24, 2018
ARK: Survival Evolved - Jen
Raptor Claus and Studio Wildcard would like to wish you a very Happy Holidays this season!
Thank you for making us a part of your festive time this year!
Share: 
Winter Wonderland!
- Raptor Claus
- Flies over any map between 0am and 2am in-game (with event enabled)
- Drops Holiday Gifts
- Gacha Claus
- Spawns where you'd find Parasaurs on all maps
- Has holiday colors and wears a Santa Hat
- Cannot be tamed
- Doesn't like being near other wild dinos
- Accepts Coal
* Gives Holiday Items in return
* Drops Dino Candy
* Feed this to a tamed dino for a strange effect
- Accepts Mistletoe
* Gives Items in return
- Colorization
- 20% of wild dinos will spawn with Holiday colors
- Uses the ActiveEvent system
- ActiveEvent=WinterWonderland
- Cleans up after ActiveEvent is reset
- Auto applies to all non-TC sessions from 12/18-1/7 (UTC)
- Run with ActiveEvent=None to disable
Extinction
- Fix for King Titan environmental effects starting again after boss despawned
- Fix for other bosses interrupting King Titan environmental effects
- Cave entrance cooldown display bug fix
- Increased radius of city meteor shield
- Improvements to dome shaders
- Reduced meteor impact damage to 750
- Improvements to height fog in desert biome
Titans
- Increased Mek sword damage to tamed titans approximately 9x
- Increased Mek pistol damage to tamed titans approximately 3x
- Increased turret damage multipliers to tamed Titans
- Changes to Titan downloading
- Titan is disabled for 15m after download
- Titan takes increased damage during this time
- Increased Titan download cooldown to 6+ hours
- Fix typo in vertical Can't Damage message
Orbital Supply Drop
- Buffed Legendary Drops in difficulty and quality of loot
- Can now be claimed by a tribe in PVE
- Only that tribe can disable shield, eject items, gather loot
- Fixed bug that eventually only allowed 1 event at a time in a session
- Improvements to shield behavior on low FPS servers
- Improvements to attacker pathing and behavior
Element Vein
- Can now be claimed by a tribe in PvE
- Only that tribe can harvest element
- Fixed bug that eventually only allowed 1 event at a time in a session
- Improvements to attacker pathing and behavior
Desert Titan
- Increased damage when it strikes itself with lightning
- Improvements to Desert Titan follow to address flying away
- Fix for flocks not defending properly
- Improvements to tail attack accuracy
- Made tail attack damage consistent
- Disabled cryoing the flock
- Fixed encumbered movement when walking on a Desert Titan
Dropped Items
- Improvements to dropped item interpolation on low fps servers (less poking -through ground)
- Prevented dropped items from falling through structures on load
- Prevented dropped items from ghosting through structures if thrown close to them
Eggs
- Improvements to egg interpolation on low fps servers (less poking through ground)
- Prevented eggs from falling through structures on load
- Prevented eggs from ghosting through structures if thrown close to them
- Fix for invisible Rock Drake and Wyvern eggs
Velonasaur
- Increased accuracy of AOE attack
- Reduced AOE damage to compensate for increased accuracy
- Wild Velonasaurs will no longer shoot for too long
- Fix for Wild Velonasaurs not doing damage in PvE
- Improvements to desyncs between spines and damage
- Reduced hovering when walking
- AOE attack will no longer loot victims
Managarmr
- Fixed anim bug related to Ice Breath
- Fixes for several orientation desyncs
- Fixes for desyncs when moving on low fps server
- Minor buff to landing damage
- Improvements to ice breath targeting
- Added message when you are unable to dive
- Slowed down baby Managarmrs
Enforcer
- Fixed instances where Enforcer could teleport to a non-existant wall
- Fixed instances where it could jump back to its last jump position
Scout
- Improved Scout tagging accuracy
- Improvements to player inspection mechanic
- Scout will now show floating damage text when damaged
Item Balloon
- Fixed instances of it not going to the correct destination
- Fix for cases where balloons didn't explode after landing
- Improvements to weight calculation
Gacha
- Fix for unclamped loot quality
- Fix for incorrect UI when taming is interrupted
Ice Titan
- Fix for broken dino animations related to Ice Breath
- Increased collision radius for shoulder Corruption
Flyers
- Improved flyer following when in water
- Added Whistle Land Flyer command
- Commands a flyer to land nearby
Crash
Fix low frequency crash
Manticore
- Improvements to landing logic
Performance
- Improvements to server performance
Map Markers
- Add support for decimal values
Snow Owl
- Slowed down baby food consumption rate
Daedon
- Disable healing when frozen
A reminder for mod authors that the sponsored mod program will be opening up applications again on January 1st. If you would like to apply for sponsorship you will have five weeks after the application period starts, so make sure that your submissions are ready!
In the meantime, I have received a couple questions about the sponsorship applications that I would also like to address. While this is is not all encompassing of the process of selection, in regards to the application process itself I hope that this helps you ready your submissions with more confidence.
One thing that has been a common request is for feedback on why a given project isn't selected. While I would like to be able to give feedback on projects, it is extremely time consuming to prepare these, especially with the volume of applications I receive. I want everyone to understand though that not having your project selected does not necessarily mean that there is something wrong with it, there are simply limited slots available with each application period. So don't let it discourage you from applying in the future.
The other question I have received rather frequently is for what kind of information you should include in your applications and design documents. How you choose to organize your design documents is up to you, but here is a very general explanation of what I am looking for. First is that you have a plan for the duration of sponsorship; the more detailed this plan, the better. After looking at the design documents and learning about what you do with your project, I then look at the mods as they currently are available on the workshop and try to determine whether or not the content available shows a good probability of being able to deliver on that plan. I might also look at other projects in your workshop to help determine that information.
I look forward to seeing what everyone puts forward in January. Happy modding!
ARK, at its core, is successful because it offers the best and most diverse survival experience that it can to each player who plays it, and the many options that we provide allows that to happen. There are many, many players that play our game over multiple platforms and each of them has a different definition of what’s most important to them, what ARK does well, and what it should do better. Early on we made a decision to offer a vast array of options, modes, maps, servers, and mods to get as close as we could to being the best survival game for everyone. This creates a major challenge when it comes to development however, as each piece of content or change is used in a large number of different ways. The many play modes are likely to be at odds with each other and are competing for the same development resources, so we have to make a number of tough decisions and pick our priorities. This can result in mechanics that feel less than ideal for your setup or bugs that only appear in certain modes. I do believe it’s better than the primary alternative - not offering or supporting these options at all.
In this industry we need to develop and introduce new content and mechanics to keep our game interesting and relevant. When we set out to develop something with the size and scope of Extinction, we first sit down and figure out what new experiences we could bring to the table. We brainstorm far and wide, documenting and elaborating on ideas before scoring them. We try very hard to introduce features that either have broad reach and appeal across our play modes or add a high amount of depth to one. The things that resonate the most through this process are grouped together into creatures, items, or features that become the key features for the expansion. Generally when we do this we’re intentionally trying to shake up the meta to breathe new life into the game. Often times it’s hard to predict exactly how the new features will be used by players, and just how much they’ll shake things up.
On the other side of the coin, testing changes to a game like ARK is quite difficult. Stepping back, it’s really a numbers game. Let’s say, for example, that you have 10 QA testers, and they’re testing 50 hours a week, that’s 500 hours of testing per week. Next, let’s say that you have 3 months to fully test your changes. Multiply the 500 by 12, and you get 6,000 hours of serious, in-depth testing. That can seem like a lot, but it’s nothing compared to the amount of time that players put in. ARK averaged ~50k users for November on PC. If you multiply that by 30 days and 24 hours, you end up with a rough estimate of 36,000,000 hours of ARK played in November. That’s 6,000 times as many hours as in the example above. There were approximately 1,200,000 hours of ARK played in the first day of Extinction. There were 50,000 hours played in the first hour after release. 10 minutes after Extinction released, players had already played 10,000 hours of Extinction, eclipsing the amount of testing done by the 10 testers above. Suffice it to say that when you experience problems when playing a game just after release this is a big reason why.
Obviously we don’t like it when our game has problems, so we focus much of our testing on critical areas and we test them over and over again and prioritize the issues we find. As you can imagine, this is a lot easier in a single player game with a fixed path through a scripted storyline. Once you start multiplying out all of the options and variables, however, it quickly becomes a monumental challenge. As illustrated above, it’s impossible to test every experience that a player is going to have in a game like ARK within a reasonable timeframe. Our volume of players means that players will always have for more time playing ARK than us. When you combine this with the fact that most of those players are playing competitively you realize that many of them are looking for a way to get a leg up on their competition. Very quickly they’re using things in ways that you didn’t intend or even think about, and it’s up to strong systems and well placed testing to make sure that they stay in a healthy place. Sometimes you experience breakdowns in one or two of the above and you have to turn around a fix as fast as possible.
When we built the Titans, for example, we balanced them against dinos, items, each other, and bases. We wanted each of them to feel different and wanted them to have roles almost like classes in a class-based shooter. We wanted them to be somewhat slow and predictable, and ultimately squishy when faced with organized and concentrated fire. We felt very early on that they should be able to do a lot of damage to an endgame base, if left unchecked. Beyond countering this strength, we wanted to limit how fast people could tame and transfer in Titans, and make it a difficult decision to make - so we went for cooldowns on transfer and starvation. Of course, players discovered a way around starvation (kibble?!?!?!), so that broke a big piece of their cost completely. Last week we released a patch that brought this back closer to where we envisioned it, but it’s unlikely that it’s the end of balance changes to the Titans.
Meks were built to counter Titans. Generally, the math that we used when developing the Titans and Meks was that approximately three Meks should be able to make short work of a Titan, and we set out to arm the Meks with abilities (like the rocket pack) that would allow them to take the Titans on. In this regard, our primary focus was on the defensive capabilities of the Mek. Unfortunately, in our efforts to nail the defensive-side of things we overlooked a few issues that could occur on the offensive side; especially related to base raiding. The reality is that this was a mistake. Players discovered within the first few days that they could be used to dismantle bases by bypassing most of their automated defenses. Once something like this is discovered we need to act quickly - we ask ourselves if we feel like the mechanic is overpowered. Then we ask if it fits with the design of the creature. We ask what the counter is and talk through the best way to balance it. Ideally, we’d have all of these discussions and make all of these decisions early in development. When faced with the numbers game above, however, you realize how likely it is that a few of these slip through the cracks to the final game. We work diligently to to step up and resolve the issue the best way that we can, as fast as we can.
If I were to step back and put on an Idealistic hat, I’d want to reshape ARK such that none of these bugs ever made it through to our players. I’d want to test and retest every interaction, every spot in every map, every scenario that a player could find themselves in. The reality, however, is that it would take a very large team, a very large amount of time to develop something as broad as ARK and deliver it flawlessly. Large enough on both fronts, that the likelihood of success drops dramatically. And even then, that game would have bugs. Yes, ARK is not perfect. However, we enjoy working on a game that delivers a broad, good experience to many players over one that offers a narrow but perfect experience to only a few or takes ten years to make. We strive to minimize the number of problems. We pride ourselves on recognizing and resolving them as fast as possible. As we continue to work on Extinction issues, long standing issues, previous promises, and whatever is next for ARK (stay tuned!), we’ll continue to approach it from that perspective. Our job is to provide the best experience we can to the highest number of players we can reach, as fast as we can. Sometimes there will be bumps in the road, but they’re a necessary part of making the things we make at the scale that we make them. We think it’s worth it.
Patch notes for 285.104:
- Extinction Expansion Pack!
- Removed Bodybags exploit!
- Group ranking number increased by 5
Extinction does not have a large body of water. As you can imagine, the surface of the Earth has undergone some dramatic changes, one of which is that most of the water has dried up. That said, we did build the Extinction creatures with water in mind, and there should be a few surprises waiting for you when you take them to other maps!
We think that Cryopods coming in Extinction should help with this problem directly. When a creature has been captured into a Cryopod, it does not count against the tame cap of the server. In addition, Cryopods can be kept forever in a Cryofridge with power, arming players with a powerful tool to work around the limitations of the cap.
Our hope is that Titans bring a new type of PVE encounter to the game with in-world boss fights and interesting new mechanics that are interesting in themselves. Once tamed, Titans are very powerful. They can clear space and take down lots of dinos quickly making them good for area cleanup or meat runs. In addition, we’ve worked to make each of them fun to ride. I enjoy exploring the various maps on them for that reason.
The Defense Units found within Extinction are part of the automated force that served and defended the city before it fell into disarray. These days they like to roll around and punch Dodos. They aren’t craftable like the other Robots found within the city (such as the Scout or Enforcer), but we felt like they brought a missing piece to the ecosystem there, namely punching Dodos.
There are a number of creatures that make their return in Extinction, and they exist in biomes/environments that you’d expect to find them in. In addition, a number of existing creatures have been corrupted by Element and they roam the wasteland. These creatures will not behave as they would traditionally, instead destroying anything that gets in the way of their hunt for additional Element to consume.
- Extinction Chronicles V
- Added Tek Quetz
* New breeding line
* 5% chance to spawns
* 20% higher base level
- Added new color set (black, red, green, purple, white)
- Added 3 new Explorer Notes and matching unlock (Corrupted Gloves)
- Increased maximum player level by 1
- Climbing pick meshing fixes
- Better handling for low fps server dino attacking
- Fix for failure to cleanup structure placers
- Pre-emptive API for server structure cleanup improvement
- Increased damage range for players/dinos on surface of Aberration
Undermeshing refers to the ability to get to where you aren't supposed to by moving outside of the playable space. Almost every game is susceptible to undermeshing in some form. Most speed runs rely on undermeshing, for example. It's effectively impossible to solve completely, at least automatically. The approaches taken to prevent it are usually a tradeoff between how much freedom you want the player to have, how complex your world is, and how much processing time you can afford to spend on physics. Generally, when there's an instance of meshing, it's caused by bad collision setup, improper level geometry (holes), or a problem with the algorithm used to move the character through the world. In some instances, you place kill volumes in locations that you want to guarantee that the player doesn't end up, but that isn’t a global solution.
The collision setup for our objects varies based on their complexity. For very simple objects, we use a basic primitive shape (box, sphere, capsule) that matches the shape of the object. It's very good if you're able to take this approach, because natively the physics system can treat that individual object as water tight - ensuring that another physical object will never end up inside of it, and that you'll always detect it if you're already inside. When constructing a modern game, however, it's very likely that you need to use shapes that are more interesting to look at and interact with than a simple box or sphere - so you use mesh based collision. Mesh collision treats the surface of the mesh as the collideable surface, but it cannot be treated as watertight, and the physics system cannot guarantee that you don't pass through it. You might ask why, then, don't you try to represent that larger object as a bunch of smaller watertight ones? We do that in a small number of instances, but quantity of primitives is also a major concern, so it is not feasible to do this for the entire world. Take the ground under your feet, for example, at any given moment you'd be surrounded by thousands of primitives to approximate the surface of a natural looking ground, and yet it'd be less smooth than the pure mesh shape. In addition, a guarantee to not end up inside of a single body isn’t a guarantee that you won’t end up between them even if they’re tightly clumped, leading to more instances of getting stuck.
When we lay out our levels - we construct them in the way that is interesting and optimize them for efficiency so that we can maximize quality and quantity. What that means is generally the world outside of the space you're meant to play in is empty - we spend our resources on the spaces where players are at. In addition - we reuse assets many, many times - rotating a rock different ways to make it look different before shoving it into the terrain at various depths to mask the reuse and keep it visually pleasing. Technically, the physics for these objects overlaps, and if you get past the surface of one, you'll stand on the next one down. While that sounds like it would help, it’s actually the meat of the problem. Adding more meshes doesn’t help, because once you can get past one, you can get past the next one. That said, there have been many instances where we’ve flagged the collision on an object incorrectly, or left a minute hole that we can and do address through Level Design.
Nearly every game uses custom physics for characters. Much of ours is built on the out of the box simulation that you get from UE4. Fortunately for our players, our game is one where the world is vast and complex, and players have the freedom to build many objects and have many dinos. Unfortunately for us, this pushes all of these algorithms to their breaking point. We've had to augment, rework, and add additional tests in many places that affect the simulation to improve our core player experience. In addition, we've built many gameplay mechanics that don't exist out of the box. Wall climbing, for example, requires a completely new set of physics tests to understand and hug the wall surface. When we set these up, we build them to be as flexible as possible, but it can be difficult to predict how the player base will use something when they get it in their hands. In many cases, this is a good thing - we’re delighted with the creative things that our players do, but sometimes they’re able to abuse mechanics in unintended ways. When we find problems with them, we have to find solutions that won't break the mechanic completely for the many other use cases, sometimes an impossible feat! This is also why we aren’t quick to completely disable a feature - we evaluate how much harm versus good it is doing across the entire experience.
We do use kill volumes at a broad scale - usually high in the air, or far below the surface. Far outside of the playspace, to segment specific areas. The reality, though, is that when someone is meshing, they're usually not out in that empty space around the world, they're running around on the insides of overlapping shapes or physical surfaces that are just below the real surface. In order to implement kill boxes in these places, we'd have to go back to every location in the map and place a kill volume just below the surface that will kill someone that touches it. As with the terrain example above, it would require entirely too many objects to cover the entire world in these accurately. In addition, a major downside to this approach is also the fact that it will detect and kill something that may have a good reason to be below the mesh - on a Basilisk? You just got killed by the kill volumes. Misjudge where the surface is, and a bunch of players are being killed erroneously and losing their stuff.
As with all aspects of making a game, it's all a balancing act. We try to spend our time on the things that are most valuable to as many of our players as possible - which means attacking holes in the world in waves and making algorithm changes when it's become obvious that they're having a large enough negative effect on the experience for our players. The reality is that there is no silver bullet, no automatic solution - so it continues to be a problem that our game (and many others) continue to fight throughout their lifetimes. Recently, we’ve fixed a bunch of holes across all of the maps and did a pass at removing Climbing Pick exploits. Going forward, our best bet is to remain diligent about resolving issues as they arise and improving the experience over time. The good news is that we like solving hard problems - and exploits like these are some of the more interesting ones to try and tackle!
