starbasecitadel

I use UDP in both directions. 

I've tested at least 20 different places, including coffee shops, libraries, restaurants, 3g/4g cellular and never had a problem with firewalls/router incompatibility.   Maybe my sample size is too small, I'd really like to have about 200 different places tested before calling it a day (that's what Beta is for), but that has been my experience. 

While I haven't hit any router issues yet, I certainly have seen differences in packet loss and latency.  A couple Starbucks location are the worse: they average about 15% packet loss, 1200ms ping.

This will help us to advise you by suggesting alternatives which do not share GM's limitations.

That makes sense if by "mastering gamemaker", OP means he has created fully playable game(s), possibly including publicly releasing them using GameMaker, and is now frustrated by its limitations and wants to create a more advanced game.  

If on the other hand OP means he is a master of all the various features of GameMaster, using their coding logic and full capabilities, but has not actually completed a single playable game (eg he can make every feature individually as a stand along prototype, but not compose them together as a cohesive product), then the next step for sure would be to create a game or two on GameMaker and release them.   A trap it is easy to fall into is to learn dozens of new languages, SDKs, engines, and other technologies for the sake of improving performance or the cool new features they have, without actually doing anything useful with it.    

But if he has created some GameMaster games he is happy with, the next step is to answer these 3 questions:

  - what kind of game types appeal to you the most (MMORPG, FPS, Facebook, strategy, shooter, social, etc)?

I wouldn't even think at all about specific languages/SDKs/engines until those 3 questions are answered. 

I agree, you definitely won't be in the "real" developer forums, or have access to their internal ticketing system, feature lists etc.

But even so, it sounds like there will be some opportunity to talk directly with their dev team, at least to a limited degree.

You really first should decide your target platform that you are most interested in, and if your primary goal to work on other people's games at a game development company, or your own games for side projects hoping to start your own company one day.

On platform, I recommend mobile for a number of reasons.  It is a rapidly growing market with much less saturation then PC, and gamers are more accepting of hobbyist games than on other platforms.    Also, job-wise the number of mobile game dev jobs is skyrocketing while there is less growth for jobs in other platforms (though they are at a much higher job base).   You just have a lot less competition on mobile right now, and that makes it easier to get hired and also move up the ranks as you are competing with people with < 5 years in mobile versus often 20 years on PC/console.

If you go to mobile route, I highly recommend CoronaLabs / Lua to learn first.  It is easy to learn and get a game going much quicker than almost any other environment.

Many new game devs believe getting into something with a higher learning curve, but that is used more often by some "hardcore" professionals, is a way to shortcut the process.  I strongly disagree!   The biggest problem by far for new game programmers is that they fail to ever produce any playable game.  Your resume and skills are way more impressive with a successful iOS game that is actually selling (even if only $1000/year) written in CoronaLabs, than someone who has strong C++ game dev skills on paper but has never produced a public game.

This isn't to say you should never learn C++, I'm just recommending Corona for your first couple of games-- then at that point you can either keep going with it (as you may find success with that route), or at that point start learning C++.   But it is really important to build a strong foundation of game dev skills first, and not trying to make life difficult by trying to learn game skills in a language/sdk tool set (C++) that requires a far steeper learning curve.   

 I never got into probability or percentage of vacancies that require specific skillsets.

I think that is a shortcoming of the analysis, however.     The rules of supply and demand are at work, so since there are only a small number of positions in the development process that don't require coding or artistic/musical skill, and many people who are interested in those roles (designers and producers), then your realistic chances of getting that position are much less likely.  Really the only position that has large numbers of non-coders/artists is QA, and even here there are far more people qualified for that position than for coding and art/music, so they are hard to get as well.  

In terms of roles such as lawyer and accountant, these generally aren't involved in game development and so really shouldn't be factored into this discussion.  

Maybe I have just missed the kinds of threads you have in mind though, or I am checking the wrong sections (I probably check Game Design the most here).  The ones I've seen are almost always along the lines of "I want specifically to be a producer or designer, and here is a brief or detailed description of the game I want to build.  But I have no coding or art experience, nor any coders or artists on my team."   For those kinds of people, they typically seem so wedded to their own specific game design that it is hard for me to imagine them being happy in another role like QA for someone else's project.  It is for these situations where the standard advice is they should learn coding or art, and I think it is good advice.

And even if it were all about indies and school projects - does a broader perspective really hurt that much? Is it that annoying, incorrect, wrong, revolting or unacceptable to look around and see there's more to game development than struggling to release a game for $0.99?

The answer here is going to be different for every person.  For some people, they would be very happy in any position contributing to the game development pipeline for any sized company on just about any project.  For them, a broader perspective can be a good thing.   For other people (and I'd include myself here), a large part of the fun is being a game designer for specific games you or a small team you are involved in comes up with and build it from scratch.   I've had several opportunities to join game companies but so far haven't been interested.  I'd much rather do what I'm doing now, which is work on non-game stuff for my day job, but have tons of creative control working on my own game on the side.   Which path is better will depend on individual personalities and goals. 

I would recommend CoronaLab's product for most kinds of 2D mobile games.   If you have programming skills, but this is your first mobile game, then it is perfect.  You can come up to speed much more quickly with it then the others.

I'd only go with one of the others if you are doing something unusual enough that it requires more low-level control, in which case I would recommend Marmalade or possibly Moai, or Cocos2d.  Each of those 3 has a steeper learning curve, but you can have finer grain control, it just depends on what you are doing.   But for probably 95% of the games and applications I've seen for mobile, Corona would be a great choice.

I have not heard about even one indie studio where the founders were not programmers/artists. Directing and coordinating simply is not what is required.

Yeah, the issue is one of credibility.  If you have at least a couple hundred thousand or more to pay some salary that is one thing.    Raising that kind of money is not easy, unless you have a couple top-selling games you played a leading role in already (and even with those credentials, fundraising is by no means easy).

Getting people to join without pay is difficult, even if you give up substantial equity.   It requires you to sell a vision.  If you have never done a game before, you lack credibility.  If you have nothing to show, you lack credibility.   Even a visually appealing, polished, GDD and presentation that you took 3 years to write, sadly, probably isn't going to be enough to give you credibility.  At a minimum, you need either some nice art, or a prototype, to have a chance at successful recruiting people to join your team with no salary.

That's the approach I'm taking-- program a playable prototype, with the initial art coming from cheap royalty free images as well as royalty free sound effects which I hope to complete end of this year.   At that point, I'll be able to shake hands with artists, hand them my iPad and let them play the game as part of my recruitment pitch to see if they are willing to join the project.  

The #1 credibility question that prospective team members and investors will ask you for is "can you successfully produce something real"?   

Which answer will have a higher success rate making the pitch?

"Here is a working prototype, it is a playable demo version though it is missing many features and art.  Play this game and let me know what you think"

"Look at this concept art and UI mockups for all the major screen types that I've put together"

"I haven't programmed anything, I have no artistic ability, I never have been involved in video game production before.. but check out my game idea and design document"

I typically see this as trying to find niches that game giants or other popular games do not cover.  

This is the key.  As an indie developer, your one and only edge over a large corp is also an extremely powerful one, you have a much greater ability to take creative risk and develop something unique.

When you work for a large company, what motivates the vast majority of people is keeping the steady paycheck.  Yes, even in a game company filled with creative people, after a few years some of the big company bureaucracy mindset that is so common creeps in for most organizations.  You don't want to be the producer who tries something unique, and it fails; even if you keep your job, you may very well get demoted or at least lose a lot of prestige and be known as "the one with that looney idea that flopped and cost us millions!"     So, you stick to what is safe; ideas that are far less likely to be home runs or particularly innovative, but are also much less likely to lose lots of money.  

As an indie developer you have more room for risk taking, mostly because your company is still relatively small and flexible.  You still are worried about your paycheck, but there is a more entrepreneurial feel that gives you much more flexibility.  

Then, as a hobbyist developer, you have the most room for risk taking of all.  As a hobbyist developer, the cost for you failing is so low (since by definition games aren't your primary source of income, so it is pure opportunity cost you are risking).

The key is coming up with something that has at least some unique feature or innovation and running with it.  That doesn't mean you have to create an entirely new genre or paradigm in the way that Ultima created the RPG genre, id Software created 3d fps,  EverQuest/WoW for MMORPG, Minecraft for sandbox etc.   That is of course awesome, but far more commonly you can still become very successful within a normal genre with a couple innovative features.

In fact, I would ask myself "is my innovation so unique and daring/risky that major studios would avoid it?"   The space where they refuse to operate in is exactly the space where you should be operating.    This is a space where on the downside, it is more risky and you should expect a lot more projects to fail, but it is also where home runs and serious breakthroughs are more likely.

Innovation does not have to be limited to game design itself (though that is what myself and probably most people here are interested in).  It could be a marketing innovation, in much the same way affiliate marketing propelled the success of so many  early internet businesses across many industries.  It could be an HR innovation, where you discover a very effective way to successfully recruit talented high school or college game developers.  It could be a teamwork innovation, where you create a new communication style that significantly enhances team productivity.  

Opportunity to take innovative risks is your one and only edge as a hobbyist/indie developer-- milk it! 

There are some cool ideas here for sure in terms of the design.

Hey guys, i've just started learning to code

However, as a project for a new coder?  No way.. it is far too complex.     I know it isn't as sexy and inspirational to start with a simple single-player game like Tetris, but that by far is a quicker way to build up your skill set than starting on something extremely advanced, and probably only making it 5% complete after 1 year and then getting frustrated and possibly never trying to make a game again.   

For example, my first game was a ASCII based Mines of Moria kind of game, then did some simple 2d sprite animation stuff, then a bit later did a single player Stratego game, then added networking multi-player to it, then did Chess, etc.    Walk, then run!

For some business applications, where requirements are very rigid and the general type of problem is pretty familiar, then a waterfall / non-iterative approach can make sense.

But for game design, at least for me personally, an iterative approach has been useful enough that I can't imagine using a non-iterative approach, from a practical basis.

To take just one example, I had initially imagined/planned/designed that the movement UI would be heavily accelerometer based.   But, before I settled on my current movement AI, I quickly prototyped 3 different UI's: accelerometer, traditional buttons, and swipe. Over the course of a few weeks, myself and 2 others tested all 3 prototypes, and I made quick coding tweaks to fix bugs / fine-tune.  We found that what I envisioned (the accelerometer), was absolutely terrible and so got scrapped completely and ended up going with swipe.  

I'm very glad that I (or anyone else) did not spend dozens of hours making extensive, detailed plans based on using the accelerometer, as all that design work would of been wasted.  

This isn't to say a nice design or an "ideas guy" is bad, I think they can be extremely useful in some situations.  Specifically, where they are not set in stone but willing to rapidly iterate, and you already have enough programmers and artists.

For a small hobbyist team, an ideas guy even without programming or art skill could still be extremely useful to the team, as long as they are able and willing to do a lot of non-design tasks and grunt work the team needs too, as opposed to spending 90% of their time on ideas.  If they spend 25% of their time or less on idea generation / design documentation, and 75% or more on other useful tasks, it could work out. 

I'm talking about things like:

 - recruit additional members: go to arts colleges and compsci colleges, hand out business cards, tack on your posters, go to game boards

 - community outreach - go to web boards and chats and try to find new alpha testers

 - find and purchase things like server hardware as needed

 - schedule interviews with prospective new team members

 - book meeting rooms / library room time / videochat and coordinate schedules for team meetings

 - grunt work to relieve the artist: sometimes the concept artist needs 100 images to be resized in a way you can't automatically batch it, this is an area the ideas guy can help out, getting the artist back to working on the aspects of concept art creation only they have the skillset to do

 - update the team's game website with content / blog posts

 - research cost-effective marketing plans

If someone is the "ideas guy" and refuses to help out with these kinds of things, when the programmer(s) and artists are overloaded with work, that is probably what people are objecting to.

Now, if the team is big enough, say 10?  20 people?  At a certain point, I think a full-time purist ideas guy / game designer or even several could make sense, depending on the situation.  I haven't worked on game development teams that large, but hypothetically I could see a lot of value at that point in a true purist ideas guy, for some scenarios.

I skimmed through your list, which has quite a lot, and I think it might be better to think of what is the minimum needed to be playable.  Not a complete game, but to start showing something at all.  I.e. 2 races, 1 unit for each race, 1 race controlled by AI, one race controlled by player, can fly around in an area, and try to take out the opponent.  Then add another unit.  

Thanks!   Yeah, I am realizing even my initial target plan was a little daunting.  I've broken it down into a much-reduced initial version with just 2 starship types (1 for each of the 2 initial races) with a single ability (besides the built-in lasers and torps that all ships get).   The goal for this release is an internal early Alpha version; a fully playable game suitable for a small group of alpha testers to play.

One piece of advice I would give is re-edit your list so that you separate them into subgroups and features associated eg:
 
Player
Unit (ship) etc.
 
At the moment reading through the list it skips back and forth in the types of features and what they would be associated with. Furthermore as you divide them up it is more likely that a feature that isn't there but should be can be identified.

Good points, I've organized it a little better and you are right, that made it more obvious I had missed several necessary features.

I would also get a UserVoice account, which is a free system that lets players suggest ideas and vote on them, which will tell you in larger scale what is important to the players, and how they view the game over all and its direction.  (Each player gets 10 points, and can add 1, 2 or 3 points to any idea, including ones they propose.  You could throw your own ideas out there as well, and see how they fair.

I checked it out and it looks like a great way to provide a feedback mechanism.  Thanks!

Alpha I Version

Human Frigate

•  Torpedoes: collision detection / damage
•  Ability: Shield Flare
•  AI

Regelos Destroyer

• Ability: Repeat Laser Blast
• AI

Bases: Art + AI for each of the following 

•  Human Starbase
•  Regelos Starbase
•  Human Citadel
•  Regelos Citadel

Energy

•  Add energy indicator to main screen
•  Subtract more energy for faster movement as well as laser use
•  Disallow lasers or fast movement when out of energy, shields max at half

General Gameplay

• Friendly versus Enemy (no friendly fire), display team color
• Stats: Display these small icons around each ship on tactical map:  Hull, Shield, Energy
• Display remaining game objects on strategic window
• Add borders to game world / fix size 

Planets

• capturing enemy planets mechanism
• seeding planets: assign ownership of planets at game start
• display team ownership of each planet on tactical and strategy map
• defense grid
• repair/fuel stations 

Player Slot Management

• 20 players per team
• victory conditions (server reset)
• players entering / leaving game conversions with AI
• quit button

No problem!

I don't have any links for those, but can add a bit on the logic side of it.

You basically have to add your own code to handle both those cases.  

For the first case, detecting whether a packet was sent or not.  There are various ways to do it.  A rigorous way is the server not only sends the message, but also adds a unique auto-incrementing number as a header and keeps that message stored in memory along with a timestamp of when it sent it.  

The server continues to resend that message, say once every 2 seconds for up to 10 seconds and then it discards it as unsendable.

The client, upon receiving the message, sends a response back to the server with that ID # (an "ACK" request basically) confirming it has been received.   The server receives this "ACK", and then removes the message from its queue so it doesn't resend the message needlessly.

The client also keeps track in memory of a list of all these ID #'s it has received along with a timestamp, and it disregards any message it encounters multiple times.  After say 30 seconds, it can delete this entry from memory.

There are more complex ways to do it, including various summarization schemes where the server sends to the client "here are the ID's of the last 10 messages I sent you, please confirm".   But as you can see, at a certain point, this handshaking code might become more complex than the main logic itself.   At that point you have to ask yourself is it worth spending the time implementing this, to increase the chances of delivery from 99% to 99.95% or whatever?   Also, in some cases just using TCP is easier for this kind of thing if you require confirmed delivery, though you typically don't want to mix TCP and UDP.  (It is easy enough to do but can cause minor network latency issues).

Most chat servers would just use TCP for this reason, not UDP, though this is an excellent project to begin to get familiar with UDP programming so  from that point of view nothing wrong.

In terms of getting the order correct, that is again something TCP handles for you automatically but UDP will typically get 1% or less of messages out of order.   Once again, using that same ID the client can make sure the ID # is the largest it has seen, otherwise it has to insert the message not at the bottom of the list of messages but somewhere in between, or it can choose to ignore it by discarding the message.

Totally agree with all the above, great question OP and great responses.  I personally research other games, not only because of the wealth of ideas to think about but even more importantly, sometimes they are fun to play themselves!

I'll add a little personal story.

Back in 1996-1997 for my senior software engineer project at undergrad school I wrote a game prototype.  In fact, that was the most recent game I've worked on besides my current game, I took a 15 year break but am back in this with a passion!

My project at the time was a 2D tile-based graphical MUD / multi-player game.  It took me a year but I successfully completed the prototype.  It wasn't a complete game, but it was playable in terms of movement, a few basic monsters and attacks, and some early sandbox features.  A talented high-school art student worked with me and did a great job with the 2D graphics.   It supported 50 players per instance or so and was UDP based.   A top-selling game publisher was impressed enough to consider hiring me as a junior game programmer but for various reasons that didn't work out. 

I graduated college and was planning to continue working on my game another year in my part-time and releasing it.  But, then I learned about a new game called Ultimate Online was coming out soon.  That discouraged me enough to immediately stop, as I didn't think I could compete with a professional game studio working on something similar to what I wanted to create.

Looking back, my game concept was actually much closer to Minecraft than UO, and there is some non-zero chance had I just kept at it another year or two it would of turned into something like Minecraft but 10 years earlier.  Now of course that is all very speculative; good games take a lot of work and my point isn't to say I would of been successful.  Rather my point is to say sometimes your games are not as close to others as you think and they are original and innovative in their own way even while sharing a lot of overlap.

Welcome!  

Also in case you are new to the programming side of it, here is a very good explanation on UDP game programming using the Lua language (but the logic applies to any language):

https://love2d.org/wiki/Tutorial:Networking_with_UDP

One final thing to mention is what is called the MTU limit.  The MTU is a router setting after which number of bytes messages get broken up (fragmented) automatically.   The bottom line is due to problems that can occur with fragmentation  it is considered good design to limit the size of any UDP message to 800 bytes or less (so including overhead, that is 772 bytes or less in the message).  You should split up larger messages into separate packets if you exceed that, to be safe.    In your case, you should be fine as is, but just be aware once you exceed around that number like getting to 900 bytes, 1500 bytes etc, there is a greater and greater chance of either complete packet loss or a delay, say latency increasing from 50ms to 400ms etc.    

Part of this is just the relative amounts of labor as well as supply/demand of contributors.

For example, it might take a designer 20 hours to come up with the ideas for 2 new races, each with 3 main solider classes with personalities that really fit well together in the game and most of the stats / weapons involved "the archer has a bow that does 10-20 damage with a range of 5" etc.

Now the programmer has to take 100 hours to implement this, and the artist needs 100 hours for creating concept art, polished images, frames of animation, package them correctly etc.  

So if your team has 1 game designer, 1 artist, and 1 programmer and you are working on weekends, the game designer might just need to meet with the team once a month, while the programmers and artists are working each weekend.  

Your bottlenecks will be waiting for programers and artists 95% of the time.  A game designer conceivably could work on 5-10 different hobbyist games at the same time on weekends as 1 artist and 1 programmer are dedicated to a single game.  You couple that with the fact that many artists and programmers (at least who aren't getting paid) will want to also contribute to game design, not just implement from a fixed blueprint, and the ratios skew even further.

How many games have failed because they couldn't find enough game designers?  Sure, some have bad game design and that dooms a game.  But in terms of hours of work of game design needed?  Very few, in fact I've never heard of such a case.  How many games have failed because they don't have enough hours of artists or programmers?  99.9%.  

Many of the game proposals here have requirements like 5 man-years of programming and 2-man years of art.  Their teams often include 1-2 part-time programmers and artists who come and go, working in their part time (thus spending half their time just learning the existing code/game/processes before they can get productive).    Projects are understaffed compared to their goals by an order of magnitude.  They eventually get abandoned when being only 10-30% complete.

Any plan that fails to solve for this very simple labor equation is doomed to failure and this is by far the reason most hobbyist games fail.

Of course, even completing a game is no guarantee it will be successful.. that is where quality, community outreach, innovation, (dare I say it "good ideas") , come into play.  But, none of that even matters if you don't end up with a product on iTunes store, Steam etc.  You might have the best idea in the world, with incredibly high quality artists and programmers, and it is still going to be a failed project if your staffing levels are inappropriate.    If you release a game, even if is sloppy, it is something you can iterate on and you are ahead of so many teams because you successfully delivered something.   One sloppy, buggy game that is 100% complete even with bad reviews is still "better" than some product written by god-level coders and artists that doesn't get finished, just by virtue of one of these is playable, and the other is not.  A Yugo that breaks down every 3 months and looks like crap is still orders of magnitude more useful than a Porsche engine without the rest of the car in terms of getting you to work.