Related
I am new in Multiplayer Game Development, I have already developed a offline game and now I want to make it a multiplayer, so with help of my friend we create a server side script in node.js, but I don't know how to integrate this in my c++ project,
I've googled but, can't find anything helpful.
anybody can suggest any tutorial.
Thanks
You've asked a big open-ended question. As Allern suggests there are a lot of things that you can do with networked programs that can extend it well beyond that of a single user game. For instance in my current game there is an access to a version welcome page in html. There are file downloads for campaign/user maps and there are connections to Firebase for leaderboards and other networked resources like ads.
However, I suspect you are referring to the communications between a number of separate user machines all synchronized to keep them coordinated. For this you will need to write some serialization code to transmit to and receive packets from the central server. Typically a serialization package like flatbuffers will be needed to move information from your data structures to a packet and the reverse.
You might also require communication/network software to asynchronously send and receive those packets (this may be included in whatever game engine you might be using). Boost.asio might help otherwise. There are numerous other networking packages and libraries all the way down to the bare-bones unix/POSIX calls (or Windows OS calls).
You will also need software on the server side to log users in, deal with players disconnecting and doing the main work of passing the game packets around. This software may also implement the logic of your game (game rules) and might do saves on the data if you want users to be able to play the game in multiple sessions (like a big dungeon crawl). There might be packages out there that do most of the server side stuff. If so, please post what you find out.
Cocos2dx does have some networking software built in but it isn't very functional as far as I'm concerned. It does have facilities to display web pages and download files fairly easy but the async communication seems a little weak. You can try the Network module in the API Docs which may have what you are looking for.
Since the type of game and how you want to implement your player interaction will dictate how the software is to be built I'm afraid this answer is a little vague. Good luck. Share your insights.
you can use public tools , as a sample is websocket,it can support C++ and javasc
Let me introduce myself a bit.
I have 7 years of C++ (most MFC) experience, 1 year C#.NET and 2 years Java experience.
I know little about web application, what I did and am doing is Windows desktop applications.
I start to do some (minor) (freelance) side projects in the past half year and uses C# mostly as it's more "rapid" than MFC. But seems there's more web projects in this market than desktop projects. And I do not feel good as long as I do not know web development.
So, should I touch the new web filed for me or just stay focus in desktop application but learn more e.g Python, or Frameworks/Libraries such as Qt or Boost?
My gut feeling is that more and more people/companies are moving their projects to the web. My company, for example, has added numerous web applications since I have been there. Another prime example of this is Microsoft (yes, even them) providing a web-based version of Office, their flagship product.
There will always be a need for desktop applications, but I see more web-based projects in the future. It's always good to learn something new, anyway.
EDIT: Oh, and you don't lose anything by being aware of "desktop-based" processes. You may be doing more server-side programming, even if it is web-based. So, in other words, it doesn't hurt to continue expanding your knowledge in that arena, as well.
There will most likely still be a market for desktop applications for many years to come. However, web development seems to have taken over a large share of the development market from what I can see. I would recommend definitely getting familiar with web development as it definitely can't hurt to increase the number of skills you have even if you never stop writing desktop apps.
Since you have experience with C# you might want to consider doing some ASP.NET work. Or if you feel the need to learn a new technology then maybe consider a framework like Ruby on Rails.
I'd really suggest looking into web development - like you said, there are many more web application projects - and you already know C#.NET and Java, and both of those languages have really good API's / frameworks for web development. ASP.NET for C# and Java Servlets/JSPs.
I'd first suggest learning some really basic HTML to learn how pages are rendered, then try to make dynamic versions using the language of your choice. Then I'd learn some other web technologies like CSS/Javascript/some Javascript libraries - then I'd start looking at frameworks that build on top of the basics in the language of your choice.
Oh, and some further suggestions - there are web frameworks that are component-based rather than request-based - you may be tempted to learn these as a shortcut to web development since most claim that developing in them is similar to desktop development. I really wouldn't suggest this - as in practice you really do need to know how the web works at a lower level to develop custom components, include things that the framework doesn't do, or to debug them when things go wrong even when using these frameworks. If you jump right in you can get lost/confused pretty quickly.
Microsoft Office 2010 will have an online version. To me this is a watershed moment for Web applications. Office apps are an important litmus test as once you can do Office on the Web (which has been the case with Google Documents for some time but Office has important symbolic meaning) you can do most things that most users care about.
Desktop apps won't die but I definitely think they're going to take more and more of a backseat.
I'd highly suggest you read How Microsoft Lost the API War if you haven't already. One of the things that's particularly amazing about this post is that it was written in 2004.
I honestly believe that with maybe the exception of OSs and browsers, everything will be a web app within the next 10 years. Having said that, let me clarify that by everything I mean everything that a) involves a UI of some kind and b) can be guaranteed secure.
User-interfaced apps will always at some point need a backend, which will at some level require code that is not being interfaced by humans and not being executed via HTTP. I am always reminding myself that things like 'cat' in Unix are actually programs that the OS is calling, not just a function built into the OS. MySQL won't be a web app (as far as I know), but app that powers web apps. We may get to a point where these apps are fully developed via a web interface, written, audited, uploaded and called all via a browser, but at some level its still running behind the scenes.
On that second point, about guaranteed security, I can very easily imagine a large corporation or government office running 95 percent of their daily routines via web apps, but mandating that certain high-security operations be done on a machine directly interfaced with some sort of mainframe, after passing through the cool doors with the retinal scans and what not. Or simply because they can't risk moving certain mission-critical apps over to the web, from fear of it breaking our losing data in the process.
But with those two things aside, I honestly believe everything will be web-based. With the advancement of Web Services and XML in general, it will be possible to not only access and interact with our data, but to plug our custom apps into another app and extend that interaction further and in any environment we want.
It's like that Apple ad "There's an app for that." Except once people get the real picture, it won't be an app written for your iPhone, but a URL. "There's a site for that."
I recommend learning the Lift framework. It's as easy to use as Rails, and it's based on a statically-typed language for the JVM, Scala. From the perspective of your background, Scala should be middling to easy to learn, and you'll be more likely to be comfortable with it than with a dynamic language.
In my opinion, you have a good chance of picking it up quickly, learn a lot about good practices in web development, and even expanding your programming horizons a bit.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 13 years ago.
I am currently working in a .Net project but from university I have also a good background in Java. Recently I am asking myself, if multi plattform languages (like Java, or VM based like Scala) aren't on the rise?
Lets have a look at Suns WORA write once, run anywhere principle, which had been rephrased to write once, TEST everywhere because in the past especially desktop applications were/are still a Windows domain. But the last years there were quite some changes like
Linux has improved hugely in driver support and usabilty
Mac OS is getting even more popular
native look & feel thanks to SWT/JFace for Java
Rich Client Frameworks (RCP and Netbeans) that save a lot of time and provide rich experience
So, creating applications targeted on multi plattforms should be a reasonable way to go. For example, why should a small/mid-sized company pay a lot of money for windows/mac when it can use Linux (honestly, when you are not a gamer you dont need windows ;) ). And of couse then those companies would prefer software that runs on their machines (maybe the CEO a has MAC because he can afford it but needs the same apps.) Eclipse RCP can provide for example and then it really is WORA.
I like working on C# right now, but in 1-2 years when I want to have my own little company I will use Linux and the development will probably focus on what I've just written. I just wanted to know what others are thinking (maybe I change my mind).
Please don't start a war on Linux vs. Windows vs Mac (I use the first two). Its only about if multi-plattform is a good way for the future, or if you gain more by the advantages of a single platform (special features).
I work for a Qt consultancy company that's been writing multiplatform applications for a few years and I work on KDE's port to OSX and previously at a company providing a client for Windows/Linux/Mac.
The obvious benefits you get from supporting multiple platforms are:
Goodwill from niche communities (including blogging, word of mouth support)
Your developers can work on whatever platform they like so you can recruit them more easily
Your application will probably be slightly less buggy as you'll be testing on multiple platforms
The downsides:
Packaging/distribution/support becomes a big of a pain
Some platforms can get easily neglected
You don't tend to hook into the backend features of the OS as well
If writing a GUI application then you tend to end up with something that doesn't really meet the HIG of any platform unless you have quite a lot of platform-specific tweaking or have a toolkit that helps with this (e.g. Qt)
I still think it's worthwhile and agree with you that it's the future of applications. Really, there is enough good, high-level technologies that there's no need to limit your market to a single platform's users and Linux is a huge in emerging markets so being able to run your application there will be more and more important as time goes on.
Cross-platform solutions I've seen used to good effect:
Adobe Air
C# (with .NET or Mono)
Qt
Java
Web applications (obviously)
Yes, this is happening, but it's a very slow process.
You can trace the trend back to the UCSD Pascal P-system from the early 80's. In the 90's we got the JVM, and in the naughties we got the CLR. These newer VMs each support many languages from third parties. Python, for example, has long had its own VM, but also comes in a version that runs on the JVM, called Jython, and another one that runs on .NET's CLR, called Iron Python.
Other VMs exist that are targeted by multiple languages. The Parrot VM was created initially for Python and Perl 6. The Reia language runs on Erlang's BEAM VM. I'm sure there are other examples.
On top of that, there are many languages that have been cross-platform for a decade or two, like Smalltalk, early versions of Perl, Ruby, etc.
This is all a kind of long-term tectonic shift. It's driven by the fact that computers are getting faster, while many tasks we use computers for don't need to get faster. So, we can use high-level languages to write programs to do these tasks, where it wouldn't have made sense in the past. In the early 80s, the successful new word processors were written in assembly language. In the 90s's, C. Today, Javascript.
Check out mono http://www.mono-project.com/Main_Page if you like C#
Use SWT (http://www.eclipse.org/swt/) if you prefer java
YMMV
If you are going to spend hundreds of thousands (or millions) of dollars developing an application, it makes sense for it to be capable of running on as many machines as possible. Just a few years ago, platforms had many platform-sepcific features, but that distinction is rapidly disappearing with the availability of cross-platform compilers like Mono.
All depends of the activity domain of the software that you develop...
If end users are or plan to use multi-pateform so you must care about it ! If not, you can develop on the plateform used by your customers !
Of course, some peope would say : even if all customers are on Windows, the development is more productive on MacOS... but it's an other question !
In general, your users will generally prefer an app that looks and behaves like a native application. Many of the cross-platform frameworks are really very good at emulating the native look and feel. Just be aware that if your app doesn't feel native (maybe through some quirk in your toolkit of choice), critics will beat you over the head about it forever.
Also, The issue of using cross-platform toolkits really depends on the application domain you're targeting. For example, if you're working with video, creating a cross-platform app with a good user experience is very, very challenging. On the other hand, CRUD (Create-Update-Delete) apps commonly used inside of enterprises are excellent candidates for developing with cross-platform languages/toolkits.
Also, one reason that Java is very popular for applications deployed inside of enterprises is the ease with which you can deploy updates (via Java Web Start - I think C# has a similar update technology too). However, once you step outside of the walls of the business most users will shy away from Java Web Start apps.
I've been developing web apps for over a decade now, all the way from CGI to ASP.Net and Struts+Spring+Hibernate. The prevalent architectural style seems to be server-assisted MVC, e.g. Struts, Ruby on Rails, etc. Recent developments lead me to ask if these are on the decline.
Adobe's AIR and Flex
Microsoft's WPF and Silverlight
Google's Chrome and Gears
SOFEA and SOUI
All of this leads me to believe that we're starting to come full-circle after a 15-year distraction kicked-off by the invention of the web. Over this period of time, we've been so fascinated by all the web has to offer that we didn't notice that the usability (and the developer experience) of web apps pretty much sucked in comparison to desktop apps. It seems we're now saying "Screw this! We love the web's benefits but we also want better usability, offline capabilities, and better integration with the desktop!".
All of the above mentioned developments seem to be moving us in this direction of putting the presentation logic back where it used to be: the client. Don't get me wrong, I don't think server-assisted MVC frameworks are going away anytime soon, but I do think they are on the decline and RIAs and RDAs are on the rise.
So, what do you think? Are server-assisted MVC frameworks near their peak?
I agree, to a point - we are becoming are more client-centric, but I think this is because the clients are actually advancing in a standardized way.
We started out with everything on the client - because thats all there was. Then it was client-server, which separated the two, then gradually the client bit was thinned out and pushed back to the server, for one reason:
clients sucked (win95, macos<10, unix X11), and deployment was a nightmare. Deploying a browser was trivial.
Thats changing tho. Air is an easy install, as is .NET 3.5. Air apps are easy to deploy (click here - say yes!) as is a WPF Click-once app. The network is now a defacto part of the environment, not something special that had to be added. A database is something you can embed into a silverlight app (SQL Server Compact Edition), or an iphone (SqLite), not something you have to have a big server for.
and everything has auto-updating, which makes the post-install story a lot better.
I dont think they are on the decline - I think the logic has just been pushed out again, and it'll be pulled back in the future, only to be pushed back out etc.
Silverlight/Air/Flash etc are all very powerful, but HTML + Javascript, which is the basis of the server MVC frameworks, has come forward massively, esp if you ignore the b'stard that is IE6.
Regardless, I'll still be writing the backend for RIA's in a server-assisted MVC framework, even if they are throwing out JSON, not HTML. So while they are no longer the be-all, they are far from dead (or peaking)
Lets clarify something!
MVC is only a design pattern for the seperation of concerns. There is no really relation to server side frameworks.
There is no technical Web 1.0 or Web 2.0 ... JavaScript and Flash were there for years. It's only about social networking, tagging etc.
The server side frameworks are not dead at all. I agree with Nic Wise in case of the bad client architectures/rendering. Can you print a HTML page (every time in the same way)? No, you can't, because every browser(-engine) has it's own representation your HTML description. Only because JavaScript/Flash... are restrictions for a lot of people/companies, the server side processing will stay there for a long time.
Developing "Run anywhere" JavaScript has been a burden for a long time! Nowadays we have Frameworks like JQuery which do this job for you. I've written my own homepage in JavaScript, using EJS (Embedded JavaScript) for the templates/mvc. The old bloated JSP/PHP pages have shown, that differing the business logic from the design is a really good thing.
A bad problem of every web application is to decide, where you save the state of the application! If you choose a bad way, you are not able to scale. Client centric frameworks with service oriented backends allow you to scale very good.
I have been working a little bit with SOFEA/SOUI. If you have an ready framework stack for the most common problems, you'll love it.
Air and Flex are nice, but they bring in a lot of restrictions (Flash/JS...).
Google's Chrome and Gears need you to install Google software at your computer. Who has Gears around here? Gears hasn't established as a wide distributed standard.
If you have experience with Hibernate/Spring and Struts, you sould try Grails! It is nice to develop GWT/FLEX&AIR/SOFEA&SOUI backends and also for the good old server side HTML rendering.
I like SOFEA/SOUI because it isn't such invasive, it offers an investment protection (SOA services) and high rate of reusability. It's also a nice way to move the load from your server to the clients.
What are the compelling features of MFC? Why would you select it for a new project?
MFC was a good option 10 years ago. It is still a good wrapper over Win32 API but unfortunately obsolete.
Qt is a better option with one big advantage - it is platform-independent. With MFC you're doomed to Windows.
I still use MFC for all kinds of applications. MFC got a bad rap from it's early implementations, but it is excellent now. I find it quite a bit more convenient than WTL as well. Plus the GUI tools in Visual Studio are already setup to make it easy to rapidly develop GUIs with MFC, mapping controls to variables, DDX, etc.
For desktop applications that I intend for wide distribution I still go with native Windows applications, usually in MFC, because we're still not at a point where you can depend on your customers to have the version of .NET that you'll be using installed and asking them to install it will cause you to lose sales, not to mention the customer service headache when they run into problems installing .NET as a result of trying to get your app to run.
The advantage of MFC is that it's still nicer than coding to bare win32 and you can distribute a native .exe that doesn't require a 23-50Mb runtime like .Net.
Now, if you're concerned about those things there are better alternatives out there: C++ Builder, WxWidgets, etc. But some places won't consider non-Microsoft tools.
You could sort of reword the question, why would you select C++ over C# for a desktop app. C++ still offers speed advantages which matter for some applications (I work for a company that creates software for electronic trading. Speed matters a lot).
If you are going to develop a desktop app aimed for Windows only in C++, then MFC is the most mature choice, with lots of free code based on MFC on the internet, lots of knowledge.
Apart from win32 api itself, MFC is the only mainstream Windows programming technology that is still alive and well in 2011 after 15+ years. Back in 2001 everybody said 'MFC is dead, it's all Winforms now'; in 2005 everybody said 'MFC is dead, it's all XAML now'; now it's 2011 and Winforms and XAML are dead (OK XAML maybe not really dead, but way past its prime) and MFC is still being updated with the latest developments (ribbon, Aero extensions, Win7 API's etc).
Of course, that doesn't guarantee anything for the future, but over those 15+ years, a lot of MFC code written, and it will remain in use for the next decade or decades. It may not be the prettiest tech but it's well-understood (its good and bad points) and is not a moving target like other hype technologies are, meaning that people who actually want to get stuff done can sort of rely on it (well more than on the alternatives, anyway).
(same goes for C++, btw)
Here's a possibility - imagine an application that would require a large amount of memory, say a graphics program, a game or maybe some high performance business application. It's no secret that .NET applications hog memory - in such a case, you may want a lean MFC app for the core of your application. You can always load up and use .NET components, controls, etc through either COM callable wrappers or directly through C++/CLI.
That all being said - MFC is a pain. Consider WTL instead - you can still call into .NET if you need to, the same way as I mentioned above for MFC. WTL is a lot nicer than MFC :-)
Apparently it is still a good choice for applications for windows-based hand-held devices, such as point-of-sale devices. In these, resources are limited so things like memory management become more significant.
Quick Tour Of New MFC Functionality
I hear they have a new ribbon control. If you're into this sort of complexity. Here's a screenshot of a newly generated app:
(source: msdn.com)
Really, it's just a widget update. So do we need more widgets?
The existing windows API is entirely C based. If you want to use C++ (and you probably should) then MFC is the logical choice if you wish to stay native (i.e. not using .NET).
MFC is just a set of object-orientated classes over the top of the C API. Plus quite a few additional "helper" classes that make it easier to do everyday tasks.
I think not.. MFC would lose out in
Level of abstraction
Development Time
Troubleshooting time
Learning curve for new developers
Future proofing (although now that's questionable.. with something new coming up every 3-4 years)
Finding good people who know their MFC
Easy to use controls
The only place where MFC would probably sneak past is if you have some very performance intensive applications like you have things on screen that need to be redrawn every 10 msec or 1 sec. "Managed" apps still haven't managed to jump past that hurdle.
MFC was an important step in the evolution, but now better options are available.
On design & technical merits alone? Sorry to be categorical, but none. It's a poor design, a hugely leaky abstraction where you have to fall back to Win32 API programming, misuses C++ egregiously, and is firmly targeted on yesterday's technology: you won't get a modern (or even an attractive!) user experience out of an MFC app. If you can get C# developers and you don't have serious hardware limitations, go with WinForms.
External factors such as the availability of competence for hire, training programmes and third party components, on the other hand, can still extend its lifespan, at least for some kinds of applications: small & simple, targeted for special applications with reasonably few users, preferably in-house.
If you are developing Windows CE and mobile apps in C++, as Einar has already mentioned, MFC is a good choice. If you make this choice, MFC then also becomes a reasonable choice for the desktop as you can use the same code across desktop and hand-held devices. MFC remains a good perfomance / easy to implement combinitation in this scenario. Personally, I use MFC in conjunction with Stingray libraries in these enivornments which gives a very good interface, good performance and is quick and easy to implement.
I would say that speed and footprint are good reasons over .NET.
It's probably true that you'll find it difficult to locate good MFC programmers, but thats just as much because the modern languages promote lazy programming techniques and most programming courses gravitate towards them as they are easier to teach.
I've written cross platform code for years so when I need to write something I always have a very thin abstraction layer between it and the system calls for almost everything except posix calls. That way you can code it go MFC but quite easily convert it a different API later if needed. My base set of c++ libraries that I use for everything does this with a small System class. I currently have it using MFC for Windows and I also have it using XWindows for Linux and a native Mac version as well. And later on when I port it for a handheld it should be quite painless.
If you want to take a peek, it's LGPL'ed and is at:
http://code.google.com/p/kgui/