Jump to content

What Would You Like To See In A Fan Game?


Emzee

Recommended Posts

OK, so masks and multiple powers are out. How about this then:Toa and Skakdi: Elemental powers with various effects, can channel the element through their weapon for more powerful attacks.Rahkshi and Vahki: Kraata power/Vahki ability, can "glide" short distances. I'm not sure how best to handle the Vahki, as their powers were mostly based around messing with your mind. If they are only allowed to fire Kanoka, then those Kanoka need to be charged with some power. Perhaps variations on the Rahkshi powers; the Vahki just channel them through disks as a visual explanation.Say we got fire/water/air/stone/earth/ice as the Toa/Skakdi elements, and poison/life drain/electricity/explosive/freeze/plasma as Rahkshi/Vahki powers. Rahkshi use beams, Vahki use disks, but both got the same effect in the end, with disks that explode, send electricity flying, etc?

The thing to keep in mind here is that both teams are to be identical in terms of weaponry. I think the best thing to do in this situation is to break with canon and come up with powers both Rahkshi and Vahki can use.EDIT: Hey, this is the 200th reply in this topic - let's keep it up guys :) Edited by UltraHau

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

no way! whats the point in making a game about something when you completely cut off the canon, somthing bionicle was known for, its giant in-depth story?

Visit www.BZPRPG.com to view my project of archiving BZPower's RPGs, and also access the BZPower Roleplaying Wiki

BZPRPG Profiles - Ghosts Of Bara Magna Profiles

Exo-Force RPG Profiles - Six Kingdoms: Apocalypse (Knichou, Berys, Arnex, The Taku, Exuze)

Link to comment
Share on other sites

no way! whats the point in making a game about something when you completely cut off the canon, somthing bionicle was known for, its giant in-depth story?

We've discussed this before, Bulik :) We had already decided the game was not going to be 100% canon, and since Vahki and Rahkshi don't have identical powers, I think this is the perfect place to break with canon. Keep in mind, every single Bionicle game produced by Lego was non-canonical - BH, TotT, all the GBA games, and even MNOG according to GregF.

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

Let's just say that Vahki have the same powers as the 2003 Rahkshi, to keep things simple. That's not too far from canon, either - Rahkshi were around in Metru Nui, so maybe Nuparu's earliest prototypes were based on Rahkshi powers until he decided to switch to mental stuff.I say we skip Kanoka shooting out of Vahki's mouths - both races have staffs that shoot energy beams, so that's where we should focus their powers.And Bulik - keep in mind that we've already basically massacred the canon by having Toa, Skakdi, Rahkshi, and Vahki all in the same place. Well, I guess it kind of works (except that Skakdi would be unlikely to team up with Rahkshi) but this scenario has never been seen in the official Bionicle story, and there definitely wouldn't be any battles on the island of Mata Nui.While we're on the topic, I'd like to point out that good storytelling rarely goes along with a good multiplayer competitive game.

IrMSNn3.png

Link to comment
Share on other sites

OK, so masks and multiple powers are out. How about this then:Toa and Skakdi: Elemental powers with various effects, can channel the element through their weapon for more powerful attacks.Rahkshi and Vahki: Kraata power/Vahki ability, can "glide" short distances. I'm not sure how best to handle the Vahki, as their powers were mostly based around messing with your mind. If they are only allowed to fire Kanoka, then those Kanoka need to be charged with some power. Perhaps variations on the Rahkshi powers; the Vahki just channel them through disks as a visual explanation.Say we got fire/water/air/stone/earth/ice as the Toa/Skakdi elements, and poison/life drain/electricity/explosive/freeze/plasma as Rahkshi/Vahki powers. Rahkshi use beams, Vahki use disks, but both got the same effect in the end, with disks that explode, send electricity flying, etc?

The thing to keep in mind here is that both teams are to be identical in terms of weaponry. I think the best thing to do in this situation is to break with canon and come up with powers both Rahkshi and Vahki can use.EDIT: Hey, this is the 200th reply in this topic - let's keep it up guys :)
Well if you're referring to elemental powers, Toa and Skakdi all have the same elements, same for Vahki, except in canon they didn't have elemental powers (just different kanoka disk and staff variations,) but we could just give them the same elements, and either break canon to give Rahkshi the same elements, or find elements similar enough that can be given the same abilities (e.g. Heat Vision instead of Fire, if we're doing rocket launchers for Stone, then Fragmentation since that's essentially a rocket launcher, Cyclone or Vaccum for Air, Weather Control for Water or Ice, etc.) Giving the Vahki Rahkshi powers saying they were originally based on the Rahkshi works too if it's easier.
rarity-with-wings.jpgrarity-heart.png <<Newest Chibi: Nuparu Inika
Link to comment
Share on other sites

Alright guys, what do you think our first demo for Bionicle: Call of Destiny should have? I'm thinking one of the toa and one of the rahkshi along with two maps/stages and maybe a few options like turning the sound on/off. BTW, are we going to be using actual bionicle characters like Tahu and Lerahk or will players have the option of customizing thier own bionicle character? Also, what did you guys think of the concept art I posted?

A Toa eh? What kind of Toa am I?

 

Ever wanted to read a manga styled retelling of the early years of Bionicle? Here ya go!

http://www.bzpower.c...?showtopic=1384

Link to comment
Share on other sites

Alright guys, what do you think our first demo for Bionicle: Call of Destiny should have? I'm thinking one of the toa and one of the rahkshi along with two maps/stages and maybe a few options like turning the sound on/off. BTW, are we going to be using actual bionicle characters like Tahu and Lerahk or will players have the option of customizing thier own bionicle character? Also, what did you guys think of the concept art I posted?

Since this is an open-source project, it's kind of hard to define "first demo" - anyone can download the game at any time they choose :) But the first things I think that should be done are:
  • [*]Create one Toa model and one Skakdi model[*]Create a single map[*]Create team-balancing system[*]Allow the Toa/Skakdi to be moved around using the keyboard, staying inside + on top of the terrain[*]Options can wait

Your concept art looks nice, but remember, we need 3D maps.

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

Alright guys, what do you think our first demo for Bionicle: Call of Destiny should have? I'm thinking one of the toa and one of the rahkshi along with two maps/stages and maybe a few options like turning the sound on/off. BTW, are we going to be using actual bionicle characters like Tahu and Lerahk or will players have the option of customizing thier own bionicle character? Also, what did you guys think of the concept art I posted?

Since this is an open-source project, it's kind of hard to define "first demo" - anyone can download the game at any time they choose :) But the first things I think that should be done are:
  • [*]Create one Toa model and one Skakdi model[*]Create a single map[*]Create team-balancing system[*]Allow the Toa/Skakdi to be moved around using the keyboard, staying inside + on top of the terrain[*]Options can wait

Your concept art looks nice, but remember, we need 3D maps.

Alright, I'll get to work on that. So, how are the models for the toa and skakdi going to be made? I know we're going to be using GitHub so that all the devs and programmers can share and work on BCOD, but what program(s) in specific will be used to work on the game?

A Toa eh? What kind of Toa am I?

 

Ever wanted to read a manga styled retelling of the early years of Bionicle? Here ya go!

http://www.bzpower.c...?showtopic=1384

Link to comment
Share on other sites

Alright guys, what do you think our first demo for Bionicle: Call of Destiny should have? I'm thinking one of the toa and one of the rahkshi along with two maps/stages and maybe a few options like turning the sound on/off. BTW, are we going to be using actual bionicle characters like Tahu and Lerahk or will players have the option of customizing thier own bionicle character? Also, what did you guys think of the concept art I posted?

Since this is an open-source project, it's kind of hard to define "first demo" - anyone can download the game at any time they choose :) But the first things I think that should be done are:
  • [*]Create one Toa model and one Skakdi model[*]Create a single map[*]Create team-balancing system[*]Allow the Toa/Skakdi to be moved around using the keyboard, staying inside + on top of the terrain[*]Options can wait

Your concept art looks nice, but remember, we need 3D maps.

Alright, I'll get to work on that. So, how are the models for the toa and skakdi going to be made? I know we're going to be using GitHub so that all the devs and programmers can share and work on BCOD, but what program(s) in specific will be used to work on the game?
That's the nice thing about standardized formats - no restrictions on choice of software! Here's what I recommend for various art formats, and the programs to modify them:
  • [*].png for bitmap images - use GIMP to edit[*].svg for vector images - use Inkscape to edit[*].blend (or .x) for 3D models - use Blender to edit

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

Let's just say that Vahki have the same powers as the 2003 Rahkshi, to keep things simple. That's not too far from canon, either - Rahkshi were around in Metru Nui, so maybe Nuparu's earliest prototypes were based on Rahkshi powers until he decided to switch to mental stuff.I say we skip Kanoka shooting out of Vahki's mouths - both races have staffs that shoot energy beams, so that's where we should focus their powers.And Bulik - keep in mind that we've already basically massacred the canon by having Toa, Skakdi, Rahkshi, and Vahki all in the same place. Well, I guess it kind of works (except that Skakdi would be unlikely to team up with Rahkshi) but this scenario has never been seen in the official Bionicle story, and there definitely wouldn't be any battles on the island of Mata Nui.While we're on the topic, I'd like to point out that good storytelling rarely goes along with a good multiplayer competitive game.

hmm... when have skadki teamed up with rahkshi? when have toa fought them both? did you miss the entire bionicle stars thing in 2010?that was practicly all of them (except vahki, but im sure that there were a few that escaped from metru nui) in one canon location fighting a canon battle. so it has been seen in the bionicle story. and dis i mention anything about mata nui? no! nobody said that we were ding this on mata nu, for mata nui's sake!

Visit www.BZPRPG.com to view my project of archiving BZPower's RPGs, and also access the BZPower Roleplaying Wiki

BZPRPG Profiles - Ghosts Of Bara Magna Profiles

Exo-Force RPG Profiles - Six Kingdoms: Apocalypse (Knichou, Berys, Arnex, The Taku, Exuze)

Link to comment
Share on other sites

BTW, are we going to be using actual bionicle characters like Tahu and Lerahk or will players have the option of customizing thier own bionicle character?

I was thinking neither - maybe a bit of Halo-style customization (secondary color, emblem, armor details, possibly even a powerless mask), but we're probably just going to use generic characters.For model formats, we'll eventually need 3D models in .egg format, but since that's Panda-proprietary, blend files would be best so we can run them through an exporter.@Bulik: you're right, I forgot about 2010. I still don't think the Rahkshi were fighting alongside the Skakdi, but it's only a technicality since they were both against the Toa.That said, Mata Nui maps are best for nostalgia, and Bara Magna is worst since it's the most recent. (Actually, Bota Magna or the Red Star would be worse because we've never really seen it in main story)Please, give up on the canon thing. I thought we had this settled and it's annoying that you're suddenly arguing for this again.@UltraHau: I think you're forgetting a pretty major feature: hosting/connecting to a server!

IrMSNn3.png

Link to comment
Share on other sites

BTW, are we going to be using actual bionicle characters like Tahu and Lerahk or will players have the option of customizing thier own bionicle character?

For model formats, we'll eventually need 3D models in .egg format, but since that's Panda-proprietary, blend files would be best so we can run them through an exporter.@UltraHau: I think you're forgetting a pretty major feature: hosting/connecting to a server!
Quick-stop on the "Panda-proprietary" thing: .egg is a completely open format, just like .png or .tar.gz, plus, there's a Blender 2.49 exporter that converts .blend models to .egg ones, called Chicken. You can download it on the Panda forums.I didn't forget networked play :) I should definitely not be done first - the other things I listed are far more important IMHO.EDIT: Post #232 - a palindrome ^_^ Edited by UltraHau

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

BTW, are we going to be using actual bionicle characters like Tahu and Lerahk or will players have the option of customizing thier own bionicle character?

For model formats, we'll eventually need 3D models in .egg format, but since that's Panda-proprietary, blend files would be best so we can run them through an exporter.@UltraHau: I think you're forgetting a pretty major feature: hosting/connecting to a server!
Quick-stop on the "Panda-proprietary" thing: .egg is a completely open format, just like .png or .tar.gz, plus, there's a Blender 2.49 exporter that converts .blend models to .egg ones, called Chicken. You can download it on the Panda forums.I didn't forget networked play :) I should definitely not be done first - the other things I listed are far more important IMHO.EDIT: Post #232 - a palindrome ^_^
Sorry for the miscommunication again, but when I said I would get to work on the 3d drawings, I meant I would draw 3d looking pictures. in other words, I was going to draw using depth and perspective. Of course these will all be hand drawn since that's what I'm comfortable with. If you want actual 3d drawings, ask someone else like Katuko since digital drawing isn't my thing. Also, I was just merely curious as to what programs would be used to make BCOD, so sorry for any confusion and miscommunication. http://www.bzpower.com/board/public/style_emoticons/default/sarcastic.gif

A Toa eh? What kind of Toa am I?

 

Ever wanted to read a manga styled retelling of the early years of Bionicle? Here ya go!

http://www.bzpower.c...?showtopic=1384

Link to comment
Share on other sites

Quick-stop on the "Panda-proprietary" thing: .egg is a completely open format, just like .png or .tar.gz, plus, there's a Blender 2.49 exporter that converts .blend models to .egg ones, called Chicken. You can download it on the Panda forums.

An open format that nobody else uses is still proprietary as far as I'm concerned :)I disagree with doing networking later - if anything, it should be the first thing we do. Networking changes the whole architecture of a game because you have to split your game logic into parts that are simulated locally, and parts that come over the network, plus you have to do some amount of predictive simulation so it's not too choppy - I don't envy Katuko's inevitable conversion of Bionicle Fighter.I don't care how good Panda's networking APIs are, multiplayer is gonna be hairy and we should get it over with as soon as possible.

IrMSNn3.png

Link to comment
Share on other sites

Here's my reasons for not doing multiplayer first:

  • [*]It's as not important at this stage as a few other features. I think we'd (and end-users, too) rather have the ability to load maps and move around in them first.[*]It's easy to add in later. Katuko, I haven't seen your code (if it's even available), but the fact that you're having to rewrite so much implies you made a lot of assumptions on where different services (like the collision system) are located. With proper design, we won't have to do this.

Coding without making assumptions will automatically give us the ability to move physics and collisions to the server when we need multiplayer functionality. For example, in my primary Panda3D-based project (main site has forums - I should be able to link to the source code though), physics and collision checking is implemented as a plugin. All the code outside the plugin merely registers physical bodies and request collision hooks with the plugin - code outside has no idea how collisions are checked, or how physics are updated. When I add multiplayer functionality to my project, all I have to do is add a new plugin that receives physics-based movements from a server (possibly running a modified version of the original physics plugin), and it automatically works with all the existing code I've written. Dead reckoning, connection handling, and all that stuff would be hidden from the majority of the code; only the new physics plugin would need to know about it.You see? I wouldn't have to change any existing code to add new behavior - only write new code. That is the hallmark of true OO design. That's why I think we should leave multiplayer alone for now - it will be easy to add in later.Your next question would probably be "how hard will it be to write a plugin system"? My plugin system implementation is only 432 lines long, counting comments and such; it's not hard to write one. In fact, we could use the plugin system I've already written (which would mean we would have to license any new code we write for B:CoD under the GPL license, though), so we could get that plugin functionality for free.Which brings up another issue: We need to decide upon a license for both code and artwork before any gets created, and make sure anyone contributing is fine with their work being licensed under whichever license we choose. Since we're hosting our code + artwork on GitHub, it must be an OSI (Open-Source Initiative) approved license, but that's no big deal. Here's my suggestions:

  • [*]GPL license for code - allows anyone to redistribute both the end product and the source code, make changes to it, redistribute their changes, and even charge money for their modified product, as long as they give anyone they redistribute their code the same privileges we gave them (i.e, they must license their changes under the GPL)[*]CC-BY-SA for artwork - the GPL re-stated for art: Anyone can modify our artwork, redistribute their changes, and charge money for their changed work, as long as they give the original author credit, and licenses their changed work under the CC-BY-SA license

There are alternatives, though:

  • [*]The New (i.e, 2-clause) BSD license - basically allows anyone to do anyone they want with the code, including make a proprietary spinoff. Depending on how much code we write, we may want to choose this - it's a bit more convenient for those who want to modify the code[*]CC-BY 3.0 for artwork - allows anyone to do anything they want with art (the New BSD license re-stated for artwork), as long as they give credit to the original author. We might want to use this license depending on the quality of the artwork used

What do other open-source FPS projects use?

  • [*]Warsow uses the GPL license for code, and CC-BY-NC for artwork. The CC-BY-NC-SA license works exactly like the CC-BY-SA, except you're not allowed to charge money for your modified artwork.[*]Nexuiz uses the same licensing scheme as Warsow.[*]World of Padman also uses the same licensing scheme.[*]Xonotic uses the GPL for code, and uses a bunch of different licenses for code (mostly the CC-BY, it seems)

I'm open to suggestions, of course.

Edited by UltraHau

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

Forgive my cynicism, but I'd be a lot more inclined to trust you that multiplayer will be "easy" if you had implemented it in your own game.In my experience, any time I've procrastinated a key feature - even if I designed the code anticipating that feature - there are always unexpected things that cause problems and major refactoring. Furthermore, you can't depend on the architecture of a program written by more than one developer, since we probably have vastly different coding styles.I like the idea of a plugin system, but it seems like overkill for a game like this where we're not planning to load user code, and we can get all the benefits by using basic OO and dependency injection principles.That said, loading a map and walking around is pretty hard to get wrong and it doesn't really have to be networked, plus, like you said, it gives something more to show than a button that says "Connect!". Let's make networking our first priority after that, though.I'd prefer to use something like LGPL for code, or possibly an MIT/Apache license. Basically, anything that doesn't get in the way of anyone who stumbles across our code and wants to use it.Artwork - well, it depends on what our eventual artists think, but it shouldn't be necessary to have too many restrictions, as LEGO's trademarks will stop commercial use far more easily than a license.

IrMSNn3.png

Link to comment
Share on other sites

If all of us here are serious about making this game, I think it might help us if we hire some members to help with coding, programming, making the 3d models and drawings, etc. So far, me JKK, UltraHau, Katuko, and I believe alpha123 are the only ones working on BCOD. Also, should BCOD have a story mode or not?

Edited by P962

A Toa eh? What kind of Toa am I?

 

Ever wanted to read a manga styled retelling of the early years of Bionicle? Here ya go!

http://www.bzpower.c...?showtopic=1384

Link to comment
Share on other sites

Forgive my cynicism, but I'd be a lot more inclined to trust you that multiplayer will be "easy" if you had implemented it in your own game.In my experience, any time I've procrastinated a key feature - even if I designed the code anticipating that feature - there are always unexpected things that cause problems and major refactoring. Furthermore, you can't depend on the architecture of a program written by more than one developer, since we probably have vastly different coding styles.I like the idea of a plugin system, but it seems like overkill for a game like this where we're not planning to load user code, and we can get all the benefits by using basic OO and dependency injection principles.That said, loading a map and walking around is pretty hard to get wrong and it doesn't really have to be networked, plus, like you said, it gives something more to show than a button that says "Connect!". Let's make networking our first priority after that, though.I'd prefer to use something like LGPL for code, or possibly an MIT/Apache license. Basically, anything that doesn't get in the way of anyone who stumbles across our code and wants to use it.Artwork - well, it depends on what our eventual artists think, but it shouldn't be necessary to have too many restrictions, as LEGO's trademarks will stop commercial use far more easily than a license.

The reason you met with unexpected errors is because you wrote code in anticipation of a feature, which is never a good thing. Write code only when you immediately need a feature - anything else is destined to be significantly changed. As for plugins, they're not overkill - they provide an easy framework for us to add/remove new features, and they allow users to write mods for the game as well.Now, about licensing: The New BSD license is basically equivalent to the MIT or Apache license, but it's shorter. I do like the patent indemnification clause in the Apache license though, so it's certainly an option. The reason I want the code to be GPL'ed is because I really don't want someone making a proprietary (and probably commerical) FPS based off of our engine. I'm also not sure how the GPL is less convenient than the BSD license (or similar). Could you explain please?For an artwork license, I'm going to change my suggestion and go with CC-BY-NC-SA. I wouldn't want anyone thinking they could sell the artwork without Lego's permission.

If all of us here are serious about making this game, I think it might help us if we hire some members to help with coding, programming, making the 3d models and drawings, etc. So far, me JKK, UltraHau, Katuko, and I believe alpha123 are the only ones working on BCOD. Also, should BCOD have a story mode or not?

We definitely need a 3D artist or two, but other than that, I'm not sure we need any extra help at this stage. As for a story mode, this will be a predominantly multiplayer game, so I don't think a story mode is necessary (or even a good thing).

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

Now, about licensing: The New BSD license is basically equivalent to the MIT or Apache license, but it's shorter. I do like the patent indemnification clause in the Apache license though, so it's certainly an option. The reason I want the code to be GPL'ed is because I really don't want someone making a proprietary (and probably commerical) FPS based off of our engine. I'm also not sure how the GPL is less convenient than the BSD license (or similar). Could you explain please?

Let's not get our heads big - a fangame game built by, what, five now? people in their free time is not going to be commercial-FPS material. We'll be lucky to fill a server, let alone have to protect our code. And so what if our code is used in a commercial FPS? We made this game for fun.Also, since this is my first Panda project, I'll probably want to extract little bits and pieces of code from it for future projects. I couldn't do that if my future projects weren't GPL - and I don't intend them to be.On plugins: modd support isn't a big deal because if our players want to change anything, they can just go into our code and make tweaks. It works well enough for Minecraft and that isn't even open source! I think there's easy enough ways to "plug in" functionality without a whole system designed to load them in. Although we might be suggesting the same thing - I haven't seen your plugin system.

IrMSNn3.png

Link to comment
Share on other sites

Now, about licensing: The New BSD license is basically equivalent to the MIT or Apache license, but it's shorter. I do like the patent indemnification clause in the Apache license though, so it's certainly an option. The reason I want the code to be GPL'ed is because I really don't want someone making a proprietary (and probably commerical) FPS based off of our engine. I'm also not sure how the GPL is less convenient than the BSD license (or similar). Could you explain please?

Let's not get our heads big - a fangame game built by, what, five now? people in their free time is not going to be commercial-FPS material. We'll be lucky to fill a server, let alone have to protect our code. And so what if our code is used in a commercial FPS? We made this game for fun.Also, since this is my first Panda project, I'll probably want to extract little bits and pieces of code from it for future projects. I couldn't do that if my future projects weren't GPL - and I don't intend them to be.On plugins: modd support isn't a big deal because if our players want to change anything, they can just go into our code and make tweaks. It works well enough for Minecraft and that isn't even open source! I think there's easy enough ways to "plug in" functionality without a whole system designed to load them in.Although we might be suggesting the same thing - I haven't seen your plugin system.
OK, you may be right about code licensing - I'm just used to working on much larger projects, so I automatically want to use the GPL. (I still don't see what's wrong with putting your future projects under the GPL, though) As for plugins: Adding behavior by modifying existing code is a huge OCP violation, and makes it harder - in some cases, impossible - for end-users to use multiple so-called "mods".Just because Minecraft does it, doesn't mean its good practice, too. A plugin system is a small investment - less than 500 lines of code - with huge dividends: We are able to add behavior + features by adding new code instead of changing existing code (conforming to OCP), and users can easily add their own mods, too. If you want to see my plugin system, you can view it here: http://openblox.hg.s...obengine/plugin (that code is GPL'ed, though) Edited by UltraHau

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

What we could have is an RTS. This would be during the BoM-DH war with the Toa. Three factions. As it is an RTS, there would be buildings to produce the units. It should be in line with the story, they would be portals for the Makuta and Toa, tunnels for the Dark Hunters and maybe a big flying vehicle-y thing. Vehicles may be Vultraz's thingy, and other stuff. Just a thought, as an RTS would be hard to make.

Link to comment
Share on other sites

I still don't see what's wrong with putting your future projects under the GPL, though.

...Because I might actually want to make money at some point?Anyways, you win on the architecture - most of my development experience is web-based so my game OO is somewhat lacking.It still makes me really nervous to wait too long to do networking. Can we compromise and add multiplayer first thing after we've got basic movement?

IrMSNn3.png

Link to comment
Share on other sites

What we could have is an RTS. This would be during the BoM-DH war with the Toa. Three factions. As it is an RTS, there would be buildings to produce the units. It should be in line with the story, they would be portals for the Makuta and Toa, tunnels for the Dark Hunters and maybe a big flying vehicle-y thing. Vehicles may be Vultraz's thingy, and other stuff. Just a thought, as an RTS would be hard to make.

they already decided to make an FPS

We definitely need a 3D artist or two, but other than that, I'm not sure we need any extra help at this stage. As for a story mode, this will be a predominantly multiplayer game, so I don't think a story mode is necessary (or even a good thing).

a story mode is not necesary, but do you think that there will always be atleast 2 other people when you want to play a match (other than arranged times)? karzani no! I would atleast want an option (if not a story mode)so that you run around a map and raid a vahki hive, etc.

Visit www.BZPRPG.com to view my project of archiving BZPower's RPGs, and also access the BZPower Roleplaying Wiki

BZPRPG Profiles - Ghosts Of Bara Magna Profiles

Exo-Force RPG Profiles - Six Kingdoms: Apocalypse (Knichou, Berys, Arnex, The Taku, Exuze)

Link to comment
Share on other sites

I still don't see what's wrong with putting your future projects under the GPL, though.

...Because I might actually want to make money at some point?Anyways, you win on the architecture - most of my development experience is web-based so my game OO is somewhat lacking.It still makes me really nervous to wait too long to do networking. Can we compromise and add multiplayer first thing after we've got basic movement?
Take a look at the Doom series, the Quake series, World of Padman, and the Humble Indie Bundle (most notably Lugaru), all of which are GPL'ed, but bring in tons of money - id Software still makes enough money to live off the first two even though their code is GPL'ed (though the artwork is under a CC-BY-NC-ND-like license), and there are lots of free and open-source derivatives. Each release of the Humble Indie Bundle - where customers choose how much they want to pay - brings in millions with each release.Lugaru is completely open-source (artwork included), and brings in thousands on Apple's app store. Just because a game is open-source, doesn't mean it cannot make money. Besides, if you make a commercial web project, you are not obligated to release the source code per the GPL, as well - you're not distributing the source code, so you don't have to release it.As for networking: Trust me, as long as design is done right, multiplayer will be easy to add later - there are quite a few ways we can encapsulate multiplayer functionality inside its own unit, without other code having to know about it. We can do exactly the same thing I described above: Stick all physics-related actions in a plugin, and the only thing that the plugin lets us do is request collision hooks, add collision meshes, and nothing else. The plugin would handle its own timestep and everything.When we add multiplayer support, all we have to do is write 2 more plugins: One goes on the server, one goes on the client. The client one merely requests the server-side plugin to create new collision meshes and collision hooks. The server-side plugin then sends updated position back to the client every frame, possibly with collision information.If you've done OO for a while, you'll notice that the new physics plugin's interface is not compatible with the original one: The original physics plugin allows us to assume that the plugin sets itself up all by itself, without any help from the outside. Unless we hard-code the server address into the new plugin, or fetch the server address from a configuration file - both of which violate SRP - we cannot communicate the required information the new physics plugin needs to connect to the game server.The way we would fix this is by adding a new plugin interface (probably called "netplay" or something), and either have our new physics plugin implement it (possibly a SRP violation), or create a new plugin that handles server connection, and have our new physics plugin talk to it.Then, when the user wants to connect to a server, we first load whatever plugin implements "netplay", pass it the required information, and tell it to connect to the server. Our new physics plugin then either communicates with the netplay plugin (if we made a separate plugin to handle network connections), or fetches the information itself (if we gave it that ability). Now it's connected to the server, we're ready to play :)See how easy it would be to add multiplayer later? I'm not saying it should be postponed indefinitely or anything, I'm saying there are features that we can get out the door a lot quicker that end-users would be a lot more pleased with, like bots, multiple maps, weapons, and other things.Again, as long as we do our design right, we won't have to put the hooks in for any feature we want to implement - we implement only when we immediately want to use it; otherwise, it's a waste of time.I'm not saying multiplayer will be easy to implement - it's one of the hardest things to get right in a game - I'm saying it will be easy to integrate with the existing codebase. Before we think about how hard it will be to implement a certain feature, we need to think about which features we would like to have first, and then draw up a plan around that.

What we could have is an RTS. This would be during the BoM-DH war with the Toa. Three factions. As it is an RTS, there would be buildings to produce the units. It should be in line with the story, they would be portals for the Makuta and Toa, tunnels for the Dark Hunters and maybe a big flying vehicle-y thing. Vehicles may be Vultraz's thingy, and other stuff. Just a thought, as an RTS would be hard to make.

they already decided to make an FPS

We definitely need a 3D artist or two, but other than that, I'm not sure we need any extra help at this stage. As for a story mode, this will be a predominantly multiplayer game, so I don't think a story mode is necessary (or even a good thing).

a story mode is not necesary, but do you think that there will always be atleast 2 other people when you want to play a match (other than arranged times)? karzani no! I would atleast want an option (if not a story mode)so that you run around a map and raid a vahki hive, etc.
Bots. 'Nuff said.Or not.Pretty much every FPS nowadays has the option to play by yourself with a group of computer opponents - take a look at Warsow for a free example. (no, for all my mention of this game, I am not associated with them - it's just a good open-source example of a good FPS) Edited by UltraHau

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

I still don't see what's wrong with putting your future projects under the GPL, though.

...Because I might actually want to make money at some point?Anyways, you win on the architecture - most of my development experience is web-based so my game OO is somewhat lacking.It still makes me really nervous to wait too long to do networking. Can we compromise and add multiplayer first thing after we've got basic movement?
Take a look at the Doom series, the Quake series, World of Padman, and the Humble Indie Bundle (most notably Lugaru), all of which are GPL'ed, but bring in tons of money - id Software still makes enough money to live off the first two even though their code is GPL'ed (though the artwork is under a CC-BY-NC-ND-like license), and there are lots of free and open-source derivatives. Each release of the Humble Indie Bundle - where customers choose how much they want to pay - brings in millions with each release.Lugaru is completely open-source (artwork included), and brings in thousands on Apple's app store. Just because a game is open-source, doesn't mean it cannot make money. Besides, if you make a commercial web project, you are not obligated to release the source code per the GPL, as well - you're not distributing the source code, so you don't have to release it.As for networking: Trust me, as long as design is done right, multiplayer will be easy to add later - there are quite a few ways we can encapsulate multiplayer functionality inside its own unit, without other code having to know about it. We can do exactly the same thing I described above: Stick all physics-related actions in a plugin, and the only thing that the plugin lets us do is request collision hooks, add collision meshes, and nothing else. The plugin would handle its own timestep and everything.When we add multiplayer support, all we have to do is write 2 more plugins: One goes on the server, one goes on the client. The client one merely requests the server-side plugin to create new collision meshes and collision hooks. The server-side plugin then sends updated position back to the client every frame, possibly with collision information.If you've done OO for a while, you'll notice that the new physics plugin's interface is not compatible with the original one: The original physics plugin allows us to assume that the plugin sets itself up all by itself, without any help from the outside. Unless we hard-code the server address into the new plugin, or fetch the server address from a configuration file - both of which violate SRP - we cannot communicate the required information the new physics plugin needs to connect to the game server.The way we would fix this is by adding a new plugin interface (probably called "netplay" or something), and either have our new physics plugin implement it (possibly a SRP violation), or create a new plugin that handles server connection, and have our new physics plugin talk to it.Then, when the user wants to connect to a server, we first load whatever plugin implements "netplay", pass it the required information, and tell it to connect to the server. Our new physics plugin then either communicates with the netplay plugin (if we made a separate plugin to handle network connections), or fetches the information itself (if we gave it that ability). Now it's connected to the server, we're ready to play :)See how easy it would be to add multiplayer later? I'm not saying it should be postponed indefinitely or anything, I'm saying there are features that we can get out the door a lot quicker that end-users would be a lot more pleased with, like bots, multiple maps, weapons, and other things.Again, as long as we do our design right, we won't have to put the hooks in for any feature we want to implement - we implement only when we immediately want to use it; otherwise, it's a waste of time.I'm not saying multiplayer will be easy to implement - it's one of the hardest things to get right in a game - I'm saying it will be easy to integrate with the existing codebase. Before we think about how hard it will be to implement a certain feature, we need to think about which features we would like to have first, and then draw up a plan around that.

What we could have is an RTS. This would be during the BoM-DH war with the Toa. Three factions. As it is an RTS, there would be buildings to produce the units. It should be in line with the story, they would be portals for the Makuta and Toa, tunnels for the Dark Hunters and maybe a big flying vehicle-y thing. Vehicles may be Vultraz's thingy, and other stuff. Just a thought, as an RTS would be hard to make.

they already decided to make an FPS

We definitely need a 3D artist or two, but other than that, I'm not sure we need any extra help at this stage. As for a story mode, this will be a predominantly multiplayer game, so I don't think a story mode is necessary (or even a good thing).

a story mode is not necesary, but do you think that there will always be atleast 2 other people when you want to play a match (other than arranged times)? karzani no! I would atleast want an option (if not a story mode)so that you run around a map and raid a vahki hive, etc.
Bots. 'Nuff said.Or not.Pretty much every FPS nowadays has the option to play by yourself with a group of computer opponents - take a look at Warsow for a free example. (no, for all my mention of this game, I am not associated with them - it's just a good open-source example of a good FPS)
its just you seemed kinda biased that there would be no bots or anything :

Visit www.BZPRPG.com to view my project of archiving BZPower's RPGs, and also access the BZPower Roleplaying Wiki

BZPRPG Profiles - Ghosts Of Bara Magna Profiles

Exo-Force RPG Profiles - Six Kingdoms: Apocalypse (Knichou, Berys, Arnex, The Taku, Exuze)

Link to comment
Share on other sites

Uh oh - first argument of the project.Look, I haven't done multiplayer networking before, and I don't think anyone else on the project team has either, at least on a project of reasonable scale, so none of us knows what's involved. I'm really not comfortable holding off on it since it's so critical to the final product. Katuko's already tried the "gameplay first, networking later" strategy for Bionicle Fighter, and that hasn't worked well. Another example is Minecraft - Mojang added multiplayer later into the process, and it's still really buggy, laggy, and some features from singleplayer are missing entirely!How about this as a compromise: while we work on the networking, we create a "prototype" singleplayer game with bots and a good amount of gameplay. When the networking harness is complete, we'll bring a lot of the work from the "prototype" into the final game.As for GPL - I didn't know that you could sell a product with GPL'd code, but I'd still rather not have any strings attached to our work.One quick reality check: remember that S.O.L.I.D. OO principles and the like are great on paper. However, I've observed that real life programming is an eternal battle between programmers who want to reuse code and make everything work the same under the hood and end users who want every little edge case to be handled uniquely.Here's a gameplay example - let's say there's a standard "fireball" ability, and a "turn into statue" ability that temporarily immobilizes your character, but makes him invincible during that duration.First things first - the "turn into statue" ability has to override your controls and make you unable to move. That's pretty tricky to design without either the control system or the ability system breaking SRP.Then, what happens when a fireball hits a statue-ized character? Obviously we don't want to apply damage. The hack solution would be to make the fireball check if he's a statue, but then you'd duplicate that for everything that deals damage in the game. A better way would have the fireball call a "applyDamage" method on the player, which would not have any effect if the player is a statue.Now let's say we want to add a "turn into ice sculpture" ability that does almost the same thing. Obviously we're not just going to copy and paste that - that's a violation of DRY. So we abstract out the "turn into immobile invincible thing" ability and apply unique element properties and animations to each variation.Now we come back to the fireball - when it hits an ice sculpture it doesn't do any damage. That doesn't make any sense! If anything, it should be an insta-kill. So where does that leave us? In the place where we apply damage, we now have to check for elements, too. Now that's violating OCP - we're changing existing functionality to add a new feature.That's probably a contrived example and there's probably easy ways to design around those problems, but do you understand the point I'm trying to make? We can't depend on perfect code design to solve all our problems.

Edited by Jedi Knight Krazy

IrMSNn3.png

Link to comment
Share on other sites

Uh oh - first argument of the project.Look, I haven't done multiplayer networking before, and I don't think anyone else on the project team has either, at least on a project of reasonable scale, so none of us knows what's involved. I'm really not comfortable holding off on it since it's so critical to the final product. Katuko's already tried the "gameplay first, networking later" strategy for Bionicle Fighter, and that hasn't worked well. Another example is Minecraft - Mojang added multiplayer later into the process, and it's still really buggy, laggy, and some features from singleplayer are missing entirely!How about this as a compromise: while we work on the networking, we create a "prototype" singleplayer game with bots and a good amount of gameplay. When the networking harness is complete, we'll bring a lot of the work from the "prototype" into the final game.As for GPL - I didn't know that you could sell a product with GPL'd code, but I'd still rather not have any strings attached to our work.One quick reality check: remember that S.O.L.I.D. OO principles and the like are great on paper. However, I've observed that real life programming is an eternal battle between programmers who want to reuse code and make everything work the same under the hood and end users who want every little edge case to be handled uniquely.Here's a gameplay example - let's say there's a standard "fireball" ability, and a "turn into statue" ability that temporarily immobilizes your character, but makes him invincible during that duration.First things first - the "turn into statue" ability has to override your controls and make you unable to move. That's pretty tricky to design without either the control system or the ability system breaking SRP.Then, what happens when a fireball hits a statue-ized character? Obviously we don't want to apply damage. The hack solution would be to make the fireball check if he's a statue, but then you'd duplicate that for everything that deals damage in the game. A better way would have the fireball call a "applyDamage" method on the player, which would not have any effect if the player is a statue.Now let's say we want to add a "turn into ice sculpture" ability that does almost the same thing. Obviously we're not just going to copy and paste that - that's a violation of DRY. So we abstract out the "turn into immobile invincible thing" ability and apply unique element properties and animations to each variation.Now we come back to the fireball - when it hits an ice sculpture it doesn't do any damage. That doesn't make any sense! If anything, it should be an insta-kill. So where does that leave us? In the place where we apply damage, we now have to check for elements, too. Now that's violating OCP - we're changing existing functionality to add a new feature.That's probably a contrived example and there's probably easy ways to design around those problems, but do you understand the point I'm trying to make? We can't depend on perfect code design to solve all our problems.

First off, before you say anything else about licensing: Read the GPL. :P Anyway, back to networking: Katuko just didn't design his game correctly. He made way too many assumptions about where different subsystems would be located, and how they would communicate, thus making the transition to multiplayer difficult. Same thing with Minecraft: They made too many assumptions about where different subsystems would be located, just like Katuko.I think your compromise idea has good intentions, but it's doomed to failure, because the "networking harness" will be attempting to follow a moving target - the prototype. When we finally attempt to integrate the so-called "harness" with the prototype, there will be bugs galore due to the huge integration step. I cannot say I have implemented a multiplayer system before, so you're right - none of us know how to implement multiplayer - but I do know that with proper design, we can separate all multiplayer-related networking code into its own separate subsystem, that doesn't affect outside subsystems, like I said earlier. If you're still not convinced, I can show you a component diagram of how the game engine will be designed, and how the multiplayer component will affect the system.I admit that you cannot follow OO principles to the letter in every case - a good software engineer knows when to break with principle, but when he does, he does not take it lightly. For example, I'll solve the example problem you posted: We already know it will be impossible to comply with OCP here, because we must check for elements when dealing damage. However, we can significantly lessen the amount of code that must change when a new element is added, or an existing one is changed. How? We have a nested table that contains damage multipliers for each element in the game. When we deal damage, we check the nested table to retrieve the appropriate damage multiplier for our situation. We also have a disable_damage() method that prevents its owning player from being injured at all, which allows us to implement the "immobile invincibility" powerup.See how I solved that problem? I knew I could make an acyclic visitor that could conform to OCP and solve this problem, but I knew the benefit of fully complying with OCP would far outweighed by the cost of writing the acyclic visitor, so I came up with a simpler solution that didn't fully conform to OCP, but was pretty extensible nonetheless. I never stated that following OO principles 100% of the time was a good idea - it's not - but they should be followed whenever the cost of conforming to OO principles is smaller than the cost of coding a possibly simpler, non-OO solution.

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

I didn't just assume where things would go, just to mention that. I have it all sketched out on paper, so I have a good idea of how the system should look. My two mistakes were not including "multiplayer code" on that schema (both on- and offline), since Game Maker is a lot more limited in what it can and can't do with its built-in functions; and also simply jury-rigging code that I planned on fixing later once I got the needed sprites and stuff. Now I got half the sprites, but due to how integrated the system has become, I will have to rewrite parts of it to allow for proper animation rather than just insta-shots.

Edited by Katuko
Link to comment
Share on other sites

So if two great games (Bionicle Fighter and Minecraft) weren't designed "properly", what's to say ours will be? Even if we learn from their mistakes, there could well be a lot of stuff we don't anticipate.I really don't feel that multiplayer is something we can tack on later, even if it will be easy (I still don't think it will be). Multiplayer is our game, and implementing it as soon as possible will allow deep integration with the rest of the game logic (yes, deep integration is bad design, but networking is so performance-critical that we really should make exceptions) and allow us to catch synchronization bugs before they get really difficult.You're essentially the team lead, so you've got the final say - but I would strongly urge you to reconsider. The worst thing that could happen is that we won't have anything interesting to show for a few months.

IrMSNn3.png

Link to comment
Share on other sites

So if two great games (Bionicle Fighter and Minecraft) weren't designed "properly", what's to say ours will be? Even if we learn from their mistakes, there could well be a lot of stuff we don't anticipate.I really don't feel that multiplayer is something we can tack on later, even if it will be easy (I still don't think it will be). Multiplayer is our game, and implementing it as soon as possible will allow deep integration with the rest of the game logic (yes, deep integration is bad design, but networking is so performance-critical that we really should make exceptions) and allow us to catch synchronization bugs before they get really difficult.You're essentially the team lead, so you've got the final say - but I would strongly urge you to reconsider. The worst thing that could happen is that we won't have anything interesting to show for a few months.

You're right - there probably will be things we don't anticipate while designing B:CoD. We probably will make mistakes. However, we should go into design thinking "We're not going to make a mistake. We're going to thoroughly test and re-test every aspect of our design before laying more code on top of it". That sort of mentality will keep us from making too many (if any) mistakes during the design phase.Again, I never said implementing multiplayer would be easy - I said writing a framework so we can add it at our leisure would be easy. Also, I know networking is performance-critical, but we have no evidence at this stage that we need to throw OO design (SRP and OCP, in particular) to the wind and litter every bit of our code with multiplayer-related code. Donald Knuth once said "make it work, then make it fast". What he means is basically this:
  • [*]Write the most elegant solution possible for the problem at hand.[*]Test the solution, and see if it meets your performance requirements.[*]If it doesn't, optimize your solution a small bit.[*]Repeat step 3 as necessary.

This way, you'll end up with the cleanest, fastest solution for the problem you're trying to solve. Like I said before, at this stage, we shouldn't be worried about optimization - we don't even know if we'll need to perform any. Besides, the largest factor in determining how fast our multiplayer will not be the way the code is structured internally, but the efficiency of our networking protocol, which has an infinitely larger impact on performance. Thus, I think it would be better if we designed our game so it would be easy to add multiplayer - kind of like that physics plugin I talked about a short while ago - but held off on implementing it; there are more important features that need to be implemented first.In conclusion: After we have map loading and basic movement/jumping implemented (I think we already agreed upon that), we have three ways to continue:

  • [*]Add multiplayer support immediately. While it must be done at some point of course, in reality it means we have to add quite a few features first - teams most notably. So multiplayer cannot truly be implemented immediately after the features listed above.[*]Add prerequisite features for multiplayer support, implement features that would make multiplayer worthwhile and fun (teams, 2-3 classes, etc), and then implement multiplayer. I think this is certainly a viable solution, but we have to keep in mind that at this stage, bots would not be implemented, and thus you couldn't play when no-one else was online. Whether the benefit of multiplayer would outweigh that cost is something we would have to discuss.[*]Add a few classes, add teams and bots, and then use solution #2. It would delay the release of multiplayer, but it would give everyone something to play.

I personally want solution #2, since it's a good compromise, but if you can think up of something better, we can discuss it of course.

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

Regarding optimization, you're right, I forgot about the two rules of optimization:1. Don't do it.2. (for pros only) Don't do it yet.I think #2 is a good option, too. It won't let us slack off much because teams will be all but useless without multiplayer, and we can add basic bots once we have a multiplayer framework (I'm imagining bots as a sort of simulated client - the server thinks they're connected players but they're running locally) - in fact, it may be best for just one team member to work on networking while the others work on bots.

IrMSNn3.png

Link to comment
Share on other sites

Regarding optimization, you're right, I forgot about the two rules of optimization:1. Don't do it.2. (for pros only) Don't do it yet.I think #2 is a good option, too. It won't let us slack off much because teams will be all but useless without multiplayer, and we can add basic bots once we have a multiplayer framework (I'm imagining bots as a sort of simulated client - the server thinks they're connected players but they're running locally) - in fact, it may be best for just one team member to work on networking while the others work on bots.

OK, so I guess we have that worked out then :) If we're all in agreement (I haven't heard from alpha123 yet), these will be B:CoD's first features:
  • [*]Map loading[*]Basic movement[*]Teams (team balancing too?)[*]Classes (2-3 probably)[*]Multiplayer support[*]Bot support (can be worked on concurrently with multiplayer)

And here's an example FPS written with Panda: It doesn't have enemy AI, but it shows how to do everything else (it even has a plugin system of its own): http://code.google.com/p/naith/

Edited by UltraHau

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

Regarding optimization, you're right, I forgot about the two rules of optimization:1. Don't do it.2. (for pros only) Don't do it yet.I think #2 is a good option, too. It won't let us slack off much because teams will be all but useless without multiplayer, and we can add basic bots once we have a multiplayer framework (I'm imagining bots as a sort of simulated client - the server thinks they're connected players but they're running locally) - in fact, it may be best for just one team member to work on networking while the others work on bots.

OK, so I guess we have that worked out then :) If were all in agreement (I haven't heard from alpha123 yet), these will be B:CoD's first features:
  • [*]Map loading[*]Basic movement[*]Teams (team balancing too?)[*]Classes (2-3 probably)[*]Multiplayer support[*]Bot support (can be worked on concurrently with multiplayer)

And here's an example FPS written in Panda: It doesn't have enemy AI, but it shows how to do everything else (it even has a plugin system of its own): http://code.google.com/p/naith/

Alpha123 said he'd have access to his computer he uses to work on stuff by either today or tomorrow. Unless something's keeping him, BCOD will (hopefully) be starting development by this weekend.

A Toa eh? What kind of Toa am I?

 

Ever wanted to read a manga styled retelling of the early years of Bionicle? Here ya go!

http://www.bzpower.c...?showtopic=1384

Link to comment
Share on other sites

Regarding optimization, you're right, I forgot about the two rules of optimization:1. Don't do it.2. (for pros only) Don't do it yet.I think #2 is a good option, too. It won't let us slack off much because teams will be all but useless without multiplayer, and we can add basic bots once we have a multiplayer framework (I'm imagining bots as a sort of simulated client - the server thinks they're connected players but they're running locally) - in fact, it may be best for just one team member to work on networking while the others work on bots.

OK, so I guess we have that worked out then :) If were all in agreement (I haven't heard from alpha123 yet), these will be B:CoD's first features:
  • [*]Map loading[*]Basic movement[*]Teams (team balancing too?)[*]Classes (2-3 probably)[*]Multiplayer support[*]Bot support (can be worked on concurrently with multiplayer)

And here's an example FPS written in Panda: It doesn't have enemy AI, but it shows how to do everything else (it even has a plugin system of its own): http://code.google.com/p/naith/

Alpha123 said he'd have access to his computer he uses to work on stuff by either today or tomorrow. Unless something's keeping him, BCOD will (hopefully) be starting development by this weekend.
We'll start designing by this weekend. No code will probably be written until next weekend :)

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

Regarding optimization, you're right, I forgot about the two rules of optimization:1. Don't do it.2. (for pros only) Don't do it yet.I think #2 is a good option, too. It won't let us slack off much because teams will be all but useless without multiplayer, and we can add basic bots once we have a multiplayer framework (I'm imagining bots as a sort of simulated client - the server thinks they're connected players but they're running locally) - in fact, it may be best for just one team member to work on networking while the others work on bots.

OK, so I guess we have that worked out then :) If were all in agreement (I haven't heard from alpha123 yet), these will be B:CoD's first features:
  • [*]Map loading[*]Basic movement[*]Teams (team balancing too?)[*]Classes (2-3 probably)[*]Multiplayer support[*]Bot support (can be worked on concurrently with multiplayer)

And here's an example FPS written in Panda: It doesn't have enemy AI, but it shows how to do everything else (it even has a plugin system of its own): http://code.google.com/p/naith/

Alpha123 said he'd have access to his computer he uses to work on stuff by either today or tomorrow. Unless something's keeping him, BCOD will (hopefully) be starting development by this weekend.
We'll start designing by this weekend. No code will probably be written until next weekend :)
Speaking of designing, I need to catch up on my concept art! How many more pieces of that do you guys want/need? Edited by P962

A Toa eh? What kind of Toa am I?

 

Ever wanted to read a manga styled retelling of the early years of Bionicle? Here ya go!

http://www.bzpower.c...?showtopic=1384

Link to comment
Share on other sites

Regarding optimization, you're right, I forgot about the two rules of optimization:1. Don't do it.2. (for pros only) Don't do it yet.I think #2 is a good option, too. It won't let us slack off much because teams will be all but useless without multiplayer, and we can add basic bots once we have a multiplayer framework (I'm imagining bots as a sort of simulated client - the server thinks they're connected players but they're running locally) - in fact, it may be best for just one team member to work on networking while the others work on bots.

OK, so I guess we have that worked out then :) If were all in agreement (I haven't heard from alpha123 yet), these will be B:CoD's first features:
  • [*]Map loading[*]Basic movement[*]Teams (team balancing too?)[*]Classes (2-3 probably)[*]Multiplayer support[*]Bot support (can be worked on concurrently with multiplayer)

And here's an example FPS written in Panda: It doesn't have enemy AI, but it shows how to do everything else (it even has a plugin system of its own): http://code.google.com/p/naith/

Alpha123 said he'd have access to his computer he uses to work on stuff by either today or tomorrow. Unless something's keeping him, BCOD will (hopefully) be starting development by this weekend.
We'll start designing by this weekend. No code will probably be written until next weekend :)
Speaking of designing, I need to catch up on my concept art! How many more pieces of that do you guys want/need?
We haven't decided on what locations will be maps in B:CoD yet, so for now, you can try coloring your Ta-Wahi drawing :)

Every moment gives us a chance to become more than what we are.

-Ryu, Street Fighter III: 3rd Strike: Fight for the Future

Not luck. It's what you do that makes you a hero.

-Kopaka Nuva, MoL

I have but one destiny.

-Takanuva, MoL

rtll200x160.png

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...