Ah, I've heard a lot about Construct, but I've never actually seen what it looks like.

gm mac is a shit program for trash babies

I've had a brief experience with that, I think, but if it's just going to be used to push a button, then that's OK.

Unless I need some specific paid version of GM, and you trust me with the GM file, I could build the Mac version for you.

http://www.80bit.com/pic/dragons-20140120-015814.jpg

http://www.youtube.com/watch?v=92WyxaY_Q28

All these technical event-management-like screenshots, what are they? What software is that?

Great to hear that everything's going fine. Let's hope for this new attempt to be a success!

<3

[colossal]

I just made Mathilda a template for the colossal 12.5 meter diameter water wheel that's going to be in the demo, under water, all rotten and infested with flora and partially broken, too. Can't wait to see what she does with it.



To scale with the submarine:

I took it upon myself to start working on railslavegames's fantastic idea of fly AI for his Oculus Rift game Selfie. Unity. C#. Got nice-looking random movement going pretty quickly, and turning on Unity's collision proved to solve half the issue of flies landing in itself. Looking really cool already.



Bonus, LAZOR BATTL:

Funnily enough, it shares similarities with the way the story/-ies is/are intended to be told in my own game, so it seems like we've hit a bit of a jackpot by working together here. Railslave's ideas appeal to me!

These flies were just a test that I made during the weekend, though. I really am quite busy at the moment, not necessarily with my own game, but a lot of other stuff too, so we'll see when I'll be able to give some proper attention to this project.

Even prettier:

Starting to have some fun here. Hundreds of flies!

Yeah, I've seen stuff like that. I guess I'm trying to find some midway point. I'm actually going to be hard-coding special access for more important stuff, probably. Also, children are not forced. Components can be created without the ability to store children, too. I will probably make the C++ interface more functional and accessible than the scripting interface. But I'm aware of what you're suggesting there. We'll see what happens.

Incidentally, I'm usually a tad annoyed when there's a base "component" class at the core of something; I feel that components should really be properly free standing and oblivious to the higher systems at play (ideally just data) rather than a glorified vtable holder indicating that the author may not really wish to move away from heirarchies at all - however that's usually 2am grumpiness talking, and I'm in the wrong room :^)

Oh, I've nothing against a good discussion. I do admit that I'm still somewhat inexperienced with component systems, but I've been getting a nice feeling about the stuff so far. I'm still the sort of person who will get in there and poke at lower-level stuff and make up specific solutions for certain things, if it can speed things up, but I still want a generic system for a lot of the stuff to allow for rapid design.

Point in case: I am probably going to implement the "character" (a submarine) in C++, because it's a core sort of object, that's going to be omnipresent throughout the game, and deserves a little extra attention. Things specific to levels and components, on the other hand, I will try to leave to scripting as much as I can, without having to recompile anything. The engine uses AngelScript.

I mean, you've obviously given it some thought, but yes, I still think it's horrible. By all mean use a const cast to avoid duplication of methods. It's the returning different types from methods than only differ by constness that seems idiomatic. I'd just name the two methods differently rather than do that: firstChildOfType vs firstChildOfTypeRef. Which conveniently removes the need for a const cast.

I'll be honest, I think it's pretty horrible too. But I say it's C++'s fault for not giving me a more elegant device to solve this problem. I say it's a core design mistake of the language. Every const-correct C++ programmer is well-acquainted with the tedious issue of having to make virtually identical const and non-const versions of a lot of functions. This is the least painful solution, that doesn't really mess with performance or maintenance, that I've found so far.

The signatures for the two versions are as follows:

Code:

const R<Component> &firstChildOfType(const R<const Type> &);
const R<const Component> firstChildOfType(const R<const Type> &) const;

R<T> is a class used for "smart references", i.e. the type of smart pointer that does not affect reference count. These are for passing things around. The actual (smart) pointer is kept safe elsewhere.

The mutable version of this method can return by reference, because every component keeps track of a reference to their own actual storage place (i.e. the component class has a member defined as R<Component> ref;).

The const version of the method has to cast the found child to a const Component and put in a new, temporary reference, returned by value. The reason is that modifying child components, in my eyes, is a modification of their parent; a const parent component (thus invoking the const version of the method) should therefore not ever return a mutable child.

Compare this to the corresponding function for retreiving a component's parent, which returns the mutable version either way, as modifying the parent cannot be considered a modification of its child.

We're building this with Game Maker: Studio. It should be as simple as buying another copy of GM on my Mac and then emailing myself the .gmx and pressing "Create Application" again.

I will probably do that as soon as we're a bit further along. You're not the first to ask for a Mac build and we'd certainly like to test and release one anyway.

Great. Drop me a new PM when you've got one!

Here's a bug involving quite a few bugs.

Fantastic.

It's because I'm using the ~~~controversial~~~ technique of saving myself from duplicate code by implementing the function properly in the const version, and then using this to be able to return the same data, but as a different, non-const data type, from the non-const version of the function (i.e. the const version returns a smart pointer~reference to a const component, while this version returns one to a mutable one).

I wasn't really aware of this either, until I'd seen it suggested by a handful of other programmers too.

It does indeed feel weird, because it's not a common practice, but is it really a problem? Casts like these should be both safe and free of overhead, as far as I know, as long as the object has been initially allocated as mutable. Non-standard, perhaps, but definitely a time-saver and a way to get rid of duplicate code.

I'm happy to listen to arguments against it, but "I haven't seen that before, so it scares me" is not sufficient.

Here are my arguments for it.

The way my program works, the components will always be underlyingly mutable, as they are all centrally managed, so I know for sure that casting back and forth will always be safe.

Agh, I didn't realise that there was no OS X version. Can't play the fancy demo that was given to me, I'm sorry to say.

[awesome]

I remember reading this thread when I was lurking before... and I'm so glad to see that it's still going! Looking awesome!

Thank you! We're trooping on!

–––––

Posted EIGHT more door variations on Tumblr earlier today. Forgot to post here.

Stone door variations for Vatnsmyrkr

We didn't feel stoned enough after a rough day of this heavy stuff, so we rounded the day off with some more easy-going pot and crack.

Where is the awesome non-violent games for example? Or adventures?

Our game is an awesome (), non-violent adventure non-platformer (it's sidescrolling and has things standing on stuff, but the submarine is free-floating, so I argue that it's not a platformer game).

My view on the matter is one that has already been expressed in the thread; platformers are generally simple to pick up and fun to play. A good example I have, is this old Game Maker game (I tried to find it, because I believe #yologames' forums were transferred from the original GMC, but I can't seem to find any search function on the boards...), which was simply called 'Bunny' if I remember correctly.

It just had plain-coloured blocks on plain-coloured backgrounds. The character was a ripped Megaman sprite coloured yellow, with bunny ears added. It was ugly and all you did was jump from start to goal while shooting enemies (vegetables). I don't even think it had elevators or anything like that. It might not even have had music, although probably sound effects, at least. It was a noob game probably made over the course of a few days.

It had nothing special or original about it, and wasn't even pretty to make up for it. But it was fun. I really remember thinking that it was surprisingly fun. That's just the way platformers inherently seem to be at their core. There's something about the basic concept that never gets old.

Take that fact, and impose actual craftmanship and impressive devotion to a project, combined with stunning graphics and wonderful audio, possibly also with a cool plot and/or some interesting mechanics/gimmicks. It's hard not to enjoy. That's just the way it is, it seems.

I realised I could just do this, thanks to the way my class is set up:

Code:

return const_cast<const Component *>(this)->firstChildOfType(t)->ref;

Disaster averted.

Wow, I didn't notice this thread. Still surprised nobody else seems to have done so either. Very empty in here. Humorous, how you barely had any time to get any activity in this thread, since it was over in the blink of an eye, haha.

Well, not over yet, I guess. A whole month to see that money piling up above the initial goal! What conclusions have you come to, in regard to stretch goals?

Congratulations again (mentioned this on Twitter)!

This is the most rapidly successful KS I have ever witnessed. So amazing.