Well for the first point, its like I said, its all about the level of entry, in terms of difficulty of making a game and getting it infront of customers mobile has significant benefits over desktop, desktop you end up with a lot of stuff like appealing to steam greenlight or trying to advertise in other ways. Steam is probably one of the best selling platforms out there, as evidenced by a lot of small developers saying sometimes 80-90% of their sales come from steam.
Unless you're targeting the casual audience most people looking for "desktop quality" games are going to look for more substance than the average phone game, 3d is usually a big draw, and people tend to be more suckered in by a promising concept than a finished game, as evidenced by how many early access games are topping the best sellers list on steam.
Flappy bird, although an extreme example of simplicity, demonstrates how simple a game can make money on mobile, the problem these days is that the market is getting flooded so that is much harder to do. The barrier for entry hasn't really changed at all, just the level of competition.
Well that's why I would never suggest becoming a game developer if you want to get rich, unless you aim for AAA you're probably going to be lucky to scrap together a midrange salary, and if you do land in AAA you're going to be working for that money, generally much harder than a coder or whatever other profession in different lines of work.
Labor of love.
Yes games are worth less on mobile but there is also a much bigger audience and people are, quite frankly, a lot less frugal with their money when they go around seeing a bunch of one dollar games. Some people buy a pretty ridiculous amount of them and almost never play them. A lot of mobile games are taking that pay to win swing as well, free app and then milking people out of money through paywalls.
Don't get me wrong I'm not saying like, MOBILE OR DEATH, I just personally think if all you want to do is churn out games and not worry about mastering coding or something you'll probably do better financially aiming for something like that, or maybe website games.
I see where your coming from, altough I am not 100% on board with your conclusions.
Yes, the barrier for what is seen as a "Goodlooking mainstream game" is still a little bit lower on mobile than on PC... yet still, the quality of the AAA mobile games is increasing, the top 3D titles are already out of the reach of a single individual to complete in a sensible timeframe, so again people will need to start target niche and Indie / Casual markets on mobile if they push out non-AAA games.
The casual market might be bigger, and true, you get more "whales" on mobile than on the PC most probably... yet to cash in on the whales, you need a very well thought out free to play strategy that might again need more resources to come up with an execute, and the masses of spenders might just make up (or not) the lower pricetag you can put on your product.
I see it this way: if you are a single dev, you have no chance competing with AAA, or even high-end Indies. You need to come up with something original, something different, and embrace the compromises you have to make along the way. Your graphics will be scrappy compared to AAA, make it a feature. Your game will be rather short, or have less features. Make every feature and level you can put in count.
In the end, you will only attract a niche audience. That niche audience might be bigger on mobile, but in the end they will most probably be spending less on your game, besides the Whales.... and harpooning the whales is an art in itself.
There are more than enough successfull 2D Indie games on PC (Fez, Thomas was alone, ...) that use graphics and gameplay that could also run on mobile devices... yet still they found an audience, could sell it for 10x as much as they could have on mobile, and made good money with it.
True about the low barrier of entry to the app stores... yet, if this is a good idea and really good for game devs IDK... read stories about devs complaining their games (that were not too shabby looking at all) getting zero attention and being flushed out from the new releases page in houts or worse, just because of the MASSIVE influx of new games being released every hour to the particular app store.
You might need to do more to get unto Steam.... but AT LEAST you get less noise distracting potential buyers from your game this way (and I am aware that even so, lot of crap makes it to Steam).
The marketing need differs little between mobile and PC. No App store will do the marketing for you, you will have to come up with a good strategy yourself. AFAIK this is the point where most new devs will fail.
So I don't really see much difference between PC and mobile when it comes to publishing and marketing. Mobile app stores set up less roadblocks, but your game will more likely be drowned in the flood of noise apps and games that plague those app stores.
That I do agree though: If you first and foremost target is to Publish something and getting it to a storefront, mobile is your best bet. Maybe you will make less than if you put the same thing on Steam (If you get the game on Steam and its at least half decent), and most probably your game will not sell many units until you have a marketing genious behind it. But at least you get the street creds for having a released game, which is worth alot in itself.
True about the "labour of love" thing... don't rely on Indie game dev to pay the bills until you had at least one big hit.
Thanks for the answer Gian!
I'm going to take a look at devmaster for sure never seen that site before and it looks really useful.
I'm not really saying that Unity isn't a good fit.
It is a great engine and made many things with it but I was just thinking that there might be other ways.
The only downside is that things can get quite messy with big projects and with that I mean the way scripts work etc.
I love OOP and I'm just missing that feeling in Unity but it's not a big issue.
I looked at the asset store before and proton seems to be a good solution any thoughts on that?
And do you know the big difference between the framework from onedayitwillmake and most other regular and networking solutions?
I know there are many but the concept of all is pretty much the same and the concept of onedayitwillmake seems completely different.
The big advantage I see with this is that the game can just fully run on servers and clients just get a snapshot of it pretty much.
Only player input would have to be send from the client to the server but about the data send from server to client I don't really get it.
Like is it sending all pixels to the client?
I haven't dived very deep in to networking so I should probably first just continue learning more about networking and then I can probably figure it out.
I have the time for this project and I do it to learn things and that's also the reason I want to add multiplayer as I don't know much about it yet.
Look, I am not the networking guru, and I have constrained myself to only using local multiplayer until now to avoid any unneeded complications until my game prototype is ready for it, so I am not the right guy to give you real advice on the topic.
the weird name you mentioned (onedayitwillmake) gives me a hompage of someone as the first google hit. Are you talking about this page (http://onedayitwillmake.com/)? Besides the rather ugly web design (though that means the guy must be a good programmer if I go by empirical evidence, programmer homepages where ugly since the dawn of the internet :) ) I see lots of links to coding algos and solutions there (that I cannot open at work)...
EDIT: And by not just taking the first google entry I see now what you are talking about on github...
Well, this is a rather hard question to answer. Somebody needs to have expieirence with existing solutions (Photon, Smartfox, whatever else is on the market), AND take the time to analyze the solution from this guy.
What I do feel competent enough to give some advice on is your doubt about scaling Unity to larger projects: Yes, I see where you are coming from. And I do share your concerns, to some extent.
Nobody is stopping you though from mixing Unitys approach with a more standard OO approach. This is what I do. I use Unitys component approach for all the Editor facing scripts.
Behind the scenes I use a normal OO approach, as this is what I am most comfortable with. I also feel mixing and matching can add something to the standart Unity approach.
For example, only classes that get used as a behaviour script in the Editor are setup as a MonoBehaviour object. All classes that are used for other purposes are normal Objects. The MonoBehaviour classes can be seen as your hook-ins for Unitys game loop, and from there you can communicate through normal OO means between objects.
Is it a cleaner way to work than in a strictly OO based Engine? No, not really.... but it gives you options, as does the fact you can use behaviour scripts and drag and drop them in the editor to setup your scene... or you can ignore the editor for the most part and do things in code if that is more your thing.