Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Futurism is back
#1
Hey, all! The efforts of Delphinoid and myself have paid off, and we've finally managed get the game set up and working properly. Here's a bit of gameplay Delph recorded:





As of now we've also gotten card images working.

We haven't made any decisions regarding hosting the game, but it's at least pretty nice that a tiny piece of JV history (and one that I'm particularly fond of) could be brought back.
[-] The following 4 users say Thank You to Norden for this post:
  • Mystery, Northadox, Tuxi, Verdusk
Reply
#2
Congratulations for accomplishing this project Smile
Strangely enough I have never played Futurism to the point of even understanding the rules, lol. It's still strange for me to realize some have been really into it.
Reply
#3
FUTURISM BOYS WW@
Reply
#4
Congratulations!

What do you need to host it? We might be able to throw it into Acid's server if it's lightweight enough.
If you need to contact me for any reason, or if you have any questions, concerns, problems or requests, message me here or email me at aaaaaa123456789@acidch.at.

This forum has been around for (loading...)
[-] The following 2 users say Thank You to aaaaaa123456789 for this post:
  • Mystery, Residays
Reply
#5
That's awesome. And I concur with axis, this site could use a game to host.
Reply
#6
(2020-02-04 06:54:05)aaaaaa123456789 Wrote: Congratulations!

What do you need to host it? We might be able to throw it into Acid's server if it's lightweight enough.

The entire app runs on three instances of node 0.10.x, as well as older versions of the redis and mongodb databases, if I'm understanding the question correctly. Card images also require libgraphicsmagicks and an AWS S3 database to work (I've been using a free account to test it). We've been testing the game on an old Linux machine so I imagine it'll run on just about anything, though our version is a little slow.

Delphinoid has a repo here that just retraces our steps, but it's just mostly for our reference, so it's not exactly plug and play. I suppose at some point we'll just want to have a repo with the full modified source and all the correct version information in one place.

One thing that we'd still need to work on is a login system- none of the programmed login systems work anymore (guest logins still save progress so we've been using those) so we'd have to throw together a new one using the code for detecting Jiggmin logins. I'm in the early stages of looking into this so I don't know how difficult this will be.
Reply
#7
Okay, once you clean up your stuff, let me know.
If you want to use the forum's logins, I might be able to put together some sort of login integration.
If you need to contact me for any reason, or if you have any questions, concerns, problems or requests, message me here or email me at aaaaaa123456789@acidch.at.

This forum has been around for (loading...)
[-] The following 2 users say Thank You to aaaaaa123456789 for this post:
  • Delphinoid, Residays
Reply
#8
(2020-02-05 03:05:13)aaaaaa123456789 Wrote: Okay, once you clean up your stuff, let me know.
If you want to use the forum's logins, I might be able to put together some sort of login integration.

Next week or something I'll try and make a repo with everything in it that's ready to drop in. Earlier this week we created a temporary login system; here's what Futurism expects from login servers:

When the client attempts to log in, it sends a JSONP HTTP GET request to the server. The server can check the cookies in the request to see if it contains a valid session token, and if it does it returns a response containing jsonp_callback({"logged_in": true, "token": whatever_the_token_was}) (otherwise {"logged_in": false}), where jsonp_callback is whatever the JSONP callback set by jQuery was.

If everything goes well, the token is sent to globe, which sends it back to the server in a POST request and expects JSON user data in return. You can really respond with anything and parse it however you want, here's what I do currently. The fields you'll probably be interested in are "name", "siteUserId" and "group". You can build an avatar URL on globe using the user's site ID.
[Image: vqGfn9p.gif]
Reply
#9
There are many, many good reasons to not base a login system on cookies. While you can use them to cache session tokens, using them as the sole form of authorization is bad design.
If you need to contact me for any reason, or if you have any questions, concerns, problems or requests, message me here or email me at aaaaaa123456789@acidch.at.

This forum has been around for (loading...)
Reply
#10
(2020-02-08 08:16:52)aaaaaa123456789 Wrote: There are many, many good reasons to not base a login system on cookies. While you can use them to cache session tokens, using them as the sole form of authorization is bad design.

Here's Jiggmin's current email: jacob@grahn.io. You can go ahead and send him your thesis on bad design.
[Image: vqGfn9p.gif]
[-] The following 1 user says Thank You to Delphinoid for this post:
  • Verdusk
Reply
#11
(2020-02-08 08:16:52)aaaaaa123456789 Wrote: There are many, many good reasons to not base a login system on cookies. While you can use them to cache session tokens, using them as the sole form of authorization is bad design.

That's just how the login system was implemented, there's not much we can do about it without rewriting an obnoxious amount of globe's code (which Jiggmin doesn't even have on his github anymore, we were only able to do this because I happened to have a copy of it forked from a previous attempt).
Reply
#12
(2020-02-08 08:49:59)Delphinoid Wrote:
(2020-02-08 08:16:52)aaaaaa123456789 Wrote: There are many, many good reasons to not base a login system on cookies. While you can use them to cache session tokens, using them as the sole form of authorization is bad design.

Here's Jiggmin's current email: jacob@grahn.io. You can go ahead and send him your thesis on bad design.

Why bother? Much of his code is a thesis on bad design already.
If you need to contact me for any reason, or if you have any questions, concerns, problems or requests, message me here or email me at aaaaaa123456789@acidch.at.

This forum has been around for (loading...)
[-] The following 2 users say Thank You to aaaaaa123456789 for this post:
  • FinalCheetah, Mystery
Reply
#13
(2020-02-09 02:50:03)aaaaaa123456789 Wrote:
(2020-02-08 08:49:59)Delphinoid Wrote:
(2020-02-08 08:16:52)aaaaaa123456789 Wrote: There are many, many good reasons to not base a login system on cookies. While you can use them to cache session tokens, using them as the sole form of authorization is bad design.

Here's Jiggmin's current email: jacob@grahn.io. You can go ahead and send him your thesis on bad design.

Why bother? Much of his code is a thesis on bad design already.

Yet, what he coded was more creative and more interesting than what most coders accomplish. I prefer that to perfect code design for a game with nothing new nor stimulating.
[-] The following 1 user says Thank You to Ilraon for this post:
  • Norden
Reply
#14
(2020-02-09 07:03:58)Ilraon Wrote:
(2020-02-09 02:50:03)aaaaaa123456789 Wrote:
(2020-02-08 08:49:59)Delphinoid Wrote: Here's Jiggmin's current email: jacob@grahn.io. You can go ahead and send him your thesis on bad design.

Why bother? Much of his code is a thesis on bad design already.

Yet, what he coded was more creative and more interesting than what most coders accomplish. I prefer that to perfect code design for a game with nothing new nor stimulating.

Which aren't mutually exclusive, but it's true that the perfectionist kind rarely finish anything creatively to speak of. (esp. outside the main job)
I don't have a sicknature
YouTube (original music) | Newgrounds (games)
Reply
#15
Game design skills and programming skills don't really correlate. That's nothing new.

In particular, good game design skills say nothing at all about good security. PR2 was security Swiss cheese, which is why to this day there are still plenty of bots around and cheaters are impossible to eliminate; PR3 wasn't much better. It took Jiggmin five years to realize that his security model for those games was fundamentally flawed, and by that point there wasn't much that could be done.

Using cookies this way is basically CSRF (cross-site request forgery) as an authorization model. It's a fundamentally broken idea that can lead to many security problems. The worst of those problems is that it's not hard at all to get into someone else's account! (For obvious reasons, I won't say how. And yes, this was certainly possible in the original game.)
If you think that's somehow a good thing, then I don't think there's much left to discuss here.
If you need to contact me for any reason, or if you have any questions, concerns, problems or requests, message me here or email me at aaaaaa123456789@acidch.at.

This forum has been around for (loading...)
Reply
#16
(2020-02-09 10:51:24)aaaaaa123456789 Wrote: Game design skills and programming skills don't really correlate. That's nothing new.

In particular, good game design skills say nothing at all about good security. PR2 was security Swiss cheese, which is why to this day there are still plenty of bots around and cheaters are impossible to eliminate; PR3 wasn't much better. It took Jiggmin five years to realize that his security model for those games was fundamentally flawed, and by that point there wasn't much that could be done.

Using cookies this way is basically CSRF (cross-site request forgery) as an authorization model. It's a fundamentally broken idea that can lead to many security problems. The worst of those problems is that it's not hard at all to get into someone else's account! (For obvious reasons, I won't say how. And yes, this was certainly possible in the original game.)
If you think that's somehow a good thing, then I don't think there's much left to discuss here.

The bottom line is that this was, as far as I could tell, how Jiggmin's login system worked (and there's a decent chance it wasn't). Even if his was more sophisticated, this was the easiest for me to implement as a temporary solution, that worked with next to no modification of Futurism's source. I don't have the time (or, frankly, the interest) in reading up on a bunch of stupid, mind-numbing IT drudgery so I can implement a state-of-the-art login system that only Nedron and I are likely to use before it gets phased out by something else (and especially not for a game that only a handful of people will realistically play anyway).

If you'd like to investigate it yourself, be my guest, no one's stopping you. I just don't see the point in moaning about it. It's not cute, funny or particularly interesting; it's just tiresome.
[Image: vqGfn9p.gif]
Reply
#17
Squabbling aside, there are other issues with security that have nothing to do with the login system anyway- for one, the game runs on an old version of node and a bunch of outdated libraries. It doesn't really matter that much because there's not much to gain from messing with an unfinished game with a tiny playerbase. We can save our concerns for if Jiggmin decides to actually revisit Futurism, where safeguarding accounts might actually matter.

Also again, Jiggmin doesn't even have globe on his github anymore, so I'm pretty sure none of this stuff is news to anyone.
Reply




Users browsing this thread: 1 Guest(s)