That's colourful, but I believe it's not a fail
You'd have to be *somebody* to mistake "math.random()*255" with "shade".

[$60]

C++: App Game Kit - $60
LUA: Corona SDK - FREE / $600 a year
C#: Xamarin - FREE / $300 and up
C++: Cocos2D-x - FREE
ActionScript: Adobe AIR - Basically download FlashDevelop, it has all you need - FREE
Java: AndEngine - FREE

I omitted already mentioned frameworks.

Personally, I've had trouble finding a tutorial that really teaches me what I want about "Game engine architecture". They teach a lot about all the little sub systems, but in the end, my main problem is how to actually tie everything together.

The best way to learn is by making actual games. From what I've learnt you should develop (if you are using an object-oriented language, or semi-OOP language) that it's the best to stick with OOP. (Object oriented programming)

It's rather hard to describe how to manage your code, because it varies between games, but you generally should reveal that by yourself, I think.

Example:
Have a GUI? Make a class called MainGUI. Inside that class, have objects of different GUI elements. One could be GUIButton, another could be GUIHealthBar. Then in main game loop do something like,

MainGUI.process();

If you understand what I mean.

And I am a big fan of using any scripting help. Hardcoding things seems to be the worst idea to me. Why would you do that? It's only making your game's engine code messy. Speaking of which, I prefer coding game's engine in core language, and having all the additional stuff scripted. Whether those are quests, weapons, spells or anything like that.

It's way easier to manage separate scripts (and don't have to compile the whole thing) for me.

Should I be aiming to integrate stuff like this into the actual map editor, or would it be done separately?

It's up to you. Depends on what editor are you using (did you code it), and what do you need (the complexity of it).
But speaking in general, from my latest experiences, I recommend not to implement too much stuff into the map editor. You might regret it once, when you need to add new stuff. But again, that's really vague, and it completely depends on your skills (if you can implement it), and others (mentioned above).

I recommend to go with LUA if you would like your game to be moddable and modded (It's a standard to modders these days). I'd also advise in it's favor due to the simplicity in implementing it into your engine/game. (I haven't tried the others, but I can atleast speak for this one)
But again, you can go for whatever you like.

Basically, 0 is a value. It's not.. void.

Really digging this character model!
I am waiting to see the textures applied

Great models overall, by the way.

Add land mines.

C:

I tried to build it from source, but it was a huge hassle.
Then, I compiled all dependencies, linked them, put whole polycode source to my project, tried to compile, and yet failed. Had many troubles with freetype's (that's how it's called?) include pathes.

I guess I'll just wait for binaries...

Cheers
All fixed now.

I'm out of town for the day, but I'll take a peek when I can if no one else does. Did you try an compile and run my example, if so did it work?

I didn't. I'll try it tommorow, perhaps since it's kinda too late now

Phew, I studied through your code, tried to find any differences, if there were any, I copied & pasted, and it still won't work

My two small projects which are broken - available for interested

(The library project adds an include path to GLM lib, althrough, it can be deleted as it's not used there [yet])

It seems like a strange problem that it doesn't work as a static library. Are you making sure to link libs like user, and kernel into your exe? That could possibly affect things. Admittedly though its been about 15 years since I did win32 coding and raw directx.

Hm, I am not sure. This is the first time I am trying to create a library. (Before I used to have the framework and the self-coded engine in the same project as my game)
To create this library, I followed this walkthrough, but omitted "To use the functionality from the static library in the app" point, and simply added include directory path to my library's path and included .h files from there (Also linked to the .lib ofcourse)

Maybe I did something wrong?

Sure, but there wouldn't need to be those ifdefs if you used a layer like SDL or SFML, and could focus on the actual game framework part.

Cool, but if I used SDL/SFML I wouldn't fill the reasons for which I am actually coding that framework. There is a slight difference between a general purpose game framework, and a sepecific framework, for a specific game.

We have a bunch of platform specific code in the KAG codebase, and while its nice to work with on the outside, adding a feature that requires modification of that platform dependent code really, really sucks.

But those are two separate things - you knew what you want to code. It was some kind of a game. You guys knew that Irrlicht and few other libraries/APIs fulfills your needs.
Now, I know what I want to code, too, but it's not a game. It's a framework, and I believe it can be as fun/entertaining as coding a game.

I totally get wanting to do stuff as gnarly as possible, but for anything intended as productive work that pays the bills, I'd err on the side of having more dependencies (which are usually fairly trivial to set up, if they're good libs) than having more platform dependent code in your own lib.

Again, I'll add dependecies where I need it.

The "portability" part isn't, because the #ifdef xyz #elif yxz #else #endif approach is just a wrapper around the fact that your platform dependent code by definition isn't portable - obviously there are going to be platform specific bits in any framework with "no dependencies", but after you're done wrapping the platforms you support up to the point where everything is platform agnostic (and therefore free of #ifdefs) you're going to be writing code on top of your own implementation of SDL/SFML/Whatever.

Maybe I should add that those #ifdefs are inside the library itself, and the code (that is using that library) looks/is supposed to look like this?
(Only meant to look this way. It's a subject to change)

Code:

#include <BlueKit/BlueKit.h>

int main(int argc, char* argv[])
{
    BlueKit::InitWindow("title",800,600,BlueKit::POS_DEFAULT,0);
    while(BlueKit::isRunning())
    {
        BlueKit::Update();
        BlueKit::Render();
    }
    BlueKit::Cleanup();
    return 0;
}

The "I want to create my own framework" part... If your intention is to write a game framework handling things like physics, optimised (tilemap, mesh, sprite, whatever) rendering, a nice sound interface, archive access, networking, cryptography, scripting, autoupdating and so on, then you'd be better off introducing even as many as seven or so dependencies to cover ground that's been covered many a time, in a way that's tried and tested (and takes 10 minutes to set up).

That was my intention. Those dependencies can still be manipulated between platforms.. For example, I might use one dependency on windows (like, say, libcurl), and another on android  (Java sided, probably).



By the way, Geti, do you think that I should really care if people find my reasons proper? I have decided that I want to do something, and asked for help with implementing it, not for help with deciding whether I want to do it or not.


Alright, Average Software, that is just code organization, thanks for warning. I'll look at how have you done it.

Uh... You're talking about portability but using win32? Hmm... Does not compute.

Please, why does there always have to be one person who enters a thread and wants to know why I don't want to use something they'd prefer?
And that happens to almost any technical thread on tigsource, but I have already made my choice, I considered alternatives like glfw, SFML, SDL and so forth, but I have picked this way for a reason.

If you want to know so badly what that reason is, then I am happy to say that I want to:
A) Get more comfortable with Win32 API
B) Be less dependant on 3rd party libraries
C) Create a framework on my own

Also,

You're talking about portability but using win32?

Yes?

Code:

#if defined(_WIN32)
//.. win32 code
#endif
#if defined(__linux)
//.. linux code
#endif
#if defined(__APPLE__)
//.. apple code
#endif

That's what I am using. Seems quite portable to me. Alternatively, I could've make separate libraries for platforms of choice, but instead I prefer to have that all in once place, so I don't end up surrounded with libraries.