SillyCow

Since I am a bad artist, and usually work alone, this is how it goes for me:

1. Think of a cool idea.
2. Make a one level ugly prototype. (I sometimes use text instead of actual graphics here)
3. Play the prototype and see if it's any good.
4. Improve the gameplay protoype until the game is fun.
5. Make the game pretty (Add art, menus, etc...)
6. Send to beta-testers (friends)
7. Improve controls & Fix bugs based on their input
8. Publish game.
9. Improve controls & Fix bugs based on user input

Since I work alone and know how to program, I skip the design document phase.

Don't use openGL for your first 2D platformer.

Use any 2D framework instead.

Do not make the mistake of using GIT as your first source control.

I use it at work, it's very powerful, but it takes a long time to understand.

If you have a small project (~5 people) , there is no need for distributed source control. It just complicates everything.

 

I can make the following recommendations: 

1. Use SVN

2. Use it from a GUI ( you'll understand stuff way faster then command line )

 

If you're using windows: Download Tortoise SVN and create a local repository.

If you want to upgrade to a server-client setup: Download Visual SVN server,.

 

Use GIT once you are working on giant project with several remote work - sites (e.g. Compiling a Linux Kernel) .

Using it for a small project is just looking to complicate things. Also, many SVN concepts can serve as an intro to GIT (commit,checkout,branch,merge, diff,patch, etc...) . 

The stock android emulator will not run at 30 FPS if you are doing heavy rendering.

 

Look at BlueStacks - http://www.bluestacks.com/ . It's an android emulator that's much faster than the stock android emulator.

It renders OPENGLes very well.

After you install bluestacks, install your APK there, and run it.

 

Then run your favourite screen capture program,

I recommend Camstudio or Microsoft Expression Blend.

 

Bluestacks manages to render most of the stuff correctly. I have seen it produce minor glitches though.

For me it boils down to two things:

1. Ready made engines are bloated, and my games are small.

2. Curiosity - I like to understand how stuff works. (That's why I started programming in the first-place)

When it comes to things which don't interest me much, like audio synthesis, I use engines without a second thought.

I have an engine design question:

I would like to run my logic on a different thread then the rendering.
The problem: The logic thread moves the units around, generally changing their state, while the render thread tries to render them.

The most naive approach is to use a bunch of  locks on the different entities. But as far as I know locks are performance eaters. Although I know that since hyper-threading that overhead has gone down significantly.

Another option is to copy the state on every render frame before I render it. But that also looks very expensive performance-wise.

I could also lock the renderer while the logic is running, but then what's the point of being multi-threaded?

So I'd like to know:

What is the correct approach to concurrent rendering while running game-logic?

Maybe I'm stating the obvious but if I was teaching kids my first priority would be to get them to understand the concept of OOP (mainly inheritance).

That is a terriible terrible idea,

I have to second this.
As a kid I got started with BASIC.
The cool thing about basic is that you don't even need functions.

Your average 12 year old does not understand:
1. If statements
2. Functions
3. Loops
4. Variable Typing
4a. Variable declaration
5. Splitting code into different modules etc...
...

BASIC did not require any of these concepts to generate a cool result.
As a kid, easy success is a great motivator.

Since basic does not really exist anymore (Visual basic is more like C# / Java),
I am thinking one might think of toying around with java-script as a first language.
It does not require any of the above (you can even use undeclared variables in global scope).
It might actually be useful for the kids later.

Little by little you can add the more complicated concepts listed above.

The downside is And there are no easy input functions such as  getch() or scanf(), and the javascript canvas is as complicated as any GDI library.


But I don't know any language with a graphics library as simple as basic:
SCREEN 13
COLOR RED
DRAW "r5 d5 l5 u5"

Regarding OOP specifically:
It is not a "Holy" concept.
As someone who learnt to program before good C++ compilers were available for home development, you can do a-lot without OOP,
Teaching it as the only way of programming is major mistake universities make today.
It causes programmers to believe that over-designing is a goal in itself.

Of course there are many challenging aspects. But one could have creative solutions.
Balance as an example: why have balance? Conquer the world as the US for the easiest mission (level one). Enforce world peace by ruling from Afghanistan as the hardest mission.

Regarding the fps part. I like the idea, but I don't think I can do it. Fps games are so different from RTS games, that I would need three different engines.

I checked out superpowers. Graphically and ux wise it looks very similar to what I want to achieve. But gameplay wise it looks completely different.

• 5th grade Art teacher taught us how to write a simple BASIC program.
• Asked a basic question, teacher didn't know the answer. ( She was an art teacher... )
• Bought a book about basic from local bookstore.
• Oh my god! programming is cool
• Made many cool basic programs.
• Made many small games in basic.
• Wanted to do more serious stuff --> got a book about C.
• Made some games in C
• Wanted to do cooler stuff --> Got a book about Assembler
• Made a graphics engine using assembler
• SOMEONE INVENTED THE INTERNET
• OH MY GOD! DON'T NEED BOOKS ANYMORE. CAN LEARN ANY LANGUAGE WITHIN A WEEK.
• Found porn on the internet ( No time to program :-) )
• Went to college ( No new languages/Technologies here )
• Got a Job
• Whenever I need to learn a new language, They send me to a crash course. Much easier than reading tutorials. Also much more expensive (But I'm not paying) .

My main tip is:
a. Learn through doing (reading is not enough). Think of a small fun project, and make it as you learn.

Actually, the vector will automatically free its contents whenever if goes out of scope, regardless of being stack allocated or not.

Untrue, a non-stack-allocated vector (one which uses a "new" keyword) will remain in memory after you exit the function, unless you call delete. Calling clear() is not enough in this case, as the vector will shrink, but will still leak some memory. But this is not the case in the original code, since there the vector is stack allocated.

stack allocated:
std::vector<int> tempVec;

non-stack allocated:
void foo(){
std::vector<int> *tempVec=new std::vector<int>();
...
delete tempVec; //correct way to release memory
//temvec->clear() is not enough and not necessary. It will only clear the vector contents, and will leave some garbage in memory
}

There are also algorithmic needs for said planes:

Near plane: When projecting a polygon from 3d to 2D, the projection will not work if the polygon crosses through the viewer. You said you don't want to go into geometry so I won't explain the reason. But here is an example of how it works:
You cannot correctly render a triangle which the player is standing on, because said polygon is partly behind the user. To do the projection correctly, you need to clip the triangle at some point in front of the viewer, thereby "breaking" it along the near plane. That way you are left with only a part of said polygon which is completely in front of the user.

Far plane: Z-buffer ( The part of rendering responsible for occlusion ) uses an inverse logarithmic scale (less accurate as you get further). Limiting the farthest point let's you pre-calculate z-buffer accuracy.

Although, these points are not always the same as near plane and far plane, they are known constraints when doing projection based rendering.

Had the same problem with my terrain generator. Got awesome results with texture blending:

Render all textures on every polygon.
For each texture on each vertex, assign an alpha value. (Render multiple textures over each other)

The tricky part:
For a given vertex compute all textures around it (four squares touching the vertex).
The alpha value should be the weighted average of the materials.

Example:
Givven a quad of Grass (G) and Rock( R ) Snow(S) in the following formation:
GG
RG

The vertex in the middle should have 0.75 grass , 0.25 rock, and no snow.



Hope this helps.

Publish your app without ads first.
Make sure people like it.
Make sure you spend time improving it by peoples comments.
I find that this is the best part about the whole Market/Play/App-store environment.
Don't worry about ads at first(Admob doesn't pay well until you have a huge install-base).

It took me about 4 hours to integrate AD-Mob into my app (From a point of knowing nothing about it).
And another day's work to refine the banners' placements.
I did this around 3 weeks after releasing.

Even the crappiest game I've ever made hasn't sold beneath 500$

So I gather that you went with the paid only approach?
If so, how did you get your initial user base?
Did you advertise your game somewhere?

Right now I think I will go with disabling progress saves for the free version.
How annoying  would you find something like this?