alpha123

Sorry, I sold my nerd card to the devil in exchange for knowledge of all the Emacs key bindings. It's a little... blurry. From what I can make out though, it seems like you've focused on the characters a lot and the terrain barely at all, which isn't necessarily a bad thing, but we do need map concept art too.

Agreed. Actually, most of the time I'm on Windows (Windows 7 is surprisingly comfortable). I switch to Linux when I need to use NodeJS (which I can't get running on Windows) or SBCL (which is experimental on Windows), or sometimes just for fun.

If BIONICLE ever comes back, I hope this is what it will look like. For whatever reason this set actually looks cool to me (I think it's the Bohrok posture thing). It's almost catching up to some BIONICLE sets. I do think that HF took at least a step backward in terms of overall design and especially build complexity, but at least this is improving the former somewhat.New packaging is disappointing. I doubt I'll actually buy this set, as neat as it may be. I more or less lost interest in LEGO after they canceled BIONICLE, and I have better things to do with my money.

If we weren't using a game engine that had Mac support, Mac support would be really low on my to-do list for B:CoD.

That being said, several weapons will probably have gun-like properties, correct?From what I understand, yes. Maybe even some elemental powers will be gun-like (fireball).

It's implemented, albeit only over a local network (Sphere makes me handle networking at a pretty low level). However, it's very primitive and hackish -- that game was originally designed as a really quick proof-of-concept for multiplayer networking in Sphere (the original version didn't involve BIONICLE at all, actually). Also note that it only supports 2 players, though it wouldn't be too hard to extend it for more. I was talking about the multiprocessing module possibly being rather slow on Windows due to no os.fork. I know that processes are faster than threads in Python thanks to the GIL.

Yeah, I'm looking for an MP3 alternative to Apple. The Galaxy Player looks very interesting, thanks.

I vote processes, but Windows CPython (except Cygwin) lacks an os.fork function. I don't have enough experience with the multiprocessing module to know if that makes a significant performance difference. Either way, threads in Python are kind of a pain due to the GIL (at least in CPython -- Jython and IronPython don't have a GIL), plus the fact that they moved to that stupid Java API...

I could start ranting about how Python doesn't have macros, multiple return values, multimethods, tail call optimization...It's the Blub Paradox. Google it.Back to the topic: Since the Lightning absorb power turns off machinery in the area (and doesn't say unavailable by it, so I'm assuming that it's implemented), shouldn't it disable the Exo-Toa?

Be careful - copy-pasting code verbatim is bad 99% of the time. I suggest finding a way to reuse your already-existing code instead.Game Maker Language has no better way to reuse code (IIRC no functions, let alone objects!).

Okay. Thanks.

A rather important question I forgot to ask: does Panda use Python 2 or Python 3? A quick scan of its site didn't say.@JKK's networking idea: That's sort of similar (although better) to what I tried to suggest. I vote for it.

I agree. I've never used Panda before and would like to see how UltraHau does it.PM or email me and I'll give you a quick run through of Python.

Well, obviously it's not going to be the very first thing we code. Loading maps and movement probably would be, but we should have those communicate with the multiplayer module, even if it does nothing with them. Dummy multiplayer is fine, I don't care if it does nothing at all (e.g. all the methods just pass), as long as we could fill in the details later. I disagree with multiplayer being a detail. Multiplayer can definitely dictate the architecture of a game. For multiplayer to be done easily, the system has to know about it from the beginning. The key there is "when needed". We don't need to here. Like I said above, we don't actually have to write the code to communicate over the network. Just getting the multiplayer framework in won't take much time, and we can drop some other stuff to make time for it if we have to. Our future code is going to have to know about and use this framework anyway. It doesn't need to know about the implementation of the framework. Communicating across the network can be done after our first release.

Cut back on some other stuff if you want to get it done fast. There's no reason not to have it in the first release. Why take the risk of not designing it correctly when we can just put it in there first thing? Why bother creating something that we're just going to throw away next release?Also, it's not like we're in any sort of hurry to release this thing. We can certainly afford take a little time to get multiplayer working. Give me a reason we shouldn't put multiplayer in the first release.EDIT: Note, I'm not yelling at you in the bold parts, I just consider those to be important points.

Would anyone still suggest these over an iTouch (mostly for music and occasional web browsing)?

Okay. Good luck with Bionicle Fighter (probably the best fan created platformer ever) and school.Oh, and don't worry about the stuff for my game. I'm a. mostly working on my RPG Ranku's Quest right now, and b. still sorting out a weird bug involving Sphere's particle engine.

I didn't know there were large areas of California with nothing but grass and cattle. (And no, we weren't staying in such an area, more like... right next to such an area). Read the article. Seems fine to me. I would put preliminary multiplayer support in the first release. We need to have multiplayer from the very beginning or else this will get messy. I'd go with just 2 maps, and maybe 2 Toa/Skakdi in the first release, to save time and get multiplayer working ASAP. I agree that bots should be in the first release, but I don't think they should actually have anything close to a good AI. Maybe just chase the player and shoot.As soon as we agree on the features for the first release, I'll add those features (and their owning milestone) to GitHub. I thought Katuko was with us. Anyway, PMed you and JKK my email. Will PM P962 if he confirms he's in on this.

Okay, sorry guys, I was stuck in a small beach cottage in northern California with no Internet access. :-/ Interesting suggestion. I'd like to see what the other team members think of this first, though.I like it, though I think you should be unable to move while charging. Perhaps they could be slower than Toa/Skakdi on the ground and have some sort of "flight energy" -- you're only able to fly as long as you have flight energy, which recharges while you're on the ground. ...Because I might actually want to make money at some point?Nothing in the GPL says you can't sell stuff. UltraHau named a lot of good examples. I vote GPL. That definitely seems like the best way to do it. I agree with the above features, although I think bot support will be easy to add in later if we choose not to do it immediately.

...In your opinion...

Game Maker isn't known for speed.

Okay guys, I'm glad we're getting started. However, I'm on vacation in California right now and don't have my development computer. I'll get back December 1st or 2nd.

Anyway, I agree that we should dream big now and think about the implementation later. If we limit ourselves to what we think will be easy to implement, we're going to lose a lot of good ideas. Powers should be pretty easy anyway, assuming Panda has a good particle engine.

I'm very against unlockables, for most of the reasons UltraHau gave. They may be an incentive for players to keep playing, but IMO they discourage new players. Also, I've never been overwhelmed by BIONICLE Fighter. If anything, I like that so much is available at the very beginning.I do think things should be pretty element-focused; after all, BIONICLE is pretty element-focused.