Advices before the start of developing

0 favourites
  • 7 posts
  • Hey, I just wanted to ask if there are some general advices or things that I should consider before starting to build the project.

    I've tinkered for a while with free edition and now I'm ready to buy a license and finally start to build a full game, from start to finish.

    It will be a platformer with hand-drawn graphics and animations. If you got any useful tips for a beginner, I'd be really glad to hear them!

    Thanks in advance!

  • Comment your code, use groups, organize it well. I prefer to have only 1-2 event sheets but with many groups. it makes searching much easier.

    Don't do many events assuming it works .

    Test after every minor implementation.

    Every 30-60 minutes comment your code or tidy up.

    I save incremental every major modification (every 1-2 hour) Eg: GameName_v1.capx, then GameName_v2.capx ... etc

    Enable the build-in backup for both local hdd and dropbox. It will save you ward work in case a UFO blasts your PC

    Learn to use the Debug option in case you don't know it

    Use functions if a group of events are repeating more then 2-3 times in your game. It will only need to make 1 modification instead of many.

    Make the code as general and flexibile as possible. For example, if you want to position an object in the middle of the layout, and the layout is 600 by 300, don't position it at 300 by 150, but instead position it at Layout.Width/2 by Layout.Height/2 (that is not really vital, only if you want to modify the positions and sizez you will have to modify the values)

    These are just a few that I can remember right now that become an habit for me

  • Hi shushpo

    I put together this tutorial a while back for beginners who are making small games, but it contains some useful general advice:

    https://www.scirra.com/tutorials/5014/d ... ers/page-1

    In addition to that I would recommend the following:

    1) Organise your project folder system to make it easier to manage assets. I use the following "ABCD" folder structure:

      Assets art masters audio masters Builds Code Documents

    Keep archive subfolders so that you can declutter old unused files from your main folders.

    2) Use a naming convention for your assets. My preference is (assetType)_assetName_(indexNo) e.g.:

    spr_enemy_00

    spr_avatar_00

    sfx_shoot_01

    tmp_forest_01

    ...but exactly how you go about this is up to you. The main goal is to make it easy to organise and identify assets.

    3) Learn how to use groups, functions, families, arrays and dictionaries. Whilst seemingly daunting at first, these objects and structures in combination can go a million miles towards improving the efficiency and versatility of your code, and actually aren't that hard to get to grips with once you start playing around with them.

    4) Use the manual, tutorials and forums, preferably in that order, whenever you get stuck. Whilst it can be fun to noodle over a problem you can often waste a lot of time reinventing the wheel; if you can't find a solution and post a question provide as much info as possible - capx/c3p files are always appreciated.

    5) Start small - try not to bite off more than you can chew for your first few games. You'll learn more and progress faster seeing a number of simpler projects through to completion than if you get bogged down creating your magnum opus. Have a look at the example projects that come bundled with C2 and try modifying those into a game - this is a great way to familiarise yourself with many of the different plugins and behaviours that C2 offers.

    There's plenty more I can add on but I reckon that's enough to kick you off - Hope it's useful - <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

  • I personally prefer to create many different Event sheets which have one aspect of the game mechanic and include what I need onto a 'Main Event sheet'.

    Therefore all major mechanics such as Level Init, Functions, Global variables, Player movement, enemy movement, collisions, HUD, scoring etc etc will all have their own Event sheets.

    What it means is that I can create many different aspects - Player movement for instance - of a particular mechanic and just include it, whilst disabling the previous mechanic. It makes testing new mechanics very easy.

    It also means I will always know where to find a particular Functions, variable etc because they are on their own Event sheet.

    Just my preference, but I expect their are many others.

  • Cipriux, mekonbekon and zenox98 Thank you! I'll look into your advices. Looks like I need to do some more digging into the basics (especially those that are not in the free edition), before starting the project Have a good day!

  • One more piece of advice: START SMALL.

    A lot of people have this first game idea that is this huge platformer quest or RPG or something that will take years to complete. My advice would be to pick a small project that you know you can finish in a few weeks or months. Project 2 can be bigger, but while you're learning, it's so important not to bite off more than you can chew.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • One more piece of advice: START SMALL.

    A lot of people have this first game idea that is this huge platformer quest or RPG or something that will take years to complete. My advice would be to pick a small project that you know you can finish in a few weeks or months. Project 2 can be bigger, but while you're learning, it's so important not to bite off more than you can chew.

    Yeah, at first I had a lot of ideas but I try to cut everything that seems to be too complicated and make it as simple as possible Thanks for your response though!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)