Damara

PART THREE: FINDING THE FUN 
 
In this third and final segment of this series, we’ll take a look at Dual Universe gameplay and how we’re aiming to improve it. There’s a delicate balance to strike between staying as true as we can to the original vision, making smart design and production choices, taking players’ feedback into consideration, and creating more opportunities for community engagement. The game needs to be challenging but, most of all, fun. It can be a tall order sometimes, but not an impossible goal. 
 
This is far from being a comprehensive list of everything we’re working on, but we think it’s a good starting point for sparking conversation with the community. You’ll also notice that we have intentionally stayed away from precise timeframes. We would rather stay flexible and give ourselves the opportunity to revise our plans based on the feedback of players. 
 
Now, let’s get to the good stuff!
 

BREAKING THE MONOTONY 

Even if the main pillars of the game aren’t quite finished yet, the launch of the beta allowed us to see how the various systems work together, how fun they are, and what actually works or sometimes doesn’t.
 
Analyzing data on player behavior and reading the copious amount of feedback we receive (thanks for that!) have pointed to two main objectives we’ll be addressing in the coming months (in addition to continuing to fix bugs and balancing issues). These are: 
 
First, emend gameplay loops that are tedious for some players. We call it “fixing the player routine”, so that playing DU doesn’t feel like “going to work”. Up the stakes, adding meaningful opportunities for conflict so that the in-game economy, social components, and building aspects come together. 
  Some elements of gameplay are more fun than others in Dual Universe. Mining can often be seen as a must-do for many new players, and because it is perceived as mandatory it can rapidly feel tedious. Earning quanta is fundamental. When we launched beta, it seemed like mining was almost the only way to get money, especially for new players who didn’t have much in the way of resources or allies. 
 
To make it more interesting with a real sense of progression over time, here is the high-level plan:
 
Make it easier for newcomers to gather resources from the surface of planets without the need to dig; Then, transition players to deploying mining units once they’ve claimed a territory. Mining units will supply a steady stream of ore, depending on the specifics of the tiles the player has claimed. These mining units come in tiers and should add a sense of progression even to early mining. There will also be a production optimization gameplay if you want to use several mining units. For players who want to specialize in mining, we will introduce asteroid mining. Think of asteroids as epic mining with high reward potential. Asteroids will be spawned in the universe. Players will be able to scan clues in space to discover where they’re located. Some asteroids will contain not just regular ores, but also rare and valuable ones. Once discovered, there will be a delay before their location is broadcast to all players. This is an opportunity for explorers who find these asteroids to reap their resources first or monetize their location. The control of valuable asteroids will also create opportunities for combat, information trading, and collaboration between players. Please also note there will be asteroids in safe zones with lower-value ores.
  THE QUEST FOR QUANTA   
Another way for players to earn quanta is the previously-announced Mission System, coming in version 0.25. It will include two components: a job board to facilitate interactions between players (for example, “I need gold delivered to this location”), as well as a secure framework for player- and NQ-created hauling missions. We hope that this will kindle the game’s economy with increased specialization and proper tools for exchanges between players. The upcoming introduction of in-game challenges will also add fun ways for players to earn cash. 
 
On that note, we plan to revise the way the markets work, considering different ways to improve connections and making it less painful to trade for goods. This should make markets more accessible and fluidify trade.
 
We are looking into how we can rebalance the industry. The reaction to changes introduced in 0.23 told us that there is more work needed here. The role of schematics is definitely one of the areas we’re looking at; whatever we do with schematics, we are particularly sensitive to making a fair move for players who have invested in buying them. 
 
Builders haven’t been forgotten. We just delivered new tools for them in 0.24, and we are already working on new ones that should let builders enhance their artistic arsenal to create more amazing constructs. We’re pretty excited about them, but should forewarn you that it may be some time before they appear as higher priority changes will take precedence. 
 
The first-time player experience will get a full overhaul to facilitate the onboarding of new players. We’re doing away with the long monologues from Aphelia and the length of time it took to get into the action. The tutorials will be more contextual, and the experience of new players should get them into the core gameplay faster. As it is now, new players sometimes need to travel long distances to find a tile free of neighbors and suitable for future expansion. The redesign will allow these new pioneers to start with their friends in a location of their choosing in a more streamlined fashion. They will also be able to select an outpost design and receive startup resources. 

STOKING THE PVP FIRES 
We know a lot of players want to hear about PvP. Once we’ve fixed the main gameplay loops, this will be the next thing we’ll tackle. Our goal is for space warfare to be one of the driving forces of the emergent gameplay, fueling the economy of the game, including for players who don’t want to directly partake in combat but might want to provide ships, ammunition, and services for those who do. 
 
While there are PVPers who are in it for the thrill of the pirate’s life, there are others who aren’t pirates so much as protectors who enjoy defender-type PVP scenarios. In its current state, PVP can be seen as gratuitous, devoid of reasons to fight beyond pillaging a bested ship’s cargo. The current PvP mechanics will be modified with the addition of construct shields and a rebalancing of weapons, among other things, as well as introducing territory control in space and, later, on planets. Controlling space territories will give players benefits such as the ability to acquire highly-lucrative space resources (i.e. rare gas, singularities) and a worthwhile reason for organizations and solo players to fight. Not only that, but you’ll be waging war in style with an array of new, unique cannons and skins. 
 
GLITZIER GRAPHICS
Admittedly, graphics improvements have been on the back burner for a while in favor of building the main gameplay systems. Upgrading the visual immersion has now taken a more prominent position in our priorities, the goal being to give more “life” to Dual Universe. 
 
This ongoing process began in 0.24 when we overhauled many of the assets used in world generation (i.e. trees, rocks, ground textures, etc.) We’ve also undertaken a big push on visual effects, with a slew of new and improved visual effects planned for gradual release in the near future. Continuing our efforts with the recent addition of new voxel textures for builders, we will freshen up many older elements in the game to bring coherence between older and newer assets, as well as between voxels and assets.
 
We are also investigating longer-term visual improvements. For some time, we’ve been working on prototypes for a new planet generation technology to make sure that our planets are interesting to explore. Before we can roll this out, we will be doing an overall pass on the existing planets, like Jago, with improved terrain and more varied environment assets. There is also a project to improve lighting with the inclusion of global illumination.

CLOSING THOUGHTS
Again, please remember that all these changes will be tested first on the public test server. The final versions of these features may vary depending on your feedback and our own thought  processes. In terms of timing, most of the “player routine” fixes are planned to be gradually introduced before the end of the summer while the space warfare and PvP revamp should begin rolling out sometime after.
 
As you hopefully see, a lot of these changes are based on your feedback and a more grounded, pragmatic approach to game design. We realize that many of these topics require additional explanations and that they will probably trigger more questions. We will answer them in due time, as we’re able, in future devblogs. Until then, we look forward to hearing your thoughts in this discussion thread. See you there! 
 

Hello Noveans,

Over the past months, we have been working with the Support and Community teams to better identify the wants and needs of our players. These findings have sparked the initiative to implement a Live Support system to address some of the most common issues during peak times as well as address urgent tickets outside of office-hours. In addition, we’re adding some self-help tools that will enable you to resolve some of the most common issues without having to reach out to Support.

The changes described below will be included in the next update.
 
NEW TOOLS
We are making it easier for players to help themselves in times of need. This is in the form of the following three features, one of which many of you will already be familiar with.
 
Global Chats
To better organize and filter the chat within the game, we are implementing the following channels:
General - Joined by default and can not be left. Help - Joined by default and can be left. Trade - Can be joined and left.  You can interact with these channels by using the following commands in the text window:
/join - To join a channel, such as Trade, i.e. “/join Trade”. /help - Lists all available commands. To leave a channel, right-click on the channel tab. We know that global channels have been in high demand from our community, and we’re thankful for that feedback and the opportunity to see them implemented. Please continue to provide feedback about our chat system on our forums.
 
Fetch
If you have a dynamic construct that’s become stuck, you can right mouse button-click on the construct from your map view and click to Fetch. This will teleport the construct towards you, allowing you to reach and interact with it normally.

We had hoped to be able to make this redundant; however we have seen that there is still a need for it. We are now intending to leave this feature available for the entire duration of beta, initially with these parameters:  
Players can only fetch once per 24 hours. Maximum range has been limited to 4,000 meters. Players must be standing on a planet/moon’s surface.  
Unstuck
If you find yourself trapped and unable to resume your current play, you can now use /unstuck in chat to free yourself in a random direction. This feature has the following limitations:
You can use this command once per five minutes. This teleports you up to 100 meters in a random direction. Teleports can not move players into the building zone of any construct.
  Please note that the Fetch and Unstuck features are intended to be used only to free stuck constructs and avatars. Any usage outside of this scope may be considered an exploit and actioned accordingly. The team will be continually monitoring the behaviour and results of these features, tweaking when and where needed to ensure that players are not abusing these systems designed to help players in need.
 
LIVE SUPPORT
It is important to emphasize that the purpose of Live Support is not to cover all game knowledge questions and assistance scenarios, at least not in this first incarnation. We’ve noticed that many of our community members enjoy helping and teaching other players. We strongly encourage everyone to join our forums where players and organizations can offer further guidance and services to each other.

That being said, our Support staff will be monitoring the in-game Help channel for any issues that are eligible for assistance, to offer advice regarding knowledge resources, or to recommend when players should file a Support ticket. 

Here is a sample of the assistance we may offer: 
Assistance with the tutorial. Freeing stuck characters (if /unstuck does not work). Raising constructs from below the surface (if Fetch did not work). Fetching ships stuck in the sky above a planet (if Fetch did not work). Refreshing glitched elements.  
Should you encounter one of these issues, give us a shout out with a description of your issue via @GM in the Help channel. Please allow at least 10 minutes for a response, after which you may choose to file a Support ticket instead. With the implementation of Live Support, we are expecting a significant improvement to response time for urgent inquiries.

We are very interested in hearing your feedback and your thoughts about these changes. Please join the discussion here.

Hello Noveans!

Currently, screen unit content is an HTML page. We synchronize screen unit content between players by sending the whole HTML; however, screen unit HTML content can be pretty big and uses a lot of bandwidth and frame time to render when updated every frame by a programming board or control unit. This has a significant impact on client performance for players, especially when a lot of screen units are in the same area. 
Performance improvement is of paramount importance to us and an ongoing request we get from players. Consequently, it is something we will continually work to achieve. 
 
To address this, we are bringing a possible solution to PTS so that players can try it out. This prototype involves using a new API to draw screen units with a dedicated Lua script. This will use simple drawing commands like
drawRectangle(a,b,c,d) drawText(“Hello DU”) Simple actions like setTextContent will not be affected. 

In addition to performance improvements, this new tech also allows for some unprecedented possibilities to create even better screen displays than before. Check out this video to get a taste of what it can do! 
 

We realize that this change will mean that players won’t be able to use SVGs on screens anymore, and that SVGs are easier and more flexible than uploading static images. It’s important to note that the new Lua system will still allow you to draw complex images. You don't really need any Lua knowledge, and it’s easier than the DPU system.

Additionally, we added an option to deactivate HTML screen units for players who experience the worse framerate. We expect this to bring significant performance improvements in markets and parking areas.
Once the change is fine-tuned, thanks to your feedback after trying it on the PTS, we will announce a transition period to allow players time to switch over to the new API before we disable support for HTML-based screen units. We will continue to support both techs during this transition period.

We strongly encourage everyone to check out this change when it’s available on PTS and share your constructive feedback with us on the forum. 
 

Hello again Noveans!
We have heard your initial feedback on the screens and we want to elaborate on some of your major concerns.
 
Will this affect both screens and content written to the players screen (HUDs)?
No, this technological change will affect only screen units at this time.

Will all player created work on screens suddenly become non-functional?
No, this technology will be available side-by-side with the current technology, both first on the PTS in a prototype state, and eventually also on the Live server.
We strongly recommend everyone does test and experiment the new tech on the PTS, as your feedback and testing will help shape this feature.

How will this make a difference on performance?
The main reason being that the current implementation does not allow for much control over the performance impact of screen renderings. Complex 3D transformations using a combination of HTML, SVG and CSS has a significant impact on render times in the client. Adding to the fact that screens are often condensed with multiples of them in close proximity to each other, there is an increasing drop in performance on the client with more screens using the current technology. The new system allows for more precise control over rendering time allowed across screens and allows us to safeguard the level of performance impact the screens have on the client.

So you will be removing HTML support entirely?
Not necessarily, the two techs will run side by side for an as of yet undefined period of time. Eventually we may introduce a phase where we make the rendering of HTML on screens an option for players along with a warning that it can significantly degrade client performance. Players with that option disabled will simply not see any HTML content and not suffer performance degradation because of it.

Why not improve the current HTML implementation instead of the new technology?
This is a complex topic, HTML/CSS/Javascript is a group that forms a UI technology. For reasons beyond the scope of this topic we do not allow the use of Javascript inside the screen units. When you remove Javascript, the group effectively becomes a not so efficient vector image drawing technology which we have very little control over in terms of rendering. We have previously implemented a lot of small limitations here and there to reduce the impact of the screens, but there are (and likely always will be) edge cases which will eventually crop up using that technology. As such, the new technology has built-in limitations on how taxing a screen unit can be, and if a screen unit goes over the limit it will simply stop drawing. This is why we ask you all to go and test this, and help us find caveats and where you run into things you can and can’t do.

What about bandwidth? Are you doing this to reduce data transfer for screens?
The current implementation does not address this, the current implementation is a way for us to collect your feedback on this concept. Eventually we may change the way data transfer for screens is handled, where we may increase the size of the defined “template” inside a screen unit itself. Followed by a lower limit on the amount of data transferred to the screen from external sources. Allowing the screen element to do the rendering and drawing work, using parameters fed to it by a control unit.
For example: You would draw the design of a fancy instrument panel using the screen element, and a programming board or control unit just sends the values for all the instruments to the screen. This is currently not in the current implementation however, but may give you a better idea of why this technology has a lot of potential for more intricate and powerful designs.

What about artists who draw using external programs and import their SVG’s into the game?
One of our hopes is to provide a good enough set of commands in the screens API so that our system can express most SVG graphics converted to these commands through for example a small conversion tool. It is unlikely that we will develop and maintain a conversion tool for this, but this is also why we want your feedback on this new API for you to let us know what commands you really want to see included to make this process easier.

We sincerely hope that this answers many of your initial questions and concerns.
I personally can’t wait to see what you will all come up with in your designs!
 

PART ONE: REFINING OUR PROCESSES 
As promised last week, we would like to give you a glimpse at the changes, improvements, and additions we have in store for Dual Universe. 
We’ve learned many lessons since our beta began seven months ago.  Going from a backer-focused game in alpha, under NDA, to a public, wide-open beta with many new players gave us a lot of insight in several areas: processes, economics, and gameplay. In this blog, we’ll focus on processes with the latter two being the topics of subsequent blogs. 

THE LONG HARD LOOK
At Novaquark, we’re still a fairly small team. Given the ambition and complexity of this game, it can be quite a challenge to make the right decisions on how to make the most of our resources. To date, we’ve been focused on bug fixing, stabilization, balancing, scaling, and improving our server and database infrastructure - plus firefighting when necessary - to make the game work better. 
 
Not to say that this is all behind us; it never will be (such is the way of MMOs), and we know some bugs and exploits still need to be addressed - this is a beta after all. Still, we paused earlier this year to ponder what the next phase of development of DU should be, to stay the course of the original plan or adapt to how things have evolved since beta began. After taking a  long hard look at everything we’ve learned from the beta, we decided where we need to focus next, based on what we think will be best for Dual Universe and its community. 

“IF IT’S BROKE, FIX IT”
Maintaining a live game while we continue to develop it ended up being quite the leap from our tightly-controlled alpha environment. As much as we prepared for it, actually doing it was a whole different beast. That’s probably one of the areas where the reality check was the most brutal for us. The world of Dual Universe is a persistent one, and every time we introduce something, it impacts the player and the delicate balance of its economy. There’s no safety net, and player feedback often came once bugs or balancing issues had already impacted the game’s common universe. 

Let’s start with how we plan to improve our processes and quality control, because this is an area where doing something wrong can have a major impact on players. We have three goals in this area: 
 
 
Gather feedback from players earlier in the process, so that when new features and changes are introduced in the game, their impact on the persistent universe is properly measured.  Have a more flexible and collaborative development approach that will allow us  to take player feedback into consideration, modifying plans when we’re able.   Overall, improve the quality of our releases, which means fewer bugs and exploits, and less hot-fixing.
  When it comes to gathering feedback from players earlier, we are evaluating some options on how we might get feedback on game design ideas from players at an earlier stage before they have actually entered the production pipeline. We are already seeing significant improvements in this area since the launch of the public test server (PTS), which lets us test prospective new features, improvements and bug fixes in a non-persistent environment where it won’t impact players’ progress on the Live server. If enough players test features on the PTS, we’ll be able to prevent bugs and balancing problems from making their way to the persistent universe. 
 
When we deployed 0.24 on the PTS first, players gave us invaluable feedback, helping us to identify several issues that we were able to address before they reached the production server. Although  our PTS-to-production process isn’t perfect yet, we are still working to improve it and think it’s getting significantly better with each iteration.  In the future, we will expand the use of the PTS to testing prototypes of features, outside of regular releases, so that all players can give their feedback as early in the development process as possible. 
 
Another major improvement to our processes that we are addressing is flexibility. On our way to beta, we had a fairly rigid roadmap that was dictated by the necessity to lay the foundations for all of the gameplay pillars for beta as well as fulfilling our promises to our backers. While the overall plan and long-term goals for DU haven’t changed, we need to be able to adapt to the feedback of players along the way whenever it’s feasible. For example, if we decide to make a major overhaul of our mining mechanics, we need the flexibility to iterate as much as necessary until we find the right formula before we move on to something else. 
 
Although they may not be visible to players, there are many other things happening internally  that have already proven to improve our releases. First and foremost, our internal release process is undergoing a revamp, based on the learnings from our past launches. We’ve allotted more time for QA than we used to, and we will postpone a release if we think it’s not ready (as we did  with the 0.24 update.) These new processes are still being refined, but we’re seeing improvements already.
 
We remain steadfast in our promise to deliver the best game possible. We feel confident that the changes we’re making now to our processes are a big step toward making that an attainable goal. 

Ready to discuss part 1? Click here.
 

PART TWO: UNDER THE HOOD 

In our previous blog, we spoke about improvements we’re making to our processes in order to get more efficient use of our resources and deliver the best game possible. Today, we’re taking a look at operation costs and how we’re working to make improvements in that area, too. 

THE COST OF DOING BUSINESS 
The server and database architecture behind Dual Universe is new and quite complex. As we had about the game itself,  we had made assumptions about how much running a game like DU was going to cost in various areas. What we found was that our estimations proved to be far too conservative. We had to confront the actual cost of scaling up operating costs for a larger, global player base. And that’s okay. We have a plan. 
 
After reevaluation, we determined that some of our design decisions have had a major impact on our operational costs (i.e. what it costs to run the servers). In particular, databases are a major part of these costs. For example, because the world can be entirely edited and every edit needs to be stored in a database then communicated between the server and the clients, it eats a lot of our I/O allocations, which in turn increases our database costs. 
 
THE IMPACT ON UPDATES
The consequence is that, in the upcoming months, we will be rolling out significant backend improvements in order to optimize these operational costs. We made the conscious decision to keep pricing low in order to make the game more accessible for people who want to play, but that means that we need to keep operational costs in check. Developing these optimizations is time-consuming, but it is fundamental if we want to have a viable game as the playerbase continues to grow. 
 
It’s important to make players aware of this because some of our upcoming releases may not seem like much to you. While they won’t appear to include much in the way of new features, they will be updates to deploy these fundamental under-the-hood changes. For instance, the upcoming 0.25 release will be primarily focused on introducing a “game-changing” incremental storage mechanism for edits to the game world that will have a major positive impact on our database costs. The good news is that we think that some of these modifications will improve performance for the players.
 
Speaking of performance: that’s another area where we’ve been doing a lot of work, using the in-game telemetry to optimize areas where performance was dropping. There are several projects in the works to address performance. Although these may not seem particularly sexy when you read about them in the patch notes, the difference in how much better the game runs and feels while you’re playing should convince you it was worth the time and effort we spent on them. 
 
One example is the in-game screens. They ended up being quite popular among players, but the use of HTML for screen customization has proven to be quite a performance bottleneck in areas where there are a lot of screens. We recently started testing a new system using simple Lua draw commands instead of HTML to achieve the goal of screen customization. This change should seriously alleviate performance issues in areas with a lot of screens while providing the added benefit of unifying customization languages in a more user-friendly way.
 
There are other optimizations like this in our pipeline, and they will be presented in due time. 

MORE IN STORE
Tomorrow, in the third and final part of this series, we’ll talk about DU gameplay, and the challenges of maintaining a delicate balance between staying true to the original vision while taking player feedback into consideration. 
 
Discuss today's blog here!