So I’m sat here with a highlighter, a pen and a book on AS3 thick enough to use as a weapon, embarking on the long and difficult road that will hopefully end with my Choose Your Own Adventure book on the internet as an all-singing, all-dancing Flash game. Since you’ve all travelled down that road before, I thought I’d seek information/ advice from Kong. Specifically, what you learned from your first game and what you’d do differently if you went back and did all it over again. This can be about any aspect of making and releasing a game from coding to money and publicity to having the will to keep going. Feel free to post links :)

This is something I’d love to read about too. Always great to learn from the perspective and experience of somebody else. :) So if you find the time post your secrets. Even small posts can sum up over many people. And having a reputation as a helpful developer certainly doesn’t hurt you. * * * Can’t help much with game development but there are two things which are always true when you start off with a new programming language. Things will take longer than you think they will. And you will spend quite some time dealing with problems related to the language and not to the actual project. So it’s a good idea to make a plan with time estimates and to check it on a regular basis against the time you actually spend. This way you can catch yourself if you invest too much time into a minor aspect. Once you notice you used up most of the time you can reevaluate if what you are doing is really that important. If it is you can make a new estimate. If it isn’t you can drop it completely or accept the current result as enough. * * * As for the will to keep going. Think in terms of learning not in terms of getting good ratings, nice comments or even money. You will definitely learn something from making your first game. That is guaranteed. But new games usually don’t get high ratings or many positive comments. It’s mainly about the “why”. Why do you want to make games? Whatever your reasons are they will be strongly connected to learning. * * * From a players perspective I can tell you that communicating with your players is a BIG plus. Especially in the beginning you will make some mistakes. You can’t please everyone but reacting to comments will contribute to your reputation. And it can negate minor mistakes. From what I hear getting feedback on your games is also difficult. There is a monthly Jam called [Game in Ten Days](http://www.kongregate.com/forums/4-game-programming/topics/532562-game-in-ten-days-gitd-archives) in this forum. Part of the voting is usually also giving feedback. So that’s a good start. Even reading without participating might help you already. To get a taste [this](http://www.kongregate.com/forums/4-game-programming/topics/641270-gitd-55-voting) is the current voting. Be extremely careful with balancing your game. The first impression of your game is very important. And the best way to turn your game into a failure is to frustrate your players. Especially before they get a chance to get to know your game. * * * Hope this helps you a bit and motivates others to post the information you are actually looking for. Good luck with your project. Feel free to keep us informed about your progress. :)

**What I learned from my first game?** My first game was garbage. It was, quite possibly, the craziest game I’ve ever made. It was poorly coded, it wasn’t that engaging, and the code looked like a garbled mess. My suggestion to anyone making their first game ever would be to start small, make your project the smallest possible, using everything you know how to do. Don’t plan on making something you don’t know how to do. If all you know how to do is text input and output, make a text adventure, with basic commands, and that’s it. Ultimately, it’s what made me begin to work towards jumping over the various barriers of programming. You’ll catch yourself with problems when you code, and your first game really highlights those problems. In my case, it was messy code. I still write fairly messy, but it used to be worse. **What I’d do differently** I’d save my best projects for a later day, and just program copies of games when I started. I’d pick games that exist that I think I can replicate and replicate the first level or a part of that game to the best of my abilities. I’d set clear, obvious, goals, and I wouldn’t stretch beyond my realm of knowledge. Creating your first game, you’ll learn a lot, but if you don’t know anything walking in, it might be kind of hard. I knew a little walking in, and I walked out without learning much at all. I was so focused on the game, I forgot to learn. If I had made a simple game with the knowledge I had, I would’ve picked up new tricks to process things and create my game better later on.

I learned that making decent games is actually pretty difficult. You need to actually sit down and take the time to lay out what you want your game to be. Scope your project to what you know you can do. Only expand the scope once you have finished implementing everything you wanted in your previous scope.

After making my first serious game, I looked back and realized that my code was a giant mess. I started fresh for my second. After making my second serious game, I looked back and realized that my code was a big mess. I started fresh for my third. None of my time was wasted. [If I didn’t spend all that time writing bad code, I’d never have figured out how to write good code](http://thecodelesscode.com/case/105).

The three biggest things I’ve learned are: 1) Start small. 2) The game is never done when you think it’s done. 3) Don’t wear blinkers. Regarding 1): Coding can be hard and frustrating work, so if you don’t get a constant stream of positive feedback going, you’re gonna run out of steam rather easily. Start with something small, something that you can then play and show around and that makes you go “wow, I made a game.” Regarding 2): There will come times where you think to yourself “the game is basically done!”. It is not. I can tell you right now that there’s a small bug you haven’t bothered fixing, that the UI might be a bit rough, that the menus could use a bit more polish, that the code could be cleaned up a bit. In my experience the last 10% of a project can take almost as long as the previous 90%. Keep a list of everything that needs to be done and don’t get discouraged. Regarding 3): Tunnel vision is dangerous. There will be times where you’re so focused on a single issue or feature that you disregard the project as a whole. This can lead to frustration and lost time. It’s a great feeling if you fix a small bug after working on it for 6h; but when you then step back and look at the entire project, you’ll feel discouraged because you spent so much time on a tiny part of the game. If this happens a few times, you’ll feel as if you’re making no progress at all. Always try to keep your head above water.

Very interesting reads so far. :) > I tend to reply with something generic like “Thanks for the feedback, sorry you didn’t like the game.” and move on. Don’t argue with them or insult them back, you’ll just look bad to other people. From a player’s perspective I can’t stress how important small gestures like that one are. Building up a good reputation takes time and effort. But the way in the other direction is very fast and straight forward. And being thankful is a healthy habit on its own. ;)

On the flip side, “Thanks for the feedback, sorry you didn’t like the game.” **feels** like a generic response and it gives the impression you aren’t listening and/or don’t care. From both a developer and consumer standpoint I believe it is better to ignore comments that aren’t constructive or don’t add anything new and to make personalized messages for those that contain new constructive feedback. As a developer it saves you time and headaches. From the consumer standpoint it shows you are listening and engaging with your players even if their own comments go unresponded to. Just my two cents from my experience as a community coordinator on a professional product.

You may have a point with the generic part. But don’t forget the setting we are talking about here. We talk about a developer who is completely new to the game. It’s his first game and nobody knows anything about him. No fanbase, no experience. Generic responses may feel generic. But cherry-picking only the positive stuff feels arrogant. Especially if your “critics” have a point. * * * Imagine you make your very first game and it’s a jump and run. And twenty people complain about how horrible your controls are and that you should go die in a fire. And there is one post that is happy about how your character looks like. Now imagine you respond only to that one person. Do those twenty people behave in an unacceptable way? Yes. Absolutely. But that doesn’t mean their point is wrong. They **do** provide you with a new and important insight. So that’s a reason to be thankful. And they **did** have a bad time with your game. That’s a good reason to feel sorry for them. Even if it wouldn’t be your fault. * * * Obviously that example is over-dramatized and the reality will be a bit more balanced. But I hope it shows where ignoring too many people will get you. Sending them all the same generic message is probably not the best response either but I would say it is still better than ignoring them completely. Once you have “proven” your worth, delivered some quality products and shown that you are open to feedback I’d say you can focus the majority of your energy on the important comments. Apple is having a lot of success with what they are doing. So that gives them the “right” to make unpopular decisions and ignore some opinions. But if you are new to the game this is something I wouldn’t advice. * * * I guess it is less about your comment being generic and more about how often you use that comment. I’d say using it every time is still better than not using it at all. The best solution is probably somewhere in between and mixed with non generic responses. Getting the right balance between the effort you invest and the results you get is not easy. But really critical are your five most voted comments. Not commenting them at all is already giving up an advantage on its own. And if there is something “negative” in them which has even the slightest point and you comment only the other “positive” posts that’s a red flag to me. There is a good chance that you either do not want to learn from the feedback people give you and you will continue to upset people or you don’t have the character to stand to your mistakes. In both cases there are better options out there. Plenty of fish in the ocean. * * * Hope that clears up a bit what I meant with my last post. :)

Yes, like Tulrog said, my point wasn’t about dismissing people, it’s about responding neutrally to the worst comments. You don’t have to just copy and paste the exact example I gave.

Okay here goes. First off, I’m the guy behind Learn to Fly if that adds any credibility to my opinions. Second, there are many ways to be successful at game development, any many goals you can strive for; in other words, your mileage may vary. I’ll try to keep it as concise as possible because there’s a LOT that could be said. ## **What I learned from my first game** **1.** The first thing I learned from my first game is that **you can make a living from making games**. It’s not a dream job, it’s a lot of work, and it doesn’t pay as well as most jobs unless you get lucky. But it’s an interesting, rewarding and challenging job. It’s also a great side-job or hobby. **2.** Second thing I learn was that you shouldn’t name all your variables “f” for friction, “v” velocity, “p” for player and “peibp” for player equipped item base power. There will be bugs, there will be refactoring and modifications, so **make your code readable, make it clean and make it self-documenting**. For example give functions and variables names that describe what they are about, and not “doOtheerStuff3(a:Boolean, b:String, c:\*)” with a comment to explain what this is all about. **3.** Third thing I learned from it was that **it will take longer than expected**. 3 times your initial estimate is a good rule of thumb, but the real lesson here is that you should make small projects first until you get a better grasp of project scale. I learned this from experience. Hard. **4.** The next thing I learned is this: **a project will be awesome at first, then turn bad, then go horribly wrong just before it gets done and ends up alright**. At the start, you dream big, then you find out you dreamed too big, then everything turns into a stinky mess, and _at this point_ you must push through, resist the urge to abandon or start all over again and publish your game. The larger your projects are, the bigger of a mess they’ll become, _especially_ if you lack experience. A big part of larger projects is knowing how to manage them. **5. And finally, learn about your monetization options**. Not so much for your learning projects, but “if you’re good at something, never do it for free.” My first game was “sold” for a flat fee, with no ads and nothing that scaled. I missed a crap-ton of money by not doing my homework. If money is your goal, then keep money in mind during development and before your release. ## **Now for random advice I would give to anyone starting out:** **1. Your first objective should always be to learn and improve yourself at the beginning**. Do projects that teach you something rather than aiming for production value early on. **2. Start small. Very small.** Incredibly tiny, and don’t be afraid or ashamed to take baby steps. Learn to Fly may be my first release project, but before that there were something like 30-40 mini projects ranging from “object follows mouse on screen” and “button that can be clicked” to “minimalist platformer with only one stage and no goal”. Start with projects that can be done in less than a week, then slowly make your way to 1-month projects and keep going if you want. Don’t go from a 2-days tutorial project to a 3-years game or you’ll still be working on it 8 years later. **3. Keep your “dream projects” for later.** Maybe your really want to make a kick-ass open-world RPG, but you should really be doing a pong or tetris clone. Starting with bigger and more importantly emotionally-charged projects will only lead to frustration as you fail to fulfill your vision. **4. Once you’re done doing learning-only projects, make an actual game, finish it and publish it.** A lot of things about game development happen outside of actual coding and design. There’s a lot that can go wrong with a release. You don’t want to face this for the first time on a project you invested too much on. **5. 80% of a game takes 20% of the development time and resources. The next 20% takes the remaining 80%**. The early phase of a project always progress nicely; you’re optimistic, you’re excited, you’re progressing fast. Then bugs, issues and limitations hit you. Be ready for some difficulty towards the end of your projects. **6. Know a critic from an a#%shole**. The first is your friend and will help you grow as a developer and tweak your game to provide an optimal experience. The other is just an a#%hole. A critic opens up a path for improvement, an a#%hole just puts your game down. Listen to the first and feel free to ignore the latter. **7. Understand the underlying message of criticism**. What people tell you may not always be what they actually need. For example, someone saying “There isn’t enough items in the game” may be saying that because existing items simply aren’t satisfying to use. And the “the game is too short” one is actually just someone saying “That was awesome, make a sequel”. **8. Get other people’s feedback during development**. Ask others to play your game, watch how they interact with it, what they like, that they don’t, what goes smoothly and what doesn’t. The thing here is that you are so close to your game that you know everything about it; you know what the controls are, what enemies do, which way to go… You cannot comprehend what it’s like to experience your game for the first time. This is what’s called the “curse of knowledge”. **9. First impressions matter most.** Most people will only give your game a few minutes to form an opinion of it. If even that. Many people might only read the title and description, or even just look at the thumbnail. If your title is boring, your thumbnail is bland, you have no screenshots and your game gets fun around the 80-minuts mark, that’s a very bad start. **10. “Don’t make me think”.** Especially with browser games, the menus, controls and mechanics of the game have to be very intuitive and progress smoothly. The play button has to be easy to find. The controls should be schemes that are already used in other games of its genre. Learning the game should be done through playing and not by reading 5 pages of text in a dry tutorial. **11. Players don’t care about you, YOU must care about THEM**. You are a provider and they are the customers. If you want your business to work out, it is your job to make them happy, not the other way around. I constantly see new developers complaining “the players don’t get it” and, well, if you’re selling something and no one’s buying, the problem is either you or the product. **12. You will never please everyone**. If you want success, side with the majority when possible, or side with your core audience or niche market. Whatever you do, someone will still be mad. Speaking of which… **13. Know why you make games.** There are many reasons to develop games. You can do it for the challenge, for fun, for money… it’s all perfectly fine. You must understand however that **what you aim for is what you will most likely achieve.** If you make games for your own personal fun, don’t come crying when people don’t like what you did. Just the same, if you make games for a living, maybe your projects won’t be what you wish you could work on. **14. Know the scale of your project, and don’t under- or over-engineer.** Do you really need to make a little quiz in C++ to get the most performance? Can you really create the next Skyrim in Flash? The smaller your project is, the more you can get away with. As such, if your project is a very small one, don’t be afraid to use cheap, hackish solutions if they get the job done. A 7-days projects won’t be a perfect example of clean code and best practices. A 5-years projects _cannot_ do with poor practice without requiring refactoring or being abandoned. **15. Be ready to cut away features**. When we start anything, we dream big (and it’s alright) but as we progress, there may be times where features simply cannot be implemented, where resources are running short or where we’re sick and tired of a project. At times like these, you would do best to scale down and release rather than to give up and start over. A game is never truly 100% ready, you just get to a point where it’s good enough to be shipped. **16. Don’t polish a turd.** If the core of your game is flawed or boring, no amount of shaders, particles, screen shake, special effects and whatever you can throw at it will ever make it great. If you are in a project and begin to see down the road that your idea isn’t as good as you originally though it was, just trim stuff out, release it and move on. **17.** Finally, specially for you MrFlibble and because I learned from personal experience: **don’t invest too much in dead ends**. In your case, I’m referring to AS3. Flash is slowly fading away, sorta sucks and only really is targeted at web browsers. If I were you, I would look at other options that can either export to flash and/or HTML5. The simplest option would be something like Haxe/HaxeFlixel or Unity. I learned AS2 as AS3 was coming out, then AS3 as Flash was dying off. If you are going to invest a lot of money, time or efforts into anything, you should see that it will either work in the long run or give you knowledge or assets that can be reused in the future. For example learning a tool that uses a specific language (e.g. Flash and AS3) vs learning something that uses Java or C# which could carry over to other tools. Or investing in tools that work only on Windows, or only in browsers vs a tool that can export to mobile, desktop, HTML5 and so on. The idea is to look ahead and make sure you won’t regret the time spent learning or creating something. I wish someone could’ve told me back then to skip AS2 and also wish that I would’ve moved away from AS3 sooner. There’s still a lot that can be done in AS3, and if you’re in it for the fun then by all means go nuts! But if you’re considering game development as a potential career, then I would advise that you learn more powerful/flexible tools as soon as possible. Unless you don’t mind learning new things in the short/mid term!

You are awesome light\_bringer! :) I think the really cool thing about your post is that many of the advice isn’t restricted to game development or even programming. It can be used for any project an life in general. Thank you for taking your time to share this with us.

Hey people! I won’t share about my real first game which was a Pokemon point & click… But I can share a bit about The Soul Driver on Kong which is my first game to be ever released. ( **Disclaimer** : This is not a tutorial on how to make game, this is literally what I learned after my first game) **FINISH IT** The first thing I learned is to actually finish something… And the confidence I was able to finally finish and release something. That’s not a small thing for an amateur, that includes stuff like: 1. Make an intro, a menu and all interfaces that you usually neglect ‘cause it not useful for a prototype of gameplay. 2. Add all sounds and musics 3. Handle upgrade, progress, and save system 4. Balance, polish, debug, until the experience is ready to be enjoyed by people you don’t know 5. Discover what is an API, how the hell it works, and all the extra stuff gameplay developer like me hate! Took me nine months to complete this simple game because there was so much to learn. That was a crucial part of my learning. So yeah, whatever game you do, finish the hell out of it. Don’t skip from one unfinished project to another. With that first finished project, I actually learned what Oriented Object Programming was, (well, actually I didn’t xD but anyway), at least I thought I understood, and made progress. **MONEY?** The second incredible thing I learned is that one could earn money from Flash game sponsor. I had no idea. That basically changed the rest of my life. I earned merely 1 or 2 months of salary for a 9 months game, but still, I decided I’d go for it. Make the next game faster and better. Oh and be careful, do NOT release a flash game before having a Sponsor. You would lose a great deal of money. Only if you can’t find any sponsor, then release it. **FEEDBACK** (look at what light\_bringer says about feedback, he says it better than me :D) With all the comments we got on the game it was awesome to read and enjoy the players feedback. But what I realized is that developers should really know how to read feedback and how to take advantage of them. Every feedback mater, read it, take it into account. I don’t mean that you should listen and always do what people say and ask for (most of them have no clue at game design), but there is probably a hint of it in that feedback. So every feedback is a different look at your game, either it is a trash talk or a love letter, they are pictures of what people grasp of your game. That’s it, that is why we make game don’t we? Even troll are fun to me, ‘cause they are hint at how your game can be trolled ^^ I can’t understand developers who don’t read their comments. It’s like playing guitar in the desert for me. Plus, if you show players you care about what they say, they will reward you a great deal with their trust and support. That’s super important if you go for the long run. **I KNOW WHAT I AM DOING…?** (Kinda) So I learned that I was a pretty standard player. And so, the game I wanted to make, chances are people will want to play them. So I started to trust myself that if I would craft something I like with passion and care, other people would love it as well. So basically I tried to make a process ouf of it. After Soul Driver , I messed around a bit looking for what I would do next, and I stumbled upon a very old prototype of a dude in a hood jumping from roof to roof. I suddenly badly wanted to run around on roofs, doing parkour stuff, beating enemies with nice move and all with my skills. After a talk with Zhyr, we exchanged ideas, and the concept for Rogue Soul was born. Nothing fancy, just a runner, but a runner I dreamed about :) **I’M A PLAYER!** And that is my most precious learning right there: it is because I **dream** about the game I wanna make, that I can **play** them as a player, that I can then **shape** them as a player. So I’m assured it will be an enjoyable experience for other players as well. Lot of developers are blinded by the fact that they are the developer of the game. They often enjoy their own game for wrong or uncompleted reasons. And they would sometime have hated it if it wasn’t their own. I learned to forget about my developer status, and playtest my game with the rude honesty of a player wanting to have fun, questioning each mechanic, each feeling, analyzing what’s not fun, and how to fix it using my game design perspective in the background.

Thank you for all your answers, this is certainly helpful info for new developers like me. About AS3 as a dead end… what language would you guys recommend instead of AS3? I know just a little AS3 and that’s only because I found a really helpful tutorial about AS3. So I’m afraid to switch and end up with a language I don’t understand.

AS (all versions) is C-type language. So you can try Javascript to get HTML games (but you will also need to know HTML & CSS) or C# for Unity.

Depends on what support you’re interested in. - **Web game** : Javascript and HTML5 could do, although IMHO Flash is in most cases still the best way to make web game at the current time. Unity is not at its best on the Web right now but who knows, it might get better. - **Mobile** : JS and HTML5 work here as well, but you can also use Unity, which I prefer. But I let others answer for Mobile, I have no experience there yet. - **PC/Console** : Well, for 2D/3D games Unity seems to be the way to go those day. I’m using it, I love it, and would recommend it. Plus it has the nice advantage to offer a lot of tutorials. So, basically I would recommend C# for Unity. Plus, it look a lot like AS3.

I’d recommend picking up Unity, Haxel or HaxeFlixel (the closest to AS3? I’m learning it out of curiosity atm) or _maybe_ something like Game Maker Studio or even Monkey X for web games. All of them can export to many different platforms, all do HTML5, and Haxe/HaxeFlixel also exports to swf, so you’re _also_ covered for flash games. For desktop, Unity, Game Maker Studio, Monogame, libGDX, Clickteam Fusion or HaxeFlixel are all good solutions imo. Some solutions are easier than others, some scale better than others, and some do certain things or handle certain platforms better than others.

Ok, thank you for your kind answers. :)

Pesonally I don’t understand using some IDEs or engines, where you write code in one hi-level language and then export it to other hi-level language. How do you debug this things?

Engines (and sometimes the IDEs themselves) implement the debugging details for you. The point is that you debug your game in the original programming language and only export once you have gotten rid of most of (if not all of) the crashes. To catch the crashes on the exported language the engine will often include a debug logger with the game that will print the stack to a log file when the game crashes. The cool thing is that the logger will often spit out the original language’s stack even though it is in the new language.

That’s solution… I prefer do not use engines because in most cases it’s hard to optimize them under specific tasks. It’s true even for some non-engine things. For example in one program (it’s not game, but it’s my first commertial program) for communication encryption used SSL. Program was written in C# at that time. And worked SLOW. Later I found why: with every connection Framework loaded SSL sertificate into local OS storage and checked it. Framework was not able to process more than 10 connections per second. Current version (written entirely on C++) processes up to about 80 connections per second.

Thanks for everybody’s answers so far. It’s been really interesting to read through and play the game links posted ( @saybox [Sleeping Beauty](http://www.kongregate.com/games/saybox/renegades-sleeping-beauty) being my current favourite :) ). Being far more of a creative, rather than technical person- it’s definitely the coding that’s the biggest challenge for me. @light\_bringer77 I’ve investigated Haxe and will come back to it, but AS3’s probably my best bet for now as there are far more tutorials/ resources available for it. Hopefully, like with learning a language, knowing one makes it easier to pick up another. Sadly the tiny bit of BASIC I remember from my dad’s old ZX Spectrum is proving inadequate… One encouraging thing is that, as a semi pro writer and occasional GIMP designer on Deviant Art, I’m pretty familiar with a lot of themes that have come up: knowing your target audience, how to handle criticism, presenting the item to make it more appealing, getting feedback, the importance of debugging (or proofreading) etc. etc. and other stuff like working with stock artists- I’ve had a look around and there are lots of free resources for things I’m no good at- like music. I’ve decided to abandon the book (for the record, Essential Actionscript 3.0 by ADL is dry as hell), and am following Youtube tutorials-typing the code into FlashDevelop as I go. Currently, I’m going through the excellent 17 part(!) [Platform game tutorial](https://www.youtube.com/watch?v=N_gLSBBKHPM) by Kyle Thompson. I feel I can get somewhere if I keep persevering, even if it’s at a slow pace.

@MrFlibble (just to be sure) Have you think through the choice of AS3 in the current context, instead of Unity or others? Adobe is “kinda” letting Flash die at this point. If you’re in for the long run, I’d rather invest in a technology that is growing, not the opposite. Btw, watching tutorials and typing into VisualStudio, that’s how I’m learning Unity, I like it too :)

Hi SoulGame, yeah, I understand that AS3’s fading away (even if iit’s doing it very slowly). I’m not too sure about Unity either though. I’ve heard from the Red Crucible forums the main browsers are dropping support for this? How much this will affect things, I have no idea. Haxe interests me too although I’m still not 100% sure how it works. If it’s s good as it says it is at cross compiling then this would be ideal, although there aren’t so many tutorials for it- plus there are probably drawbacks. There usually are with stuff like this anyway… My thinking is that technology always changes, so having to relearn is pretty much inevitable. Not being a particularly technical person, I’m just hoping that developing an understanding of one language will set me up well in the future should I need to learn another (in the same way that learning Spanish makes it a lot easier to then learn Portuguese). At the moment, my plan is to get the understanding and ability to put out the game I want, and then I’ll take it from there. Although I always want to keep my options open. :)