I think it makes sense for people buying the first\second tier in kick which gives them the game in return.
Basically they buy the game in a reduced price which is actually valuable.

But donating 100$ or even 1000$ and getting something of the worth of 20$ is a bit silly.
Especially if the team don't have much to show already.
It's a bit similar to "overpricing" your game. People are crying that AAA titles cost 60$ but they are willing to pay 100$ for something that is not even ready yet?
What is the difference between an evil corporate that charge 60$ for a game to make maximum profit, and a bunch of indie guys that ask for 100$ and give you back a lot less than you could get with 100$ had you spent it on existing indie games.

Edit: It would make sense to spend a lot of money on Kickstarter game projects had there were not much alternatives. But currently we are in a saturation of games. Why do you spend money on a game that is not even made yet and not spend the same money on a developer that already made a good game but he won't survive because people won't spend more than 10$ on a complete game and wait for a bundle instead...

If we are talking about profit, the XBOX "slim" had a large profit margin as MS desgined it to be profitable. As opposed to the previous XBOX versions which didn't make much of a profit from only selling the console.

In addition, you need to remember that MS was making quite some profit from the Kinect Hype. The Kinect was also sold with a high profit margin(relative to production costs).

Cardinal Quest is good
Deadly Dungeons is also great.
You can also try out little dragon.

To be honest, I prefer to play turn based games on the phone because action games tend to be horrible on touch devices(for me). Unless it one of those stupid swipe to cut fruits or something like that...

randomshade, many kick starter game projects don't even have a demo or anything playable.

It gives the people a chance to participate in development of something they believe to be worthwhile. Honestly I always thought this idea is kind of backwards, but it appears to be working.

We could just simplify and say the entire Internet is money-sucking scam.

"participate in development". Well, if you going to watch a game developed from day one, it's going to ruin you the fun experience of playing a complete new game.

But anyway, my point still stands. There are more good games out there than anyone can play. Why would you spend 100$ to fund just one of these games, especially that this 100$ are not going to "spread out".
You are better off using these 100$ to buy several games from smaller indie developers and support them so they could make more games in the future.

Some projects are indeed unique and new, but many Kickstarter projects(mainly games) have existing alternatives.

edit: zalzane, and that is different from Kickstarter how?
The difference is that maybe Apple will ban you or somethn glike that. I dunno.
Anyway, the general idea is what I ment, even if it's currently not implemented properly.


Why do you keep bringing the "running off with donations" argument, it's irrelevant to what I say.

Well, sure, making a game being made is something you "get back". But you are still a sucker anyway. Why is it so hard for you to agree you are a sucker?
The people you donate money to might:
A) Not invest any of their own money on the project.
B) Might even give themselves pay checks from the money you gave them.
C) Will keep all profits from their project.
D) Might not give you any dime for your own project if you ask them to.

Just admit you are a sucker, there is no shame on that.

Some Kickstarter projects "make sense". As in, you fund a cause or something that will "give back".
But when you fund a game on kickstarter, you just fund their business plan. There are so many games out there, is your only choice to find enough entertainment is to donate 100$ to make a game?

You can drop the project after getting funded, just like in Kickstarter. But I think it tracks your profits in the Apple store, so you can't just fool everyone.

Capntastic, well he is a sucker.
Considering you are going to fund a pay check for people to work on their dream project and keep all the profits to themsleves, you ARE a sucker.
Being a sucker can be ok with people, but you are one.

You are not giving money to charity, you are giving money to a business. It's like you would give money to fund a project by Microsoft. Good lord, eventually we might see crowd fundings for MS and Apple projects. XD

What do people get in return for supporting a Kickstarter project?
Perks? Helping other people out? Making a game\project happen?

Take a look at this website http://www.appbackr.com/
In this website you invest money instead of throw money for perks. You get a real return proportional to your investment.

In Kickstarter the value of what you get back is a fraction of the money you donate.

In addition of getting tons of money from supporters, sometimes making other people do the work for them with the donation money, the project creators on kickstarter keep all the profit from their project and don't share it with the donators.

Wouldn't it make sense for project supporters to demand a proper return for their money? Do people enjoy throw money at people who wouldn't give them a dime in return?

I don't get it, I guess the masses are just suckers. Or the people donating in Kickstarter don't understand that money doesn't grow on trees.

The mod was NS1, IIRC

Is it possible you have an issue with synching Asynch and the GLThread?
Possibly GLThread is waiting too much for Asynch instead.
The way I do it I just have GLThread run freely and make it flag the Update thread(your ASynch) once every render iteration. That way the Update thread runs at more or less the same rate of the render thread, and the render thread does not need to lock or wait for the update thread.
Edit: take a look at the other thread I have in Technical where I show my own performance woes.

I am using GLES2.0
And what I think is the issue is not the GPU it's the driver and API calls.
If I draw only half of the tiles, then I get 60 FPS. Also I have more draw calls than 30, but 30 is for the tiles.

Yes, I do use GLSurfaceView, but I was able to draw at 60 FPS with it. I think it might just "snap" the frame rate to something round like 30 and 60. So if your render takes 25ms, you get to "rest" 8 ms until it reachs a frame time of 33ms. But it does the same if you are bellow 16.67 ms for 60 FPS.

If I don't draw the tiles then I get 60 FPS. I tried reducing the geometry with placeholdeers, but it didn't improve anything. I think maybe the draw calls are really that bad. I only have 31 draw calls for the tiles, but I guess 31 draw calls is terrible?
I wonder why draw calls are so bad, it sound a bit ridiculous. Like it makes the whole API impractical to use conviniently.
It just surprise me that the draw calls are the bottle neck and not the fill rate or geometry for instance...

Ok, here is how it looks after separating the update thread:



It still only gets 30 FPS, and it looks more messy while loading dynamically loading resources.
I might be addressing both these issues by reducing polygon count. I should try the same "experiments" with tile place holders that have a lot less polygons:

Oh i would say it's bad for the logic to take longer, because usually the render thread makes the pace.
I am thinking of using a semaphore and each time a render frame is compelte it will release the semaphore to flag for the next game logic update. This way the game logic will run at more or less the same rate as the render frame.
My game logic is less demanding because I am making a turn based RPG game.
I think it takes about 7 ms right now.
I should probably have such a render loop:

Code:

While (Alive){
DrawList p = GetCurrentDrawList();
FlagGameLogic();
GLDrawCalls();

So the next frame's game logic can start while the current frame is being rendered.

Hmm, do you repeat the logic update in a loop or do you somehow limit the amount of updates per second it can do?

What does Async task do?
Also, could you have a read after write in the OpenGL thread? Like, you write into a GPU buffer\texture while rendering and using it afterwards to render? That might be bad to performance.

Did you check if there is correlation with the GC thread?(which isn't shown on your screenshot)

Well recently I found that the GC is terrible on the Android. You will need so even if you do new float[4] many times inside your frame you are going to get many hiccups due to the garbage collector.
So you need memory pools and etc. Or just reusing and recycling memory.

Edit: Take a look at this:




You will see that every place the GC kicks in I get a gap in the main thread:

Ok, it seems the garbage collector is a lot worse than I realized... but I would still like to know if I should multi thread that piece?

I have profiled my mixed Java\C++ Android game and I got the following result:

https://dl.dropbox.com/u/8025882/PompiDev/AndroidProfile.png

As you can see, the pink think is a C++ functions that updates the game. It does things like updating the logic but it mostly it generates a "request list" for rendering.
The thing is, I generate DrawLists on C++ and then send them to Java to process and draw using GLES2.0.
Since then I was able to improve update from 9ms down to about 7ms, but I would like to ask if I would benefit from multi threading the update?

As I understand from that diagram is that the function that takes the most time is the one you see it's color on the timeline. So the pink area is taken mostly by update. The other area has MainOpenGL.Handle as it's main contributor(whch is my java function), but since it's not drawn to the top of the diagram I can conclude other things are happening at the same time that use the CPU? Or even GPU stuff that isn't shown in this diagram.

I am not sure how the GPU works on this. Does it calculate stuff in parallel to the CPU? Or is it part of the CPU usage as in SoC? I am not sure.
Anyway, in case GPU things DO happen in parallel to CPU, then I would guess that if I do this C++ Update in parallel to the thread that makes the OpenGL calls, I might make use of "dead CPU time" due to GPU stalling or maybe have the GPU calls getting processed earlier because it won't have to wait for Update to finish?

How do you suggest to improve performance based on that?
Thanks.