I like your idea of having limited actions per turn, it should make this game feel like a cross between a 4X and a board game.  I love 4X games but they suffer from a problem where the further you get into the game the more decisions you have to make each turn but the less important each individual decision becomes.  If you can find a way to successfully limit actions without restricting the player too much once they've expanded this could help keep things flowing in the late game.  I look forward to seeing how this actually plays out, maybe you could post up a game play example video?

Also just a word of warning, the 'Endless' name has been tagged by Amplitude Studios which they've used for several games already (including a 4X space one).  Since they've built the 'Endless' name up as a brand and you are developing a comparable product to them you could run into some issues with trying to use that name.

Brace yourselves for the onslaught of poorly coded games with bad assets but really nice effects and shaders

has anyone used unreal? is it as easy as unity? Cause the basic games look damn better.

I'm using both and in my opinion Unity is more immediately accessible and user friendly but Unreal has more potential, particularly for more advanced/experienced users and people willing to code.

The biggest difference in feel between the two for me is that Unity is clearly designed from the ground up to be a generic game engine which it does a good job of.  It adheres well to its entity component design and gives you a lot of flexibility in structuring and organising your game as you see fit.  Unreal on the other hand has clearly evolved from a bespoke tool and is still carrying around a lot of baggage and legacy from its origins.  As a result it can be quirky to use since it makes a lot of unwanted assumptions for you regarding your game that makes it less flexible but also makes me distrust it since it can sometimes do unwanted things behind your back.

The flip side of that coin is that there's nothing Unreal can do which you cant figure out if you put the time into debugging it since you get all the source code to work with.  This also means that if the engine is missing some feature which you later realise you need there is always the option of extending the engine.  That makes it a lot safer prospect since Unity is a black box so you always run the risk that you might run into an issue which you simply cant analyse or fix which could sink your project.  This can turn out to be very important since support for both engines sucks.

I've got a Markus at home which I've found comfortable even when sitting for long periods.  It's slightly above your price range but it's probably worth it.

I've been waiting for a game like this and have often been tempted to try and make one myself. Good show, I'm looking forward to seeing where this goes

Being concerned and trying to help is a good thing and I commend you for that.  You just can't impose yourself and your ideas on others where it isn't wanted. 

I'd like to make the point I specifically avoided naming them, and was trying to accrue some corroboration to better convince them I had a point since there was no possible other dev presence in the forum with which to do this.

Your opinion doesn't need corroboration, if they wanted to take your advice they are capable of corroborating it themselves or asking you for more details if they wanted to but they've decided not to and that's their call to make.  It just seems that you're on a mission to prove to them that you're right and they're wrong.

I dunno man, you haven't been directly involved in the development process of their game or seen the source so regardless of your technical background you're speaking from a position of naivety.  Admittedly it does seem they have an issue that should be able to be resolved in a better way but there may be many reasons why that isn't feasible at their current stage in the project.  Even if you are right though and they are inexperienced or lack the technical ability and you do know better than them, you've given them your advice and it's their prerogative whether to take that on-board and act on it or not.  There's nothing more you can do and to continue to harass them and bitch about them on other forums because they refuse to do things your way is totally out of order.

Looks cute but I think your main character is just a little too derivative of Kirby from canvas curse.  He's basically an exact copy with a tan.

+1 for Eldritch Horror.  If they also like card games then "the Lord of the Rings" LCG by fantasy flight games is also a really enjoyable co-op game with loads of replay value and expansions.

Hi motorherp!

Sounds like you need to include and initialise GLEW

Sorry, I don't follow. Am I using extensions here without realizing it? Are random, copious 1282 errors an indication of that? Or does glew provide some other diagnostics that'll help me figure out what's going on?

Quoting knowledge folders:

OpenGL allows extensions by hardware vendors. OpenGL has a protocol and low level API to discover what these extensions are and the supported functions. Using extensions in your C++ code is - unfortunately - platform specific. The address of the function (function pointer) must be retrieved from the OpenGL implementation (e.g. hardware driver). Under Windows this can be done using "wglGetProcAddress".

GLEW is a common API to write portable code which internally hides the platform specific detail. So you will be downloading GLEW for each platform and the client programs can stay portable as long as the target platform supports a GLEW implementation.

The way I understand it is that basically functions such as glDrawArrays etc are actually function pointers which need to be assigned to their implementations which will depend on the platform and hardware installed.  Hence why you get an "invalid operation" error when trying to use these functions without having assigned them since OpenGL believes they are not supported by the hardware.  There are ways you can do this manually but it's a massive headache.  GLEW is a free lib which auto handles setting up all these extensions for you.  Just for the record, alternatives are available but GLEW seems to be one of the main ones and it works for me.   

Well, I sprinkled  `glGetError` checks everywhere, and there are 1282 (invalid operation) codes getting thrown all over the place. glDrawArrays reports 1282, glColor does also, and interestingly, the innocuous line `glMatrixMode(GL_MODELVIEW);` throws it as well.

So at least there's something to go on.

Sounds like you need to include and initialise GLEW

We've been using Jira on our latest project.  I don't really have any complaints about it so it might be worth a look.

You could design a system where you don't have to construct buildings or one where you don't even manually have to produce units.

Z did that, it worked pretty well ->

Currently sat in the bath with a glass of Bailey's listening to George Michaels Careless Whisper.

Keep it

A lot of it, at this point, just seems to be the nature of the beast and that maybe this idea isn't as feasible as I originally thought. Maybe I need to go back to the drawing board and think about it a bit more.

Obviously without seeing the code or knowing your exact use case and requirements I can't say with any certainty, but from the difficulties you seem to be having it sounds like re-examining things from the beginning like you say will be worthwhile.  Ultimately if you're having to jump through so many hoops to make a certain paradigm work for you then you're probably using the wrong paradigm in the first place.

If the class/method handling these virtual objects needs to handle a wide range of children object types but also needs to know specific implementation details about those children objects and respond differently based on that information then inheritance probably isn't the correct pattern to be using.  Instead it sounds like you're needing something more like an entity component system.  This would allow your calling method to do something along these lines:

Code:

void FireAllRocketBoots()
{
   foreach(Entity entity in entities)
   {
      RocketBoots rocketBoots = entity.GetComponent<RocketBoots>();
      if(rocketBoots != null)     // only entities that actually contain rocket boots return a non null component
         rocketBoots.Fire();
   }
}

I wrote a post about the problems and solutions I encountered when I implemented splines in the tool. To be honest, most of the solutions are not mine, but I hope this post will be useful!

You can read it there:
Splines and shoot 'em up

Nice to know people are still finding my tutorials useful  .  This looks really good, looking forward to seeing the finished thing.

Looks like you're already getting media attention which is pretty crazy considering this is still probably pre-production.  Be careful not to let too much early exposure rob you of your opportunity to gather feedback whilst remaining flexible and non-committal during the early stages of development.