Cara berbagi akun PSN, berbagi library games digital.

Beberapa hari ini saya melihat di OLX Balikpapan, ada beberapa member yang menjual ID PSN yang berisi game digital didalamnya, dan tidak tanggung-tanggung harga yang dibanderol cukup murah untuk satu paket games. Dari sini muncul berbagai macam pertanyaan, apakah ini legal? apakah game bisa dimainkan secara online atau hanya offline? apa konsekuensinya?

Yuk mari kita bahas, saya akan mencoba menjabarkan sesingkat mungkin, dan konten yang saya bahas hanya untuk seputaran berbagi akun untuk console PS4 saja.

Pertanyaan pertama : Apakah game yang dishare itu legal? atau tidak melanggar ketentuan dari Sony?

Jawabannya adalah legal, sebenarnya pihak Sony memperbolehkan kita untuk melakukan share akun PSN ke maksimal 2 console PS4 dan itu merupakan hal yang murni dilegalkan, namun hal ini dalam cakupan digunakan dalam hubungan keluarga, jadi Sony memperbolehkan membeli 1 game dan bisa dimainkan oleh 2 console milik 2 anggota keluarga yang berbeda misal si kakak, adik, dan ayah dalam satu keluarga dan satu rumah. jadi total ada 3 console yang secara legal bisa memainkan game tersebut. *TOS dari Sony akan selalu diperbarui sampai Oktober 2018 kita masih bisa share ID

Namun dalam kasus di atas tentunya sudah banyak diselewengkan, share akun PSN ke teman, orang tidak dikenal dan bahkan di jual belikan ke orang lain, makanya hal ini menjadi sedikit "abu-abu" dan jujur pihak Sony pun kesusahan untuk mengontrol hal ini. Dan untuk penjual ID kita tidak tau ID tersebut sudah dijual ke berapa user, dan inilah sebenarnya yang jadi masalah, karena kita tidak kenal jadi kita tidak tau, jika ID tersebut dibagikan ke banyak user ini yang akan menjadi masalah di kemudian hari, Sony akan mendeteksi kalau ID tersebut telah digunakan oleh lebih banyak console dan selanjutnya kita tidak tau apa yang akan terjadi, bisa ke banned atau gamenya di lock/ di tarik, kita tidak tau. Jadi untuk hukum jual beli akun PSN temen-teman bisa menilai sendiri apakah itu termasuk legal atau ilegal.

Pertanyaan kedua : Apakah game yang dishare bisa dimainkan secara online bersamaan atau harus offline?

Jawabannya game yang sudah dibagi ke 2 console tentunya bisa dimainkan secara online, baik itu secara bersamaan dalam waktu yang sama. Dan jika game itu game offline, game tersebut tetap bisa kita mainkan tanpa harus terhubung di internet terus menerus, setelah game tersebut selesai di download.

Just for information aja untuk temen-teman ada satu metode lagi, yakni share ID secara benar-benar ILEGAL, dan ini bisa dilakukan ke banyak console secara tidak terbatas, namun syaratnya kita tidak boleh sama sekali terkoneksi dengan internet, jika kita terkoneksi maka semua gamenya akan tergembok dan tidak bisa dimainkan lagi.

Pertanyaan ketiga: Apakah semua DLC dan konten berbayar dari game yang sudah di beli di akun yang di share juga bisa di download di mesin lain?

Jawabnya tidak semua DLC bisa di share, yang jelas premium avatar, in game money seperti di uang cash di game GTA 5, Fifa Coin dan sejenisnya tidak bisa di share ke akun lain, aksesoris dalam game MMO juga tidak bisa di share.

Pertanyaan Terakhir : Bagaimana cara share akun PSN ke orang lain?

Untuk share ID PSN sebenarnya cukup mudah sekali, pada menu utama PS4 sebelum login atau pada menu setting kita tinggal buat login/sign in id baru, yang kita perlukan adalah USERNAME dan PASSWORD dari akun yang mau di share, kalau kita sudah login ke akun tersebut dan melakukan Set As Primary PS4 maka otomatis kita bisa mengakses library games yang pernah dibeli dari akun tersebut, dari sini kita bisa bisa men download game yang ada di library, jika sudah selesai di download kita bisa memainkan game tersebut secara online atau offline. biasanya setelah proses ini pihak penjual ID akan mengganti password dari akun tersebut, supaya kita tidak bisa membagikan username dan password dari id tersebut ke orang lain lagi.

Free games dan layanan PS+ juga bisa ikut di share ya temen-temen, jadi kita bisa membeli PS+ di region 3 yang lebih murah dan menggunakan free games atau layanan onlinenya di akun primary kita misal region 1.

Kesimpulannya adalah, dengan berbagi akun PSN ini sebenarnya membeli game digital menjadi lebih murah karena 1 harga di bagi menjadi 3, asal 3 orang teman kita ini berkomitmen dan tidak meng share lagi ID tersebut ke pihak ke 4 dst. Sebenarnya hal ini cukup menguntungkan kita dari pihak konsumen, dan jujur sebenarnya share akun PSN ini tidak terlalu di expose beritanya ke khalayak ramai, dan terkesan "sedikit" ditutup-tutupi oleh pihak Sony, tau sendiri lah, Sony tentunya mau meraup keuntungan sebesar-besarnya dari kita para konsumennya. Share id PSN juga sangat menguntungkan untuk teman-teman yang menggunakan untuk usaha rental PS4.

Contoh kasus :
1. Mesin 1 : ID Utama yg beli PES2019/FIFA2019 deactive as primary
2. Mesin 2 : ID Kedua yg di share set as primary

3. Mesin 3 : ID Ketiga yang di share set as primary

Namun bagi sebagian orang saya yakin pasti ada perasaan kurang 'Puas' tidak 'Srergg', muncul semacam semacam ketakutan dll, karena bisa jadi akun yang kita beli akan bocor, dipakai orang lain dll. Sebenarnya sih secara hakiki baik itu kita beli game secara fisik atau digital, kita sebagai pengguna hanya meminjam game tersebut, dan yang memiliki game tersebut secara hukum tertulis ada pihak developer, kita hanya meminjam game dari mereka, Sony cuma sebagai penyedia platforming dan penyedia hardware, jadi ya sama aja library game yang kita punya bisa ditarik oleh developer kapan saja.

Semoga informasinya bermanfaat, syarat dan ketentuan di atas bisa berubah sewaktu-waktu tergantung kebijakan dari pihak Sony. Kalo ada kurang lebihnya saya silahkan di koreksi. Dari ini kita jadi lebih tau lagi bahwa ada cara lain memainkan game secara lebih murah, tanpa membajak console tersebut :)

Read More

March updates: lots of small things

One of my goals this year is to publish in smaller chunks instead of trying to do everything in "one big launch". This is what I've been working on over the past few weeks:

1. I've been learning more about reactive updates, because I think this will make it easier to implement my interactive diagrams, and I think I'll be able to write tutorials more easily. The web has changed a lot since 2010 and I haven't kept up, so now I've been learning a lot about what's now available.


2. I updated my 3D renderer for Mapgen2. I had been developing this for a game that has since been cancelled, so I never finished this project, and didn't publicize it. But it's here if you want to play with it. It's an incomplete 3D render of the maps you can make with mapgen2. I improved the 3D rendering by tweaking the initial settings. I added a seed URL parameter so that once you find a seed you like with mapgen2, you can come to this page and see it in 3D (change rotate_z to spin the map around). And I added an elevation+moisture export. It's all rather rough, and if I get a client that needs something like this, I'll put more effort into it, but for now it only gets minor updates.


3. I updated the implementation of the 2D Visibility article. This was one of my earliest pages, and at the time I had written it with SVG, but found it was too slow on my iPhone and didn't work at all on my Android phone. I rewrote the whole thing with Canvas, which was great, but I made the draggable circles and squares into separate Canvases. I also made the background grid a separate Canvas. Then I had to use absolute positioning to overlay these layers on top of each other. It worked but when I changed my site to have a responsive layout for phones and tablets, it was hard to convert this page. I went through this code and reimplemented the system to use a single responsive-sized Canvas. I also added numeric labels to corners and triangles during the sweep steps, and mouseover effects to give feedback that you're over a draggable item. I also decided that I didn't like the animation and switched it to a slider that lets you control time. I got rid of JQuery, as I no longer needed JQuery-UI to make a slider now that browsers have a native slider control. However the native slider control has some issues on some mobile devices so I tweaked it to make larger and slide better. I built a polar/cartesian animation to help explain the connection to sweep line algorithms, but ended up not using it. Maybe next update.


4. I updated the code generated from my hexagon library procedural code generator. It generates hex grid code in 8 different languages. The original code produced module-level functions. This wasn't a good style for languages like Java and C# that put everything into classes, so I turned those functions into static methods. That's still not the best style, so I spent some time last week making them into instance methods. I also added a class-style Javascript output, since Javascript now has class syntax. I also added invariant testing to make sure that q+r+s == 0 in the Hex class constructor. It's an easy test that can catch some bugs from misunderstanding how cube coordinates work. At some point I'd like to use the generated Javascript code to implement the hexagon page.


5. I've also been investigating ways to make my pages load faster. Right now the text will show up and then after the page loads, it loads the Javascript code, and then that will generate the diagrams, as well as the code to animate and interact with them. It's a noticeable delay with an annoying layout update. It'd be nicer if I could generate the diagrams on the server side, and then the code to animate and interact with them would be on the client. That way the initial diagrams would already be rendered by the time you visit the page, and it would only have to render the subsequent diagrams when you interact with them. My code currently isn't structured to support this, but I'm learning how to structure it to make that work.


6. I played with animation techniques for hexagon grid diagrams. What I do now is kind of annoying to implement. I wanted to try CSS transitions instead; they weren't available when I wrote the hexagon page but they're available now in most browsers. The main idea is that when switching between pointy and flat layouts, the entire grid rotates, but the labels have to rotate in the opposite direction. I should be able to use CSS transforms. I tried out several different animation techniques, with an eye towards getting GPU acceleration with SVGs. My conclusion was what I do is annoying and slow, and I now have an option of annoying and fast, or non-annoying and slow. I'm likely to favor non-annoying. And that me to discover a Safari bug, which I filed on the Safari bug tracker.


7. I started deciphering the RimWorld save file format, because I'd like to use some RimWorld maps as test cases for a pathfinding algorithm I plan to work on. I think it could make a big difference for games like RimWorld. My initial experiments with Dragon Age Origins maps were promising, with significant speedups with very little code. However, I never finished those experiments. I'm hoping RimWorld (one of my favorite games right now) will give me enough motivation to work on this. Now that I think about it, it'd probably be easier to ask Tynan for the map format than for me to decipher it myself…


8. I'm going to the Game Developers Conference later this month so I made new business cards. I have 50 different designs, and 50 rounded-corner cards and 50 sharp-corner cards, so there's only one of each card. If you're at GDC, find me and pick your favorite card. Each one is based on one of my projects and has a story behind it. My goal is to chat with lots of people.

I track my projects on Trello but some of these things aren't “projects” so they aren't on Trello.

Read More

Using Vue with Canvas

In my last post I had said I was trying out some libraries to automatically track dependencies for me. The one I'm playing with right now is Vue.js. It can track dependencies between data and the HTML/SVG elements. For example if I write SVG:

<circle :cx="center.x" :cy="center.y" r="30"/>

and I have it hooked up to data:

data: {
  center: {x: 100, y: 150}
}

then Vue will remember that the circle depends on those x and y properties. If I modify the data with center.x = 75; Vue will detect this and update the circle. This is quite convenient!

Vue only updates DOM elements: HTML and SVG. In some of my articles I use Canvas or WebGL, so I was looking for a way to make Vue work with those. After playing around with a few different approaches, I discovered a clever trick, and I'm writing this blog post to share it.

The first trick, thanks to @JoshWComeau, is to make a canvas component that takes a “draw function”. That way, instead of having to make a new component for each type of drawing, I can reuse the canvas component and pass in a different function each time. Here's an example:

<a-canvas width="500" height="200"
          :draw="(canvas, ctx) => { ctx.fillRect(x,y,1,1); }" />

The second trick, which I found through reading about how Vue works and also experimenting, is to make the draw function's dependencies trigger a redraw. Vue will automatically track dependencies in the DOM elements and also in computed values:

computed: {
    redraw() {
        let canvas = this.$el;
        this.draw(canvas, this.ctx);
    },
}

This will create a data dependency. Since the draw() function depends on x and y, whenever x or y changes, it might affect the value of the draw() function, which might affect the value of the redraw computed property. Great! This automatically sets up the dependency without me having to “subscribe” to x and y like I do with the Observer pattern.

Although I have successfully set up dependencies x → redraw and y → redraw, it's not enough. You see, Vue only looks at the dependencies needed for rendering the DOM. Since I had set up the DOM as <canvas width=… height=…/>, Vue sees that there's no need to compute redraw at all. And that means my draw function never gets called. Doh!

So the third trick is to put the result into the DOM, with <canvas width=… height=… :data-dummyvalue="redraw"/>. Now Vue has a dependency redraw → DOM. Combined with the previous dependencies, whenever x or y changes, it knows it needs to compute redraw, and in doing that it calls my draw() function.

This is great! It's all automatic. If the redraw function had been (canvas, ctx) ⇒ ctx.fillRect(100, 100, w, h) then Vue would redraw the canvas whenever w or h changed. The canvas component doesn't have to change and I never need to explicitly list the dependencies.

There are a few other details. Vue wants to create the canvas with the dummyvalue but to compute the dummyvalue you need to call draw() which needs the canvas. There's a cycle there that needs to be broken. And we also need to trigger a redraw whenever the size changes, so we need to add the width → redraw and height → redraw dependencies. These are handled in the code I put up on gist.

So far I've only used this in a very simple page and it's worked well. I looked around but didn't see any Vue components that worked this way; if you know of any, please post in the comments.

Read More

UCLan Games Alumni 'White Paper Games' featured in both Edge and Games TM Magazines.

In March 2018 double page spreads and interviews with Alumni, Pete Bottomley, Co-Founder of 'White Paper Games'  will be published in BOTH Edge and Games TM magazines chatting about their fascinating stealth thriller game, 
'The Occupation'!

The team, including UCLan Alumni, Pete Bottomley, James Burton, OJ Farrell, Scott Wells-Foster and NJ Apostel are experiencing enormous interest in the launch of their latest game, 'The Occupation' which follows the successful publication and sales of their first game, 'Ether 1.'

We're so proud of their achievements as we see them go from strength to strength, pushing the boundaries of their narrative and skills with each new endeavour.

It's also great to have them as Associate lecturers on the Games Design course at Uclan as their knowledge and industry experience is invaluable for our students to be in tune with current industry requirements.

Pete Bottomley commented that the success of WPG 

"Shows how important the UCLan course was in the development of our team!"

and we replied

"and how important WPG is in the development of our course!"

See further info:
Articles on The Occupation on Steam

Read More

How I implement my interactive diagrams, part 2

In the last post I described how I structure my interactive diagrams and gave some examples. In this post I'll describe what I'd like to do for future diagrams.

When I started writing interactive diagrams I used d3.js, which is a great visualization toolkit. At the time I thought data visualization was the hardest part of what I was doing, and I needed a library for that. Since then, I've seen other libraries — React, Riot, Ember, Mithril, Intercooler, Marko, Vue, Aurelia, Ractive, Rax, Svelte, MobX, Moon, Dio, Etch, Hyperapp, S/Surplus, Preact, Polymer, lit-html, Elm, and many more — that have given me different ways to look at the problem. I've realized that the visualization isn't the hardest part of what I'm trying to do. There are two two big problems I want a library to help me with:

• How do I update the visualization?


• Which algorithms do I need to run again?

For deciding how to update the visualization, there's a spectrum:

1. The simplest thing is to redraw everything from scratch. I use d3 or jquery to remove all the existing SVG nodes, and create new ones in their place. If I'm using Canvas instead of SVG, it's more likely that I'll redraw everything from scratch.


2. If I don't want to redraw everything (for performance reasons), I can use d3.js's data joins to help me figure out which parts of the visualization to add, remove, and update. This is great for many data visualization needs, but a bit overkill for most of my projects.


3. The next simplest thing is to pretend I'm redrawing everything from scratch, but let the system figure out what actually changed, and only update those things. This is the “virtual DOM” approach used in React and other libraries. This approach wasn't available when I first started writing interactive tutorials, and I'm only now catching up.

I've been using approach 2 but will be trying approach 3 for future projects. It's simpler to describe what I want than how I want to get there. Also, since I am writing documents instead of web applications, I prefer to describe the output in document form (html/svg) instead of code form (javascript). However, this is just a preference, and you should follow your own preference.

For deciding which algorithms to run again, including calculating the visualization, there's also a spectrum:

1. The simplest thing is to run everything. Easy!


2. If I don't want to run everything (for performance reasons), I can manually decide what to run based on which input control was changed. This is what I do for most of my projects, but it's error prone. It was especially bad for the hexagon page.


3. I can have the algorithms mark which inputs they depend on, and then when those inputs change, the algorithms automatically run again. I did this somewhat for the A* page, which re-runs graph search when the graph data changes.


4. I can ask the system to track the data dependencies: which controls each input depends on, which inputs each algorithm depends on, and which algorithms each visualization depends on. Then it can automatically update the right things when a control is changed.

I've recently experienced approach 4 with ObservableHQ (see my notebooks), which tracks changes between cells and automatically runs algorithms and visualizations that depend on them. It's quite refreshing! I tried Vue for this unfinished page, and it was a great fit for my needs. I've not yet tried Elm, which seems like the coolest approach for dependency tracking and automatic updates.

I've mostly been using approach 2 or 3 but will be trying approach 1 or 4 for future projects. Tracking dependencies manually, even if using the Observer pattern, is error prone. In approach 2 the controls have to know which inputs are affected, the inputs have to know which algorithms are affected, and the algorithms have to know which visualizations are affected. In approach 3 the visualizations have to declare which algorithms they care about, the algorithms have to declare which inputs they care about, and the inputs have to declare which controls they care about. Approach 3 is better than 2, but both mean I'm constructing the dependency chain. I'd rather not have to do that. So my options are either not to worry about it, or to use something that automatically handles dependency tracking.

Every once in a while to I like to pause to examine my work and try to figure out what's time consuming or error prone. I'm hoping switching to a more functional+declarative style will allow me to make interactive tutorials more quickly in the future.

Read More