I'm planning to write in JAVA simple, but easy to develop in future MMORPG. I know more or less how it should looks like, but I have some questions:
Which kind of data should have client? I know that, for example, server informs client if "that field" is free or not, but what about loading map? Client contains sprites etc., but should they also have map files or server should tell client where is the grass and where is water etc...
How to keep data by server? Players should be represented as files in one folder where server have to find right file, open it, get data and send it back for many players? Maybe database server + database + sql would be better idea?
Any ideas/knowledge about MMORPG structure?
Is Java a good choice for 2D MMORPG?
MMO's are not easy programs to develop. It sometimes takes experienced teams years to develop one, and the questions you ask here don't seem to indicate you are a very experienced programmer. Having said that, I would suggest taking a look here:
http://slick.ninjacave.com/
http://www.13thmonkey.org/~boris/jgame/
These resources might be good starting points and get you up to speed quickly, but I'd suggest looking for a good tutorial on how to sync client/server data, en get a bit up to speed on programming Java in general.
I developed Browsergames in the past. Usually it is a good idea to put "static" data (data that doesn't change very often, like map layouts) into the client, so that you don't need to resend it every time.
I would definitly prefer a database (some sql or nosql) to file-based storage. If you wan't to improve you coding skills and make them more marketable than definitly go for a database.
If you really want to release a simple game, than I would go for html5 as frontend. The graphic capabilities of JAVA a pretty limited. Also nearly nobody would download your game prior to playing it.
Related
There is web application, journalism related, that uses MySQL databases and presents a web based interface to users.
I want to build a iOS app that does a mobile interface as well. The UI is pretty easy and I have experience with that.
The problem is with the database, which I have no experience with.
I will be learning about databases and probably take the Coursera course on it. I am not asking you to teach me that. I just wanna know which technologies I should invest my time in over the next couple months.
My understanding so far is that the app should not talk to the database directly,
but rather there should be some one on the server talking to the database on behalf of the App.
This is the question and the part I want to understand clearly, so correct me if I am wrong.
I will have to write some sort of a unix program that runs on the server and talks to the db and then communicates back to app? how? using a web view? Using unix sockets to talk to the app? ssh? Which one is cool with Apple?
My preference for writing something like that on the server would be: python(have experience), java(have experience), and maybe ruby(no experience). I'd prefer to avoid scripting languages.
Are they ok? Which one is best suited? Also is this middle dude going to have to be on the same server that has the database or can be another machine on the internet(i'd prefer this, so i can put it on my own VPS and not have to screw up with the server machine)
This is similar to another question from tonight, but you're coming at it from a different angle.
In general terms, an iOS application that needs to be able to run in offline mode will need to have its own database. This means creating Core Data models to store all of the data required by the application. Internally this is stored in a SQLite database.
If you want to make an application that's online-only, it's somewhat easier since you won't need to worry about the Core Data part and can instead focus on building your service API. If you're familiar with Python then your best bet is Django to provide that layer. You'll need to implement a number of endpoints that can receive requests, translate that into the appropriate database calls, then render the result in a machine readable format.
Scripting languages are what power most back-ends even for massive scale systems. In most cases the database will be the bottleneck and not the language used to interface with it. Even Twitter stuck with Ruby until they hit tens of millions of active users, so unless you're at that level, don't worry about it.
For most applications, using HTTP as your transport mechanism and JSON as your encoding method is the way to go. It's very simple to construct, easy to consume, and fairly easy to read. There are probably a number of ways you might go about reading and writing this, but that's another question.
For small-scale applications where the number of users is measured in the hundreds then you can host the application and database on the same server. Even a modest VPS with 512MB of memory might do the job, though for heavier loads you might want to invest in a 1GB instance. It really depends on how often people are accessing your application and what the peak loads are like.
I'm considering creating a little chatbot that learns from users, similar to Clever-Bot (but very different in the way it learns), but I need a way to interface whatever language I use, with mySQL.
I was thinking that java would be the smarter option, though after hunting around it seems a bit difficult to integrate it with a server. Is this true? If not, how would I go about doing that?
Otherwise, would it be smarter to use JavaScript/jQuery/PHP? I'm quite good with these and haven't got a whole lot of experience with Java (but it would be good practise).
Thoughts?
For creating chat bots, consider AIML. And an interpreter that would help you use your AIML files. Going for a backend database isn't a good thing I would say, since AIML is built for Artificial Intelligence stuff,chat bot in your case. Most of the famous chat bots on the Internet use AIML, example A.L.I.C.E .
The application is vb.net front end and sql server express backend. The networks are always cabled LANs.
Installations are small with only a few users, none of whom would have any technical knowledge.
Very little technical support is ever called for and I'd like to keep it that way.
I don't know Java or Objective C or HTML/CSS/Javascript which as far as I can see seem to be the choices for smartphone development on Android, iphone or web based application
I want users to be able to access as much of the functionality of the application as possible for the least effort both in terms of coding and acquiring new skills on my part.
I don't know where to start or which would provide the easiest path.
I don't know how to make the database available to smartphones whilst keeping it physically secure in a small office.
If all things were equal I'd probably learn towards HTML/CSS?Javascript as it seems to be the most widely applicable.
On the other hand maybe I should wait for win phone 7?
To reach the largest number of users in a device independent manner then delivery via browser is going to give you the best results for the least effort.
If you have designed you existing application with a Data Access Layer, a Business Rules Layer and a User Interface layer, this may be as simple as creating an ASP.NET UI for mobile/internet/intranet users.
If your appliciaction is not designed this way, then my approach would be to seperate out the code in you existing into these three layers, or at the very least seperate the UI layer out of the existing code. Then it just a matter of implementing a UI layer for each access method you plan to use.
That way you end up with a lot less code to maintain, and when the businees rules or backend data changes you only have to do the change in one place for all you User Interfaces.
Well, .NET Compact Framework is already avaialbe on WinMobile, so you defenitely should give it a try if you're free to choose which mobile OS to target.
If not, I suppose that for task like this it would really be better to use web interface. If you don't now HTML/CSS/JS - as for me it's not a problem but a great chance to learn new interesting trendy things! :)
I would go with a simple html app designed for a mobile screen.
Android or iphone will only get a % of your users. If you want to get them all, you would need to write in both (and then blackberry and winmo are SOL).
So without seeing the application, it is very hard to know how much work converting vn.net to something you can get at from a web browser would be... but I don't think it would be much worse than a port to android or iphone, and it will allow a much bigger market to view.
Either way, you will need to learn something new. Learning is good though, right?
Ok so sorry for being, I guess, a bit off topic but still I think this is the best place to ask. My new semester just started (don't worry I won't ask you to do my homework) and this time we have a rather cool subject about www programming in general where we have to do a web service, web abb - whatever as long as it's "web". Here's the problem though, my team and I want to do it with Flex and Java EE but we don't have much experience about what are they actually used for. I mean we know you can do virtually anything with it, but we don't really want to lose time on doing something useless. My first idea was to do a "brainstorming" 3D room/service - a place where people could log in have a video conference, a whiteboard, a place to upload pictures everyone could see, some toolbars for google, youtube etc. plus some other features which would make real-time brainstorming easy when you can't get everyone in one place. But is Flex+Java EE really suitable? I mean I'm 99% sure it's doable but is it really worth doing it in Flex+Java EE or was the whole purpose of Java EE completely different?
#EDIT: well this was only one of our ideas obviously. I do know the basics of JSP, Servlets, JPA etc. of course but yeah the main goal of this project is to get some actual experience. The problem is we don't really know is it worth doing something like let's say a social network (something like extended facebook) for gamers (doesn't really matter if it already exists) in Java EE or would it only look ridiculous (because PHP or whatever would be a far better choice)? Bottom line is that we are wondering are only large scale applications (for banks etc.) written in Java EE or is it good for anything (even the smaller projects)?
Adobe Connect has many of the features you describe above and was built using Flex and a Java-based backend. The biggest challenge in a real-time collaboration app such as Connect is that each user needs a way to get frequent notifications of what other users are doing. You really can't get away with polling the server every 5 or 10 seconds because the app won't be responsive enough. For this reason technologies like AJAX's "Comet" or Adobe's BlazeDS / LivecycleDS messaging have emerged. BlazeDS runs on top of Java and has a data push feature that should be sufficient for a school project; its limitations are that it is HTTP-based and has trouble scaling to large numbers of users on a single server.
I've been developing a small card game which is called "Tarneeb". The game itself looks like Bridge card game but with different rules. Anyway, i finished the entire game as a standalone desktop application using Java 6. This is a picture of the game. Anyway, i now need to transform that into a web app with multiplayer capabilities, so the users can for an example make a new room and join existing rooms where the game is played.
Unfortunately, I have no idea on networking in Java but i searched quite a lot and i found some other Java products that may help me (JavaFX, JSP, GlassFish) but i still couldn't figure out what i exactly needed to accomplish my task. All i need right now is the direction to head to and i will do my research and hopefully learn the new skills needed.
Other answers have already pointed you to some resources.
But the biggest problem you will likely have is that it is usually impossible (or extremely time consuming up to a complete rewrite) to "add" multiplayer capabilities afterwards if you didn't plan the architecture accordingly.
As you might have a lot of interaction and a lot of updates which I should - correct me if I'm wrong - be at the client as fast as possible, I'd suggest having a look at Cometd which keeps the http connection open to each client and pushes the updates from the server to the client. If you're using jetty as webserver (and thus its "continuations") it's even highly scalable.
The thing is, there isn't one standard way of doing this which you need to read up on.
How do you want to implement this web application? As an applet? Using standard web pages? As a web start application which people have to download?
The last option would allow you to re-use most of your existing code. If you go with that option it may be worth you looking into RMI as that will probably fit in with your existing architecture.
But otherwise, as S.Lott pointed out, you need to go and learn how to make web applications before doing anything else. Those tutorials would be a good start, also you should definitely learn (X)HTML, JavaScript, and a Java web technology such as JSPs, JSF, or Struts. Exactly what you need will depend on your requirements, without more details it's diffiult to recommend one.
First, learn what a "web site" and "web application" are.
Do the tutorials: http://java.sun.com/developer/onlineTraining/index.jsp
Watch the Glassfish Tutorials: http://java.sun.com/javaee/overview/screencasts.jsp
Once you've done all the tutorials, you will have built a web application.
After you've built the tutorial web application, you can build your web application.
Web apps are very badly suited for the kind of realtime interaction you have in a card game. Yes, it can be done, but it will involve dirty hacks and you'll always have problems with high latency and broken connections. And of course you'll have to completely rewrite most of your app.
If there a possibility of running the game as a Java applet? That would make your job much easier (enable much more reuse) and the end result more usable.
There is no way to port a client based app into a web app quickly. Depending on how you want to go about it, it sounds like you either need to pursue a JSP/Javascript solution or a JavaFX solution. JavaFX actually allows for smoother (smoother than JSP/Javascript, but still going to take more than an afternoon =D ) porting of client based apps, but it has a steeper learning curve than JSP/Javascript technology in general. An interesting note here is that JavaFX isn't just a web app language. If you had coded your initial client based app in JavaFX, you would have about 50% of the work done.
JavaFX
Use Java NIO, it is quite simple and if you will grasp the basics, there would be no real need in all these countless libraries... or anyway you would know their internals. One of the important things however, mentioned here already, is that the game structure has to be adapted for networking from the start. It may be a complete rewrite in the worst case. Basically, you will have to create clients database, socket connections, and from the server side, every connection (represented by a SelectorKey object), should be encapsulated into an object, representing a "joined client". Then read/write operations would be performed to the key's socket. But there is more. The server will have to be the center of your application link, so that you will have to develop an entire network messages protocol for your game (over TCP, there is no need in UDP in this kind of game). Also - read more about the protocols (TCP/UDP/sockets, ethernet), the more you read - the better.
Also! Pay attention to the HTML5 websockets stuff. It is a great thing!!!