Translations

Know another language? Translate this tutorial!

Stats

1,001 visitors
6.3K page views
43 translation visitors
57 translation page views

Tips and tutorials - Game programming

Favourite 15 favourites
Tutorial written by WhiteclawsOriginally published on 6th, January 2012 - 1 revision

Hello everybody ,
Today i am going to give you some tips on how to make your games faster and without stress

Tip 1 :

Before starting your game , write all your ideas on a White paper
Not on your PC :)
When you get a Solid Idea
Re-write it on the other side of the paper (Save the earth , don't use too much paper ) :/
This works for stories , mission storylines , Player names , Game title , etc
Ex:
Ideas for the name of the hero
First Side:donnydore,Sailly,Max,PaperBeast
Second side: Paper Beast
Ideas for the story
First Side:The princess got captured,The hero got captured
Second Side: The princess got captured

Tip 2 :

Design your graphics on Paper Real One ( no colors is recommended ) and then scan it and draw on the hand-drawing with black and color it .
Or...
If you don't have a scanner just copy the design from your paper
Why you ask ? because when you draw it , you have more chances to get near the result that you want

Tip 3 :

All your graphics has to be ready when you start programming
because you don't have to stop programming each day because you have to design objects

Tip 4 :

The Players are the best sources of information , you can ask them which game they like and take good information of them

Tip 5 :

Do not stress yourself.
You produce better when you have time to think about your game , so if you want to produce better just work and don't stress yourself

Conclusion
i hope you learned from this tutorial , thumbs up , comment , feedback , and use these informations wisely :)

Congratulations on finishing this tutorial!

Did you learn a lot from it? Share it now with your friends!

Comments

0
Bigheti 12.6k rep

Very good...is important to define in white paper before to do the programming. Tks!

Friday, January 06, 2012 at 9:25:27 AM
4
Kyatric 41.3k rep

I like the tip1, clever technique.
Nevertheless, there's nothing wrong with having his ideas wrote down on the PC. It is just a matter of preferences and organization.

This brings me to tip 3 which imo, can be fairly discussed. If I understand correctly, you say that first you need to make all your graphics ironed-out/final and then code ?
That's a strange approach.
What I'd rather recommand would be to have a bank of placeholders graphics always at reach. When you need to add an element to your program, you can then pick quickly one shape/anything from this bank as placeholder.
THEN you start thinking about making the actual graphics of the game. This way, your mechanics already works with the simplest graphic representation (meaning that the mechanics and code are good).
It also now make more sense and serve as a concrete support to determine exactly what kind of graphics you want/need and FIT in the game you are actually making.

Such a bank of placeholder graphics is really handy and you can always easily fill it. When you're bored or stuck in your code, switch for a while, do a bunch of shapes, save them and get back to your code.
This can actualy help the workflow and keep a clear mind about what you're doing.

Friday, January 06, 2012 at 3:44:07 PM
0
Whiteclaws 13.5k rep

you are right

Friday, January 06, 2012 at 4:19:06 PM
0
Cpryd001 4,236 rep

I definitely relate to the first tip. Many programmers from the 80s would write much of their code on paper before they even touch a computer. Many web designers make websites in their sketchbooks. Never forget the power of paper!

Tuesday, January 10, 2012 at 6:47:05 AM
0
dagda825 4,403 rep

I agree with tip #1...except... I prefer Free Mind and Dia to paper and pencil.

Wednesday, January 11, 2012 at 9:58:15 AM
0
existonfile 2,737 rep

I also do some of my best design on pen and paper first before I ever open my laptop. Great tips!

Monday, January 30, 2012 at 11:51:06 AM
0
thiago 3,983 rep

I agree with with Kyatric. Making a prototype with placeholder helps to make a more consistent artwork.

Tuesday, April 03, 2012 at 3:54:21 PM
0
jwjb 4,489 rep

@kbdmaster, very helpful tips, especially found the part of having all your graphics completed up front instructive as I typically use placeholder graphics until the coding is more complete and kind of see-saw from graphic design to coding from thereon, thanks again.

Monday, August 20, 2012 at 5:44:22 AM
0
Shapter 1,946 rep

I can only agree with Kyatric : tip 3 seems illogical.
If you have all your graphic assets done and something that worked on the paper ends up not working / not as fun as espected once coded you will have to modify the graphics accordingly.

Art is time, a huge ton of time !

Tuesday, July 09, 2013 at 6:42:26 PM
0
Jaycephus 1,239 rep

I like to make state diagrams before I get deep into programming. I just found LucidCharts which lets you do both cloud-based and offline diagramming and mockups. I use state-chart diagrams per the UML definition. "Real-Time UML" by Bruce Douglass has a section on diagramming state-machines. Beginning programmers who are attracted to Construct are probably not aware of the advantages of doing this planning.

Friday, December 06, 2013 at 3:34:18 AM

Leave a comment

Everyone is welcome to leave their thoughts! Register a new account or login.