[Flying King Collective]

The internet in china has lots and lots of odd restrictions.  Lots and lots.


Flying King Collective did it for me.  There's something subtly terrifying about the notion.

A few ideas.

- Pacifism in the face of conflict.

- Disposable protagonists.

- Adventures in the dreamscape.

I would like to write.  Badly.

Getting off-track during file loading is a bitch.

You should use a serialization system that doesn't make you write procedural code!  

the entire fucking point was so the PNG decoder (and related) was not in the Texture class as my graphics engine really shouldn't care how a texture is loaded

Pardon.  I was making fun of myself, not you.  Because I wrote a big unnecessary serialization system, you know.  When I didn't need to and solutions already existed.

A metroidvania where instead of getting magic orbs you have "holy shit, I can do this?" moments.  Awesome.

Also, [7 makes the fellow's arm freak out a bit.]

...But it might easier to just check them all, especially in a small world.

Moving on from something with a fixed number of game objects involves a few basic ideas.  Figure out a way to "hold" all your world's contents--whether that's in a big grid of tiles, or a "pile" of free-floating objects--and how to go through that repository to check for collisions and things.

As objects beyond just your player begin to need behaviors of their own, you might need to set up a system for updating some or all of the objects in your world.  An easy way to do this is an "update" method that gets called on every object every frame.

Good luck! 

Old algorithms for 2D constructive solid geometry would sample the poly-shapes into bitmaps, combine them, then turn the resulting raster back into new poly-shapes.

Presumably, then, a bitmap-to-polygon algorithm is a pretty cheap affair.  And what you'd want for Box2D.

A good starting point, maybe:  http://stackoverflow.com/questions/277195/convert-bitmap-to-polygon-reverse-rasterizing

Though, these guys seem to imply this stuff can get a little rough.

Getting off-track during file loading is a bitch.

You should use a serialization system that doesn't make you write procedural code!   

Gunnerkrigg and Evan Dahm's stuff.

I like plot comics.  Feel free to refer me to more.

THE BLACK BOX BUG IS FIXED!  Thanks to Landshark for helping me with it.

Clicky!

I hope those of you who couldn't try this before will give it a whirl now.  I feel really bad for not fixing this sooner.


And pardon this quadraposting I've pulled over these last few weeks; I consider these meaningful updates, so I don't feel too bad about it.

I'm operating under the assumption you're using Game Maker.

With GM6 you can use a DLL; I'd be happy to write one, actually, though I'm sure one already exists.

What the post two before me is talking about is progressive generation.  That is, if the player can travel and more forest is generated on-demand, the stuff he's talking about is relevant.  If not, it's not.

If you generate the whole forest in one shot, storing the random seed means you can load that seed and "randomly" generate the same forest again with another call to your generator code.


If that's not for you and you'd like to store the data itself, then come up with a repetitive file format like this:
[number of objects]
[object index] [X] [Y]
[object index] [X] [Y]
[object index] [X] [Y]
[...]


Also, please tell me you've got parallax for that forest.  It could be so sexy.

It is frustrating when there's a lingering bug in one's tools.

Take any OpenGL/SDL application under Windows, maximize the window and un-maximize it.  Failure ensues.

Part of my goal *is* portability; I keep my dependencies minimized, especially for my engine's core.  (as opposed to implementation layers)

But that's my game engine, not the serial system.  Which, though I might look into Boost, I'm keeping.

Though I use the hell out of STL.  Shame it doesn't have hashmaps or bimaps, though.  Wrote the latter myself, going to do the former at some point.


Anyway, whenever I get around to opensourcing my engine, I'll release this code standalone for the hell of it.  Thanks for the feedback, and feel free to give more.

Ignorance. 

I'll look into Boost's system.

Sexy animations as always, Paul. 

I'm gonna try the crap out of this tomorrow.

1) how well does it handle saving c++ vectors, or doesn't it
2) does it have a stack structure? Ie first in, first off? Do you have to go through ALL your data to get to the start

Regarding the stack question, it's all automated so that one doesn't need to worry about how complicated the interdependencies are.

It handles all STL structures in an automatic (if not optimally efficient) manner.

From a design perspective I'm not sure that every object that needs to be serialized should have imposed on it the need to inherit from some base class.

I really don't like enforcing the superclass, but I've ensured it'll work safely with multiple (diamond) inheritance.  I could potentially do away with it with more sophisticated use of templates, but that could get nightmarishly complicated to implement.


-

Regarding serialize methods and stream operators, I designed the whole system around not having to write new procedural code for each class.  My beef with that was always that one had to write two separate pieces of code (read and write) which describe the same information.  These can be long and tedious for complex objects, and are made worse when manually facilitating backwards compatibility in files.  What's more, if just one class has a bad read method and passes over the wrong number of bytes it's bound to be a nightmare to debug when it's not the only data in the file.

That said, it may well be an overengineered system, and potentially a bit heavy as an addition to an existing project.

I could make descriptive reflection optional, so as to make versionless class clauses as simple as this:

Code:

Type MyClass::_type = TypeSetup<MyClass>()
____<< Register(&MyClass::x)
____<< Register(&MyClass::y);

I have a teeny little community right now, and I'm still a bit curious about this myself.  My ears are open to anyone wiser who responds.

My own experience has been getting a few people who were excited about my game, putting up a forum for them to give me bug reports and suggestions, and adding things there for ingame stuff.  My project is online, collaborative and community-based, though, so it comes a bit more naturally than it might with a single-player game.


--Oh!  Just saw that your game is online.  Well, now, that changes things!

First off, making sure your game has initial appeal to people is important: community members are 'recruited' from players, not the other way around.  Once you get loyal community members, they might bring in more people, but don't count on it.

Secondly, letting members of an early community in on the development process is both a great source of help and a wonderful way to get community members participating.  Make your forums focused around feedback and suggestions and respond promptly (and positively) to both.

Third, keep the information coming.  I'm not to this sort of stage yet, but it's easy to see in successful community managers like the Wolfire guys.  Regular updates and a sense of continuous, rapid progress on the project will help people to stomach early versions of your software and keep coming back for the new ones.

Eep.  Any ideas on how to handle stuff like that?

I was hoping to figure out an arrangement like internet media portals, where copyright owners can express objections to content on an individual basis.

Perhaps the prints no es un good idea? 


Regarding the obscure EULA, I'll try to move it somewhere more prominent.  I didn't expect that to come off as a jerk move but I realize now it might.

[Get it here]

Lifting this topic from the depths yet again to release a new update, 0.2.3.  I'm a day late making this post.

Get it here

I was going to keep working until I had multiple worlds and a "choose entry point" screen, among other things, but that was taking too long and I was sitting on some good changes.  I've released a non-required update which improves gameplay in a few ways:

- No more monolithic cache (load times are gone)
- No more pipeline freezes (those caused graywall and disconnecting)
- The ability to reconnect when disconnected, so as not to lose your place
- Bugfixes
- A better camera
- Visual tweaks to the painter

Also, a video is up now.  Click!


By the way, my Kickstarter finished, raising 238% of its goal!  :D

From just reading the descriptions and watching the videos, I'd give the technical award to Achron. http://www.igf.com/php-bin/entry2011.php?id=421

That's a really clever system.  :D  Agree.