Currently, I am developing a 2-player tetris game. Originally, I was planning to implement a client-server model in a mobile environment.
However, now I change into web game, which is accessible by a browser. Since I am not used to a web development, I want to know if client-server model is necessary in a web game.
To be honest, I am a little bit skeptical writing both client and server code since a browser does a job to connect to the server.
Is it possible to build a network-based game by using only one server without a client part?
Is it possible to build a network-based game by using only one server without a client part?
Nope. You need a client.
It doesn't matter if you're in the browser or writing a native application. Yes, the browser solves a lot of client problems for you - it implements HTTP for you, and it has display (CSS), content (HTML), and evented logic (JavaScript) that you can use. But you still need to write your client using those technologies.
Even if the browser exposed a call in javascript like this:
window.startPeterHwangsTetrisGame();
You still have a client. The client is 1 line of code, and it is exactly the above script*.
Realistically, you should look for a game-oriented web development tutorial and start there.
*(aside from the necessary HTML within which that javascript exists)
Well, in one sorta correct way, no, because you're not redesigning the browser, but nobody would say it like that. Web design includes a lot of code / markup used on the client (browser), and while your server is sending the browser the data, and that data is a mix of CSS, HTML, and JavaScript (as well as media like graphics and perhaps music), the browser is the piece of software doing the lifting on those pieces once it receives them. That data is selected by the server, so the logic for that is on the server, but this is what people would think of as "client design" in the context of a web application.
There are also a number of models (ways of arranging your programming designs) which would lead to cleaner code, and a lot of these would send a grouping of information (called a model) to the client (the browser) and then the browser would do some interpretation of how to use that data (called a view). This is a simplification since I don't think you're ready for a big dive into specific theories, but you could start with a JavaScript and HTML tutorial and then learn a server language:
Python is my favorite, but PHP is big as is Java (NOT to be confused with JavaScript), and I make my living doing C#. Really there are plenty of great choices.
One commentator recommended Node.js because you'd use JavaScript on the server with Node--just like for the client part (the response data you're sending to the browser). That's double duty, but I am partial to Python (as I said). Just pick something, and as you learn, you'll get to know what you like. If you change languages, it'll be easier to learn your second one.
Related
This question might have been asked in the past but I cannot seem to find the answer. I would like to navigate between pages without avec to redirect to a brand new xxx.html file. Basically, I want to keep only one html file being the index.html
In order to understand what I mean, here is a small preview of this functionality I want to achieve.
Preview
As you can see, the piece of clothing is not its individual html file. What method is used to achieve this?
What you are seeing is called a Single-Page-Application. There are a lot of frameworks with which you can create a page like this. If you are going for plain HTML/CSS/JavaScript it will be a lot harder to do correctly.
What you're seeing here is a dynamic webpage that is taking advantage of client-side technology to create this effect. To help further explain, let's quickly go over some web development terminology:
Client-Side: Code that is executed on the user's computer (in this case in their web browser).
Server-Side: Code that is executed on a server, then a response of some sort is sent to the client.
With server-side code, the value cannot change unless a new call is made to the server to get a new response. This is because the code isn't actually running on the computer the user is running, it's running on some other computer probably thousands of miles away. However, with client-side code, dynamic changes could be made in real-time because the code is actually running on the user's computer.
When it comes to server-side code, we as developers have a myriad of options. Any language that can send an HTTP response to a web browser could theoretically be used as a server side language. In 2018, that's basically every major language in existence! That being said, some popular options today include Python, Ruby, Java, and Javascript (Node JS).
When it comes to client-side code, however, we're limited by what can run in a user's web browser. In general, modern web browsers only understand Javascript. However, while the language has gotten better over the years, writing code in pure JavaScript can sometimes be cumbersome, so there are libraries that help make writing Javascript easier (such as jQuery) and there are even languages that compile down to Javascript to add new syntax and functionality (such as Typescript and Coffeescript).
If you'd like to start writing dynamic web applications, a good place to start would be to learn the basics of JavaScript. Then, maybe start learning jQuery, or front-end libraries such as Angular or React. Good luck!
You will have to use javascript for this. Either you can load all content at once and just show/hide the content you need, or you could ajax to fetch the content and then render it without page reload.
I'm working on a project and I just need a holistic overview on how to go about it.
I'm going to use HTML/CSS canvas to make the game.
However, the game involves visualization of large amounts of data that is best served in a database. What I do not know how to do is:
Link my HTML/CSS game to a SQL database
Parse a text file to populate the database.
I don't have specific issues I just don't even know where to start? Some people have said AJAX? Others have said parse.com?
You have two options:
write a server-side application to serve data from a DB
use client-side HTML5 storage (such as local storage, WebSQL, IndexedDB, etc)
If you use the server implementation you will need AJAX to communicate with the server.
To do this you will have toove beyond JavaScript and learn server side programming. The good news is there are tons of awesome server side languages that make building websites easy.
If you come from a javascript background, ruby would probably be an easy transition. I'd suggest Sinatra.
If you are using SQL server, c# and asp.net are great choices that are very well designed, thou c# is very different from JavaScript as a language.
Like python? Web2py and Django are good.
Then there is PHP and java...
You would probably write an API in one of these server side languages, access it using Ajax to retrieve Jason and process it.
And don't bother with parse.com. write your own parser in the language of your choice. Its usually really easy, and instructive.
I think you already know a language you can use. How about javascript? Of course a real serverside language like Java or PHP would be better - maybe as already told: ruby but why not try it with node.js:
Node.js could be the first thing you may look at. (http://nodejs.org/)
It's really nice & well documented - there is also a big question about node.js with mysql: MySQL with Node.js which also works fine.
First off, I am not asking for any code or anything like that.
all I need is some advise.
I'm creating a roulette game and everything in my roulette game is based on jQuery.
however, as we all know, jQuery is client side so I was thinking about using AJAX to send some details back to server and from the server to the users browser so I can make this roulette game work in "multiplayer" fashion... But the issue is that I don't think its possible to send the roulette's wheel animation to the server and back to users browser so I am a bit confused about this!
In my research I came across some information (old ones) about using node.js and jquery together! I don't know if this is possible or how easy it would be to use my jquery code in node.js as I have never used node.js before..
so the question that i have is:
based on the information i provided above and my requirements, what are my options?
can I use AJAX to achieve what i am trying to do and if so, a bit
information would be great.
if AJAX is out of question, is it possible to use my jquery code in
node.js to achieve what I am trying to do?
ANY ADVISE WOULD BE APPRECIATED.
P.S. I don't want to use HTML5 as 1st I don't know much about HTML5 and also, some devices, browsers do not support it.
Thanks
The best way is to use websockets to ensure real time communication. One of the best alternatives for implementing that could be using a server under node.js. Have a look to this video from Code School node.js tutorials: https://www.youtube.com/watch?v=mtDK4jf4RS0 where is ilustrated how to implement a real time chat. Your problem is based on the same.
There are three parts to a multiplayer game displayed in a browser:
client-side display,
server-side data management,
client-server communication.
If you're already set on your display technology (jQuery), then you're probably going to use $.ajax() for client-server communication. However, technologies used for server-side data management are completely up to you and they don't necessarily have any connection to the technologies used for display and communication (meaning the traditional communication initiated by client).
Basically, use any kind of server technology stack you like. Node.js might do just fine but there are many other viable alternatives. They just need to support communication with the client.
So, to be absolutely clear, your question doesn't really make sense. You might use jQuery in the client and Node.js on the server, but they will never really "work together". They will manage completely separate parts of your application and connect through protocols not specific to either of them.
As for the animation, the animation itself is solely a client-side problem. If you want to "synchronize the animation" across multiple clients, you can let the clients communicate with the server, but they only ever need to send/receive plain data. Then you adjust the client-side animation based on the received data.
As another poster points out, websockets are a better fit for this than regular client-initiated HTTP requests. Not because of "the animation", but because you want all the clients to receive the information about the start of betting at the same time.
I am also developing a MMO game using javascript only. Firstly, there are two different types of javascript here. Usual client side javascript (the one you already know) and the server side javascript (i.e. Node.js).
You will need to develop both client and server before connecting them with jQuery's Ajax. So you need to study Node.js before designing overall architecture of your game.
I read many Node.js tutorials and watched many youtube tutorial videos but I was still confused, before I really sat down and read a good textbook that explained from basics, one like below. Try to get hold of it from your local library.
Express web application development learn how to develop web applications with the Express framework from scratch by Hage Yaapa
Express is the popular framework that runs on Node.js now. So it's worth getting familiar with Express Framework. Once you understand how express app works (not so difficult), you will see how you can frame your game structure like I did :)
In order for many clients to share same animation, there must a server that synchronizes the game state. Ajax can only link between server-client communication in my understanding. There is no mechanism that connects between clients. The clients ask server what number was the result of roulette roll and show the corresponding animations.
Yes, you can use NodeJS and jQuery together.
NodeJS is server-side, meaning that you set up a server (a lot of people use the Express module, which is easy to use), which serves content to clients asking for it. Your server-side code can be in any language supporting sockets, not just NodeJS. But NodeJS is easy to use if you know JS already.
jQuery is client-side, meaning that it's executed by the user's browser, and may or may not have a server-side component (if it doesn't need it), or it might have one where it sends requests to the server-side code. When it requests a page from the server, it can be static content (like when you request index.html) or dynamic via an AJAX request. Client-side browser code must be HTML/CSS/JS (you can't make Firefox or Chrome interpret C, for example).
Assumptions:
I have a banking app with a Java-style web server.
The Client side is written in JS with backbone and some other plugins. (The developers are fans of Angular, but they're not using that).
My JavaScript developers have come to me and said "X is impossible because of the way we do the MVC in the browser."
Now I'm fine with an MVC on the server side, and we already have that. But when the JavaScript guys want to have an MVC on the client, then it feels like we're keeping state about the customer's experience in two different places. I think its simpler to keep in one place.
I'm familiar with the 'three tier' architectures of the 90s - with a database tier, a tier for transaction management, and another tier for customer interaction. We moved away from that because it was horrible.
I'm also familiar with running server side apps in Node.js. To me - it makes sense to have a server-side MVC in this scenario.
My question is: What are the reasons I would need an MVC model on the browser client for a server based application?
I don't get your comment about not keeping state on the client since you keep one on the server.
It's the difference between then-current Hotmail and Gmail. Gmail obviously was not implemented in AngularJs, but the forward-and-backward navigation, undo, etc... without a round-trip to the server is what one gets from keeping some relevant state on the client.
Both serve different purposes, in my mind. One facilitates user interaction. Another deals with persistent / protected state.
Totally agree with New Dev answer.
In the server, you handle state in the form of current logged user, data, and so on.
In the client, your state will be the application state (which "page" or screen they're on, which is the currently selected item in a list, and so on).
Think of the server (if it's implemented using a REST API) as your database+authentication, and your client as a desktop app (the UI state is what you're handling). This way of thinking really helped me initially with Backbone. Translate your SELECT to a collection.fetch, INSERT/UPDATE to a model.save() and DELETE to a model.destroy(). In a SPA, your API is your database and your SQL is HTTP and JSON -and probably more, but it may help to think it that way.
Seems like you are retreating to the good old days (not!) when every click required a round trip to the server to work. It somehow seems to contradict with the Ajax /REST model.
It may suit for your application, specifically, but this model works pretty good for a lot of others.
As for your question: client MVC allows you to build rich UI applications with a code that can be maintained.
And jsut to add a quote from wikipedia: Early web MVC frameworks took a thin client approach that placed almost the entire model, view and controller logic on the server. In this approach, the client sends either hyperlink requests or form input to the controller and then receives a complete and updated web page (or other document) from the view; the model exists entirely on the server.[8] As client technologies have matured, frameworks such as AngularJS, Ember.js, JavaScriptMVC and Backbone have been created that allow the MVC components to execute partly on the client (see also AJAX).
I fought for a long time to avoid Javascript simply because it was not strongly typed. I've since retreated on that point because of the simple fact that Javascript is the most strong DOM language anywhere, plus it also has thousands of open source framweworks out there (just look at JQuery, or even Typescript).
Prior to the "everybody needs a browser" era, server side was king. I remember the era of dumb terminals. Since then, when we have mainframe like computing power on every desktop these days, and it makes sense to utilize client PC power. If we really look at MVC we see a controller which only does routing (doesn't really matter if it's client side does it?), The models are always going to be closest to the DB, but... these days client side data binding is king, and you need models the client can bind to. The model itself, then doesn't have to even be server side anymore and with protocols like JSON, it's simple to create dynamic models on client side, just parse the Name/Value pairs and show it. We see validation moving to client side (which makes sense for user input, but the client side can validate data from DB too just to show the user errors. This leads to client side state machines for the view. So what's left for the server to do? Answer: get things started, and get data and save data.
When we saw Silverlight and even Flash start tanking, it was because the RIA thing (Server side) era was being displaced by client side frameworks. HTML 5 hastened the death of server side RIA because now the browser can have persistent 2 way communications based on a standard. All of a sudden, moving much of MVC to the client makes sense. It's just that it's foreign to server side traditionalists, like myself (for now)...
You can see frameworks like Durandal, Angular, Knockout, Node and others are simply re-inventing MVC and Binding except this time it's client side. It's really a good time right now to learn this stuff because it's relatively new. It's only going to grow because all of the infrastructure is already in place. The new system we are targeting is no long a big huge server, but it is the exploitation of the big huge "Browser". We have to look at Web browsers a the new big huge system because they represent everything to the user and e-commerce. The more we know about manipulating and supplying the DOM the better off we are... Server side will always be there but it is no longer the center of the universe.
They predict that the popularity of mobile devices and the desire for more applications (client side) is so strong in the next 10 years that there will be shortage of developers to keep up the pace. For me that's reason for switching gears to client side.
This is more of a curiosity really, to see if some one has done anything similar, or if at all it is possible.
I'm working on a project that will get notification through external notifications. Now I could go about doing this by having notifications coming to my server and have a comet setup between my client and server.
BUT
I was wondering if I could write server logic into my client and listen out for notifications from external sources. Immediately one issue I see is, external sources would need callback URL etc, which I dont know if you could do from client side (unless one could use the IP address in that way).
As you can see it is more ideas and discussions if such a thing was possible, this is somewhat inspired by P2P models whereby you wouldn't be mediating things through your central server.
Thanks in advance!
GWT compiles (nearly) Java source into JavaScript, so compiled GWT apps can't do anything that traditional JavaScript running in the browser cannot do. The major advantage of bringing Java into the picture isn't automatic access to any/all JVM classes, but the ability to not only maintain Java sources, which tend to be easier to refactor and test as well as keep consistent with the server, and to compile that statically defined code into JavaScript, performing all kinds of optimizations at compile time that aren't possible for normal JavaScript.
So no, while you can have some code shared by the client (in a browser) and the server (running in a JVM), you can't run Tomcat/Jetty/etc in the browser just by using GWT to compile the java code into JS.
As you point out, even if this was possible, it would be difficult to get different clients to talk back and forth, without also requiring that the browsers can see and connect at will to one another. BitTorrent and Skype have different ways for facilitating this, and currently browsers do not allow anything like this - they are designed to make connections to other servers, not to allow connections to be made to them.
Push notifications from the web server to the browser are probably the best way forward, either through wrapping comet or the like, or through an existing GWT library like Atmosphere (see https://github.com/Atmosphere/atmosphere/tree/master/samples/gwt-demo for a demo).