I recommend against the release it on every store idea. Many have next to zero sells, while almost all of them require custom assets, and when you go to release a patch or update, it can be a nightmare to have to update every distribution channel.

You mean that it's hard to automatize generating versions for each distribution channel?

I'm finishing a (C++ template) system which allow me to group
 - group pools of objects of different type together;
 - have all live instances of the objects be updated at the same time (in one update call);
 - objects are updated by type, and other considerations which mean less cache miss;
 - access to objects in the system from outside the system is allow only through "monitored" access: you have to provide tasks to apply to the object and it will be executed only when all objects are updated (there is also a way to access the object in an thread-unsafe way);

Why is it useful? To allow me to gather different kinds of objects together that should always be updated together in a synchronous way (like all graphic objects) but still have a simple way to manipulate these objects from different threads.

It would simplify a lot most of my current code. We'll see!

A loooooong time ago (like 2008?ish) I wrote a collision detection system in C++ that takes any two Shape objects, then depending on their subclass, executes a function that checks against those two shapes. It's pretty tight, but I didn't bother implementing every function at the time. Especially the reeeeeally complex ones. Years passed, deeds became legend, legend became myth, blah blah, and I forgot about them.

While trying to debug why two objects with complex shapes weren't hitting each other, I eventually figured maybe my collision detection function was incorrect, and found this as the entire body of the function:

Code:

// HAVE FUN WITH THIS ONE FUCKER AHAHAHAHAHA
return false;

 

Hahaha that one is good.

I use a macro for this kind of stuff (UCX_NOT_IMPLMENTED_YET), it generate a debug-break (which generate a crash in release) with the message "NOT IMPLEMENTED YET!!! DO IT NOW!!!!!!!".

I also have a macro for remembering to write a function before compiling:

Code:

/// Use this macro when you just want to remember to implement a function before compiling
#define UCX_DO_IT_NOW       static_assert( false, "NOT IMPLEMENTED : DO IT NOW!" );

What I wanted to remark is that we're getting into a world in which programming skills are not always needed.

I think that's really the other way around. Lack of programming skills shows strong limits very quickly. Which is one reason why most successful indie devs says you'd better have at least basic programming skills to make games, whatever your role in a team.

I've been a Flash developer for more than 10 years now, in gaming and other stuff (websites). My experience is that you can wrap a lousy game on a fancy cover and will gain more attention than a great game on a lousy cover. It's just the way it is. There is one exception (there always has to be an exception) on this trend and it is... Minecraft (BIG exception).

I believe it's true only on very short time periods after release, which is not how you make money with digital stuffs, which should be long term (AFAI understand at least).

But that's another discussion I guess.

I agree, perhaps programming is the less creative part of gaming.

That's not at all what he meant and I fully disagree with what you just said.
I think Paul meant, and if I'm correct I agree, that the particular "opportunity" in question posted by PR doesn't have any flexibility to let the programmer have some creative inputs at some points.
Basically it's a factory work: you get a plan and you're expected to do exactly that.

Unfortunately, that means it's less interesting to creative programmers. There are only two ways to motivate people in a project, which in the best cases are combined: intrinsic (the game is awesome, everybody learn a lot, things are going fast in the team,etc) and extrinsic (money, advantages, workplace). Here the intrinsic motivations are not provided, so to recruit anyone who would have both skill and time to do the job, it would require high extrinsic reward, either money or... etc.

Is this what you meant Paul?

Hi!

I'm looking for very basic level editors that I can use in class to practice with my studens basics about level design.

Thanks!

Would MineCraft be out of question? It's not a traditional level editor but you can learn basics of design by making a dungeon for other to discover or something.

Nope, I'm using GCC on all platforms and it's plenty accurate. But that might be a problem, because I was wanting to package up my various helper classes and release them as "handylib". I don't want to use boost so that leaves me rolling my own cross-platform timing system if I want it to be MSVC-compatible. I'll see.

If you do this, you would only have to write a clock like std::chrono::high_performance_clock yourself and still use std::chrono for the rest.

My current version of GCC for windows doesn't support std::thread, so I've rolled my own crude threading wrapper for Windows and eventually POSIX. It leaves much to be desired- in particular, you can't yet pass an arbitrary thread function (must be void(void)). I don't intend to use it for much except animated loading screens, though.

Yeah if you just spawn a thread at some point and it's not the basic way your system work, it's ok to not use std/boost::thread or anything else.

Beware if you compile with MSVC, the granularity of std::chrono is very bad and will be in the next version too. Source: https://connect.microsoft.com/VisualStudio/feedback/details/719443/

I've hit some time precision problems because of this recently. The simplest solution is to use boost::chrono instead as it is very precise, but it forces you to use boost::thread instead of std::thread if you are using timing facilities like std::condition_variable or std::this_thread::sleep_for/until().

Just know that current std::chrono implementaitons are not yet all equivalent. Unfortunately I think it will be true until next year 

Made my game (if you can call that a game already...) all different cpu cores with equally distributed workload.

Now back to graphic code.

The point is that only unreliable programmers seem to be agreeing with that budget.  Reliable proffesionals wouldn't touch it with a bargepole.

I'm quoting this again because it's the answer of your question and you apparently don't want to read it.

I personally, am known to be reliable, but I'm also known to not team up with amateurs (so I don't team up often). The reason why you don't find people like me is exactly this quote. Also, reliable programmers in game dev often have their own projects going on. So you still need a compensation to spend their very valuable time on your project (that have all the chances to appear shitty from the programmer pov anmyway) instead of spending his time on work that pays a lot (reliable programmers gets reliably jobs) or on their own, far more interesting, projects.

As the advices around here are very varied (and I think a lot of very introverted people don't like phones and skype), the best way would be to try it anyway, see how it goes and make future decisions on your experience. If it's a project that is too critical to accept tries, then you have your answer.

What if you used one of the engines like cocos2d-x? I think that it already has the Obj-C stuff sorted out so you can just focus on your game code.

Cocos2d-x is all C++, rewritten from the Objective-C one, that's why it's cross-platform. It is very easy to make games for both iOS and Android without rewriting code, but for windows/mac/linux it requires a bit more tweaking. I suffered a lot to include keyboard input on my grad project when I got my macbook stolen and had to quickly port the objective-c cocos2d-iphone project (targeted to Mac) to a windows cocos2d-x project.

But it is very nice to work with, if you are used to C++.

Also, Cocos2D-X force the user to organize the related code using Objective-C idioms instead of C++ idioms. It's ok most of the time but it can really be problematic if you can't totally isolate you C++ code from the code that work with Cocos2D-X.

Currently my game don't do much but still occupy the 4 CPU cores and does a lot of locking and oversubscription, which was what I was expecting anyway. Now I'm just fixing this by removing locking (using task queues) and introducing some sleeping when nothing have to be done on some specific threads.

To clarify, the graphics I'm talking about are out of the game itself.
The biggest problem is that the game itself is unfairly hard to play because of the navigation controls yes.

I also forgot to say that I like that the subject of the game is somewhat political, and in the same time I think it might have a huge impact on who will even try this game after looking at the title and description. I don't know if it's bad or good for selling, but I think you have to make sure your audience is what you are looking for. If you can manage to keep this kind of political or strong theme, it would be awesome.

AFAIK, it depends: most games don't need ASAP updates, physical games needs fixed frequency updates, and depending on what is the bottleneck it might be either rendering or game update that need ASAP updates.

I'd go with fixed frequency for both personally. Far more predictable.

I tested this game very quickly on a Samsung Note 3, so here are some remarks:

 - I fired the game, but then got a message to I wanted to get out of it but getting back is apparently buggy: it makes a 'toc toc' sound, then when I want to get back to it it will show the exit screen.
 - Why is there an exit screen? Why is it asking if I'm being bored by the game? It looks like the devs are being insecure about the game. Remove this screen: when I use the get back button from the menu I just want to exit, don't add this kind of thing.
 - The graphics might be a problem: to sum-up, it looks amateurish.
I'll try to help on this but I'm not an expert on graphics so maybe ask to an expert after you read this:
 1. I think the drawing is good.
 2. I think the coloring of characters is good, but read the rest.
 3. The composition of screens is insanely bad: texts superposed, which looks like buttons but they are not, too much different fonts, too much different gradients. The splash screen is really not good at all, in particular the blurry vulture... this screen really have to be totally changed. As said, the drawing of the characters are good enough to me, this is totally broken by the global composition.
 4. I think that the colors might be too bright, which plays in the amateurish look. I don't know what to do about it, but maybe you should work on limiting the color pallete or something?
Anyway graphics needs a lot of work, or please remove all graphic complexity. I don't mean it's very bad, it's just really amateurish (I've done the same errors myself when I first made games, but it was around high school so I learnt, but you'll need to learn some basic composition coloring stuffs I guess)
 - I think the menu have too much depths.
 - I think it's nice to have the story introduced as some kind of comics. However it would be better if each image would appear when I tap, instead of having 4 in once. That's a taste thing not a particular problem though. I make comics and digital comics so I think this could be better but it's not the game so it's ok.
 - The story is hard to follow because of the way text is used. As I said I make comics so I know how it works but it's hard to explain how to fix this without re-storyboarding this part.
 - The first level is insanely difficult. Basically, the control is very very very very hard. I think you figured now why most platform games on touch devices either have only a jump action (runners), or only have directional navigation but not jump. Here it's so hard that I just can't get at the end of the level. I stopped trying after 3 minutes. If the game starts this way, there is no reason for me to assume it's easier after it.

Note that I don't abandon easily hard games, but if the basic navigation control is a challenge, then I don't see the point.

So, I stopped there but I think you might have learnt a lot with this game. I hope you'll fix the graphic problems and navigation problems in the next ones.

I very quickly tested the game, I'll give you feedback in the thread.

This is interesting that game companies finally emerge from black africa. Good luck guys!

However, i think you should review your thinking:

 - Most indies don't have publishers as it is the point of being indie...
 - there are publishers helping indies, but I think you need to show success before them to be interested...

For payment processors, currently BTMicro and FastSpring are the most recommanded, but I don't know if your location wold be a problem. I think it would help to have the account in their possession then transfer the money regularly to your place, but you'll have to see with them if they can do it without fireing alarms in bank systems.
See this page for a list of payment processors with useful data: http://www.pixelprospector.com/the-big-list-of-payment-processors/

Getting back to graphic programming after months of purely console output is refreshing!