Please, what kind of game destribuição for windows?
For example, how deployment games Steam?
The output .exe file does not run. it displays the message “This application can only run in the context of an app container.”
Tks!
I am not sure how many of our users are deploying to Steam, but I think that @corytrese has experience with this. Perhaps he has some advice.
1 Like
Thanks for the answer!
Deploying to Steam is not that difficult.
You are running into a different type of issue, however. That error message is usually about an app container being missing.
I have not deployed Cocos2d-x v3 games to Steam – we found that v2.2.6 is a better choice for our Steam games.
However, the main thing you need to do is build a classic reguarl old win32 app that links to the Steam SDK.
I am here to help, just post your follow up questions. I’m sure we can get you going.
1 Like
Can you expand on that a bit?
I can try to expand on it a bit. Cocos2d-x v2 and v3 take different approaches to implementing the desktop.
My understanding is that v3 uses GLFW3 and shares implementations between the desktop OS and v2 uses different implementations on each OS. While the latter sounds like a weakness, it is actually a strength when it comes to OS features.
To succeed on Steam, you need a certain minimum set of features that are above and beyond the requirements for mobile. Features like mouse-hover, positional sound and OS specific hardware support (Magic Mouse, Magic Trackpad.)
While v3 contains a much simpler GLFW3 implementation, it is not easy to customize for the OS. The features you need for Steam will be what determines if you have a “Mixed” review or “Very Positive.” I have deployed games to Steam that did not have the required features and it was a disaster.
If the v3 desktop implementation was sufficiently developed to support things like Magic Trackpad gestures, mouse hover and other required features I would feel differently about it. However, as it stands, getting a version of Cocos2d-x to run on Steam with all required features is much easier on v2 than it is on v3.
1 Like
@corytrese thanks for your help!
To build a classic win32 app is necessary to run the project through the proj.win32 folder … I had not tried it.
I think the point about the version will be very relevant to me!
tks!
The key to integration with the actual SteamSDK is linking steam_api.lib and following the documentation on Steam’s developer web site about how to get an auth session ticket and correctly call the Init for SteamAPI.
They have pretty good, although brief, documentation on how to do it. The code is identical on all three platforms, so once you get it working in proj.win32 you can copy it to proj.mac and proj.linux
The fact is that Steam users have high standards. Out of the box, no version of Cocos2d-x will make people happy on Steam – but with some work I am sure you could make v3 perform satisfactorily just as I have done with v2.
If you are starting from scratch, v3 could be just what you want to use. Perhaps in a few months I’ll be asking you for tips on how to get v3 up to Steam standards.
@corytrese Why no version Steam make people happy on Steam?
Because there is much diversity of hardware … diversity of screen resolution, or performance.
Tks for your time!
I’m not sure I follow the question.
Players on Steam have high standards and take a negative view of anything that appears to be a mobile port.
My point was simply that to have a well received game on Steam, you need to meet the player’s expectations.
Those include things like volume control, full screen, mouse hover, configurable resolution, keyboard bindings, mouse wheel, Steam trading cards and high resolution graphics.
All of those things are achievable with Cocos2d-x (probably either version) but they take extra work.
This information will be useful for me … Thanks a lot!
Corytrese, I have an American football game (two, actually, but I’m combining them into one for the PC version), and I’ve successfully converted it to run in Windows with cocos2d-x 3.9, but I’m concerned after reading your post.
Also, I’ve never created a Steam app before, so I’m trying to learn the Greenlight process and how to successfully create a Steam version. From what you’re saying, it’s a pretty straightforward approach of linking to their library, right?
What I’ve done:
- user can toggle between windowed mode and fullscreen, in the settings
- there is an Exit button on the main screen (in addition to the normal Windows x button in windowed mode)
- my editor supports both a virtual keyboard and the physical keyboard
- music and sounds sound great with my 5.1 speakers
- added pthreads support for fast (VERY fast) simulation of entire seasons in memory (less than a second, and that’s running every play of every game)
I don’t have mouse-over tips, but what I do have is that every concept and play in the game has a “?” icon to the side, which brings up information about that particular option. For example, if you tap the “?” next to “Counter Play” it describes what a Counter is and the Pros and Cons, as well as when it’s good to call.
I’ve shown the game to my 19 year old son, and he thinks it’s good to go, but I’m curious what else you think I might be missing?
Thanks!
-Dogwalker
Sounds like you’ve got a great start. Greenlight campaigns can be tricky to complete – but the bar is much lower now than it was a few years ago. You won’t need as many votes today as you did in the past.
Mouse over and full screen support were our biggest sources of negative reviews for our releases, so I’d advise anyone releasing on Steam to consider trying to add those features.
I’d also caution anyone releasing to Steam to make Steam their first release of the game. Games that are released to mobile (or web) before Steam tend to generate a lot of negativity.
My final piece of advice is to use an analytics package and crash reporting system that allows you to collect crashes and statistics from the users. Once you have a few thousand people playing the game … they’ll find crazy ways to crash/break the game that you never considered – and a crash reporter is worth the effort so you can respond and triage issues from players.
Thanks, Corytrese. Unfortunately, my game is coming from the mobile world, but I’m seeing places (such as looking at career leaders) where I can make use of the extra real estate on the PC. I definitely agree that I need to add analytics and a crash reporter!
I’m a little messed up in that my xcode project is still on cocos2d-x version 3.4, while the PC is on 3.9. I want to update both to 3.10, so I need to look into the best way to do that. Do I need to create new projects with cocos -new, and copy everything to them, or can I just create an empty project and then copy the cocos folder to my existing project?
Thanks again!
I only use version 2.x so I have no idea.
Hey @corytrese buddy,
Just passing by to thank you for all your advice. It is very well explained.
Keep having a great one, and hope to hear more of your dev stories soon.
In case it helps anyone else, I created a new project after checking my project in (I use git). I cloned my repository back in, but deleted generated folders (proj.android, etc), keeping the new ones. I carefully merged my AppDelegate with the new one (very easy, they were almost identical).
Then using git compare (I use SourceTree), I identified what differed in proj.android, etc, and made simple changes.
And voila, in one evening, I’m now fully on cocos 3.10! Sweet! Kudos to the cocos team, as always!
1 Like
Which crash reporting package are you using please? I am targeting Win32 as well.
For the time being, I’m using:
http://crashrpt.sourceforge.net/
But I will switch to HockeyApp soon, as they have added support for win32 applications (which was previously missing.)
corytrese, I hadn’t thought of mouse hover support, since I have those in-game help buttons, but you make a great point. I don’t know whether I’ll have time to implement something like that before my target release date, but I’ll research it. I do let the user toggle between windowed mode and fullscreen, but I’m currently selecting a fixed window size if they choose “non-fullscreen.” Did you do that as well, or do you actually let them choose from a range of window sizes? I guess the safest option (but probably unpopular) would be to only support full screen?