GNU Ring 1.0 released

https://ring.cx/en/news

http://news.ycombinator.com/item?id=14873083

As a GNU package since October 2016, the Ring team wants to thank Dr. Richard Stallman and the FSF for their support for the Ring project.

Important links

Download Ring Contribute to Ring Technical documentation

20 December 2016

Ring on UWP: genesis of a technical challenge

Ring's beta 2 version is now available on the Universal Windows Platform (UWP). It's not only a great step forward for Ring, an official GNU package, but a technical success for our development team.

How I tried to get into game development and failed

http://enterprisecraftsmanship.com/2017/07/17/a-story-about-how-i-tried-to-get-into-game-development-and-failed/

Http://news.ycombinator.com/item?id=14874744

If you read this blog regularly, you know that I usually write about DDD, functional programming, and enterprise software development best practices in general. These are the techniques I enjoy talking about, as well as applying them in my own projects. However, there was another field I always wanted to try myself in. That is game development. The ability to write my own games was the reason why I started learning to program in the first place. And I believe many programmers had this motivation behind their careers as well.

But let’s start from the beginning.

Inception

I wrote my first game when I was about 14 years old. It was a poor version of Minesweeper – a ubiquitous game shipped with every version of Windows. I wrote it in Turbo Pascal. It was a console application where you had to enter the coordinates of a field with the keyboard. Not the best choice in terms of user experience but I had no idea how to work with the computer mouse back then.

Since then, the idea of writing a game was always in the back of my mind. I made numerous attempts to implement it but never made it through. In the beginning, it was mainly due to my impatience. I never had enough motivation to finish things that are both hard and don’t yield measurable results in the short term. Later in my career, it was more of a calculated choice. Game development takes a lot of time, it’s completely unrelated to what I do for a living and doesn’t have any financial upsides. So the circumstance was never good enough to dive into this field, despite the fact that I always wanted to.

Until last year.

I don’t know if you are familiar with this phenomenon of io games, so let me give you a quick explanation. Up until maybe 2014 or so game development meant one of a couple options (although, I’m not into this industry much, so might be wrong on that).

The first one was small flash single player games similar to what you can find at kongregate.com and alike. They are good for spending a couple hours but that’s usually it. You forget about them completely as soon as you figure out the mechanics or go through the entire game content. They usually don’t possess much replayability. Only the best bring substantial monetary reward to their creators.

The second option is large AAA games like Civilization, Call of Duty and so on. Needless to say, they require too much of investment to be feasible for an indie developer. There’s a better alternative nowadays – Unity. It makes the development process easier but the distribution model stays the same – you need to either publish it on Steam or find a “traditional” distributor to work with.

Both options didn’t work for me in terms of the ratio between the time investment and the potential outcome. Flash games require little investment but bring too little in return. “Big” games could potentially become a hit in terms of financial results, but require years of work, even with Unity.

There’s also an option of mobile gaming but the competition there is even harsher than on PC nowadays.

And here came the io games which provided a unique combination.

They are simple, even trivial to play, but not so easy to master so there’s some learning curve involved.

They have a multiplayer which adds a high degree of replayability. It’s always more fun to play with a real player than it is with a bot. They are easy to develop. The WebSockets technology has opened an immense opportunity for multi-player online games. No need to build a desktop client anymore, and no need to find ways to distribute your game as you can now build it using plain HTML and Javascript. In short, an io game is a multi-player HTML game. The name “io game” is due to the fact that, historically, such games have been hosted in the .io domain. One of the first such games were agar.io and slither.io.

So, as you can see, the effort required to build an io game is not much higher than it is to develop a typical flash game. Unlike typical flash games, though, an io game can potentially attract more players because of the multi-player aspect.

And what about the potential outcome? This is where the things start to become very interesting.

In July 2016 I read this article about slither.io. It says that the author of this game pulls more than $100,000 in revenue daily. A hundred. Freaking. Thousand. A day.

Me after reading the article

I decided that it was time to act. I figured that even if the article is off by 2 or even 3 orders of magnitude, I would still be doing very well should I develop something similar. So here began my game development journey.

The idea

I had lots of ideas for the game from my past failed attempts. Most of them revolved about strategy and MMO RPG games. That’s because I personally prefer strategies (such as Civilization) over action/arcade type of games.

However, I decided not to go this route as the game logic would be too complex to implement and thus the whole endeavor would become too risky. It’s hard enough to dive into a completely unfamiliar field; taking on additional hurdle of working on a complex game would add up unnecessary risk.

Also, I’m a big fan of the stairstep approach. If you want to open a new area for yourself, start small. Learn what you can from this experience, then expand into something bigger. In the case of game development, that means creating a simple game first, almost an MVP, and then move on to something more ambitious.

The resulting game turned out to be not as simple as I expected, just as any other project would with that many of unknown variables. But I’m getting ahead of myself.

So I threw away my initial plans to implement the dream game and instead focused on coming up with something simple but still fun to play. And there the idea of a robot game was born. In it, you would control a robot and try to shoot enemy robots, also controlled by real players. No 3D graphics, just top-view 2D.

Now it was time to decide which development stack to use. The client was going to be HTML + Javascript, there was no doubt about it. However, I thought about using a transpiler as I didn’t like the dynamic typing that comes with vanilla Javascript. For a short moment, I considered using F# with something like BABEL, Fable or FunScript but threw this idea away. I wasn’t proficient enough in F# (and still am not), and so I decided that the additional risk of adding another unfamiliar technology is not worth the potential benefits of using a purely functional language. Also, I was certain that the game would require some pretty low-level optimizations and so getting as close to bare JS as possible would be beneficial in the long run.

My second option was TypeScript. It’s not that different from pure Javascript, can be used in combination with Javascript, and provides a strong type system you can get advantage of during development. Overall, TypeScript looked like a logical choice for someone with a Microsoft stack background. It almost felt like C# for browsers.

Moving forward, TypeScript proved itself as a good choice. The thing I like the most about it is optionality of its type system. You can always fall back to the plain Javascript where needed.

As for the server side, the choice was pretty clear to me as well. I was going to use C#. At the time I started the development (August 2016), .NET Core wasn’t mature enough, had no out-of-the-box WebSockets support, and so I stuck to the “big” .NET Framework.

Proof of concept

I quickly developed a prototype in order to check the fundamental assumptions and the technology stack. Here’s what it looked like:

Two Two “robots” staying across each other

The two red squares represented robots. You could enter the game by visiting the game’s front website and have a “robot” assigned to you. You could move the square around and see other players’ movement.

Everything looked good overall, and so I moved on to step 2: finding a partner. I knew that taking this endeavor on my own would mean longer development time, more problem with unfamiliar technologies, and, therefore, additional risk.

And so I asked a colleague of mine – one of the best programmers I know – to participate in this project. I laid out its potential perspectives, and he agreed. He had some personal tasks he had to take care of at that time and I needed to finish my Pragmatic Unit Testing course, so we took a small break. Starting from late September 2016, however, we were working on the game day in and day out during our evenings, weekends, and holidays up until April 2017.

Looking back to this period of time, I have to say that I rarely had a period in my life when I worked so much during that long, and I consider myself a pretty hardworking guy overall. The game absorbed me completely. During those 6 intense months, I stopped working on courses for Pluralsight and scaled back my blogging activity from 1 post a week to 1 post every 2 weeks. I even skipped a New Year vacation my wife and I were supposed to take – the choice I now regret making.

OK, back to the proof of concept. The main objective of it was figuring out how to deal with lag compensation. If you read anything about online game development, you notice that the most fundamental problem there is perceived latency. You absolutely have to ensure that the delay between some action the user takes and the result of that action is minimal. There’s nothing more critical to the game dynamics than this. A noticeable lag, even when it’s not that large, can make it completely unplayable. The game should feel as if there’s no network communication at all.

And the more interactive the game is, the harder it is to achieve this kind of experience. For example, a multi-player mode in a turn-based game like Civilization doesn’t require much effort to implement. Players wait for each other’s turn anyway; they don’t see the results of other players’ actions until they are complete.

It’s a different story with games like Quake. Quake or, say, StarCraft must inform your opponents about every move you make as soon as you make it. It’s crucial because those games are highly interactive; any lag could slow down the counter-measures your enemies undertake and therefore worsen their position in the game.

I brought up these two games for a reason. There are interesting stories behind the way they implemented their multi-player modes.

There are basically two ways you can play with other human beings: via a local network connection (LAN) and via the global one (WAN, the Internet). The difference in lag between the two is huge. While the ping between computers in the local network is usually within a single digit millisecond mark, the ping between machines connected via the Internet can reach hundreds of milliseconds and more.

The minimum delay a human can notice is about 100 milliseconds. Everything less than that constitutes a great experience for us, basically a no lag situation. We do notice delays above 100 ms. And the bigger the delay is, the more it irritates us. A big lag degrades our perception of the game. You will have to come up with a really great game play in order to make players tolerate such delays.

So the difference between LAN and WAN is that it’s very easy to create a responsive and fast multiplayer game where all players are connected via LAN. And it’s not so easy to do that when playing via the Internet.

This entails two completely different programming models. With LAN, you can implement a simple and intuitive interaction routine between all players:

Multi-player mode implementation

This is (more or less) how the multi-player mode is implemented in StarCraft. When you command a soldier to move, he doesn’t move right away, your computer sends a message to other players first and applies the change only when it receives its own message back. Basically, all computers modify their state simultaneously, the initiator doesn’t have a priority here.

This works due to the fact that the LAN connection is super fast. You can send tons of messages to each other and the delay would be unnoticeable. Which is perfect as it enables very simple programming model.

The situation changes when you start communicating via the Internet. You no longer can just make the player wait while the messages make a full circle before showing the effect of their actions. This would make the game virtually unplayable.

That is what Quake’s developers experienced when they tried to use the multi-player mode they developed for LAN in the setting of the Internet. The increased lags made the game unresponsive to the point of being unusable. John Carmack then had to make a full re-write of the multiplayer engine in order to compensate for those lags. Here are a couple of articles where you can read more about the compensation logic: one, two.

In short, you have to treat the player’s character differently from his enemies. You no longer can afford the simplicity of the programming model built for LAN. The reason being is that the player is susceptible to his own moves more than he is to the moves of his enemies. When the user starts firing, he expects the rifle to respond momentarily, no delays are acceptable here. But it’s not the case for the fire started by his enemies. There’s no way for the user to know when they started firing anyway unless the players sit right behind each other.

So on one hand, you must show the player’s actions in the present time: any move or update performed on the main character must be shown immediately. This is done by client side prediction. Here’s how it works. In most cases, you can safely assume that the action the player takes will be acknowledged by the server and act as if it already is. In other words, show the character responding right away. Then, when you receive the actual game state from the server, correct the local state. If the prediction is implemented correctly, the difference would be small and the correction will go unnoticed.

And that works fine in the vast majority of cases. The only time when the client and the server might go out of sync is when there’s an unexpected network lag between them. In this case, the client prediction can be off by a large margin. I’m sure that you as a gamer can remember instances of when that happened to you.

For the enemy actions, there’s no way you can do any kind of prediction as the only information you have about them is the one you receive from the server. The problem here is that this information itself comes with a delay because of the time the message needs to travel from the server to you.

So what you have here is this convoluted situation where your own character acts in the present (no delays involved), but the enemy characters are shown in the past (because of the ping time between you and the server). And that means that any time you aim at someone, you aim at the position in which that character was hundreds of milliseconds ago. Kind of like when you look at the stars, you see the state they were in years ago due to the time it takes the light to travel through space. Consequently, when you shoot at a moving enemy, you will miss, even though you have the enemy right before your gunsight.

So how the games like Quake deal with this kind of issues? When they see a message from your client about trying to shoot someone, they rewind the game scene backward to see where exactly your aim was at the time of shooting. If you indeed targeted the victim correctly, you will get the hit. The downside of this technique is that the victim can potentially get the hit even after they hide themselves. From a victim’s perspective, it could be that they quickly pass some open space, hide behind a wall, and then get killed by a lagged shot. Again, kind of like relativity of simultaneity – one of the principles in special theory of relativity in physics.

Overall, though, it’s a small price to pay for the opportunity to get better user experience in the face of slow Internet connection.

Alright, why am I telling you all this? I just wanted you to know how important this topic is for any kind of highly interactive multi-player game. My colleague and I tried to tackle it first, before moving forward with the actual game implementation. For about a couple of weeks or even a month, all we had gameplay-wise were red squares moving around and shooting each other with black dots.

Finally, after some period of trial and error, we had a good solution to deal with lags. In order to test it, we inserted random artificial lags in two directions: from client to server and from server to client. The application worked around those lags pretty well, they were mostly unnoticeable for the player.

What we ended up with were three models. The first one was client prediction for the player’s character. It was implemented using a technique similar to event sourcing. Whenever the player did something with the robot, the client sent a message to the server and applied that action to the local game scene right away to avoid delays. The event also got recorded to a local list of pending events. When the client received an updated game scene from the server, this update contained the number of the last processed event the server received from the player. The client then overrode the player’s position and reapplied all pending events starting from the one which was not yet processed by the server. This ensured smooth and responsive experience when the player controlled his character.

The second model was for the enemy characters. When the client received updates about the enemies, it didn’t just change their positions on the local game scene, it interpolated them. Interpolation means that the application showed the transition between the previous and the current states smoothly, without weird and quirky jumps.

And for the bullets, we used extrapolation. Which means that the client simulated the position of the bullet in the future and displayed it a little bit ahead of the actual position received from the server.

During the development period, we experimented with these models further and made small adjustments to them. The final version ended up using extrapolation for both bullets and the enemies. The reasoning behind the initial design was that it was easy to simulate the position of a bullet because, once created, its speed was constant and could not change. As for the enemy robots, they could move unpredictably and so it was too risky to extrapolate them taking into account that this extrapolation will most likely be incorrect. But as it turned out, this fear was unfounded. Even though the enemies did move randomly, the resulting position corrections were small and hard to notice. At the same time, extrapolating the enemy positions meant that all objects on the game scene resided in the present time relative to the player’s character. And that simplified a lot of things for us moving forward.

This lag compensation algorithm worked (and still works) extremely well. With a decent Internet connection, the game feels like you are playing it locally. You can see lags only if your connection is slow or if you are physically too far away from the server (which at the time of writing resides in US East).

Not only that, the algorithm also allowed us to send fewer messages from the server comparing to other similar games. Because of the extrapolation logic we implemented, the client behaved great even with fewer data points. And that meant less work for the server (and thus better performance) and less traffic cost.

Issues with client garbage collection

So, getting back to our story timeline. In parallel with the compensation mechanism, we worked on issues that arose on the client. The game delivered good 60 FPS for the first minute or two but then the rate plummeted to 10 or even 5 PFS. Which was an obvious show stopper.

We fixed the issue pretty quickly. It turned out we instantiated the game scene several times, hence the immense pressure on the Javascript garbage collector. Another change that helped a lot was combining all game loops into a single one. Game scene rendering, user input processing, and applying updates from the server – all this was processed by a single handler now.

By the way, we considered using an existing UI engine for the game but decided not to do so. A 3rd party engine meant giving away a lot of control over the low-level implementation details which could potentially affect our ability to deal with performance issues down the road. Also, we estimated that the time needed to learn that engine would be roughly the same as the time to learn how to implement the same features using plain HTML canvas. The game was a 2D shooter, so the rendering part wasn’t too complicated anyway.

The game client optimization, especially garbage collection optimization, was our ongoing task moving forward. We sacrificed some programming best practices in order to improve the performance. Specifically, we gradually departed from the use of immutable data structures on the client in favor of mutable ones just to decrease the pressure on the GC. Here’s for example what our Vector class ended up looking like:

Note the set method. I wouldn’t recommend anyone to use this practice in a typical enterprise application 🙂

Issues with server garbage collection

It was October 2016 and the lag compensation mechanism worked well for the most part. But there still was something strange it how the game behaved. From time to time, the lag between server and client spiked. So much that the prediction algorithm couldn’t handle it and the game showed sudden jumps for the objects on the game scene.

I rechecked the math, double checked all prediction rules, tried to change them, but nothing of that helped. Then we turned to the server. Added excessive logging to catch exactly when that happened, started monitoring CPU and memory usage and sure enough, the pattern soon emerged:

Issues with server garbage collection

This was a VM in Azure which we used as our test game server. Note that on that picture, the server was handling a single game with no players connected to it. So it’s not that we were overloading it or something.

The server ought to have been processing the game scene every 15 milliseconds, and it did for a while. Then the time between ticks increased to 20-30 ms and then it dropped again. This variation resulted in sending game updates with unequal intervals which ultimately led to objects jumping on the game scene.

We tried to tame the garbage collector, tried to tweak its settings, increase and decrease the time between its executions, nothing helped.

After further investigation, it turned out that we also had an issue with the WebSockets library we used on the server. It didn’t handle the volume of messages we tried to sent with it. Or rather, it did handle it but sent those messages with unpredictable delays which also added up to the perceived game lag. Although, that could be due to the issues with the garbage collection.

After days of trial and digging into the WebSockets implementation, we decided that enough is enough. Screw it, we were going to rewrite our server in NodeJs.

It took us several days to convert our code from C# to TypeScript. And when we finally did that, a miracle had occurred. All those problems we were dealing with during the good part of October just went away. No lags. No issues with unequal distribution of messages from the server. No performance problems. Nothing.

Note that it was the exact same code converted from C# into TypeScript, the implementations were identical. We just copied .cs files into .ts ones and fixed the compiler errors. The only exception was the WebSockets implementation, we used one of the NodeJs libraries for that.

I must say that I was skeptical about this whole “Javascript on the server” thing in the past. To me, it always looked like a dumb idea. Apparently, I was wrong. NodeJs proved to be a good solution for our problem: it is fast, stable, and easy to work with. And TypeScript allowed us to keep the strong typing and not deal with the bare bones JS, so I had nothing to complain about.

There were two other benefits we had after the rewrite. First, we were able to share the code between the client and the server. Which was a big thing as they had a lot of logic in common. Second, it opened better hosting opportunities as Linux is cheaper than Windows Server and is much more prevalent. Currently, we use Ubuntu as our host OS.

Change of game concept

Alright, I’m getting ahead of myself once again. So in the beginning of November, we had a working prototype where we solved the majority of our hardest problems. We had red squares firing to each other with black dots and they were doing that very well in spite of lags and poor Internet connection (which we simulated on both the server and the client). It was time for the actual game play and content development.

As I mentioned earlier, we were going to create a 2D top-view robots game where you control your character with WASD or arrows and shoot enemy robots with your mouse.

We found some robot animation on the Internet (as a temporary solution). Meanwhile, we started looking for a freelance designer who could draw the game art for us.

This is what those temporary robots looked like:

game development: Temporary robots Temporary robots

The robot foundation rotated independently from its head. You could move in one direction and point the robot’s head with your mouse in another. These two features – movement and firing – were completely separate. This made the game more fun in my opinion. Alternative solution – where the robot’s head direction depended on the direction of its legs – would have been more accurate but then again you would have to think more about how to control your robot instead of focusing on the game’s main goal – shooting everyone around you. We tried to make the game as simple as possible for the players.

Two more game concept we started implementing were walls and perks. Walls added more tactical variety as they allowed you to hide behind them and be safe from the enemy fire. Perks did the same thing but from a different angle: they allowed your robot to have a temporary advantage in terms of speed, health, fire power, and so on. Walls were destructible, so you still could get your enemy, it just took more time as you needed to destroy the wall before him first. As for perks, they appeared on the map from another game object – crate. Both walls and crates respawned on the map periodically.

The development moved fast after we finished with the lag compensation algorithm and fixed our problem with garbage collection.

This is what it looked like soon:

On this video, my colleague shoots two lonely bots.

As a side note, I must say that the game we were developing was heavily inspired by NES’s Battle City:

game development: Battle City for NES Battle City for NES

I don’t know how famous this game was here in America but in Russia, everyone of roughly my age played this game back when they were kids. To say this game was famous in Russia is an understatement. Everyone knew and loved it.

And by the way, the bricks on the video are from Battle City. This was also a temporary solution, of course, we were going to replace them afterward.

We implemented lots of things during November: collision detection, score calculation, HP, perks, centering (when your robot always stays at the center of the map and its other game objects that move when you walk, not your robot), and so on and so forth. We also added bots. We knew that in the beginning, there would be few real players online, so the game needed to offer those players something even when there’s no one else playing it yet.

This is a video of a robot fighting with lots of bots at once:

Note the circle around him. It represented a force shield which made the player invincible for some period of time.

And here’s a video of us both fighting against evil hordes a couple of dumb bots:

By the way, on this video, you can notice that two bullets annihilate when they come close to each other. We had this feature for some period of time. And it added a nice tactical capability – dodge the enemy bullets by destroying them with those of your own. But we removed it later when we were optimizing the game. Collision detection of bullets consumed a lot of CPU time, and we decided it’s not worth it. More on this later.

In the mid of November, we found a designer and got estimates from her as to how much it would cost to create a robot animation. It was a lot, and not because she was overpricing this work. An animation similar to what you can see on the video is genuinely hard to implement, there are quite a few high-resolution details that need to be worked out.

After some thought, I proposed to change the game concept. Let’s turn robots into tanks, I said. There were several reasons behind this proposal. First, tank games are ubiquitous and the players would have much easier time relating to them. Second, with the top-view we had in the game, we could show tanks in much more detail in comparison to robots, just because robots don’t look that attractive when looking at them from the top, but tanks do. And finally, the animation was simpler and the designer said it was going to be much cheaper for us to have them instead.

So here we were. We decided to switch from robots to tanks and started working on our first tank design.

Conclusion

Heck, I’m 5 thousand words into this post already, and only covered everything up to November. There’s still at least as much things to write about that happened between December and April.

Let me know in the comments below if you want to read the rest of the story. What I think I could do is split it into two or three parts and call this one the first.

無人超市

馬雲於2017年7月淘寶造物節推出24小時營業的無人超市「淘咖啡」，配合人臉辨識技術，不用收銀員掃條碼，顧客直接拿取貨物就走，體驗免排隊結賬的消費模式。

無人商店的概念並非馬雲首創，Amazon推出Amazon Go、日本Lawson或是上海的「繽果盒子」也有類似的銷售模式。

Lawson的技術是，顧客把產品放進特製購物籃，偵測籃中的貨物，並自動計算價錢，顧客只須把籃子放到收銀台，籃底會打開，貨物便會跌進下層的購物袋裏，顧客便可直接帶走。

消費模式將會推翻

另一邊廂，Amazon Go的技術則採用大量鏡頭和感應器，觀察顧客的一舉一動，並於顧客把貨物拿下貨架時已能知道價錢，省卻收費過程。

由於此項技術成本甚高，產品售價沒有比一般人手操作的便利店優惠，所以有待技術成熟降低經營成本後，才可觀察它的普及性。

馬雲推出的無人超市運作模式是，當顧客進入商店前先要開啟手機的淘寶程式，掃一掃門口的二維碼，連接手機的支付寶，店門便會自動打開，顧客入店後可以自由選購貨品，跟傳統的超市沒什麼分別。

如果有人想渾水摸魚，那是不可能的，因為支付寶屬實名認證和鎖定銀行戶口，讓消費更公開透明。選定貨品後，便要穿過第二道門，手機屏幕便會顯示「商品正在識別中」，然後「商品正在支付中」，當貨品金額直接從支付寶扣款後，大門才會開啟。整個交易過程，毋須掃碼付款，毋須牽涉收銀員；離開商店後，顧客手機便會收到付款資訊。

免除人工成本，無人超市的成本約為傳統超市的四分之一，每天只須早上補貨便可營運，平均一名補貨員，可以同時管理10間無人超市，這對傳統超市和零售行業造成巨大衝擊。

馬雲與娃哈哈集團董事長宗慶後亦聯手宣布，未來幾年，將在全國開展10萬間無人超市。當淘寶網上消費攻陷線上的消費模式，讓傳統批發零售消費鏈重新定位，買家更可直接與賣家溝通，當中無時差或地域界限；現時無人商店的實現，連線下的消費模式也將推翻，而且無人超市只是無人商店整個消費文化的一個開端，透過無人商店，營運者搜集大量交易數據，了解不同顧客群的個人消費模式，什麼時候在什麼店舖，用多久的時間，挑選哪一類型的商品……個人的消費模式將由營運者掌握。

了解受歡迎的貨品，減少囤貨，或是策略性地展示貨物，可提高營業額；根據不同消費群的喜好，度身設計配合他們口味的優惠，直接透過手機程式傳達到消費者手上，哪位營銷商能夠利用數據，掌握技術，便可大大增加市場的佔有率和盈利。無人超市預示商場設計的重新定位，例如零售商店可免設收銀處，只須在入口和出口加設相關的感應器，一切運作也變成全自動。

透過BIM 成本大減

網上購物佔了重要的板塊，實體店也是線上消費的延伸。網上購物，可到實體店試身或退還貨物，商場的禮賓師由Pepper機械人取代，美食廣場和餐廳也由機械人送餐。建築業也是看到機械人的普及，可改變工人短缺的長期問題；美國的砌磚機械人由一條傳輸帶、一個機械臂和一個混凝土泵組成，它能把磚拾起，混上沙漿，然後把它們有序放在一起，每天能砌成800至1200塊磚：相反，每名工人只能完成300至500塊磚。

3D打印技術成熟，美國已有3D打印公司在俄羅斯用了24小時建成一間400平方呎的獨立屋，成本大約只需8萬港元；做法是以3D打印混凝土結構部分，完成後移走打印機，裝上保溫層、窗戶和天花等。

不要只談外國的例子，香港的建築業也興起使用建築資訊模型BIM。建築顧問團隊跟承建商以電腦模型，在虛擬世界展示整個建築過程，於設計初期能夠大量減少設計、結構或機電配置的各種錯誤。電腦系統利用衝突檢測功能，以圖示告知團隊有關各類建築構件在三維空間衝突的詳細資訊，而且全是自動化，製作施工圖便能更加快捷、便利和準確。

透過BIM，建築工期也能大大節省，由於所有設計圖俱備，各項目的不協調已於設計時預計，到真正施工，便可減低傳統打拆重做或是夾圖的時間。不過，面對香港一邊起一邊改的建築文化，BIM也許未能發揮最大功能。

改變也得循序漸進，香港不是每間建築師樓也擁有BIM團隊，承建商亦然；不少項目均是採取局部利用BIM技術預視建築期間的衝突，從而減少建築費。

不少設計、製作施工圖，到生產物料興建，日後管理維修等等，也利用BIM協助；面對嶄新的科技發展，建築設計行業也得與時並進，房屋署並是支持BIM發展的重要一員。

待建築機械人和3D打印技術發展更加成熟後，不難想像，日後香港的建築界將會有如無人超市的突破性發展。

陳雅妍_香港建築師學會會員

文章只代表個人意見，不代表香港建築師學會立場。

Infoman

兒童電影家教陶傑

香港兒童心智精神狀態公認很有問題。全球化的網絡資訊和手機遊戲奪走了兒童的魂魄，不太認識父母的容貌。少數尖子，則變成讀書機器，年幼老積。荷里活電影3D特技，不重故事，經營畫面山崩地裂的爆炸和地震海嘯的末日，令小孩像人工孵化場電燈泡和溫度計工業孵出來的小雞，供家鄉雞和麥當勞消費，早就沒有了走地雞，也就沒有了童真，香港還剩下多少真正的兒童，是一個很有趣的問題。在圓方看見兒童電影節，嚇了一跳。「兒童電影」是一個正在消失的類別。「蜘蛛俠」和「美國隊長」不是真正的兒童電影。兒童電影除了要有電腦特技和綠布景的敍事方式，還要有適合兒童的主題：純真、善良、友誼，以及一切的美好（Kindness）。譬如同樣有兒童文學家達爾小說改編的「朱古力工廠」，主角是一個叫威利王卡（Willy Wonka）的朱古力工廠掌門人，邀請兒童參觀他的朱古力魔幻世界。七十年代的電影版本，英國製作，上一代的喜劇演員真懷德飾演朱古力掌門人，電影沒有電腦特技，色彩繽紛的影棚佈景，今日看來，品味和風格，都屬於上一代，但顏色的配搭、線條的設計，都與電腦時代不同。父母要與子女溝通，不妨帶他看從前的兒童電影。帶他看了真懷德的舊版，再讓小孩看美國鬼才導演添布頓和Johnny Depp的新版，叫小孩比較三十年同一個故事，兩般的表述方式，叫他告訴父母，或者寫一篇小影評，講一講有什麼不同。新版的朱古力魔幻之王，雖然俊朗很多，但一張臉好像整了容，木無表情。真懷德那個造型比較像早期的麥當勞叔叔，直接與兒童有親切現實的對話。而添布頓版的那一齣，主角比較像一個機械人。雖然美工更為大膽，喧紅配鬧綠，紫衝艷黃，刻意撞顏色，這一點，也需要父母引導子女觀察。商場的自由行少了，靜一點，有一個夢幻遊戲角。VR完了海底世界，要接觸一下真人，學畫畫、聽故事。紅樓夢裏也有風月鏡中的太虛幻境，賈寶玉最終要走出來，觸摸到丫鬟襲人。通識是從小培養的：文學的敍述、美術的影像、音樂又如何將文字和影像連結起來。這一切，都在前電腦時代的兒童電影裏找得到。問題是連父母也失憶了，也沒有這般視野，教出來的小孩，前半截不行，後半截只能送英國寄宿學校，讓英國人替貴子弟補課了。

Infoman

Lingofad - cvid learning

xmpp - realtime teaching / student / teacher mgt

Option 1 Homework based learning

1) Student asks questions upon need

2) All the learning process will be recorded.

3) student can choose either cvid or realtime teaching according to their need.

Option 2 School based online teaching

1) School, headteacher provide some guidelines/ core content input to the cvid

2) teacher bases on the input (including the headteacher and students) to tailor made the contents. The content will be adjusted every year.

3) an admin bot ( or a TA before the bot) put the contents to be followed by students according to the predefined learning schedules.

4) student learns the content at class even with some VR

Infoman

Baby boss

Infoman

無人能DQ的 - 畢明

名采論壇

法新社圖片 Bel19ve。自那天起，他的名字旁邊又多了新徽號，像打敗虎的武松，和除三害的周處，他襟前非凡的姓名前後還添加了：“bel19ve”。「相信19」，把19嵌入了相信，摘下職業生涯第19個大滿貫，到20時相信還會創造出另一個新字。他在創造歷史，或者應該說，他又再開創歷史，無人能DQ他的王位。 2017年7月16日之後，他還被奠基為#GOAT - Greatest Of All Time，我打令：費達拿#GOAT。他贏了，我會收到賀電，恭喜賀喜，四方八面是小鳳姐。11度打入溫布頓決賽， 8次取得冠軍，前無古人；第19個大滿貫，男子組無人能及的紀錄，且以不失一局的完勝姿態直搗決賽兼攻下冠軍，是自1976年波格在溫網橫掃每一輪比賽之後，41年來首次有第二人能分毫不損進入決賽，但當年波格20歲，他差一個月36。李白《司馬將軍歌》：「手中電擊倚天劍，直斬長鯨海水開。」是這種氣勢，是這種氣魄。溫布頓決賽，他的對手再不是以前的勁敵，拿度敗走，梅利、祖高域傷出退賽，剩他寂寞獨領風騷。可想過，這個未完的傳奇，至今從未在任何比賽中途退出，一直堅持把每場球賽打完。今次，他的最後一個攔路虎甚至不是「第五天王」華連卡，是第一次殺入決賽的Cilic，本來也不是慳電的燈一枚，但出閘脫腳，結果整場冠軍戰絲毫未能威脅費天王，無驚無險，衝線終點。沒有鬼哭神嚎日月無光風蕭水寒，沒有「百戰沙場碎鐵衣……獨領殘兵千騎歸」的壯懷激烈，一樣有三十功名塵與土，八千里路雲和月。絕不能說今次的稱王、那夜的勝戰不轟烈，來得絕非輕易。35歲的高齡，去年才動過手術停賽半年的傷膝，後浪似虎，同代如狼，個個想撕下他的優雅作為戰利。贏費達拿，永遠是履歷的星章，這個「昔日」王者早滿身刀傷，化成鍛造他再登寶座的燃料，今日再接受萬世歡呼。今年年頭兩挫宿敵剋星拿度，那個篡他位的強橫刺客，又被後浪祖高域淹過，被最佳隊友華連卡打敗，從頂峰摔下，他已被太多人否定過，被自己質疑過，但我早寫過「他知道自己的故事未完，他創造自己的傳奇未完。處逆境，不喪志，中強矢，能怒飛，這一振翅高飛，復仇是甜蜜的，揚眉是吐氣的，那口氣，屈了十年，你以為『千古江山，英雄無覓』，他的風流已被雨打風吹去，他以一口再奪冠之浩氣，告訴世人『想當年，金戈鐵馬，氣吞萬里如虎』，今天不負當年。」好一個千古風流人物，在溫布頓場上，翠草白衣，一扣一剔一反一挑一殺，優雅中不失狠辣，把一路上的對手Dimitrov、Raonic、Berdych修理得七個一皮。潛台詞是「大叔我還未玩夠，你哋彈開先」。一次出征大捷不因最後一圈再無車緊貼，或者最後一個欄不夠高做成驚險而小看衝線的光輝。費達拿的低潮是舉世見證的，正如他今年的強勢回歸，球王在逆境中仍然相信、仍然改進，真正做到：「假如當所有人都懷疑你，你仍然能相信自己，但繼續讓別人懷疑；假如你能夠等待，而不會被等待磨蝕……」（If you can trust yourself when all men doubt you, But make allowance for their doubting too. If you can wait and not be tired by waiting……）做到溫布頓Centre Court球員入口處高高在上的銘刻，英國諾貝爾文學獎得主 Rudyard Kipling一首《If》的詩句："If you can meet with Triumph and Disaster, And treat those two impostors just the same"。費達拿為什麼與眾不同？除了天才、觸覺、技術和球品。他發球，慢慢逐格播出，是罕有地可以把視線看着對手最久至最後一刻才移走上望擊球的，容許他比誰都更準確的決定發球戰略。

他早就高瞻遠矚預算了自己的生涯要打長線，不要一個突然滑落不可挽回的晚期，他早就嚴格保養好自己的身體，和物理治療師還有訓練員Pierre Paganini積極管理好比賽行程，不讓自己比賽過度、折損太深。他的長遠視野和不爭一時的野心，比任何球手都更顯王者胸襟，才能在王朝末段，兩奪大滿貫。

我懷疑以拿度、梅利、祖高域的打法，當身體少壯不再，傷患囤積後油缸還能走多久。

費達拿為什麼與眾不同？他也試過「天山雪後海風寒」「烽火城西百尺樓」，但他重新上路，練習用新球拍、連身形體能都還在進化。如果你有留意，如今的他，比早些年還要結實瘦壯。他的戰事未完，他的故事未完。

“The two most powerful warriors are patience and time” - Leo Tolstoy 杜牧的《題烏江亭》：「勝敗兵家事不期，包羞忍恥是男兒。江東子弟多才俊，捲土重來未可知。」且看比費達拿年輕的拿度祖高域梅利35歲時如何，職業生涯晚年如何，江山如此多嬌，但幾個男兒是丈夫。

Infoman

「債王」格羅斯（Bill Gross）警告，各地央行陸續收緊貨幣政策，或危及全球經濟復甦，由於個人和企業負債皆持續增加，短期息率毋須大幅調升，也能引發衰退，故提醒央行及投資者要審慎。

Infoman

(摘自信報作者張公道）

港人受到外國的低廉樓價所吸引，一些人希望在外國置業，而坊間亦有很多展銷會及廣告，介紹海外樓盤。

根據區區觀察，很多買家都遇上種種問題，只要留意傳媒報道，有關買家如何收不到樓，投訴無門等，便知一二。有關海外置業，應注意︰

第一，在舉世資金泛濫下，樓盤倘真是筍貨，本地人早已搶購，何須遠銷海外。第二，港人對當地的法律及相關法規一無所知，例如各種稅項、對住客的保障（假如作收租之用）及資金的流出流入有否限制等，隨時會跌落陷阱。

第三，在展銷會的介紹，經紀一定把樓盤描述得美輪美奐，位置優越，交通便利，容易租出，以及升值潛力龐大等，抵受不住誘惑者，便很易下注。第四，港人對代理商或經紀所說的地產商一無所知，若然是騙局，隔山追騙下，成功機會極微，即資金凍過水。即使確為地產商興建，但收樓之時發覺貨不對辦，亦非常麻煩，內地便曾爆出多宗新聞，但即使在英國亦有同類事件發生。

有金融界的朋友指出，一些港人無法在港買樓，於是轉往海外，此言或許有點勢利，但此類買家更應注意，倘若在香港無買過樓，更易墮入陷阱。愚見認為，

無論在何處置業，皆必須親往看看，最好樓宇已落成，有現樓看，更為穩健。

那麼，樓宇所在的區域、周圍的環境、樓宇的質素，心中有數；同樣重要的是，可與當地人士交流一下，認識各種法例，了解發展商的聲譽及作風，以及在當地的律師樓簽約，則一切有保障得多。即使在當地無親友，亦可藉着與其他當地人士交談，了解一些實情。在展銷會內聽經紀的介紹後，即行簽約，風險甚高。

hkaee1@gmail.com

Infoman

XMPP Advantages ( From book XMPP Definited Guides)

The Extensible Messaging and Presence Protocol (XMPP) is just such an open technology for real-time interaction. Consider some of its advantages:

■ XMPP is proven.

Over 10 years of development has resulted in a stable, widely deployed,seriously tested, Internet- scale technology, with dozens of interoperable codebases, tens of thousands of deployed services, and millions of endusers.

■ XMPP is secure.

It provides built-in support for channel encryption and strong authentication, inherent resistance to many forms of malware, a diverse ecosystem of implementations, a decentralized used in XMPP solves serious scaling problems associated with traditional HTTP-based polling approaches ; as a result, it enables you to build applications that were literally impossible until now.

■ Xmpp is a standard.

The core aspects of XMPP have undergone rigorous public review withinthe Internet Engineering Task Force (IETF), and extensions to XMPP are published in an open, developer-oriented standards process run by the XSF. This approach has resulted in strong technologies that can be freely implemented under any licensing terms, from open source to shareware to proprietary code.

■ XMPP is a community.

Open standards, a large number ot software products, and a communications network are all good, but the "secret sauce"of XMPP maybe its vibrant and friendly community of technology , developers, open source projects, commercial software companies, service providers, and end users. This community is committed to working together to solve problems and build great new applications.

Infoman

Yesterday, a hacker pulled off the second biggest heist in the history of digital currencies.

Around 12:00 PST, an unknown attacker exploited a critical flaw in the Parity multi-signature wallet on the Ethereum network, draining three massive wallets of over $31,000,000 worth of Ether in a matter of minutes. Given a couple more hours, the hacker could’ve made off with over $105,000,000 from vulnerable wallets.

But someone stopped them.

Having sounded the alarm bells, a group of benevolent white-hat hackers from the Ethereum community rapidly organized. They analyzed the attack and realized that there was no way to reverse the thefts, yet many more wallets were vulnerable. Time was of the essence, so they saw only one available option: hack the remaining wallets before the attacker did.

By exploiting the same vulnerability, the white-hats hacked all of the remaining at-risk wallets and drained their accounts, effectively preventing the attacker from reaching any of the remaining $77,000,000.

Yes, you read that right.

To prevent the hacker from robbing any more banks, the white-hats wrote software to rob all of the remaining banks in the world. Once the money was safely stolen, they began the process of returning the funds to their respective account holders. The people who had their money saved by this heroic feat are now in the process of retrieving their funds.

It’s an extraordinary story, and it has significant implications for the world of cryptocurrencies.

It’s important to understand that this exploit was not a vulnerability in Ethereum or in Parity itself. Rather, it was a vulnerability in the default smart contract code that the Parity client gives the user for deploying multi-signature wallets.

This is all pretty complicated, so to make the details of this clear for everyone, this post is broken into three parts:

What exactly happened? An explanation of Ethereum, smart contracts, and multi-signature wallets. How did they do it? A technical explanation of the attack (specifically for programmers). What now? The attack’s implications about the future and security of smart contracts. If you are familiar with Ethereum and the crypto world, you can skip to the second section.

There are three building blocks to this story: Ethereum, smart contracts, and digital wallets.

Ethereum is a digital currency invented in 2013 — a full 4 years after the release of Bitcoin. It has since grown to be the second largest digital currency in the world by market cap — $20 billion, compared to Bitcoin’s $40 billion.

Like all cryptocurrencies, Etherium is a descendant of the Bitcoin protocol, and improves on Bitcoin’s design. But don’t be fooled: though it is a digital currency like Bitcoin, Ethereum is much more powerful.

While Bitcoin uses its blockchain to implement a ledger of monetary transactions, Ethereum uses its blockchain to record state transitions in a gigantic distributed computer. Ethereum’s corresponding digital currency, ether is essentially a side effect of powering this massive computer.

To put it another way, Ethereum is literally a computer that spans the entire world. Anyone who runs the Ethereum software on their computer is participating in the operations of this world-computer, the Ethereum Virtual Machine (EVM). Because the EVM was designed to be Turing-complete (ignoring gas limits), it can do almost anything that can be expressed in a computer program.

Let me be emphatic: this is crazy stuff. The crypto world is ebullient about the potential of Ethereum, which has seen its value skyrocket in the last 6 months.

The developer community has rallied behind it, and there’s a lot of excitement about what can be built on top of the EVM — and this brings us to smart contracts.

Smart contracts are simply computer programs that run on the EVM. In many ways they are like normal contracts, except they don’t need lawyers or judges to interpret them. Instead, they are compiled to bytecode and interpreted unambiguously by the EVM. With these programs, you can (among other things) programmatically transfer digital currency based solely on the rules of the contract code.

Of course, there are things normal contracts do that smart contracts can’t — smart contracts can’t easily interact with things that aren’t on the blockchain. But smart contracts can also do things that normal contracts can’t, such as enforce a set of rules entirely through unbreakable cryptography.

This leads us to the notion of wallets. In the world of digital currencies, wallets are how you store your assets. You gain access to your wallet using essentially a secret password, also known as your private key (simplified a bit).

There are many different types of wallets that confer different security properties, such as withdrawal limits. One of the most popular types is the multi-signature wallet.

In a multi-signature wallet, there are several private keys that can unlock the wallet, but just one key is not enough to unlock it. If your multi-signature wallet has 3 keys, for example, you can specify that at least 2 of the 3 keys must be provided to successfully unlock it.

This means that if you, your father, and your mother are each signatories on this wallet, even if a criminal hacked your mother and stole her private key, they could still not access your funds. This leads to much stronger security guarantees, so multi-sigs are a standard in wallet security.

This is the type of wallet the hacker attacked.

So what went wrong? Did they break the private keys? Did they use a quantum computer, or some kind of cutting-edge factoring algorithm?

Nope, all the cryptography was sound. The exploit was almost laughably simple: they found a programmer-introduced bug in the code that let them re-initialize the wallet, almost like restoring it to factory settings. Once they did that, they were free to set themselves as the new owners, and then walk out with everything.

What follows is a technical explanation of exactly what happened. If you’re not a developer, feel free to skip to the next section, since this is going to be programming-heavy.

Ethereum has a fairly unique programming model. On Ethereum, you write code by publishing contracts (which you can think of as objects), and transactions are executed by calling methods on these objects to mutate their state.

In order to run code on Ethereum, you need to first deploy the contract (the deployment is itself a transaction), which costs a small amount of Ether. You then need to call methods on the contract to interact with it, which costs more Ether. As you can imagine, this incentivizes a programmer to optimize their code, both to minimize transactions and minimize computation costs.

One way to reduce costs is to use libraries. By making your contract call out to a shared library that was deployed at a previous time, you don’t have to re-deploy any shared code. In Ethereum, keeping your code DRY will directly save you money.

The default multi-sig wallet in Parity did exactly this. It held a reference to a shared external library which contained wallet initialization logic. This shared library is referenced by the public key of the library contract.

// FIELDS address constant _walletLibrary = 0xa657491c1e7f16adb39b9b60e87bbb8d93988bc3; The library is called in several places, via an EVM instruction called DELEGATECALL, which does the following: for whatever method that calls DELEGATECALL, it will call the same method on the contract you're delegating to, but using the context of the current contract. It's essentially like a super call, except without the inheritance part. (The equivalent in JavaScript would be OtherClass.functionName.apply(this, args).)

Here’s an example of this in their multi-sig wallet: the isOwner method just delegates to the shared wallet library's isOwner method, using the current contract's state:

function isOwner(address _addr) constant returns (bool) {
return _walletLibrary.delegatecall(msg.data); } This is all innocent enough. The multi-sig wallet itself contained all of the right permission checks, and they were sure to rigorously enforce authorization on all sensitive actions related to the wallet’s state.

But they made one critical mistake.

Solidity allows you to define a “fallback method.” This is the method that gets called when there’s no method that matches a given method name. You define it by not giving it a name:

Infoman

評：最後·觸及根本的問題，作為創作型作家，你認為虛構藝術的功能何在?為什麼要表現現實而不是寫事實本身? 海：幹嘛為這個感到困惑?從已發生的事情,從存在的事情，從你知道的事情還有你不知道的那些事情，

通過你的虛構創造出東西來,這就不是表現,而是一種全新的事物·比任何東西都真實和鮮活·是你讓它活起來的。

如果你寫得夠好，它就會不朽。

你是為此而寫,並不是為了你所知的別種原因。更何況是那些沒人想得到的理由?(苗焯/譯) (原載《巴黎評論》第十八期·一九五八年春號)

Infoman

評: 你有一次在信中告訴我·在簡陋環境下寫出小說的不同片段，對作家是有益的·你能用這個來說說〈殺人者〉嗎?你說過·這個小說·〈十個印第安人〉和〈今天星期五〉是在一天之內寫成的·或許還有你頭一個長篇小說《太陽照常升起》?

海: 我想想·《太陽照常升起》是我生日那天在瓦倫西亞動筆寫的, 七月十一日。我妻子哈德萊和我提早就到瓦倫西亞，為的是買好位置看鬥牛,節慶到七月十四日才開始。和我年齡相仿的人都寫過一部小說,可我寫上一段還覺得費勁。所以我就在生日那天動筆,整個假日都在寫,早上在床上寫，到馬德里之後接著寫。那裡沒有節慶,我們訂了一個有桌子的房間，我能在桌上寫真是太奢侈了。旅館附近，阿瓦雷茲街上有一個喝啤酒的地方挺涼快的,去那兒寫。最後熱得寫不下去了·我們就去昂達伊(Hendaye)·那裡有片又長又美的沙灘·有一家便宜的小旅館,我在那兒寫得很順。後來又到巴黎去·在聖母院路一一三號一家鋸木廠樓上的公寓裡寫完了第一稿。

從動筆算起用了六個星期。我把初稿拿給小說家阿什(Nathan Asch)看,他有很重的口音，說，「阿海，你說寫了個小說是甚麼意思?一個小說，阿海·你寫的是旅遊書。」

我聽了他的話並沒有待別喪氣,又改寫了這個小說，保留了福拉爾貝格州施倫斯村陶伯旅館的那部分旅途內容。

Infoman

There’s a great MSR demo from 2012 that shows the effect of latency on the experience of using a tablet. If you don’t want to watch the three minute video, they basically created a device which could simulate arbitrary latencies down to a fraction of a millisecond.

At 100ms (1/10th of a second), which is typical of consumer tablets, the experience is terrible. At 10ms (1/100th of a second), the latency is noticeable, but the experience is ok, and at < 1ms the experience is great, as good as pen and paper.

If you want to see a mini version of this for yourself, you can try a random Android tablet with a stylus vs. the current generation iPad Pro with the Apple stylus. The Apple device has well above 10ms end-to-end latency, but the difference is still quite dramatic – it’s enough that I’ll actually use the new iPad Pro to take notes or draw diagrams, whereas I find Android tablets unbearable as a pen-and-paper replacement.

You can also see something similar if you try VR headsets with different latencies. 20ms feels fine, 50ms feels laggy, and 150ms feels unbearable.

Infoman

Google today announced the launch of Hire, a new service that helps businesses more effectively manage their internal recruiting process. Hire offers businesses a cohesive applicant tracking service that’s deeply integrated with G Suite to make it easier for businesses to communicate with their candidates and track their progress through the interview process.

Earlier this year, Google launches its Google for Jobs initiative and its job search feature in Google Search to help job seekers find the right job for them. Now it it launching this new tool to help businesses manage their candidates. The missing piece here is giving businesses tools for managing job posting — and maybe posting them directly to Google’s new jobs widget in Search. As the company pointed out when it launched its AI-powered job search engine, though, it has no interest in doing this and is instead partnering with major online job boards instead.

Google says Hire is meant to help businesses do away with manually tracking candidates. “Hire and G Suite are made to work well together so recruiting team members can focus on their top priorities instead of wasting time copy-pasting across tools,” Google product manager Berit Johnson writes in today’s announcement.

While Hire itself is interesting in its own right, it’s also interesting to see that Google is now looking to use the G Suite tools and back-end services it has developed over the last few years to solve problems in very specific verticals. I wouldn’t be surprised if the company decided to launch more of these projects now that it has the foundation in place to do so.

Infoman

Posts by Infoman

GNU Ring 1.0 released

How I tried to get into game development and failed

Inception

Until last year.

I don’t know if you are familiar with this phenomenon of io games, so let me give you a quick explanation. Up until maybe 2014 or so game development meant one of a couple options (although, I’m not into this industry much, so might be wrong on that).

There’s also an option of mobile gaming but the competition there is even harsher than on PC nowadays.

And here came the io games which provided a unique combination.

They are simple, even trivial to play, but not so easy to master so there’s some learning curve involved.

So, as you can see, the effort required to build an io game is not much higher than it is to develop a typical flash game. Unlike typical flash games, though, an io game can potentially attract more players because of the multi-player aspect.

And what about the potential outcome? This is where the things start to become very interesting.

In July 2016 I read this article about slither.io. It says that the author of this game pulls more than $100,000 in revenue daily. A hundred. Freaking. Thousand. A day.

Me after reading the article

I decided that it was time to act. I figured that even if the article is off by 2 or even 3 orders of magnitude, I would still be doing very well should I develop something similar. So here began my game development journey.

The idea

I had lots of ideas for the game from my past failed attempts. Most of them revolved about strategy and MMO RPG games. That’s because I personally prefer strategies (such as Civilization) over action/arcade type of games.

However, I decided not to go this route as the game logic would be too complex to implement and thus the whole endeavor would become too risky. It’s hard enough to dive into a completely unfamiliar field; taking on additional hurdle of working on a complex game would add up unnecessary risk.

The resulting game turned out to be not as simple as I expected, just as any other project would with that many of unknown variables. But I’m getting ahead of myself.

Moving forward, TypeScript proved itself as a good choice. The thing I like the most about it is optionality of its type system. You can always fall back to the plain Javascript where needed.

As for the server side, the choice was pretty clear to me as well. I was going to use C#. At the time I started the development (August 2016), .NET Core wasn’t mature enough, had no out-of-the-box WebSockets support, and so I stuck to the “big” .NET Framework.

Proof of concept

I quickly developed a prototype in order to check the fundamental assumptions and the technology stack. Here’s what it looked like:

The two red squares represented robots. You could enter the game by visiting the game’s front website and have a “robot” assigned to you. You could move the square around and see other players’ movement.

Everything looked good overall, and so I moved on to step 2: finding a partner. I knew that taking this endeavor on my own would mean longer development time, more problem with unfamiliar technologies, and, therefore, additional risk.

I brought up these two games for a reason. There are interesting stories behind the way they implemented their multi-player modes.

So the difference between LAN and WAN is that it’s very easy to create a responsive and fast multiplayer game where all players are connected via LAN. And it’s not so easy to do that when playing via the Internet.

Multi-player mode implementation

This works due to the fact that the LAN connection is super fast. You can send tons of messages to each other and the delay would be unnoticeable. Which is perfect as it enables very simple programming model.

The situation changes when you start communicating via the Internet. You no longer can just make the player wait while the messages make a full circle before showing the effect of their actions. This would make the game virtually unplayable.

For the enemy actions, there’s no way you can do any kind of prediction as the only information you have about them is the one you receive from the server. The problem here is that this information itself comes with a delay because of the time the message needs to travel from the server to you.

Overall, though, it’s a small price to pay for the opportunity to get better user experience in the face of slow Internet connection.

And for the bullets, we used extrapolation. Which means that the client simulated the position of the bullet in the future and displayed it a little bit ahead of the actual position received from the server.

Issues with client garbage collection

So, getting back to our story timeline. In parallel with the compensation mechanism, we worked on issues that arose on the client. The game delivered good 60 FPS for the first minute or two but then the rate plummeted to 10 or even 5 PFS. Which was an obvious show stopper.

Note the set method. I wouldn’t recommend anyone to use this practice in a typical enterprise application 🙂

Issues with server garbage collection

I rechecked the math, double checked all prediction rules, tried to change them, but nothing of that helped. Then we turned to the server. Added excessive logging to catch exactly when that happened, started monitoring CPU and memory usage and sure enough, the pattern soon emerged:

Issues with server garbage collection

This was a VM in Azure which we used as our test game server. Note that on that picture, the server was handling a single game with no players connected to it. So it’s not that we were overloading it or something.

We tried to tame the garbage collector, tried to tweak its settings, increase and decrease the time between its executions, nothing helped.

After days of trial and digging into the WebSockets implementation, we decided that enough is enough. Screw it, we were going to rewrite our server in NodeJs.

Note that it was the exact same code converted from C# into TypeScript, the implementations were identical. We just copied .cs files into .ts ones and fixed the compiler errors. The only exception was the WebSockets implementation, we used one of the NodeJs libraries for that.

Change of game concept

無人超市

無人商店的概念並非馬雲首創，Amazon推出Amazon Go、日本Lawson或是上海的「繽果盒子」也有類似的銷售模式。

Lawson的技術是，顧客把產品放進特製購物籃，偵測籃中的貨物，並自動計算價錢，顧客只須把籃子放到收銀台，籃底會打開，貨物便會跌進下層的購物袋裏，顧客便可直接帶走。

另一邊廂，Amazon Go的技術則採用大量鏡頭和感應器，觀察顧客的一舉一動，並於顧客把貨物拿下貨架時已能知道價錢，省卻收費過程。

馬雲推出的無人超市運作模式是，當顧客進入商店前先要開啟手機的淘寶程式，掃一掃門口的二維碼，連接手機的支付寶，店門便會自動打開，顧客入店後可以自由選購貨品，跟傳統的超市沒什麼分別。

兒童電影家教 陶傑

Lingofad - cvid learning

xmpp - realtime teaching / student / teacher mgt

Option 1 Homework based learning

Option 2 School based online teaching

費達拿為什麼與眾不同？他也試過「天山雪後海風寒」「烽火城西百尺樓」，但他重新上路，練習用新球拍、連身形體能都還在進化。如果你有留意，如今的他，比早些年還要結實瘦壯。他的戰事未完，他的故事未完。

「債王」格羅斯（Bill Gross）警告，各地央行陸續收緊貨幣政策，或危及全球經濟復甦，由於個人和企業負債皆持續增加，短期息率毋須大幅調升，也能引發衰退，故提醒央行及投資者要審慎。

無論在何處置業，皆必須親往看看，最好樓宇已落成，有現樓看，更為穩健。

XMPP Advantages ( From book XMPP Definited Guides)

■ XMPP is proven.

■ XMPP is secure.

■ Xmpp is a standard.

■ XMPP is a community.

Yesterday, a hacker pulled off the second biggest heist in the history of digital currencies.

There are three building blocks to this story: Ethereum, smart contracts, and digital wallets.

This leads us to the notion of wallets. In the world of digital currencies, wallets are how you store your assets. You gain access to your wallet using essentially a secret password, also known as your private key (simplified a bit).

There are many different types of wallets that confer different security properties, such as withdrawal limits. One of the most popular types is the multi-signature wallet.

通過你的虛構創造出東西來,這就不是表現,而是一種全新的事物·比任何東西都真實和鮮活·是你讓它活起來的。

如果你寫得夠好，它就會不朽。

從動筆算起用了六個星期。我把初稿拿給小說家阿什(Nathan Asch)看,他有很重的口音，說，「阿海，你說寫了個小說是甚麼意思?一個小說，阿海·你寫的是旅遊書。」

我聽了他的話並沒有待別喪氣,又改寫了這個小說，保留了福拉爾貝格州施倫斯村陶伯旅館的那部分旅途內容。

At 100ms (1/10th of a second), which is typical of consumer tablets, the experience is terrible. At 10ms (1/100th of a second), the latency is noticeable, but the experience is ok, and at < 1ms the experience is great, as good as pen and paper.

You can also see something similar if you try VR headsets with different latencies. 20ms feels fine, 50ms feels laggy, and 150ms feels unbearable.

兒童電影家教陶傑