MichaelHoste

Thanks for your feedback!

Yes, we're using ChatGPT 3.5 for now and we will certainly switch to GPT-4o mini in the near future. It already works with ChatGPT 4 but we noticed that the cost increase was not worth the minor improvement of quality.

I tried your example with ChatGPT 4 and it's somewhat better but not perfect: "I've even come to hate my brother and younger brother."

We hope that the quality will improve with the cheapest (and also fastest) models available.

Thank you! I didn't know PIN were also used for the magnetic strips (we never use them in Europe, or at least in Belgium).

The legacy software could explain it. But the difference of processes between my main bank (random temporary PIN obtained with 2-factor authentication: postal letter with code to send back using smartphone) and my credit card company (bank card mailed to my address with current PIN) was weirding me out.

That's something that crossed my mind, a 4-digits PIN is a weak password by definition.

But hashing them with the customer ID, date of birth, or something else, and using bcrypt to slow bruteforce down could already be an improvement.

I loved and finished the game but I had the same issue on two occasions. I felt sick and I had to stop. Now I know it was not the food I had just eaten but the game itself, thank you!

The link seems to redirect to https://news.ubisoft.com/notfound without any visible content.

Here is the press release from Blender: https://www.blender.org/press/ubisoft-joins-blender-developm...

Right now, we think about the possibility to integrate with Wordpress or Symfony.

If you use React, one of our users also created a plugin for React-Intl: https://github.com/deecewan/translation-io

Laravel is currently the only integration in the PHP-world. But most of the code could certainly be reused for a Symfony application, or any other PHP project.

We think that every framework must have a tailored solution to handle translations best, so we move forward in small steps to be sure our solution fits the pain (of maintaining translations up-to-date as the app evolves).

We have strong opinions about this, and we explained them here: https://translation.io/blog/gettext-is-better-than-rails-i18...

Even if we compared GetText to YAML key/values (Ruby on Rails), the same reasoning applies also for PHP key/values of Laravel.

I have no idea, the title changed after I posted it and it was "288". It was also originally a "Show HN:" but someone removed it (maybe I was using it wrong, I don't know).

I was indeed afraid that it would look too static without using "random" phases. Using seconds would be great (I could try to make them look smaller too).

Looking at my source of inspiration (http://www.humanssince1982.com/a-million-times/) you can see that the random phases are way prettier than mine. But it would make the code uglier with a lot of "setTimeout"s, and I wanted to keep it clean.

The keyboard controls are the same as XMoto (up for acceleration, down for brake, left/right for rotation) but they are applied differently. The smallest difference in physical value (torque, acceleration, grip, weight, etc.) changes everything and it's very difficult (if not impossible) to have exactly the same behavior as original XMoto. So I just recreated some physics that are fun to play with and works well with the existing levels.

If you want to play with the physics, you can try to change some values here by clicking on them: http://js.xmoto.io/?level=1010&debug=true It's fun to do and I'm open to new modes :-)

If you are interested, the input code is here. As you can see, acceleration and brake are only applied on the wheels, like in real-life. But for the moto rotation, I cheat by applying some torque on the moto body because the driver was not heavy enough to make it rotate quicky: https://github.com/MichaelHoste/xmoto.js/blob/pixijs/src/mot...

I tried to start a blog to talk about the project's creation: http://xmoto.io But as always, I prefer to spend my time working on the code than writing blog posts... So they are not up-to-date (and will never be).

Games are not my branch of work and I was like you. What I can tell you is that learning to deal with the game loop is the hardest part. The synchronization between the physics, the drawing and the game logic is not very intuitive for a web application developer :-)

Thanks for the compliment!

Nice catch for the bug! I fixed it on the wip branch here: https://github.com/MichaelHoste/xmoto.js/commit/24855d191a43...

There is an abstraction between player physics and ghost physics and I think I need to refactor the collision system to avoid this kind of behavior.

Yes of course I had multiplayer in mind the whole time. I even started a Rails application here for that purpose: https://github.com/michaelhoste/xmoto.io (it was more of a proof-of-concept)

But I'm afraid of the tweaking of the physics once the multiplayer game is started (and replays are created). Do I need to freeze them once-for-all and only work on supporting more levels or create an editor?

I still have plans for this project, but this is a side-project and like always, life happens and free time disappears...

EDIT : the work-in-progress is in fact in the "pixijs" branch, I almost finished the rendering engine switch to http://www.pixijs.com/ (higher level of abstraction, more cool 2D effects)

There were 3 difficult parts:

* The most difficult one was recreating the physics with a modern physics engine (box2D) to make them feel like the original ones. The smallest difference was making some levels impossible. It's not perfect but I tried to tweak them the best I could. And I created a debug mode to help me (and others) achieve this: http://js.xmoto.io/?level=1010&debug=true (I had way too much fun with this mode!)

* Levels: the level format was documented but not everything was "well"-documented. So I had sometimes to reverse engineer things. Like you could see, there are thousands of levels and they added layers of logics with time. So the first levels are usually compatible, but not the latests. And when I tried to add some logics (parallax, checkpoints, etc.), sometimes, the first levels broke (it's difficult to write tests for this). I wrote a blog post about it here: http://xmoto.io/2013/08/20/level-parsing.html

* Replays: I tried to find the smallest possible format to save all player's replays on a database. The original purpose was to create a kind of online community where people could challenge themselves and replay size matters. I first tried to save the replays as "keyboard inputs" but it wasn't reproductible as physics engine are not deterministic between browsers (I learned it the hard way). So I had to save both keyboard inputs and physics "checkpoints" (every x seconds) to adjust the replays. I'm quite happy with the results because it's about 20ko for 1 minute of replay. Here is a big monologue about my reasoning: https://github.com/MichaelHoste/xmoto.js/issues/8

It was fun because I'm a full-time Ruby on Rails developer and I was way out of my confort zone :-)

The GetText part is almost stack-agnostic and we already created some code snippets to synchronize PHP and angular-gettext projects with success.

However, Ruby on Rails is our first target and we want to make it right before going in every directions.