#i could do the specific aims and then go back and rewrite my intro

[defiledtomb]

Ouroboros: Progress

I haven't written one of these in forever, so it's slightly clunky, but I aim to have one of these out at least every quarter, if not monthly. Let's dive into it! Spoiler warning for the sneak peeks at the bottom.

What I got done since last month:

After the update drop, I took some time off the main story to prevent the budding burnout. I’m sure you are well aware of my malaise by now- it's a constant effort to stay on the tightrope.

I don't think I brought it up explicitly but when I started writing Ouroboros it was me riding the high of becoming a person again right after years long sick leave and battle with mental health, meaning that while I am absolutely thrilled that I'm getting so much out of life again, that fragile part of me still lives on and I have to take care not to let it get the best of me, and that means constant vigilance and self-compassion. Writing a project this big could easily be a full time job on its own, but I also have to account for going back to the workforce after being gone for so long. It's tough! irl work/life keeps amping up and will continue to eat my energy. Though, come summer, I might actually have some good news on my schedule and how my writing will fit into that. Fingers crossed.

Otherwise I have really enjoyed interacting and goofing around with you on tumblr again, and I’ve had a blast just reading and playing games. It was a very welcomed break. I still got a lot done regarding Ouroboros:

- Got started on all the short stories you voted on, and built the framework of code for how stories will be unlocked as you progress the story. 

- I got some much needed help with setting up a side-blog for writing content only; it’s getting there! Soon Ouro will have its own space.

- I added about 3k words to the next chunk of act 1. A drop in the ocean, but progress is progress. 

- I started sneak-writing on the next act and specifically, the underwater/caving chapter. I am so excited for it! Besides writing and hiking, diving and caving are core parts of my interests. (Didn't I once say that Ouro is disgustingly self indulgent? x] Because it sure is.) 

What’s next:

I am still taking it slow, since most of act 1 pt2 is already written  (60k words ish), and I have some responsibilities I’m gonna need to devote my time to. My goals for February are leading up to Ouro’s first anniversary, so I want to prepare something fun for us to enjoy! If it will be a chunk of update or something else remains to be decided. On the 8th of March we ride.

My priorities for February are:

-having fun with the short stories

-get the sideblog up and running with a new FAQ and character pages, and a new intro post.

-solidify the code and scene transitions for the next update 

- (stretch goal) edit/rewrite/add to the unhinged mess that the next update still is 

 Re: bug reports

Thankfully, last update was relatively bug free, but there are still a few reports sitting in my inbox waiting for changes, mainly

-the egregious oversight of having id's romance scenes appearing although the hunter is committed to L/not in the poly. More on that here.

-the questions with Iontif cutting off short in one path

-a section of the flashback with wrong pronouns + other pronoun variables not displaying correctly (the bane of my existence!!)

Thank you to those who reported these, I always note them down if I don't fix them directly. The reason why I am almost always tardy on bug fixes is because I'm treating this as a first draft that will be rewritten; it makes little sense to dedicate so much time to fixing things that will need to be fixed again. I do them when I have little else I want/have to do. I'm sorry! Triaging problem areas is essential to keeping this show going. I hope that it isn't too invasive to have a few errors in the scenes; rest assured that they will get fixed (eventually 🤡)

Re: save system

Something that has really bothered me lately, is thinking about CoG's obstinate refusal to implement save systems. I absolutely won't release Ouroboros without one, as with how much variation goes into the story (and knowing from first-hand experience playing large games, that one miss-click (or that horrendous bug that chooses options for you if you even look at it wrong) will have you go down a path you didn’t want, or you are faced with starting over, which sometimes leads to such fatigue that you just…stop playing.) it feels like shooting yourself in the foot to not have one. And worse, it feels plain cruel to subject the reader to that. There isn’t any possible way to fit every nuance of a choice into the box-text, or to imply a delayed outcome as a result of making a choice that seems very “innocent” at first glance.

So I stand before a really difficult decision; either code a save system from the bottom up, and I would have to do that sooner rather than later, or port the game to twine which brings its own bundle of problems. Right now I honestly no idea what I want to do, and I have to admit that it fuels a bit of writer's block as I feel locked in place until I come to a decision. Heurgh.

Now for the fun part. Sneak peeks!

I wont share the latter parts as they are still... Unhinged. But the next update isn't just romance, its weapons and insidious cults and fighting, too.  More on that, later.

Thanks for your support, your kind words and for sharing your journey in Ouro. It means the world to me. I’m serious!

[evanvanness]

Narrative edition, Week in Ethereum News, Jan 12, 2020

This is the 5th edition of the 6 annotated versions that I committed in my head to doing when I decided to see how an annotated edition would be received.

Given the response on my Gitcoin matching grant, I may have to keep going.  Check it out - giving 1 DAI right now will get more than 100x matching.

Thanks to everyone who has given on my Gitcoin grant.  It’s the best way to show you want these annotated editions to continue.

Even 1 Dai is super appreciated given the matching!  Since Tumblr adds odd forwarders to links, here’s the text of the link: https://gitcoin.co/grants/237/week-in-ethereum-news

Eth1

Latest core devs call. Notes from Tim Beiko, discussion of EIPs 2456, 1962, 2348

EthereumJS v4.13 – bugfix release for Muir Glacier

Slockit released a stable version of their Incubed stateless ultralight client, aimed at IoT devices. 150kb to verify transactions or 500kb including EVM. incentive layer coming soon.

A little slow on in the eth1 section, but Incubed getting to be stable is cool.  Obviously if they can get the incentive layer worked out, that will be fantastic.

When I think about that that I was wrong about, definitely if I go back to q1 or q2 2017, I  thought that IoT Ethereum was much more of a thing.   There was Brody’s early washing machine prototype, Airlock->Oaken, Slockit had some stuff 3 years ago, etc.  It hasn’t really happened.

Why not?  It seems to me like most of those things require enterprises to take the plunge.  No one is going to go out and manufacture a domestic electronic device just yet with all the uncertainty there.  

And light client server incentivization hasn’t happened yet.  There’s just things to be built still. So it’s cool to see Incubed hitting a stable release.  Slowly but surely all the necessary primitives get built.  I still think there will be lots of robots transacting some day.

Eth2

Latest Eth2 implementer call. Notes from Mamy and from Ben.

Latest what’s new in Eth2

Spec version v0.10 with BLS standards

Prysmatic restarted its testnet with a newer version of the spec and mainnet config

Lodestar update on light clients and dev tooling

3 options for state providers

Eth2 for Dummies

Exploring validator costs

Eth2 for dummies was the most clicked this week.  Even within the universe of people who subscribe to the newsletter, there’s always demand for high level explainers.

The spec is essentially finalized and out the door for auditing, so now it’s a sprint towards shipping, though of course there may be some minor changes as a result of further networking and of course from the audit.

Lately some in the community have been promoting a July ship date and I personally would be disappointed if it slipped that far.

Layer2

Optimistic rollup for tokens Fuel ships first public testnet

Optimistic Game Semantics for a generalized layer2 client

Loopring presents full results of their zk rollup testing

StarkEx says they can do 9000 trades per second at 75 gas per trade with offchain data, with the limiting factor being the prover, not onchain throughput.

9000 is a pretty crazy number, although since the data is offchain that makes it a Plasma construct and not a rollup.   StarkWare to my memory hasn’t provided details on what the exit game is - as an end user do i get a proof I can submit if i need to exit?  I have no idea.

Anyway, it’s very cool that the limiting factor is the prover, ie, nothing about Ethereum is what is currently limiting the 9000 transactions per second number.

Of course Loopring would also have a fairly crazy number if they did offchain data, but they have a thousand or 2k tps per second number with onchain data, and let’s be honest: right now the limiting factor here is the demand for dexes.   No dex at the moment can fill even a hundred transactions per second.  But as trades get cheaper, presumably there is more demand.   And token trading will certainly increase in the next bull market.

Meanwhile Fuel shipped its first testnet.  Very neat.

Stuff for developers

An update on the Vyper compiler: there’s now two efforts, a new one in Rust using YUL to target both EVM & ewasm as well as the existing one in Python.

A look at vulnerabilities of deployed code over time

a beginner’s guide to the K framework

Vulnerability: hash collisions with multiple variable length arguments

Verifying wasm transactions (and part2)

Austin Griffith’s eth.build metatransactions

Build your own customized Burner Wallet

Abridged v2 aiming to make it easy to onboard new users of web2 networks

Ethcode v0.9 VSCode extension

Embark v5

The Vyper saga is interesting. The existing Vyper compiler had a number of security holes found.  EF’s Python team decided they didn’t like the existing codebase.  So now some of the existing Vyper team is continuing on with the existing Python compiler, whereas there will also be an effort to write a Vyper compiler in Rust but to the intermediate language Yul, which means it will have both ewasm and EVM.

Also interesting to see the data viz of depoyed vulnerabilities over time.  App security has been improving!

Ecosystem

RicMoo: SQRLing mnemonic phrases

ethsear.ch – Ethereum specific search engine

Avado’s RYO node – nodes opt-in and let users access them via load balancer

30 days of Eth ecosystem shipping

Aztec’s BN-254 trusted setup ceremony post-mortem. Confidential transactions launching this month

RicMoo always has interesting posts on techniques to use in Ethereum that aren’t mainstream.  This one is pretty interesting.

I’m very excited about Aztec’s confidential transactions shipping this month.   Much like Tornado, this is huge.  The difference is that Aztec is about obscuring transaction amounts.   Well, it’s about more than that and will be an interesting primitive for people to build with.

Enterprise

700m USD volume on Komgo commodity trade finance platform

TraSeable seafood tracker article on the challenges points out the troubles with no private chain interoperability

Caterpillar business process management system

Q&A with Marley Gray about the EEA’s Token Taxonomy Initiative

700m USD.  It continues to strike me that enterprise is one of Ethereum’s biggest moats, and yet I don’t think I do a great job covering it.  Much of what gets published is press release rewrites.

And of course I did a small bit of editorializing by noting that an article on private chains was finding how hard it was to have all these private chains.  They need mainnet!

Governance and standards

EIP1559 implementation discussion

EIP2456: Time based upgrades

Metamask’s bounty for a generalized metatransaction standard

1559 is important because it kills economic abstraction forever!  It’s happening in eth2, it’d be nice to have it happen in eth1.   While I think some of the tradeoffs have not been written about - and that originally caused me to be a bit skeptical, perhaps i’ll write a post about that -- it’d be great to get 1559 into production.

In general, Eth needs better standardization around wallets for frontend devs.

Application layer

Flashloans within one transaction using Aave Protocol are live on mainnet

Orchid’s decentralized VPN launches

Data viz on dexes in 2019

ZRXPortal for ZRX holders to delegate their tokens to stakers

Dai Stability Fee and Dai Savings Rate go up to 6%, while Sai Stability Fee at 5%

EthHub’s new Ethereum user guides

It’s great that EthHub is doing user guides, that’s something that is missing.  What’s also missing is a concerted Ethereum effort to link to stuff so that old uncle Google does a better job of returning search results.

Aave’s flashloans is another neat primitive.  Things unique to DeFi.

Tokens/Business/Regulation

David Hoffman: the money game landscape

Australia experimenting with a digital Aussie dollar, with a prototype on a private Ethereum chain

3 cryptocurrency regulation themes for 2020

OpenSea’s compendium of NFT knowledge

A newsletter to keep track of the NFT space

Initial Sardine Coin Offering

NBA guard Spencer Dinwiddie’s tokenized contract launches January 13

Progressive decentralization: a dapp business plan

I wrote a Twitter thread about Dinwiddie’s tokens.  I’m curious how they do, given that the NBA made him change plans and just do a bond.  I haven’t seen the prospectus, and press accounts have conflicting information, but it appears that the annual interest rate is 14%.  In that case, I wonder who puts fiat in?  I doubt anyone would sell their ETH at these prices for a 14% USD return.  There is some risk, but it basically requires Dinwiddie to lose the plot and get arrested or fail a drug test.  So it seems like quite a good return given the low risk (assuming it is indeed 14%)

That Sardine token is wild, but not crazy.  I won’t even try to summarize it, but perhaps even weirder is that they announced it at CES.  Is your average CES attendee going to have any idea what ETH is during the depths of cryptowinter?  Unclear to me.

Lots of good stuff in this section this week.   Jesse Walden wrote up the “get product market fit, then community, then decentralize” which has worked for a bunch of DeFi protocols.   

It’s also the opposite of what folks like Augur and Melon have done.  So far the “decentralize later” camp has gotten more traction, but I personally don’t consider this argument decided at all, especially if you are in heavily regulated industries like Augur or Melon where regulators might put you into bankruptcy just because they got up on the wrong side of the bed that morning.

I also think Augur could be a sleeper hit for 2020, and I think Melon’s best days are still in front of it.

General

Andrew Keys: 20 blockchain predictions for 2020

Haseeb Qureshi’s intro to cryptocurrency class for programmers

Ben Edgington’s BLS12-381 for the rest of us

Visualizing efficient Merkle trees for zero knowledge proofs

Eli Ben-Sasson’s catalog of the Cambrian zero knowledge explosion

Bounty for breaking RSA assumptions

It’s amusing how heavy crypto stuff often gets put into this section.  The cryptography stuff is all super interesting, but not sure I can provide much more context for it.

Juxtaposed with intense cryptography in this section is Andrew Keys’ annual new year predictions.  Always a fun read.

Haseeb’s class looked great.  A place to pick up all the knowledge that has taken some of us years to piece together, blog post by blog post.  

Full Week in Ethereum News issue.

[xseedgames]

Little King’s Story PC Relaunch - Guest Blog

Hi everyone,

So we’re very happy to have a guest blog entry today from Peter Thoman, better known as “Durante” in gaming circles. Rather than a lengthy intro explaining why, I’ll let his own words below do the talking, so we hope you enjoy it.

Ken Team Leader @ XSEED Games

A few months back Ken Berry of XSEED contacted me to ask whether I could do anything about the issues with their Little King’s Story port. Despite hearing good things about the game, I hadn’t really followed that particular PC version, since a lot of other titles were released around the same time and it’s not really my genre. Still, I was intrigued to see what was wrong with it, and delighted at how Ken was able to provide me with the source code for the game without too much bureaucracy.

Initial Impression

Before going into the details of how I improved the port, I want to remark on the difficulty of this project for the original team who worked on it. After receiving the source, it was immediately clear that this was not a simple port. Little King’s Story was built on a custom engine designed from the ground up for this particular game, and its particular original target platform (the Wii). Clearly, during its development, it was seen as a one-off project that would be done once it ships, and portability or maintainability were secondary concerns.

In any case, I quickly figured out that the largest issues with the port were overall performance, intermittent stuttering, and a whole host of issues with the 60 FPS mode, and decided to tackle these in order.

Overall Performance

First, I removed the frame limiter to more easily investigate performance issues. Even on my high-end system, I only measured roughly 80 FPS in the overworld area at the start of the game. Basic profiling revealed that it was entirely CPU-bound, and I assumed this was not going to be caused by the original Wii code, given that it ran acceptably on a ~700 MHz processor.

This assumption turned out to be correct after more in-depth profiling: the vast majority of the game’s CPU time was spent interacting with the DX9 API. I won’t go into the full details here, but the crucial point is that many individual objects induced a state change of the rendering pipeline, with its associated CPU overhead. I decided to tackle the issue by implementing various caches (for passes and materials) which prevent state changes unless they are necessary. After a bit of tweaking, this lead to a performance of around 123 FPS in the same testing area, an improvement by more than 50%. More could be done - like always in optimization - but since the game is limited to 60 FPS at most anyway I decided to move on to another issue.

Intermittent Stuttering

On a high-end CPU, stuttering was actually a more fundamental problem than the performance overhead discussed above. While moving around in the world, every few seconds the game would noticeably drop one or even more frames. First, I thought that the culprit could be some timing issue, and while improving the frame sleeping logic helped by making the game play feel better, it still didn’t eliminate the major stuttering.

Profiling an intermittent stuttering issue such as this is far more difficult than working on overall performance. Sampling-based evaluation is almost useless, and that’s by far the most developed category of tools. Ultimately, I resorted to using Nvidia NSight and its integration library, and manually narrowed down candidates for causing stutter by marking individual regions in each frame execution. A somewhat time-consuming process, but it paid off:

In this image, the colorful stacks indicate the stutter causes I ultimately tracked down, and the lower half shows a similar sequence after dealing with the underlying issue. Note that the marked regions, which previously could take up 2 to 3 frames, are now in the 0 to 2 millisecond range. To give you a more visual idea of the improvements I’ve created this comparison video.

Issues with 60 FPS

Offering 60 FPS - or, much better, support for completely arbitrary framerates - is a common demand for PC versions of games, and one I fully agree with. In quite a few cases where it is not offered, mods later demonstrated that the effort to do so would have been very small for the developer, and that the only reason it was not provided is a lack of care for the PC version.

Little King’s Story is not such a case. There are many reasons for this, here are just a small subset of them:

1.     The game does not have a unified system for handling time or animation speed. Many modules act independently of each other, and often time-specific information is encoded in places where it would not be expected.

2.     The central NPC simulation code assumes that it can pre-compute how long it will take (in frames) for an NPC to complete an action, such as moving to another location.

3.     Some bosses, enemies and scenes are moved or designed in custom scripts, which use a custom virtual machine and instruction set that is not intended to share framerate information.

 My initial goal was to provide arbitrary framerate support, but point 2 in the list above makes that an infeasible goal. It would basically require rewriting large parts of the simulation, which makes up a significant portion of the entire game’s ~1 million line codebase.  Given that, I shifted to the goal of making locked 60 FPS work as well as possible.

The original port fixed the speed of most NPC animation sequences, but left many other hardcoded animations, and even the gameplay-relevant time progression rate untouched at 60 FPS (resulting in double speed).

I employed a side-by-side 60/30 FPS setup as shown above, and chipped away at framerate-dependent speed mismatches little by little. In the end, I managed to fix the simulation speed, the speed of many hardcoded object animations (such as trees or grass), and the movement speed of NPCs and animals.

However, the custom scripting system used for some boss battles and scripted scenes, point (3) in the list above, still prevents the 60 FPS mode from being perfect throughout the game. However, unlike the initial release, 60 FPS is playable (and a huge improvement in smoothness) during the majority of the gameplay. As a workaround for the remaining situations, I’ve implemented a 30 FPS toggle for the 60 FPS mode, which is engaged using the “F1” key. Note that this comes with some issues due to point (2) above: animations already in progress at the moment the framerate is toggled will run at an incorrect speed until the next movement starts.

 Graphics, Launcher and Control Improvements - What I Wasn’t Asked For

While working on the game, I noticed a few things which would significantly improve the visual quality and not really take too much time to implement. So I did. This include multi-sample anti-aliasing (MSAA), anisotropic filtering, transparency supersampling and a few other minor tweaks.

The most complex addition was creating an option for more shadow casters, including trees and grass. I found the lack of tree shadows a bit disappointing given that other objects cast dynamic shadows, so I added this as a (somewhat CPU-heavy) option. While I was at it I also added an option for soft shadows, to better fit with the soft dropshadows cast by NPCs.

Of course, I also had to add options for these features, and since the original launcher was not particularly extensible I replaced it with a new one. As a personal preference I also re-implemented options to be stored as XML rather than in a custom binary format, and added a lot of information about each option in order to hopefully make their impact more clear.

Finally, while playtesting the controls of the game always felt a bit “off” to me. Even though I was playing with an analog gamepad, movement was restricted to 8 directions, which in particular makes precise directional aiming (a significant gameplay component) more cumbersome than it needs to be. To solve this situation, I added support for analog directional controls for Xinput controllers.

Conclusion

The new version of Little King’s Story should perform significantly better on all systems, most sources of significant stutter should be eliminated, and the 60 FPS mode now provides an accurate (and smoother compared to 30 FPS) experience except in some scripting-related cases. Furthermore, the game now features additional graphics options to make better use of high-performance GPUs, and can be more precisely controlled with analog gamepads.

While I couldn’t achieve everything I initially wanted to - arbitrary FPS and even a completely perfect 60 FPS mode prove intractable for this game - I’m happy that XSEED gave me the chance to contribute a lot more directly and meaningfully to the quality of this PC port.

   *  *  *

So Ken with XSEED again here. To celebrate this relaunch of Little King’s Story, we are running a week-long 40% off sale on Steam and The Humble Store starting right now. Though these enhancements only apply to the Steam build at the moment, we plan on applying them to our DRM-free and GOG Galaxy builds soon, so just hang tight for a little while longer and those builds will be updated too.

Thanks to everyone for your patience and ongoing support, and we hope you enjoy the new and improved Little King’s Story for Windows PC.

Ken