Can anybody provide me with examples of front-end problems that could be solved by means of artificial intelligence models (neural networks, fuzzy logic, genetic algorithms)?
The only thing I've found is "Optimization of web newspaper layout in real time" (http://hera.ugr.es/doi/15001684.pdf)
I would be very pleased if you provide me with more practically relevant problems.
Well, any problem that has a wide range of possible solutions which can be discovered and optimized faster by an AI algorithm than a human...
I'll just throw some random ideas out there:
Classifying users based on user behaviours (time spent on pages, links clicked, mouse positions, all sorts of other measurable facets of user behaviour). You might want to classify them in all sorts of dimensions, the possibilities are basically endless.
Interactive simulations with agents driven using neural networks and genetic algorithms.
Classification of user drawn images.
Sentiment analysis.
You can do whatever AI stuff you want on client side. The question you should ask is when to do it client side and when to do it server side. Obviously if you want to keep your algorithms safe then don't write them in Javascript that can be viewed client side. If you need to have reliable performance, don't do it client side.
Related
So, suppose there was a game which consisted of a website, and a client that you can launch from said website. I've looked a bit and a relatable example would be Habbo Hotel.
What I'm asking is, what are all the different parts that would make such a game work: for the website part, I'd imagine a server, a database, and some HTML, CSS and PhP coding would be required, but how would the client side operate?
More specifically, how would the client-to-server (and vice versa) real-time communications happen?
Suppose the client be coded in C, how would the integration of C into a (I suppose PhP-framed) browser window be executed?
Note that the client is never downloaded on the user's PC, so where would it reside?
I'm sorry if these are a lot of questions, if the answers were to be too tedious to compose, feel free to just leave some documentation or tutorials (which I've looked for but haven't really been able to find), I'll happily read them on my own. Thanks in advance.
On one side your question is too broad but on the other side I can give you some pointers of how to do this in a modern way:
don't have a client, just a page in a browser
use HTML5 canvas, you may also want to look into SPA (single page application)
connect via websocket, there are HTML5 javascript implementations and PHP or node.js for the server-side
best is, use node.js on the server, PHP would be way too cumbersome
via websocket, send and receive JSON objects
host node.js on its native platform (Linux)
you may want to look into phaser as an HTML5 client-side canvas rendering framework, but it lacks many functionality and is mainly oriented towards twitch-based action games, which don't work well with this architecture because of lag
this will lead you to one conclusion: javascript is at the center of this system. you'll encounter several roadblocks, such as:
security on websockets with SSL for login
avoid SSL for real-time data (above 1 Hz)
UI on the client inside the canvas is not easy to implement, you'll have to re-invent the wheel or find a UI library for that
expect lag, the network code will take some 20%-30% overhead in respect to native C/C# code using TCP/IP or UDP (Lidgren?) and protobuf (Lidgren+protobuf) is what high-frequency AAA titles use (MMORPG or FPS alike)
From the questions you asked I sense a great lack of understanding and knowledge about the field. I guess you'll have to study some 6-12+ months beforehand. This is what I recommend, because if you start right away you'll make a lot of errors and waste your time. If above are any names you don't know about, search them and study them well. And don't start to code, there is a very steep learning curve ahead of you!
EDIT: more about server-side
If you want to implement an action-based interactive game (like an FPS or 2D shooter) I have to tell you this.
You may want to look into Unity 3D, using directly TCP/IP connections and binary messages (no HTTP, no websocket, instead protobuf).
C# (client-side) and node.js (server-side) are a good combination. For horizontal scaling you may want to look into cloud computing, docker, provisioning and a lot of server security.
But this is hostile terrain, it leads you into DevOps territory, which is way off game development. More like an architect's job. Imagine that 3-tier system (client + server + database) has a bottleneck on the server.
You want to spawn more nodes to handle more clients. This is what EVERY lobby-based game does (LoL, Overwatch, WoT, WoW instances, and so on) and what you do for partitioned maps (e.G. the "maps" in LOTRO, RIFT, many more MMORPGS). Also, to mirror (which means multiple instances of the same map to accomodate an overpopulated crowd).
To have this kind of horizontal scaling your servers must go online/offline on their own without you clicking around on command and control (e.G. puppet and similar software).
While this is the ultimate approach, it also has the most steep learning curve, especially because of security (advert DDOS, flooding, slow-loris, fake clients, and the list goes on). A new node must be "provisioned" on the fly (e.G. cloud-config) before it attaches to the cluster and goes online, so there's a whole new world of pain and learning.
The center-piece of such an elastic cloud-based server system is SSO (single sign-on).
My Family Owns a Restaurant and for various reasons, I want to make a POS software to replace the one they currently use. I am most comfortable making GUI in html/css so, if possible, I would like to take this path. I just have a few concerns.
Are There existing API's for dealing with printers, registers and credit card machines?
Can I make these applications run on Linux, and if so, how? (I Know Linux Can't Run .hta)
How would I go about connecting multiple terminals within the code?
I don't expect I walkthrough, but any information would be greatly appreciated.
Also, if using html/Javascript isn't viable, I would be open for suggestions. I am comfortable coding in C++ and Python, however I dont know of any easy ways to make GUI's with these languages.
Thanks!
In short, no. You could use HTML/JavaScript for the front-end, but if you have multiple terminals, and printers etc. you will need a back-end infrastructure of some description which will need to be a server-side language; preferably something like ASP.net, PHP etc.
You'd need to design an architecture, design a database schema, work out the interfaces between all parts of the solution and design a user-friendly UI... the right place to go to get this question answered is to enroll on a degree in computer science and get a few years experience in developing these systems!
Sorry to be snarky but this is a big undertaking; if it were me, I'd not commit to doing it for a family business as my first web application. There are huge risks around payment card information and customer personal information that, if you get wrong, could lead to serious business risks.
Edit: A very quick google search lead me to http://www.unicentaopos.co.uk/ one of many free, open source POS systems. the one linked seems specifically geared toward restaurants.
Yes, You can do it with this. But, it will depend upon your receipt printer, if you have a cash drawer. For example, the TSP100 Receipt printers connect to a cash drawer and when printing, you can open the drawer. It is independent of the application.
As for the backend, you obviously cannot do that with HTML/CSS. You have to know how to design databases.
I'm learning React.
I'd like to create a game with a basic tile-board (like here http://richard.to/projects/beersweeper/ but where tiles can have two states ('available' or 'already clicked').
In terms of speed, React looks interesting as with its virtual DOM/diffs, I could only adjust the css and text inside tiles that have been clicked (so that they visually differ form those still not clicked by anyone).
My goal (and personal challenge haha) is to make this game playable by 1000 simultaneous players who can click where they want on a 100,000-tiles board.(distribution among clients in real time of tile status would be done with Firebase)
Should I use basic standard React and its built-in features (onclick events,ts listeners...) or is it impossible with only-React to enable that many events/listeners for 1000 people on 100K tiles in real time with any user being able to click anywhere (on available tiles) ?
Should I use alternative/complentary tools and techniques such as canvas, React Art, GPU acceleration, webgl, texture atlases....?
WebGL is the right answer. It's also quite complicated to work with.
But depending on the size of the tiles, React could work but you can't render 100k dom nodes performantly... no matter how you do it. Instead, you need to render the subset of tiles visible to the user.
To pull something like this off, you'll need to have a lot of optimized code, and firebase most likely won't be up to par. I'd recommend a binary protocol over websockets and a database that makes sense (fast lookups on multiple numeric index ranges, and subscriptions).
Ultimately, I'd probably go with:
webgl (compare three.js and pixi.js)
custom data server in golang (with persistence/fallback managed by a mysql engine like maria or aws's aurora)
websocket server written in golang
websockets (no wrapper library, binary protocol)
The only reason for golang over node.js for the websocket server is CPU performance, which means lower latency and more clients per server. They perform about the same for the network aspect.
You'll probably ignore most of this, but just understand that if you do have performance problems, switching some of the parts out for these will help.
Do a prototype that handles 2 concurrent users and 1000 tiles, and go from there. In order of priority:
don't render 100k dom nodes!
webgl instead of dom
binary websocket protocol, over socket.io or similar (not firebase)
custom data server in go
binary websocket protocol not using socket.io (e.g. ws package in node)
websocket server in go (not really that important, maybe never)
Lots of people use React as the V in MVC.
I believe that react is fine for UI but you should ask yourself what will be the server side logic, you still have to think about M and C
If you are looking for 1000 simultaneous users load, the keyword scalable will be your friend.
Also you should check out Node.js for the server side service. Express.js for it's fast implementation, and finally Pomelo.js which is a js game server implementation, based on node.js
On the subject of performance.. WebGL will most likely boost your performance. Here you can grab a nice tutorial on the topic : https://github.com/alexmackey/IntroToWebGLWithThreeJS
If you want to build it without GL languages whatsoever, you should digg deeper into JavaScript create your own pseudo-class library with dynamic data bindings. Otherwise you might end up using small percentage of a powerful framework that will only slow down your API.
I would restrain from using canvas, as they are good for model visualization rather as game front-end. Checkout d3.js for it's awesomeness and unfortunately performance issues.
Here I have written a nice fiddle, that creates 100x100 matrix with hovers, and perfromance is not so good. You can easly tweak it to get 100k element matrix: https://jsfiddle.net/urahara/zL0fxyn3/2/
EDIT: WebGL is the only reasonable solution.
I have been requested to make a port of an iOS game for Facebook.
The game itself is fairly simple, it is a puzzle game using a 2d array for a grid with XML passed from a server for loading objects onto the the grid, to create levels.
The game will ask questions at stages which will be passed to my server and stored for research purposes.
Some questions for those with experience.
What front-end options do I have with Facebook?
I have looked into both Flash and HTML5/js both of which i have little to no experience in (I'm experienced in Java/C#/Ruby + Rails).
Javascript seems like a nightmare from what I have read, even looking into javascript game engines, but at least it is free.
My backend will most likely be rails for handling server logic.
Summary(because I ramble too much)
-Is javascript for programming games really a problem for simple games on Facebook?
-Are js game engines worth using? Does anyone have any experience with them?
-Would prevention of cheating be possible with a js/rails game, do server side checks work?
-Are there any alternatives for a front end for someone with C#/Java/Ruby background?
I've never seen any Unity or Java apps on Facebook(I don't use it much) and I don't know if the licensing will be an issue for this research project.
Any input from those experienced would be greatly appreciated, I feel a bit lost with all the potential options.
Answers to the summary
-No, it is not a problem.
It brings with it certain challenges that will need to be understood, but it is a mature platform with loads of online documentation
-Definitely, but maybe not even necessary. It doesn't sound like your game is that complex, so you can probably feel comfortable trying any engine and seeing where it takes you. You may be more in need of data frameworks to deal with synchronization and management of state. I can't really recommend much without knowing more.
-Yep, preventing cheating is definitely possible. If banks can prevent arbitrary money exchange or invalid transactions, you can prevent cheating in a facebook game. You'll have to validate a lot on the server side, but that's par for the course.
-Besides flash, no. It's a javascript world out there. Flash has a lot of potential for serious games in the future, but if I were new to both I would probably bet more on JavaScript for the various other benefits it brings to the table (general web interaction, server side programming, etc)
If you are unconvinced of what JavaScript is capable of, head over to a site like chrome experiments to see what people are squeezing out of browsers nowadays.
Imagine a space shooter with a scrolling level. What methods are there for preventing a malicious player from modifying the game to their benefit? Things he could do that are hard to limit server-side is auto-aiming, peeking outside the visible area, speed hacking and other things.
What ways are there of preventing this? Assume that the server is any language and that the clients are connected via WebSocket.
Always assume that the code is 100% hackable. Think of ways to prevent a client completely rewritten (for the purposes of cheating) from cheating. These can be things such as methods for writing a secure game protocol, server-side detection, etc.
The server is king. Clients are hackable.
What you want to do is two things with your websocket.
Send game actions to the server and receive game state from the server.
You render the game state. and you send input to the server.
auto aiming - this one is hard to solve. You have to go for realism. If a user hits 10 headshots in 10ms then you kick him. Write a clever cheat detection algorithm.
peeking outside the visibile area - solved by only sending the visible area to each client
speeding hacking - solved by handling input correctly. You receive an event that user a moved forward and you control how fast he goes.
You can NOT solve these problems by minifying code. Code on the client is ONLY there to handle input and display output. ALL logic has to be done on the server.
You simply need to write server side validation . The only thing is that a game input is significantly harder to validate then form input due to complexity. It's the exact same thing you would do to make forms secure.
You need to be really careful with your "input is valid" detection though. You do not want to kick/ban highly skilled players from your game. It's very hard to hit the balance of too lax on bot detection and too strict on bot detection. The whole realm of bot detection is very hard overall. For example Quake had an auto aim detection that kicked legitedly skilled players back in the day.
As for stopping a bots from connecting to your websocket directly set up a seperate HTTP or HTTPS verification channel on your multiplayer game for added security. Use multiple Http/https/ws channels to validate a client as being "official", acting as some form of handshake. This will make connecting to the ws directly harder.
Example:
Think of a simple multiplayer game. A 2D room based racing game. Upto n users go on a flat 2D platformer map and race to get from A to B.
Let's say for arguments sake that you have a foolsafe system where there's a complex authetication going over a HTTPS channel so that users can not access your websocket channel directly and are forced to go through the browser. You might have a chrome extension that deals with the authentication and you force users to use that. This reduces the problem domain.
Your server is going to send all the visual data that the client needs to render the screen. You can not obscure this data away. No matter what you try a silled hacker can take your code and slow it down in the debugger editing it as he goes along until all he's left with is a primitive wrapper around your websocket. He let's you run the entire authentication but there is nothing you can do to stop him from stripping out any JavaScript you write from stopping him doing that. All you can achieve with that is limit the amount of hackers skilled enough of accessing your websocket.
So the hacker now has your websocket in a chrome sandbox. He sees the input. Of course your race course is dynamically and uniquely generated. If you had a set amount of them then the hacker could pre engineer the optimum race route. The data you send to visualise this map can be rendered faster then human interaction with your game and the optimum moves to win your racing game can be calculated and send to your server.
If you were to try and ban players who reacted too fast to your map data and call them bots then the hacker adjusts this and adds a delay. If you try and ban players who play too perfectly then the hacker adjusts this and plays less then perfect using random numbers. If you place traps in your map that only algorithmic bots fall into then they can be avoided by learning about them, through trial and error or a machine learning algorithm. There is nothing you can do to be absolutely secure.
You have only ONE option to absolutely avoid hackers. That is to build your own browser which cannot be hacked. Build the security mechanisms into the browser. Do not allow users to edit javascript at runtime in realtime.
At the server-side, there are 2 options:
1) Full server-side game
Each client sends their "actions" to the server. The server executes them and sends relevant data back. e.g. a ship wants to move north, the server calculates its new position and sends it back. The server also sends a list of visible ships (solving maphacks), etcetera.
2) Full client-side game
Each client still sends their actions to the server. But to reduce workload on the server, the server doesn't execute the actions but forwards them to all other clients. The clients then resolve all actions simultaneously. As a result, each client should end up with an identical game. Periodically, each client sends their absolute data (ship positions, etc.) to the server and the server checks if all client data is identical. Otherwise, the games are out of sync and someone must be hacking.
Disadvantage of the second method is that some hacks remain undetected: A maphack for example. A cheater could inject code so he sees everything, but still only sends the data he should normally be able to see to the server.
--
At the client-side, there is 1 option:
A javascript component that scans the game code to see if anything has been modified (e.g. code modified to render objects that aren't visible but send different validation data to the server).
Obviously, a hacker could easily disable this component. To fix that, you could force the client to periodically reload the component from the server (The server can check if the script file was requested by the user periodically). This introduces a new problem: the hacker simply periodically requests the component via AJAX but prevents it from running. To avoid that: have the component redownload itself, but a slightly modified version of itself.
For example: have the component be located at yoursite/cheatdetect.js?control=5.
The server will generate a slightly modified cheatdetect.js so that in the next iteration, cheatdetect.js?control=22 (for example) must be downloaded. If the control mechanism is sufficiently complicated, the hacker won't be able to predict which control number to request next, and cheatdetect.js must be executed in order to continue the game.
There's nothing you can really do to prevent anyone from modifying your JS or writing a GreaseMonkey script. However you can make it hard for them by minifying your script as well as making your code as cryptic as possible. Maybe even throwing in some fake methods or variables that do nothing but are used to throw an attacker off. But given enough time, none of these methods are completely foolproof, as once your code goes to the client, it is no longer yours.
The only way I can even think of implementing this is by modifying your Javascript to function as a client and then designing a central server mechanism to validate data sent from that client. This is probably a big change to implement and will most likely make your project more complex. However, as was said earlier, if the application runs entirely on the client, the client can pretty much do whatever they want with your script. The only way to secure it to use a trusted machine to handle validation.
They don't have to touch your client-side code -- they could just sniff and implement your Websocket protocol and write a tiny agent that pretends to be a human player.
Update: The problem has a few parts, and I don't have answers off the top of my head, but the various options could be evaluated with these questions in mind:
How far are you willing to go to prevent cheating? If you only care about casual cheating, how many barriers are enough to discourage the casual cheater? The intermediate Javascript programmer? A serious expert? Weighing this against the benefits of cheating, is there anything of real value at stake, like cash and prizes, or just reputation?
How do you get a high confidence that a human is providing inputs to your game? For example, with a good enough computer vision library I could model your game on a separate machine feed inputs to the computer pretending to be the mouse, but this has a high relative cost (not worth my time).
How can you create a chain of trust in your protocol such that knowledge of (2) can be passed to the server, and that your server is relatively confident your client code is sending the messages?
Sure many of the roadblocks you throw up can be side-stepped, but what is the cost to the player and you? See "Attrition warfare".
Some other methods that can be implemented:
Make the target elements difficult for a script to distinguish from other elements. Avoid divs with predictable class and id names if possible. Inject styling using JavaScript instead of using classes. Think like a hacker and make it hard on yourself.
Use decoys that a script will fire on. For instance, if the threat vector is a screen scraping algorithm using pixel colors, throw some common pixel colors in non-target elements. Hits on these non-targets could seem inconsequential to the cheater, but would be detectable. You don't want the cheater to know why you know.
Limit the minimum time between actions to slightly below the best human levels. The best players will hit that plateau, and it won't matter as much who's cheating, and immediately be able to detect anyone scripting faster than that by side-calling method calls.
Random number generators are typically uniform. Human nature is not. Likely a random number generator will have values within a set limit and even distribution. Natural distribution is a Gaussian curve. If you sampled the distribution and it looks like a square wave in the x and y axis, 100% it's a cheater. This will be fairly difficult for the cheater to detect the threshold for the algorithm because it's a derivative of the random, and not the random distribution itself. You're also using aggregate data and not individual plays to detect it, so reverse engineering the algorithm would be extremely difficult without knowing your detection algorithm.
Utilize entropy whenever possible. Avoid predictable game plays. Imagine a racing game on a set collection of race tracks. Each game play could have slightly differing levels of traction, horsepower, and momentum. The script would have to be extremely good to beat it. In a scrolling game, you can alter factors that are instinctual to humans, but difficult for computers, such as wind force, changes in gravity, etc. It would also make it more fun as a side benefit.
Server generated tokens can be used to validate UI elements were used and not calls to the code itself. Validation can be handled in one call at the end of the game comparing events to hashed codes of UI elements. The token should be a hash with a server private key and some value of the UI element.
Decoy the cheater with data they think you're using to detect cheats. Such as calls to a DetectCheat method with dummy calls to a fake backend. It's the old magician's trick. Wave your hand over here, while you slip a card into the deck with the other hand. Let them waste days on end in a maze that has no exit, with lot's of hair pulling.
I'd use a combination of minification and AJAX. If all of the functions and data aren't loaded into the page, it'd be more difficult to cheat.
On the other hand, modding turned out to be a very profitable tool for companies like Id Software. Perhaps allowing the system to be modded might make the game that much more enjoyable to the community at large.
Obfuscate your client exposed code as much as possible. Additionally, use some magic.
You can edit the javascript on the browser and make it work.
Some people suggest that make a call to check with the server. So after making a call to the server, it will be validated in the server. Once validated, it will come to client side and do actions. But I think even this is not foolproof.
For eg.,. for a Basic login action : in angular while making a call to server, the backend validates username & pwd and if validated, it will come back to the client and let the user login using angular.
When I say login using angular, it is going to store things in cookies, like user objects and other things. But still the user can remove the JS code which is making the call to backend, and return TRUE(wherever needed) and insert user object(dummy) to cookies and other objects(whatever needed) and login. It is a very difficult thing to do, but it is doable. In many scenarios, this is not desirable even if it takes hours to edit/hack the code.
This is possible in single page applications, where JS files dont get reloaded for each page. To mitigate the possibility of getting hacked we can use minified codes. And I guess if actions like this is done in backend(like login in Django) it is much safer.
Please correct me if I am wrong.