This week at Bungie, we’re consuming stacks of Light.

Within Destiny 2, the exodus of Io, Titan, Mercury, and Mars continues. Zavala has tasked you with spreading word of impending Darkness and keeping our beloved vendors up to speed. There are still a few more loose ends to tie up on these destinations, so get to it.

Along your quest, you’ll have some final chances to earn unique loot and fill out your collections before access to various strikes is impeded by the Darkness.

While the Traveler may have chosen you, it’s almost time to go beyond the Light. Don’t forget where you came from, though, as we’re celebrating Destiny’s almost-seventh birthday this week! Yeah, we know, it’s been six years. But seven is darker.

Whether you’re a veteran of Destiny or have just been rez’d in the Cosmodrome, thank you for playing, and thank you for being a part of our community.

Suit up

To quote the article, here’s what you can expect on November 10:

This armor can be earned by completing activities or through vendor rank-ups. Weekly challenges are also being updated to offer avenues for players to earn higher-stat packages for these armor sets.

Additionally, Year 4 will see the return of pursuit weapons. For those of you who may have joined our community in the last Season or two, these weapons have static perks, but allow for some customization. The final two perk columns have multiple perks to choose from, so you can tailor your weapon to your desired playstyle. Our eagle-eyed Guardians may recognize this beauty from a recent Stasis trailer….

Our goal is to have a pursuit weapon available per Season, earned through a focused quest. Banshee will give you a choice between Strikes, Crucible, or Gambit to earn the base model. Make sure you take a moment to think about how you want to earn the weapon, as you’ll be locked in to specific objectives for whichever activity you pick.

Once you finish the main quest, Commander Zavala, Lord Shaxx, and the Drifter will offer you an additional quest which will reward you with weapon ornaments to the theme of their respective activities. If you’re omnivorous and enjoy all three offerings, all three will be available to you.

So, now that we’ve caught your eye with some fancy armor and a new sniper, let’s take a quick look at how things are changing for core activities as you launch into your new adventures on November 10. Strike, Gambit, and Crucible playlists are being streamlined.

Crucible

Starting in Season 12, the Director will be updated to reduce the number of playlists available at a given time.

Strikes

Gambit

As covered last week, Gambit and Gambit Prime will be consolidated into a single mode. We have some additional details on specific rule changes, as well as development notes from the team on how things are changing, and the goals behind them.

Hi Gambiteers! We wanted to give you an explanations of rules changes coming to Gambit in November, as well as a key update from last week.

First, some goals we wrote down before we started:

• Build a more approachable Gambit Prime, keeping the one-round format with a longer round, but without the Gambit Prime armor perks.
• Rebalance the motes phase to last 2/3 of each match, rather than half of the match.
• Speed up the Primeval fight (compared to Gambit Prime) to give more of the feeling of a ‘boss rush.’

We started with the Gambit Prime encounters, full stop. However, without the Reaper buffs, the Large bosses that come in enemy waves were too tanky – so we pulled them all down to miniboss or elite. The pacing should feel like how Gambit feels for a pickup group, or how Prime feels for a fully kitted team.

We also playtested the “having the motes” phase target a score of 150, and/or have a heavier mote drain, but this allowed organized teams to steamroll even more effectively – not less. So, we pulled back to the current Gambit Prime mote target and drain.

We started with the Gambit Prime Blockers, but pulled the Taken Captain from the Blocker lineup, as he proved a little too potent for a 10-mote Blocker. We replaced him with the Phalanx, who can be tough to kill, but not as lethal. Since we don’t have the armor perks, we also had to remove the 20-mote Giant Blocker.

We kept the invasions during mote phases at three – just like Gambit Prime – but pulled back the minimum time between invasions during mote phases from 10 seconds to 20 seconds. It never feels good to get invaded back-to-back.

For the boss fight, we started with the Gambit Primeval fight, removed the timed Slayer buffs, increased the Primeval health and potency of the slayer buff given by when killing envoys. We respawn the envoys every 40% damage done to the Primeval – so if you get invaded and the Primeval is healed a lot, you have the opportunity to get more Slayer buffs and catch up. The fight length ends up somewhere in between the original Gambit and Gambit Prime, so we adjusted the invasion timer during the Primeval phase to match – right in between Gambit and Gambit Prime timing.

So, overall this mode will be a little quicker than Gambit Prime – mostly due to shortening of the boss phase and the removal of the larger bosses from the fronts, but one that still gives that great Gambit feeling that you all love.

We see you’re hungry for info, and we’re excited to bring the heat. As we approach Beyond Light, we’ll have more details on how your weekly rituals are changing. Economy, Eververse, Sandbox, and more. We’re looking forward to talking about things like solo queue Iron Banner, but we have a few things left to tie up as we approach launch.

Stay tuned…

Triumph Trackers

Last week, we announced some changes coming to Triumphs in November. Various Triumphs and Seals will soon become unavailable, leaving you to figure out which things to prioritize before the end of the Season. Partnering with some community API creators, there are now multiple options for you to create a checklist of sorts. Here’s a quick list in no particular order. They’re all amazing, and we hope you find one that suits you best!

Many thanks to these creators, and we’re excited to see how their portals and communities grow as we begin another year of Destiny content.

The noble quest to vanquish all bugs

Destiny 2 Update 2.9.2 shipped this Tuesday, and the Player Support team has been prowling the #Help forum in search of fresh bugs to smash. Thankfully, it doesn’t look like there are any major issues cropping up!

This is their report.

COMPANION APP

Early last week, Bungie.net and the Destiny API underwent maintenance. As a result of that maintenance, item transfer performance using the Companion App or third-party apps became roughly 10x faster for most players. The Companion app can be used by all Destiny 2 players on any platform, console or PC.

CONTACT FORMS

Last week, we were investigating an issue with our Contact Forms on Bungie.net. This issue has now been resolved, and players can now use the various contact form to submit help requests on help.bungie.net.

RESOLVED ISSUES

Below is a list of issues that have been resolved with Update 2.9.2 on September 8. The full patch notes for Update 2.9.2 can be viewed here.

• Players will no longer freeze when respawning in Gambit.
• Enemies will no longer stop spawning in Hexahedron area in the Prophecy Dungeon, blocking players from progressing.
• Players who completed Tommy’s Matchbook catalyst pursuit will no longer be re-awarded it.
• Redrix’s Broadsword will now be available to reclaim from Collections.
• Players will no longer block quest progress by acquiring Calcified Light without the quest active.

CURRENT KNOWN ISSUES

While we continue investigating various known issues, here is a list of the latest issues that were reported to us in our #Help Forum:

• Player badge counts will sometimes not update when the Season of Arrivals Collections badge is completed.
• The Tribute Hall’s Completionist triumph doesn’t count Season Collections badges.
• Players need to complete the Exodus: Preparation quest before they can begin the Exodus: Evacuation quest for Traveler’s Chosen.
• The Artifact is sometimes enabled in Iron Banner.
• Bounties/progress is sometimes not counted in Iron Banner.

For a full list of emergent issues in Destiny 2, players can review our Known Issues article. Players who observe other issues should report them to our #Help forum.

Stacks on Stacks on Stacks on Stacks

Have you consumed your daily dose of Light, yet? No? Well, go grab your Traveler’s Chosen and have a stack! I heard it goes well with popcorn, a soda, and a relaxing MOTW.

Movie of the Week: Legends Never Die

Honorable Mention: Thread the Needle

Honorable Mention: Wait, that’s illegal!

It’s weird to think, six years ago I was sitting in my friend’s garage, wrapped in a blanket, playing through Destiny for the first time after calling out “sick” from work. I think my initial character was a Hunter. The cloaks were cool, and the Golden Gun shown in the trailers caught my eye. I had no clue what Rampage was, why Suros was considered good, or why anyone would care about an Exotic Rocket Launcher.

Fast forward to now, we have a massive community with multiple expansions, Exotics, weapons, subclasses, and more under our belts. You’ve fought back the Darkness, lost your Light, met a Wizard that came from the Moon, and more. And now – in only a few months – after looking at beautiful concept art since 2014, we’ll finally sink our boots in the snows of Europa. We’ll also be embracing Darkness abilities for the first time.

I know I’ve said “we’re just getting started” a few times since starting on the Community team… but every release gives us a chance to set off on a new path. Fresh experiences with a sense of wonder, challenges that push you and grow your skill, and opportunities to make new friends along the way. Thanks for joining us on this wild ride.

Now, it’s time for me to hop into Iron Banner as I hunt for a few different rolls on my weaponry. I’ve heard whispers from our Sandbox folk on upcoming changes to 110 Hand Cannons. Might be fun to snag a few random rolls to try out when Beyond Light ships. That conversation is for another time, though. How about next month? We’ll see if this little tease makes it through editorial. If it does, I bet you 200,000 Glimmer that someone makes a five-minute YouTube video about it.

Happy hunting.

Cheers,

-dmg04

This update comes packed with a lot of quality of life changes for map makers and server owners.  Are you ready to take on the Piglin Brutes?  I’m looking forward to seeing how the loot has been adjusted in the Remnats.

Two new accessibility settings have been added to help with visual comfort.

• Distortion effects such as nausea and the Nether portal overlay can now be reduced
• At lower values, the nausea effect is replaced with a green overlay as an alternative visualization
• Field of view effects, shown after speed modifiers are applied, can now be reduced

CHAT DELAY

• Chat delay has been added to the Chat Settings screen
• Pressing F3+D now clears the pending chat messages

• Tweaked the Bastion Remnant chest loot
• Chests in Bastion Remnants are now more likely to be positioned on top of gilded blackstone

• Brewing stands can now be crafted with blackstone
• Lanterns and Soul Lanterns can now be waterlogged
• Crimson and warped fungus can now be placed on mycelium
• Chains can now be placed in all orientations

ITEMS

• Tools are now sorted based on material in the creative inventory
• Totems of undying now give the fire resistance status effect for 40 seconds when activated

• Endermen will no longer place their held block onto bedrock blocks
• Zoglins can now be leashed
• When a Zombified Piglin is spawned riding a Strider, it will now be holding a Warped Fungus on a Stick
• Removed Herobrine

• Added Piglin Brutes!
• Piglins now become angry with players who open or destroy a Chest Minecart
• Tweaked bartering loot

PIGLIN BRUTE

• Piglin Brutes are stronger versions of Piglins that live in bastions and protect the treasures there
• Unlike the their cowardly and greedy counterparts, the Piglin Brutes cannot be distracted by gold and aren’t afraid of anything
• Piglin Brutes attack players on sight, no matter how they are dressed
• Piglin Brutes wield axes and don’t need any armor, because they’re just that tough

RESPAWN BLOCK POSITIONS

• Modified how respawn positions are chosen for beds and respawn anchors
• Respawn anchors will prioritize cardinal directions over corners
• Beds will prioritize the side of the bed the player entered from and then spaces circling around the foot of the bed up to the head of the bed
• Respawning players will now face the block that they respawned at
• Placing players onto dangerous blocks is now avoided when possible

VILLAGERS

• Villagers now emit green particles when joining a village, setting a home bed, or acquiring a job site / profession
• Villagers now lose their job sites when changing dimension

• Custom worlds now support custom biomes
• Sign edit screen will now intialize from existing sign text (should have no noticeable impact on vanilla)
• Small improvements to data and resource pack selection screens
• Tags can now have optional entries

EXECUTE

• execute in now respects dimension scaling

SPAWNPOINT & SETWORLDSPAWN

Added an angle parameter for setting the default facing angle of a respawning player
Syntax: spawnpoint [<targets>] [<pos>] [<angle>]
Syntax: setworldspawn [<pos>] [<angle>]
New parameters:

• angle – Floating point angle in degrees. Supports the relative ~ modifier

• Custom world generation and dimension settings now use the same folder pattern in data packs as other resources (namespace/<type>/resource.json)
• There is now experimental support for a worldgen folder in data packs
• worldgen/biome can contain biome definitions
• worldgen/configured_carver can contain definitions for world carver settings
• worldgen/configured_feature can contain definitions for feature placements
• worldgen/configured_structure_feature can contain definitions for structure placements
• worldgen/configured_surface_builder can contain definitions for surfaces
• worldgen/noise_settings can now contain noise configurations
• worldgen/processor_list can contain sets of block processors
• worldgen/template_pool can contain pool definitions for jigsaw structures
• Custom biomes can now be used in the single biome/caves/floating islands world types (add the data pack containing the biome first)
• Custom biomes can now be used in custom dimension generators

DEDICATED SERVER PACKET LIMIT

• Dedicated servers can now kick clients that consistently send too many packets within a second
• Controlled with the rate-limit settings in server.properties
• The default rate limit of 0 means “no limit”

PACK SELECTION SCREENS

• While screen is open, it will automatically update when pack directory contents change
• Both pack selection screen will now display contents of pack.png as pack icon

PACK VERSION

• Resource pack version raised to 6

TAGS

OPTIONAL ENTRIES

Entries in tags can now be marked as optional. Failure to resolve optional entries does not prevent the whole tag from loading.
Example:

{
  “replace”: false,
  “values”: [
    “#minecraft:beds”, // existing syntax
    { “id”:”#missing:tag”, “required”: false }, // optional sub-tag entry
    “minecraft:anvil”, // existing syntax
    { “id”:”minecraft:stone_button”, “required”: true }, // new syntax for required tags
    { “id”:”missing:block”, “required”: false } // optional single-element entry
  ]
}

A total of more than 150 bugs have also been fixed in this release!

Jan Klose (director) and Thorsten Lange (technical director) worked on German studio Deck13 Interactive’s Lords of the Fallen, which launched worldwide October 2014 on PS4, Xbox One, and PC.

More than three years ago, the publisher CI Games gave us the incredible opportunity to create a new Action RPG. After Venetica, Lords of the Fallen was the second game of that genre that Deck13 was about to develop. Little did we know that we would end up on the then-nonexistent “next generation” hardware, work together with people from all over the world and win new fans from the most foreign of countries. We are unbelievably grateful but it has been a rather rough ride. We hope this postmortem help others not to fall into the same traps.

1. Finding the core game loop early

Creating the first concepts for a brand new IP is both challenging and thrilling at the same time. At the beginning of the production, we already had a concept in place that was not too far away from Venetica, our first RPG. In open talks with the publisher CI Games about what was possible, time- and budget-wise (and what wasn’t), we soon decided that we better not try to do too much at once, but rather focus on one core gameplay element and build the game around it. During conception, this proved rather tricky for a game in the RPG genre, because people generally expect a host of features that turn their game into an alternative world, a world in which everything is possible.

Our debut RPG project Venetica already featured tactical close combat, but all in all, Venetica was more focused on story and a unique atmosphere. The combat, while being a good start and a valid source of inspiration, was not really the game’s focus. But it was an element that had been much fun to develop, and we wanted to build up on that. So should tactical combat be the foundation of Lords of the Fallen?

Luckily we shared a vision with producer Tomasz Gop: our passion for Demon’s Souls. Above all, this game taught us one thing: You can build a game around a hard and challenging combat system and, at least after people embraced Demon’s Souls, you wouldn’t need to boil the project down to some convenient cutscene-packed game that would almost play itself. After Demon’s Souls, you were able advertise your game as hard and challenging again, a thing almost all people at Deck13 had grown up with and missed in many games that had recently been released.

So we agreed with Tomasz that the tactical action combat should become the one core element of the game, that we would start with it and build everything else around it. Even the story, a component that we at Deck13 are kind of known for, was not supposed to play the major role, however we still planned to make it strong and compelling too (a thing that we should only partially succeed with).

Our experience with a similar combat system and our love for Demon’s Souls resulted in a very clear game mechanic that we kept until the end, even though some people later said it really played quite a lot like Demon’s Souls successor, Dark Souls. Some even called us a Dark Souls clone. While this certainly felt a bit unfair, the good thing about it was that people were desperately waiting for Dark Souls to appear on the new generation of consoles, but it didn’t, so we were able to fill that gap (and certainly many players did consider our game to be quite different to Dark Souls when they actually played it!). Also, we considered our combat mechanics to be quite similar to Dark Souls mainly because they both tried to convey a very timing-focused combat. And we were not fond of making our system less focused on timing just because another game had just excelled in this area.

In any case, the tactical combat worked very well, and it was the one element that kept the game and its development together from start to finish.

2. Adapting the goals and the team

We started with about 40 people on the team. That’s already quite a lot, but for the project we had planned, certain key areas were seriously understaffed. So we were facing the big task to find more skilled people quickly. Back at the time when we were developing Venetica, we had a similar situation, and no experience with hiring people fast. That had resulted in rushed hirings of people who did not really fit and, especially in the programming department, sometimes did more harm than good. Supposed experts needed training in basic tasks, and in the end some code sections written by new hires had to be rewritten by the lead programmers, who in turn ran late with their own work.

We were determined not to make this mistake again.

So we started the hiring process as early as possible to have enough time to find the right candidates, and we planned time to train them before they would get started on production of the game. After scanning the applications, we did Skype interviews and then sent them a questionnaire with some tricky questions. Then we invited the best candidates over for a two-day test-task on site, to see how they would work on their tasks and how they would fit into the team. And this time, we barely made any “mistakes” and created the very best group of people we had ever worked with. Soon we were about 65 employees with people from all over the world. Oh, and we switched our meeting language from German to English on the way.

3. Fledge: our own “next-gen” engine

After about a year of development, the publisher asked if we could ditch all plans for the “last-gen” platforms, as the new platforms were close to launch. We still did not know any real facts about their system specifications (actually we needed to heavily rely on rumors) so that was a tough question. We needed to guess a lot and still tried not to gamble. In the end, we decided to take the risk. It proved to be a very good decision.

People were asking us if we were serious about using our own engine for such an ambitious project. Why not use Unreal or CryEngine?

Well, we wanted to be fully in control when it comes to technology, and we felt that the only way to achieve that was to use our own. We started developing the current iteration of our tech back in 2009, and successfully shipped on both PS3 and Xbox 360, so it was not like we had to start from scratch. In addition, there are some third-party components which we used that would have been impossible to create on our own, like the NVIDIA’s APEX for destructible objects and cloth simulation or Geomerics’ GI solution, Enlighten. While we did not know up front that we would have to switch platforms during production, in hindsight we think that it would have proven much more difficult to do that if we had chosen a third-party engine.

Whenever evaluating whether to use a third-party engine versus rolling your own, one major argument for an engine like Unreal is the number of shipped titles. But while the catalog of shipped titles using Unreal is certainly impressive for the last generation of consoles, the same obviously did not hold true for the new gen, since the platforms weren’t even out yet.

But the most important argument for our own engine is that it’s just in our culture – it’s what the people on the tech team want to do. For the major part of the development cycle, the tech team consisted of only five to seven people taking care of everything programming related. We think that this is a testament of what you can achieve if the people can work on (and focus on) things they love.

Having said that, it should be clear that Lords of the Fallen was not exactly a walk in the park for the tech team. We had to define what “next-gen” would mean for us, given the scope of the project. It was always a challenge to define and stay within budgets to make sure the content would work properly across all supported platforms. It was not only the “more of everything” approach that we took compared to last-gen, but we also developed techniques and features that just would have not been efficiently possible at all on older hardware (like our volumetric lighting solution). Keeping the tools up to date to support these new features was quite challenging as well.

4. Evolution of team and structures

Lords of the Fallen was by far the largest project that Deck13 had ever done. While we felt pretty well-prepared in the beginning, we found out that we needed to learn an awful lot along the way. For some people, this resulted in exciting new assignments. One example was in the animation section, where Sebastian Seubelt, lead animation artist, and animator Ralf Risto coordinated the whole animation pipeline up to the point of directing the actors in the motion capture studio (they did 12 mocap sessions over the course of development, flying to the remote Polish town of Rzeszów for each of them). In other departments however, it meant dramatic changes that were not welcomed by everyone. The artists, for example, had to switch from creating nifty 2D and 3D assets to feeding and maintaining a massive outsourcing pipeline. At the beginning, both Deck13 and the publisher underestimated how precise and strict the asset delivery toolchain needed to be organized, resulting in unusable assets and frustrated artists. Unclear responsibilities between developer and publisher made things even worse, and at one point we decided that we needed to give things a more formal approach.

We decided that we needed one central place at Deck13 where every single briefing for the art outsourcer teams was created. That was basically an (online) A4 sheet containing all relevant data for each and every asset of the game. Even a single barrel received clear reference images, text describing the important aspects, polygon limitations and material requirements. We wrote several hundred of those individual briefings. With the Chinese company Virtuos we had a great art outsourcing partner who could perfectly work with these briefings, and the results were so good that we could place most of the objects we received into the game almost immediately. (Also, their time zone was seven hours ahead of ours, so they worked while we slept, and vice versa.) As our whiteboxed levels already contained all the necessary objects in a very rough state, we could directly replace these dummy objects with one single click in our editor, turning a rough white level into a vivid world, click by click, asset by asset. But it had been a long way before we got there.

The evolution of our structures did not stop there. Every department became better and better with their planning tools, migrating from Post-It walls to online boards like Jira and starting every day with a quick stand-up meeting. Even though some aspects of our work still lacked the proper organization, people worked unbelievably professionally and remained great and enjoyable (but understandably slightly maniacal) colleagues at the same time.

5. External experts’ contributions

The game would not have become what it is now if not for lots of external feedback during the whole production. The project started off with a totally different setting, at first on paper, and it kept the setting until the first playable version was reviewed. The game was initially set on some sort of Scottish island and the villains looked a lot like ancient Romans. However, even though the graphical quality of the assets was really good, it soon became clear that this approach did not really hit the nail on the head. After a number of reviews, a lot of this was turned around, and the Rhogar, a demonic race, entered the scene. The environment on the other hand became somewhat more snowy, spiky, and… castle-y.

Only the core combat gameplay was kept, because it was basically the one thing that was working right away, and all the way until the end of the production. This was the thing giving us the confidence that the game really had a chance to become good, no matter whether or not we had already found the fitting visuals to accompany it. A lot of people helped shape the game and turn it into what eventually became.

Some individual people deserve special praise. Producer Tomek Gop, who previously worked on The Witcher 2, has a surprising eye for game design and enemy balancing. He provided perfect feedback on any new enemy or boss design that we had him play, and he was able to talk about the tiniest details together with our enemy design team.

Designer Eric Williams of God of War fame did a very important review of the game after Alpha, suggesting some new gameplay mechanics, enemy design and asset focus. Without him, the game would now feel rather different, and most likely not for the better.

Writer Susan O’Connor of Tomb Raider fame helped us with finding the right story, even though we gave her a difficult task with so many ideas already in place when she joined. She was more moderating the elements than suggesting new ones. Still, without her work we would have had a hard time focusing on our most important characters and story elements. It was a pity that we did not have more time in advance to work on the script. We could have done so much more here.

Damian Zielinski, art director at CI Games, has the right eye to spot ever-so-slight inconsistencies in any screenshot, giving valuable feedback on visual quality throughout the whole process.

Composer Knut Avenstroup Haugen of Age of Conan fame is an excellent musician who created just the right tune for the game world and boss fights. His live orchestra direction gave the game the epic touch it needed.

And finally, the publisher CI Games was keen to request external reports from game evaluation companies that wrote mock reviews and in-depth assessments, giving us plenty of hints on how we should shape our features in order to make the best out of them.

The team is unbelievably grateful to have worked with so many renowned people from the games industry who helped to make Lords of the Fallen happen, who broadened our horizons and gave us a totally different view on the game and ourselves as a team.

1. Management structure

While the project was staffed rather well from a developer and publisher perspective, not all key personnel was in place. Missing throughout most of the project was a managing producer, someone who loves reading and writing schedules and charts, asking the tough questions and making tough decisions regarding scale, features, and deadlines. To put it short, someone who knows what to throw out of a project to make it happen. Instead, creative people on both the developer’s and the publisher’s side were striving to create the most beautiful, content-packed game one can imagine, with the result that schedules were too crammed, people had too much on their desks and were not able to finish all the desired features on both sides.

This put horrendous stress on the artists, programmers and game designers as they tried to fulfill all the goals, and they never fully succeeded with that. We tried to counter the lack of a managing producer with building up management power at Deck13, firstly by establishing two-week sprints together with the publisher to have a clear overview of the tasks that were to follow next and to see early enough what would inevitably slip. Still, every sprint basically felt like the team would fail to meet the goals, and people were close to resigning, as they could not keep up with the psychological stress this was causing.

At that point, we decided to hire Mathias Reichert, a development director and veteran in the German games industry. After a couple of weeks at the project, Mathias pointed out that the task he was given had been described to him “a bit too optimistic” at the beginning. But he was soon able to work with the team and the publisher to establish better channels of communication and was brilliant in collecting the developers’ and the publisher’s needs, distilling the essences of what was important and relevant, and inform everyone accordingly. Things began to work.

And then they began to work really well when the publisher finally established Steve Hart, a managing producer, on their side. He would quickly opt for the more important features and drop the less-important ones. Our team noted that it was a pity that the producer came in only when 3/4 of the development time was already over. But still his contribution made it possible to release the game at all.

2. No clear responsibilities

At the beginning of the project, both publisher and developer sides did not feel that it was very important to approach things too formally, and therefore there were (in some areas) no clear hierarchies or responsibilities in place. Sooner or later this resulted in a struggle over competences, especially after some of the initial goals were not met. This again resulted in some bizarre incidents. For example, at some point, people at the publisher began thinking of level layouts, and were we doing so at the same time. This resulted in two parties submitting level maps to the project. And when a level map has once been created, it’s hard to get an idea out of someone’s head. So what now? Which version of the castle was the better one? Could they be combined?

One might be able to imagine how long it took to settle on the maps that were best for the project (and not the egos), and this issue seriously threatened the whole production plan. Luckily, things like these ceased once Mathias and Steve were in place. These two guys were, from time to time, puzzled about how we could have come so far without people like them on the teams. Their work strongly increased the faith of both publisher and developer. Things started to improve, and we were happy and relieved to have the project back on track, even though it happened rather late.

3. Communication

Throughout large portions of the development time, we were not really good at communicating. While we were not so bad talking internally (well, there still were issues but we had them under control), we were really miserable communicators when it came to publisher discussions. As there wasn’t one person channeling all requests and feedback, there were times when it actually felt as if everyone was talking to everyone, without clear rules or structures, resulting in a lot of negative vibrations, confusion, and anger.

Basically we had not thought about establishing guidelines for communication, and things only got better when we did so. For a start, we stopped the wild communication between so many people at publisher and developer teams, employing “channel” people, mainly department leads, who would be responsible for gathering and distributing feedback.

Also, we were sometimes not very good in replying to requests quickly. Our most frequent excuse was that we had to observe so many individual tasks that there was just no time to reply to a request within an instant. However, we did not consider the effect that this had on the other side: People just did not know why exactly their request remained unanswered for hours or even days. Did we just not feel the request to be important? Or had we simply not seen the mail in our inbox folder? Or had we talked about the request and abandoned it without feedback? Well, employing some rather simple rules solved this problem. We agreed that any request from the publisher was to get a feedback from the team lead within at least hours, if not sooner, and if there was no time to really assess the matter, we would at least write back that we had received the mail and would give an estimate on when we would get back at the latest. This greatly improved the communication atmosphere and removed a lot of frustration on the publisher’s side.

All in all you could say that we employed a “service” attitude at Deck13, understanding ourselves as a service provider without losing our identity as a developer, a thing sometimes hard to achieve. Still I think that we succeeded with it.

4. Art-driven design approach

Having no proper management structure in place also meant that the people and departments with the strongest standing were those who dominated parts of the design process. This tended to make things rather difficult, especially when detailed art design decisions were made by top management without considering the whole pipeline, giving tech and game design personnel a hard time.

After finishing Venetica, we were determined to make the areas work together better. However, at times it felt like we were doing even worse than before.

At the start of the production, technicians were clever enough to set up strict asset limits based on their best estimates. This was supposed to ensure that the artists would not create assets with an insane amount of polygons or use a crazy amount of material layers, slowing the engine down to a point where even technical optimization would not be able to save the day. During preproduction, however, these limits were largely ignored with the argument that we would “first need to find the right look” and that we would be able to “boil the whole thing down later anyway.” But it turns out that if you show people a scene full of great stuff, they will not want to go back to scenes that look more scarce, whatever argument of reason you might offer them (like “framerate”). Then it was all coming back to the tech guys who, obviously, had told everyone that it would end up like this and nobody listened to them. Believe it or not, the tech people always seem to be right in the end, so next time it would be wise for us to listen to them right from the beginning, even if that might mean hard fights with management, marketing, or other publishing departments.

The game designers, on the other hand, were facing a different kind of problem. At Deck13, game designers usually create 2D maps of their levels, offer them to the art department where a 3D world (the blocked-out level) is created out of that, and that goes back to the game designers to put in their gameplay assets using our Fledge Editor and test the gameplay flow, and then it goes once again back to the art department, who will improve the level structure and add details with whitebox geometry. This is a tricky process because these two departments need to talk to each other after every step they take, and in the heat of the battle this might slip from time to time. Things get even harder when 3D models of game levels surprisingly come floating in from the publisher, suggesting some “cool structure” here and some “awesome new castle” there. If you have ever tried to cram gameplay into an existing map that has been created by artists that were working without the guidelines in mind, you will agree that this feels like quite the wrong way around, especially if your team is considerably larger than a couple of people.

Enemy design was another critical topic. Several experienced people in the art and game design departments had a pretty clear picture about the rules we needed to apply to make the enemies work well in our game: As it was so crucial for the player to quickly identify the type of opponent he would be facing (to brace himself with the right equipment and tactics), we needed them to be clearly distinguishable in size, color, and movement (see Left 4 Dead as a great example on how to do it right). However, there was a design guideline installed that said that all enemies were required to look like “honorable warriors with human shape.” This, however, resulted in all enemies looking pretty much alike when you actually played the game, making it very hard for the player to identify who he was fighting against. Luckily, external feedback was finally gathered, the guidelines were changed, and we created as much enemy variety as time still allowed. Again, we could have achieved this more cheaply.

The art-driven design approach resulted in being over-budget with our assets, and with the stuff being rendered on screen at once. It again meant that we could not fulfill our production sprints because nobody could actually integrate everything that they would have needed to.

5. No real beta phase

At some point, the release date was set. This was mainly due to the fact that we had a new and unknown IP that would need to compete on the big platforms. For our game to be noticed at all, it had to be out there before the big wave of great new titles would hit the market by Christmas 2014. So whatever we wanted to still put in the game, it needed to be ready way before that time. That seemed extraordinarily tough, and it was only doable by crunching throughout the final months, to the point where people got so stressed that you could barely talk to them. Two things let us survive this phase and come out of it with a (rather!) polished game: Firstly, people were just so determined to make this game a success that they did everything they felt necessary to reach the goals. The other factor was managing producer Steve Hart, who helped channel publisher requests throughout the final months. He was able to make some tough decisions on what to throw out of the final product and what to focus on, close to release.

Still, we did not have enough time left for proper beta testing. Even though testing was ongoing and a great QA department at the publisher supported our small internal QA management team all along, there was just not enough feedback on balancing and, even worse in our case, on compatibility.

This resulted in some very annoying bugs that were still present in the release version, at least on PC where we just did not cover enough hardware configurations to make sure the game would run everywhere, and this resulted in some very annoyed people (and rightfully so!) who could just not get the game to run on their machines. We tried to be as fast as possible, and to help as much as possible, but still it was very dissatisfactory to just fix the stuff after the release and not before. We were not deliberately putting a product on the shelves where we still knew about bugs just to keep the deadline. Instead, we were releasing a product that was free of serious bugs to the best of our knowledge. It was just that this knowledge was too shallow because we did not have enough time to collect more test data.

Conclusion

With so many sacrifices and such an uncertain outcome (at least from our perspective), we were, lots of times, wondering whether all of this was really worth it. Well, we were lucky. The game was received well on all three platforms, it received awards and sold very satisfactory. Deck13 is now known as a capable developer, we got credits for the engine we developed with a small team, able to deploy on Xbox One, PS4 and PC with high quality. We professionalized our structures, bringing art and game design to the next level, and we vastly improved our network of valuable contacts. So, all in all, Lords of the Fallen was the necessary step to turn Deck13 into a serious studio. We still have a very long way to go, but this milestone was necessary, and it was good. It was a big leap, and hopefully only one of many more to come.

Apple isn’t sitting idly by as the legal battle between it and Epic Games continues to gain momentum. The iPhone maker has now filed counterclaims against Epic Games accusing the company of breach of contract and asking the court to award Apple damages due to that alleged transgression.

The exact size of those damages is unknown currently, likely due to the fact that Apple is asking the court to award it a slice of the money Fortnite brought in with Epic’s unsanctioned payment method on iOS. In addition to damages equal to what Apple categorizes as Epic’s ill-gotten gains, it is also seeking a permanent injunction that would block Epic Games’ payment processing service on iOS.

It’s a reaction that goes right to the source of the current dispute between Apple and Epic, a dispute Apple says in today’s legal documents took the form of a well orchestrated “sneak assault on the App Store.”

That alleged sneak attack took the form of a quiet Fortnite update that gave players the ability to bypass Apple’s official in-app payment methods, thus locking Apple out of its usual 30 percent revenue cut. Apple responded that same day by pulling Fortnite from the App Store for violating its App Store Guidelines causing Epic to rapidly file the lawsuit against Apple it had ready and waiting accusing the company of anti-competitive behavior.

Epic maintains that Apple’s refusal to allow external storefronts or payment methods on iOS is anti-competitive behavior. Meanwhile, Apple moved to revoke Epic Games developer account over the violation, a move it says is standard but Epic saw as retaliation as it would impact its properties beyond just Fortnite. Currently, a temporary restraining order is preventing Apple from removing some aspects of Epic’s developer dealings (specifically the ones that relate to Unreal Engine) as the court begins to mull over Epic’s full injunction ask.

The entirely of this latest filing echoes much of what Apple’s said since the beginning of those whole affair: that Epic has benefited immensely from Apple’s App Store and technology and that its cries of anti-competitive behavior stem from its own desire to make money from Apple’s platforms.

“There is nothing anti-competitive about charging a commission for others to use one’s service,” argues Apple. “Many platforms—including Epic’s own app marketplace and Unreal Engine—do just that.”

The rise of microservices-oriented architecture brought us new development paradigms and mantras about independent development and decoupling. In such a scenario, we have to deal with a situation where we aim for independence, but we still need to react to state changes in different enterprise domains.

I’ll use a simple and typical example in order to show what we’re talking about. Imagine the development of two independent microservices: Order and User. We designed them to expose a REST interface and to each use a separate database, as shown in Figure 1:

Figure 1: Order and User microservices.

We must notify the User domain about any change happening in the Order domain. To do this in the example, we need to update the order_list. For this reason, we’ve modeled the User REST service with addOrder and deleteOrder operations.

Solution 1: Queue decoupling

The first solution to consider is adding a queue between the services. Order will publish events that User will eventually process, as shown in Figure 2:

Figure 2: Decoupling with a queue.

This is a fair design. However, if you don’t use the right middleware you will mix a lot of infrastructure code into your domain logic. Now that you have queues, you must develop producer and consumer logic. You also have to take care of transactions. The problem is to make sure that every event ends up correctly in both the Order database and in the queue.

Solution 2: Change data capture decoupling

Let me introduce an alternative solution that handles all of that work without your touching any line of your microservices code. I’ll use Debezium and Apache Camel to capture data changes on Order and trigger certain actions on User. Debezium is a log-based data change capture middleware. Camel is an integration framework that simplifies the integration between a source (Order) and a destination (User), as shown in Figure 3:

Figure 3: Decoupling with Debezium and Camel.

Debezium is in charge of capturing any data change happening in the Order domain and publishing it to a topic. Then a Camel consumer can pick that event and make a REST call to the User API to perform the necessary action expected by its domain (in our simple case, update the list).

Decoupling with Debezium and Camel

I’ve prepared a simple demo with all of the components we need to run the example above. You can find this demo in this GitHub repo. The only part we need to develop is represented by the following source code:

public class MyRouteBuilder extends RouteBuilder { public void configure() { from("debezium:mysql?name=my-sql-connector" + "&databaseServerId=1" + "&databaseHostName=localhost" + "&databaseUser=debezium" + "&databasePassword=dbz" + "&databaseServerName=my-app-connector" + "&databaseHistoryFileName=/tmp/dbhistory.dat" + "&databaseWhitelist=debezium" + "&tableWhitelist=debezium._order" + "&offsetStorageFileName=/tmp/offset.dat") .choice() .when(header(DebeziumConstants.HEADER_OPERATION).isEqualTo("c")) .process(new AfterStructToOrderTranslator()) .to("rest-swagger:http://localhost:8082/v2/api-docs#addOrderUsingPOST") .when(header(DebeziumConstants.HEADER_OPERATION).isEqualTo("d")) .process(new BeforeStructToOrderTranslator()) .to("rest-swagger:http://localhost:8082/v2/api-docs#deleteOrderUsingDELETE") .log("Response : ${body}"); } } 

That’s it. Really. We don’t need anything else.

Apache Camel has a Debezium component that can hook up a MySQL database and use Debezium embedded engine. The source endpoint configuration provides the parameters needed by Debezium to note any change happening in the debezium._order table. Debezium streams the events according to a JSON-defined format, so you know what kind of information to expect. For each event, you will get the information as it was before and after the event occurs, plus a few useful pieces of meta-information.

Thanks to Camel’s content-based router, we can either call the addOrderUsingPOST or deleteOrderUsingDELETE operation. You only have to develop a message translator that can convert the message coming from Debezium:

public class AfterStructToOrderTranslator implements Processor { private static final String EXPECTED_BODY_FORMAT = "{\"userId\":%d,\"orderId\":%d}"; public void process(Exchange exchange) throws Exception { final Map value = exchange.getMessage().getBody(Map.class); // Convert and set body int userId = (int) value.get("user_id"); int orderId = (int) value.get("order_id"); exchange.getIn().setHeader("userId", userId); exchange.getIn().setHeader("orderId", orderId); exchange.getIn().setBody(String.format(EXPECTED_BODY_FORMAT, userId, orderId)); } } 

Notice that we did not touch any of the base code for Order or User. Now, turn off the Debezium process to simulate downtime. You will see that it can recover all events as soon as it turns back on!

You can run the example provided by following the instructions on this GitHub repo.

Caveat

The example illustrated here uses Debezium’s embedded mode. For more consistent solutions, consider using the Kafka connect mode instead, or tuning the embedded engine accordingly.

The post Decoupling microservices with Apache Camel and Debezium appeared first on Red Hat Developer.

Nish

We are thrilled to announce the release of our new e-book: Blazor for ASP.NET Web Forms developers. This book caters specifically to ASP.NET Web Forms developers looking for guidelines. As well as strategies for migrating their existing apps to a modern, open-source, and cross-platform web framework.

Blazor E-book for ASP.NET Web Forms

Blazor is a new web framework that changes what is possible when building web apps with .NET. It is also a client-side web UI framework based on C# instead of JavaScript. When paired with .NET running on the server, Blazor enables full-stack web development with .NET. Blazor shares many commonalities with ASP.NET Web Forms. Such as having a reusable component model and a simple way to handle user events. It also builds on the foundations of .NET Core to provide a modern and high-performance web development experience. Additionally, Blazor is a natural solution for ASP.NET Web Forms developers looking to take advantage of client-side development and the open-source, cross-platform future of .NET.

In this book, each Blazor concept is presented in the context of analogous ASP.NET Web Forms features and practices. The book covers:

• Building Blazor apps.
• How Blazor works.
• Blazor’s relation to .NET Core.
• Reasonable strategies for migrating existing ASP.NET Web Forms apps to Blazor where appropriate.
• A reference sample that demonstrates the migration strategies used.

Read Online

Should I Still Use ASP.NET Web Forms?

Of course! As long as the .NET Framework ships as part of Windows, ASP.NET Web Forms will be supported. For many Web Forms developers, the lack of cross-platform and open-source support is a non-issue. If you do not require cross-platform support, open-source, or any other new features in .NET Core or .NET 5, then stick with ASP.NET Web Forms on Windows. ASP.NET Web Forms will continue to be a productive way to write web apps for many years to come!

Other Free E-books

If you are in the path of migrating your existing web and server apps, check out our free e-books on gRPC for WCF Developers. As well as Migrating your .NET App to Azure and more at dot.net/architecture.

Feedback

The book and related reference application will be evolving, so we welcome your feedback! If you have comments about how this book can be improved, please submit feedback.

Nish Anil

Senior Program Manager, .NET Team

Follow

Nomad’s groundbreaking Base Station Pro is about to begin shipping, but after initial feedback, the company has opted to bundle an optional Apple Watch charging adapter with orders pro bono.

Nomad Base Station Pro Apple Watch adapter

Nomad Base Station Pro with Apple Watch adapter

Where to buy

Who is Ankur Sinha?

The Fedora Community

What Hardware?

Ankur has three machines and runs Fedora 32 on each of them:

• Thinkpad E490 laptop
• a custom workstation that university IT set up for research work
• a headless MacPro5,1
• 2x Microsoft Sculpt Ergonomic keyboard/mouse/numpad
• Netgear wifi extender
• TP-Link TL-PA8033PKIT AV1300 3-Port Gigabit Passthrough Powerline Adapters
• Moto g7 phone with Android 10

What Software?

Fedora 32 workstation, and server on the MacPro.

– Workstation/Gnome3 with a few extensions: caffeine, pomodoro,

  syncthing.

– byobu with tmux: multiple sessions: default, work, fedora

– taskwarrior, vit, timewarrior, gnome-pomodoro, gnome-calendar/evolution for calendars

– neomutt with msmtp + offlineimap + notmuch for e-mail

– vim for *everything* possible – vimrc link

– qutebrowser, weechat, zathura, vimiv

– syncthing + dropbox + git for syncing/version control

For research work:

– NEST + lots of python and Gnuplot for analysis, LaTeX for writing

  (stuff from NeuroFedora!)

– inkscape + gimp + dia + freemind for figures/mind mapping

– jabref for bibliography management

Other bits: – occasional gamer?

– Oad + endless sky + openttd!

Update #3 (Fri 11th Sep, 2020 06:00 BST): During the latest Ubisoft Forward broadcast, Prince of Persia: The Sands of Time Remake was officially announced for Xbox One, PlayStation 4 and PC. While there was no mention of a Nintendo Switch release in the trailer, a Ubisoft Twitter account later on posted (and then removed) a tweet referencing a Switch version, and Switch pre-orders were also available for a short period of time on the game’s official website.

In response to a tweet about the game potentially coming to the Switch, senior analyst at Niko Partners Daniel Ahmad (who previously implied it wouldn’t be coming to the system at all – see previous update below) said it wouldn’t be happening “in January”:

We’ll be keeping an eye on this increasingly convoluted tale and update accordingly.

Update #2 (Wed 9th Sep, 2020 13:50 BST): According to Daniel Ahmad, senior analyst at Niko Partners, Ubisoft’s Prince of Persia Remake – which is expected to be announced this week – will not be coming to Nintendo Switch, nor will it arrive in November, as has been reported (thanks, VGC).

Update #1 (Sun 6th Sep, 2020 07:30 BST): According to Bloomberg’s video game reporter, Jason Schreier, Ubisoft’s Prince of Persia Remake will supposedly be revealed at next week’s Ubisoft Forward, airing on 10th September.

Schreier shared this information on the most recent Triple Click podcast. Here’s what he had to say, (thanks, Pure Xbox):

“…they had been planning a new Ubisoft Forward, where they were going to announce a bunch of games like the Prince of Persia remake that was leaked a couple of weeks ago. That [event] is planned, it was announced today as being for next week, September 10th.”

VGC has also backed up Schreier with its “own Ubisoft sources”, which indicate the claim is correct.

To find out more about the next Ubisoft Forward, view the full schedule in our previous post. You can also expect to learn more about Immortals: Fenyx Rising (formerly known as Gods & Monsters).

Original story (Thu 20th Aug, 2020 03:15 BST): According to an online and local retailer in Guatemala known as “MAX“, a Prince of Persia Remake is coming to the Nintendo Switch and PlayStation 4 this November.

Bloomberg’s video game reporter, Jason Schreier, has seemingly backed up this listing over on Twitter:

“Video game retailers sure love leaking Ubisoft’s surprise announcements”

One individual said they didn’t believe it and the industry insider then told them their tweet wouldn’t age well.

So, what is this supposed remake? Video game historian and Nintendo Life contributor Liam Robertson thinks it might be based on the “original” Prince of Persia game (if it is real). Of course, there have been many reboots over the years as well.

Ubisoft is hosting its next online broadcast (Ubisoft Forward) in September. If this listing is legitimate, we guess we’ll hear more about it then.

Would you like to see the return of the Prince of Persia series? Tell us down below.