Bay 12 Games Forum

The only problem with buying CK2 is sorting through all the DLC. Especially if you own some and not all. Then you have to manually click on every single one to see if you own it or not.

http://www.enhancedsteam.com/ will make your life so much easier. It only works on the web version of steam, but it lets you see which DLC you own and which you don't at a glance from any page.

OP updated with new title.

Has anyone tried attacking one of the spawners or a mammoth yet? I'm not really sure if there's any point in doing so

Oh my gosh the trees are beautiful.

@skyrunner:
autos decrease the amount of code that needs to be written at the cost of increasing the complexity of the compilation process. In practice autos will definitely make your life easier in the vast majority of cases, but be sure not to confuse a lightweight syntax with a lightweight language!

@MorleyDev:
I wasn't saying any of the features I mentioned were not in other languages or bad in any way, simply that they added to the weight of C++ more than C backwards compatibility does (which does bring up a curious point: C++ is actually not entirely backwards compatible with C. How much of C++'s features are then C++'s own language idioms, and how many are actually C backwards compatibility?). This is speaking relative to something like scheme or javascript, both of which are much more lightweight languages. And many would argue that C is a much more lightweight language than C++ anyways.

Also a note on templates (along the vein of killjoy):
- Templates are very powerful and allow for some pretty nifty things (just take a look at boost), but templates are subtler and more complex than generics are. The underlying instructions for a generic does not change from one type to another (hence why they work only with reference types or PODs in languages that have generics). On the other hand, templates actually compile into different instructions for each type that you use. So templates are quite different from reflection+generics, since reflection happens at runtime while templates are created during compile-time and do not change their behavior during runtime.

@Skyrunner:
Do you think you could just use pygame along with libtcod and use pygame's event handling?

@Neonivek: http://playstarbound.com/dungeon-generation/

There are set pieces in Starbound, along with hand-crafted quests tied along with them. It remains to be seen how well the devs implement these and whether they'll be available on release, but the Starbound devs do intend to address the very thing you're complaining about.

@alway:
"particularly since we don't really know what all it will be doing yet." <-- precisely why you want a messaging system. So you can have objects that you write now communicate with objects that someone else writes in two years with the same interface. Siquo's example message is simplistic for the purpose of demonstration, but a real message/message handler system would be more complex and interface with many more components.

As for worrying about a messaging system being too complex to code, I would say don't worry. There are a couple of experienced coders on this forum, and experienced coders know how to make things easy for themselves. That being said, having a good base simulation object and entity/component class including some sort of update, position (if applicable), or other common universal attributes will still be necessary.

There are also many tricks up the sleeve of a computer scientist that will make the performance loss basically unnoticable. And the benefits from the easy multithreading that you basically get for free for making a good messaging system will make these performance losses moot anyways.

@Siquo:
The messaging system is alright for some cases, but I think for GUM we need a different type of messaging system. We don't have centralized objects, so we need some sort of publish/subscribe system (i.e. whenever a new animal is created, it needs to be able to publish a NewAnimal message to everyone who wants to know about such a thing). Also, I don't think the message handler should be tied to a specific thread, since it's not scalable (i.e. the same messagehandler should be able to process 20 messages over 1 thread or 2000 messages over 4 or something like that). In particular, classes like "World" or "Graphics" should definitely not be inheriting from the message handler.

One thing in particular that bothered me, messages should not have an execute function. The message pattern usually involves listeners, and listeners decide how they want to respond to messages. In your particular example, then you wouldn't need to dynamic_cast to check if the message listener is in fact a graphics object. alway is also right in that writing so much boiler-plate code just to send a simple message isn't that great.