Jump to content

What Would You Like To See In A Fan Game?


Emzee

Recommended Posts

Okay, sorry guys, I was stuck in a small beach cottage in northern California with no Internet access. :-/

how about holding right mouse down makes you charge your element blast, almost like a small grenade, with the effects of the element (makes nearby people burn with fire, ice frezzes nearbytargets, earth makes giant explosion of dirt doing splash damage, etc)

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.

@Everyone: If we're going to give Vahki/Rahkshi flight abilites, they must have some other ability removed/nerfed. Any suggestions?

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.

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?
Nothing in the GPL says you can't sell stuff. UltraHau named a lot of good examples. I vote GPL.

(I'm imagining bots as a sort of simulated client - the server thinks they're connected players but they're running locally)

That definitely seems like the best way to do it.

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/

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.

 

If the Kanohi masks are a type of technology and most of the MU citizens are Biomechanical beings then how would a Kanohi mask recognize the difference between a Matoran and a Toa?

Muffin button

Link to comment
Share on other sites

how aout a slower walkspeed while charing, because i can see alot of people charging their blasts, but are getting owneded out in the open, and others cant run from cover while they fire their charged blasts

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 didn't know there were places in the US without Internet :/

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.

Slowing down Vahki/Rahkshi on the ground and allowing them to fly only for a limited time sounds good to me - I'd be fine with giving the Vahki/Rahkshi flying ability if we nerfed them like alpha123 suggested.

I like it, though I think you should be unable to move while charging.

Now that might be an interesting way to balance charging. We'll probably have to discuss it a bit more, but I like the idea of charging attacks - I hope B:CoD gets such a feature :)

how aout a slower walkspeed while charing, because i can see alot of people charging their blasts, but are getting owneded out in the open, and others cant run from cover while they fire their charged blasts

That's what would make alpha123's suggestion so interesting. People would have to look for safe places to fire their charged blasts. Or, they'd have to be willing to take some damage in return for their enemies being possibly damaged more (from the charged blast). 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've got some questions concerning the weapons.1. I understand they'll function like guns for the most part, but what about close combat?2. Will the guns be upgradeable? i.e Tahu's firesword could change into say Vakama's disk launcher or a Rahkshi with the ability of fragmentation would have a more powerful staff after reaching a certain level?3. If they won't be upgradeable, will the guns just be scattered across the battlefield waiting to be picked up? Also, while I'm at it. If we go that route, we should eventually program in the abilty to pick up an opponent's weapon once you kill them like in most FPS games.4. In most FPS games, you usually have the ability to carry a grenade or two with you. Will something similar be implemented in BCOD? If so, here are some suggestions:Toa and Skakdi: Elemental BlastsVahki: Kanoka DisksRahkshi: Something similar to Elemental Blasts.

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

  • [*]There probably won't be any explicit close-range weapons (like a sword). Some weapons might work better at close range, though.[*]No. Upgrade-able weapons are too easy to exploit - I say B:CoD will never get them.[*]No - the selection of weapons you get to use is defined by the class you select. Implementing the ability to pick up an enemy weapon would almost make having classes pointless IMHO. We have talked about having Cordak blasters (or a similar generic weapon) scattered around the map, though.[*]First off, Vahki and Rahkshi (this goes for Toa and Skakdi, too) should have identical gameplay - they should not differ in any manner whatsoever. This makes balancing the game much, much easier. Personally, I think charged attacks like we talked about earlier in this thread make grenades redundant, but that's just me.

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

OK, since alpha123 is back, we can start thinking about development:Versioning schemeWe need a hard set of rules that define how we make release numbers. Personally, I recommend Semantic Versioning (http://semver.org), if anyone can find something better, I'm open to that.MilestonesWe also need to define what group of features will make a release (though since this is an open-source project, anyone can get the latest source code themselves, but it won't be as easy). I personally think the following features should make our initial release:

  • [*]Map loading[*]Basic movement + jumping[*]3 maps[*]3 selectable Toa/Skakdi classes - Vahki/Rahkshi can wait[*]Bot AI. Playing an FPS by yourself is boring, if not downright pointless

For our next release, I think we should add the following:

  • [*]6 more maps[*]The last 3 Toa/Skakdi classes, with 3 Vahki/Rahkshi classes[*]Preliminary multiplayer support[*]Networked bot AI, so bots can play against people

As soon as we agree on the features for the first release, I'll add those features (and their owning milestone) to GitHub.EDIT: One other thing: To enable the development team to communicate even in the event of BZP downtime, the team needs to exchange email addresses. The current development team is:

  • [*]Me - UltraHau ^_^[*]Jedi Knight Krazy[*]alpha123[*]P962 (I think)

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 didn't know there were places in the US without Internet :/

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).

Versioning schemeWe need a hard set of rules that define how we make release numbers. Personally, I recommend Semantic Versioning (http://semver.org), if anyone can find something better, I'm open to that.

Read the article. Seems fine to me.

MilestonesWe also need to define what group of features will make a release (though since this is an open-source project, anyone can get the latest source code themselves, but it won't be as easy). I personally think the following features should make our initial release:

  • [*]Map loading[*]Basic movement + jumping[*]3 maps[*]3 selectable Toa/Skakdi classes - Vahki/Rahkshi can wait[*]Bot AI. Playing an FPS by yourself is boring, if not downright pointless

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.

  • [*]Me - UltraHau ^_^[*]Jedi Knight Krazy[*]alpha123[*]P962 (I think)

I thought Katuko was with us. Anyway, PMed you and JKK my email. Will PM P962 if he confirms he's in on this.

 

If the Kanohi masks are a type of technology and most of the MU citizens are Biomechanical beings then how would a Kanohi mask recognize the difference between a Matoran and a Toa?

Muffin button

Link to comment
Share on other sites

I'm with you in the sense that I support the project. But between my own game and school, I sort of got enough to do already. That, and I'm really not familiar with 3D or Python/whatever Panda uses.If you need ideas and text-based design, I can do that. If you need some sketches and/or textures, I can get that. If you want sound effects, music, whatevs, sure, I can search for/make that. I can even try my hand at 3DS Max if you want some very, very simple models; but as said, I have no real experience with that.I know I promised to make some stuff for your game, alpha, but as you can see I never got that far. Which is why I'm reluctant to sign up for yet another game-making project. (Especially when I won't be in charge. :P)

Edited by Katuko
Link to comment
Share on other sites

I don't know too much about Panda, but I could do some modeling with Blender if you guys don't have anyone to do that. I'll send you guys my email if you me to help but if not, I completely understand (an eagerness to learn the program and help you guys is no replacement for experience.)

rarity-with-wings.jpgrarity-heart.png <<Newest Chibi: Nuparu Inika
Link to comment
Share on other sites

I'm with you in the sense that I support the project. But between my own game and school, I sort of got enough to do already. That, and I'm really not familiar with 3D or Python/whatever Panda uses.If you need ideas and text-based design, I can do that. If you need some sketches and/or textures, I can get that. If you want sound effects, music, whatevs, sure, I can search for/make that. I can even try my hand at 3DS Max if you want some very, very simple models; but as said, I have no real experience with that.I know I promised to make some stuff for your game, alpha, but as you can see I never got that far. Which is why I'm reluctant to sign up for yet another game-making project. (Especially when I won't be in charge. :P)

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. Edited by alpha123

 

If the Kanohi masks are a type of technology and most of the MU citizens are Biomechanical beings then how would a Kanohi mask recognize the difference between a Matoran and a Toa?

Muffin button

Link to comment
Share on other sites

I don't know too much about Panda, but I could do some modeling with Blender if you guys don't have anyone to do that. I'll send you guys my email if you me to help but if not, I completely understand (an eagerness to learn the program and help you guys is no replacement for experience.)

At this stage, we need artists - we have enough programmers ^_^ So yes, I (I can't speak for the other team members) would certainly appreciate your help; some previous work you've done with Blender would be helpful, though.

I'm with you in the sense that I support the project. But between my own game and school, I sort of got enough to do already. That, and I'm really not familiar with 3D or Python/whatever Panda uses.If you need ideas and text-based design, I can do that. If you need some sketches and/or textures, I can get that. If you want sound effects, music, whatevs, sure, I can search for/make that. I can even try my hand at 3DS Max if you want some very, very simple models; but as said, I have no real experience with that.I know I promised to make some stuff for your game, alpha, but as you can see I never got that far. Which is why I'm reluctant to sign up for yet another game-making project. (Especially when I won't be in charge. :P)

Ideas and text-based design are always helpful ^_^ Granted, at this stage, we've all but chosen what features will make it in the first release, so I'm not sure many new ideas are needed at this stage.Sketches and textures: Both would really be appreciated - we don't really have any artists on the team at the moment. We haven't decided what license we're going to use for art/music, so you may want to wait for us to decide that.Sound effects and music would be good, but again, we haven't decided on a license for art/music, so you should probably just wait until we decide upon one.

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.

Adding multiplayer in the initial release will really delay our initial release, so I'd rather not have it in the initial release. Like I talked about with JKK, if we design our game's architecture correctly, moving the physics simulation to the server will be easy. Also, I think we can afford to have 3 maps and 3 classes - we can work on programming, while the as-yet-to-be-named artist team works on maps and class models.

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 don't know too much about Panda, but I could do some modeling with Blender if you guys don't have anyone to do that. I'll send you guys my email if you me to help but if not, I completely understand (an eagerness to learn the program and help you guys is no replacement for experience.)

At this stage, we need artists - we have enough programmers ^_^ So yes, I (I can't speak for the other team members) would certainly appreciate your help; some previous work you've done with Blender would be helpful, though.
Like I said before, I haven't done anything with it before. That's why I was wondering if I should try my hand at it or just leave it to more experienced people. I'll see if I can make something to be used as an example of my skill if you want.
rarity-with-wings.jpgrarity-heart.png <<Newest Chibi: Nuparu Inika
Link to comment
Share on other sites

I don't know too much about Panda, but I could do some modeling with Blender if you guys don't have anyone to do that. I'll send you guys my email if you me to help but if not, I completely understand (an eagerness to learn the program and help you guys is no replacement for experience.)

At this stage, we need artists - we have enough programmers ^_^ So yes, I (I can't speak for the other team members) would certainly appreciate your help; some previous work you've done with Blender would be helpful, though.
Like I said before, I haven't done anything with it before. That's why I was wondering if I should try my hand at it or just leave it to more experienced people. I'll see if I can make something to be used as an example of my skill if you want.
Yeah, that would be great - thanks :)

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 just sketched up a concept for the character menu, but I need to know: Will weapons change depending on element? Is each element a class in and of itself?You see, I was thinking that since masks will not be used in-game, the user could be allowed to select their looks to create some variation if they can't change color. If the attacks depend on element and not the weapon itself, then we could also allow people to wield, say, either a sword or axe but have both be functionally identical. I mean, a Toa of Fire would always have a burning weapon, but what sort of blade it is doesn't matter.

Link to comment
Share on other sites

Adding multiplayer in the initial release will really delay our initial release, so I'd rather not have it in the initial release. Like I talked about with JKK, if we design our game's architecture correctly, moving the physics simulation to the server will be easy. Also, I think we can afford to have 3 maps and 3 classes - we can work on programming, while the as-yet-to-be-named artist team works on maps and class models.

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. Edited by alpha123

 

If the Kanohi masks are a type of technology and most of the MU citizens are Biomechanical beings then how would a Kanohi mask recognize the difference between a Matoran and a Toa?

Muffin button

Link to comment
Share on other sites

Adding multiplayer in the initial release will really delay our initial release, so I'd rather not have it in the initial release. Like I talked about with JKK, if we design our game's architecture correctly, moving the physics simulation to the server will be easy. Also, I think we can afford to have 3 maps and 3 classes - we can work on programming, while the as-yet-to-be-named artist team works on maps and class models.

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.
Why take the risk of not designing it correctly when we can just put it in there first thing?Because, if we put it in "first thing", we will be more likely to make an incorrect design, since we don't know how we will structure the rest of our game, and thus our game's internal structure would revel in the details of our multiplayer code. As Robert Martin says, "it's better for the architecture to constrain the details". Multiplayer is a detail. It would be better if multiplayer conformed to the rest of our game (which is accomplished by doing it later), than the other way around.Why bother creating something that we're just going to throw away next release?Because there are more important features than multiplayer. Also, your point about "code getting thrown away" is relatively pointless IMHO - code gets thrown away and re-written when needed in the Real World all the time.Give me a reason we shouldn't put multiplayer in the first release.I can give you 3:
  • [*]The faster we make a release, the more faith and interest people will put in this project, and the more interest the team members will show, too.[*]Adding multiplayer before anything else is done is doomed to failure. How will we write a multiplayer framework for a game that has no other code? Simple. All our future code must know about and use this framework, which violates practically every OO principle out there.[*]Multiplayer can be done after our first release, which gives us more time to experiment with it.[*]

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

Because, if we put it in "first thing", we will be more likely to make an incorrect design, since we don't know how we will structure the rest of our game, and thus our game's internal structure would revel in the details of our multiplayer code.

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.

As Robert Martin says, "it's better for the architecture to constrain the details". Multiplayer is a detail. It would be better if multiplayer conformed to the rest of our game (which is accomplished by doing it later), than the other way around.

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.

Because there are more important features than multiplayer. Also, your point about "code getting thrown away" is relatively pointless IMHO - code gets thrown away and re-written when needed [emphasis added] in the Real World all the time.

The key there is "when needed". We don't need to here.

The faster we make a release, the more faith and interest people will put in this project, and the more interest the team members will show, too.

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.

Adding multiplayer before anything else is done is doomed to failure. How will we write a multiplayer framework for a game that has no other code? Simple. All our future code must know about and use this framework, which violates practically every OO principle out there.

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.

Multiplayer can be done after our first release, which gives us more time to experiment with it.

Communicating across the network can be done after our first release. Edited by alpha123

 

If the Kanohi masks are a type of technology and most of the MU citizens are Biomechanical beings then how would a Kanohi mask recognize the difference between a Matoran and a Toa?

Muffin button

Link to comment
Share on other sites

Well, as long as alpha's protesting delaying multiplayer, I'm going to jump back on the multiplayer-first bandwagon. You keep saying that it'll be easy to move physics simulations to the server. There's far more to multiplayer than physics! In fact, I'd say that this game would have almost no physics in the sense of a general-purpose simulation. I don't consider player movement to be physics - though it usually has some physical concepts like velocity and gravity, it's far better to write player movement from scratch for a specific purpose, otherwise the controls will feel floaty and unnatural. Speaking of floaty, gravity needs to be increased to several times its strength on Earth - believe me, games feel more natural that way.As far as networking design goes, I see all the clients simulating their own movement and sending their position and actions up to the server. The server would be responsible for deciding the results of actions (i.e. applying damage) and sending player's current positions to other clients. The server would also simulate any non-player objects and characters on the field (i.e. monsters, environment hazards, item pickups)Am I missing anything? Also, I think that UltraHau should code solo for a few days - if other team members try to pitch in before the framework is stable, we'll probably cause more harm than good. Also, while I can't speak for alpha123, I'm a total Panda (and Python) noob, so if I try to work without well-written code to emulate, I'm going to produce junk that we can't use.

IrMSNn3.png

Link to comment
Share on other sites

Also, I think that UltraHau should code solo for a few days - if other team members try to pitch in before the framework is stable, we'll probably cause more harm than good. Also, while I can't speak for alpha123, I'm a total Panda (and Python) noob, so if I try to work without well-written code to emulate, I'm going to produce junk that we can't use.

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.

 

If the Kanohi masks are a type of technology and most of the MU citizens are Biomechanical beings then how would a Kanohi mask recognize the difference between a Matoran and a Toa?

Muffin button

Link to comment
Share on other sites

If you could PM me a list of Python's really unique features and quirks, that'd be awesome! It's close enough to other languages I've used, though, that I think I've got a pretty grasp of the basics (first impressions are Ruby meets JavaScript with significant whitespace)I've thought of another compromise for the multiplayer debate: multiplayer and networking, is, as UltraHau stated, a detail. The client/server architecture of the game, however, is a critical piece of the framework. So I think, in the first release of the game, we should separate our code into two distinct modules: client and server. These two modules should only communicate with each other via abstractions (a good model for any multi-module design). In Phase 2, we swap those abstractions for a version that can communicate with an instance of the module running on a remote computer.Not only does this settle the debate, but it solves the problem of our game having to run the same code in three different modes (client, server, dedicated server), which could get complicated even if networking doesn't.

IrMSNn3.png

Link to comment
Share on other sites

alpha123, what you're suggesting is called "putting the hooks in". It almost never works in the software industry, for quite a few reasons:

  • [*]You don't fully understand the feature for which you're "putting the hooks in" (multiplayer in this case), which means you'll throw away that code in the end[*]It makes code that shouldn't have to know about multiplayer revel in its details - map loading and such is a client-side issue, for example

What would be better would be to design and implement the more important features first, and then implement multiplayer once we see its requirements, which we will only be able to do after multiplayer's prerequisite features are implemented. This way, multiplayer only has the feature it absolutely needs, which results in shorter, clearer code in both the long and short run.

I'll be helping you guys with the artwork/style for BCOD. Count on it! ;)

OK - PM your email to the other team members so we can keep in touch even if BZP goes down :)

Well, as long as alpha's protesting delaying multiplayer, I'm going to jump back on the multiplayer-first bandwagon.You keep saying that it'll be easy to move physics simulations to the server. There's far more to multiplayer than physics! In fact, I'd say that this game would have almost no physics in the sense of a general-purpose simulation. I don't consider player movement to be physics - though it usually has some physical concepts like velocity and gravity, it's far better to write player movement from scratch for a specific purpose, otherwise the controls will feel floaty and unnatural. Speaking of floaty, gravity needs to be increased to several times its strength on Earth - believe me, games feel more natural that way.As far as networking design goes, I see all the clients simulating their own movement and sending their position and actions up to the server. The server would be responsible for deciding the results of actions (i.e. applying damage) and sending player's current positions to other clients. The server would also simulate any non-player objects and characters on the field (i.e. monsters, environment hazards, item pickups)Am I missing anything?Also, I think that UltraHau should code solo for a few days - if other team members try to pitch in before the framework is stable, we'll probably cause more harm than good. Also, while I can't speak for alpha123, I'm a total Panda (and Python) noob, so if I try to work without well-written code to emulate, I'm going to produce junk that we can't use.

You're right - multiplayer is more than physics, but I merely gave physics as an example; the ideas I presented could easily be extended to other.Your networking design is a bit too trusting IMHO. A rogue client could teleport its character all over the map by merely giving the server whatever position it wanted. Most (if not all) networked FPS games make the server simulate everything, but have the clients make their own local predictions about where a certain object will be next, but let the sever make corrections every once in a while.I'm fine with coding alone as soon as we reach consensus on what will be done first - without deciding that, the team (and the code) will be thrown into turmoil.

Also, I think that UltraHau should code solo for a few days - if other team members try to pitch in before the framework is stable, we'll probably cause more harm than good. Also, while I can't speak for alpha123, I'm a total Panda (and Python) noob, so if I try to work without well-written code to emulate, I'm going to produce junk that we can't use.

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.
You can see some previous Panda work I've done here: http://openblox.hg.s...b3ed6dddc37/src. Be warned, there's quite a bit of Python (around 16k lines), and around 10% of the code has no comments whatsoever.

If you could PM me a list of Python's really unique features and quirks, that'd be awesome! It's close enough to other languages I've used, though, that I think I've got a pretty grasp of the basics (first impressions are Ruby meets JavaScript with significant whitespace)I've thought of another compromise for the multiplayer debate: multiplayer and networking, is, as UltraHau stated, a detail. The client/server architecture of the game, however, is a critical piece of the framework. So I think, in the first release of the game, we should separate our code into two distinct modules: client and server. These two modules should only communicate with each other via abstractions (a good model for any multi-module design). In Phase 2, we swap those abstractions for a version that can communicate with an instance of the module running on a remote computer.Not only does this settle the debate, but it solves the problem of our game having to run the same code in three different modes (client, server, dedicated server), which could get complicated even if networking doesn't.

Sounds good to me - I vote for just making the game with a client/server architecture and adding networked multiplayer later. 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

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.

Edited by alpha123

 

If the Kanohi masks are a type of technology and most of the MU citizens are Biomechanical beings then how would a Kanohi mask recognize the difference between a Matoran and a Toa?

Muffin button

Link to comment
Share on other sites

Panda uses Python 2.EDIT: Post #262 another palindrome. I think I better stop doing this :)

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

Panda uses Python 2.EDIT: Post #262 another palindrome. I think I better stop doing this :)

Okay. Thanks.

 

If the Kanohi masks are a type of technology and most of the MU citizens are Biomechanical beings then how would a Kanohi mask recognize the difference between a Matoran and a Toa?

Muffin button

Link to comment
Share on other sites

Your networking design is a bit too trusting IMHO. A rogue client could teleport its character all over the map by merely giving the server whatever position it wanted. Most (if not all) networked FPS games make the server simulate everything, but have the clients make their own local predictions about where a certain object will be next, but let the sever make corrections every once in a while.

I thought briefly about an authoritative server design, but I figured that A. we probably won't have many problems with hackers given our small community, and B. authoritative design will put processing strain on the server - not good when, more often than not, the same computer will be running the server and a client, and we can't depend on that computer being powerful enough. If hacking, flying, and teleporting really become a problem, we can have the server place some constraints on player movement.I think that the responsibilities of the client and server are definitely worth further discussion.As for "what first", I'm comfortable holding off on multiplayer if the game has a client/server architecture resilient to asynchronous communication. We should put the server module in its own thread to prevent any surprises in networking.

IrMSNn3.png

Link to comment
Share on other sites

I thought briefly about an authoritative server design, but I figured that A. we probably won't have many problems with hackers given our small community, and B. authoritative design will put processing strain on the server - not good when, more often than not, the same computer will be running the server and a client, and we can't depend on that computer being powerful enough.If hacking, flying, and teleporting really become a problem, we can have the server place some constraints on player movement.I think that the responsibilities of the client and server are definitely worth further discussion.

Another problem that I failed to bring up earlier is your protocol design fails to bring latency into account. Say you have two players: Player 1 and Player 2. Player 1 fires a rifle at Player 2, and it takes 200ms for Player 1's client to tell the server it fired a rifle, and it will take 50ms for the rifle bullet to hit Player 2. Player 2 saw Player 1's rifle and put up a protective shield 25ms before Player 1 fired his rifle, but due to Player 2's slightly slower connection, it will take 300ms for Player 2's client to tell the server it raised a shield.End result: Player 1's bullet ends up hitting Player 2, and Player 2 ragequits.I know that was a rather contrived example, but it happens all the time in fast-paced action games. I say go for an authoritative server design - we have no proof that the server will be processor-intensive, and we will have a better, more secure simulation as a result.

As for "what first", I'm comfortable holding off on multiplayer if the game has a client/server architecture resilient to asynchronous communication. We should put the server module in its own thread to prevent any surprises in networking.

I'd rather have the server run as it's own process for several reasons:
  • [*]Python threads (at least in the standard CPython implementation - this doesn't apply to other Python implementations like PyPy) are not truly concurrent; they only appear to be that way because one thread can stop while another starts at any possible time, but only one thread is ever executed at a given moment by the Python interpreter - multiple processes, on the other hand, are run at the same time if the target machine allows it[*]Separate Python processes are easier to coordinate than threads using Python's multiprocessing module[*]A multi-process approach is stabler, too: Say we use the multi-process approach, and someone is hosting a LAN tournament on the same computer with which they compete. For some reason, their client crashes. However, the other competitors can continue to play due to the fact the server is a separate process. This is admittedly not a large concern for now, but refactoring threads into processes can be a pain

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

Another problem that I failed to bring up earlier is your protocol design fails to bring latency into account. Say you have two players: Player 1 and Player 2. Player 1 fires a rifle at Player 2, and it takes 200ms for Player 1's client to tell the server it fired a rifle, and it will take 50ms for the rifle bullet to hit Player 2. Player 2 saw Player 1's rifle and put up a protective shield 25ms before Player 1 fired his rifle, but due to Player 2's slightly slower connection, it will take 300ms for Player 2's client to tell the server it raised a shield.End result: Player 1's bullet ends up hitting Player 2, and Player 2 ragequits.I know that was a rather contrived example, but it happens all the time in fast-paced action games. I say go for an authoritative server design - we have no proof that the server will be processor-intensive, and we will have a better, more secure simulation as a result.

I see the issue, but I'm not convinced that switching to an authoritative server will fix it. Let me check out the logic here...0ms - Player 2 presses button to raise shield25ms - Player 1 presses button to fire225ms - Player 1's request to fire arrives at server275ms - Bullet hits Player 2's character300ms - Player 2's request to shield arrives at serverUnless you had something in mind to intentionally delay input from players with faster connections, or retroactively apply effects of actions based on the player's ping?I know some FPS games do something like this - I believe it's TF2 where when a request to fire arrives at the server, it checks where the enemy was at the time the player fired, leading to occasional shooting through walls.I don't particularly mind doing authoritative server, I just thought that client-side calculations might be a simplification worth considering.

I'd rather have the server run as it's own process for several reasons:

  • [*]Python threads (at least in the standard CPython implementation - this doesn't apply to other Python implementations like PyPy) are not truly concurrent; they only appear to be that way because one thread can stop while another starts at any possible time, but only one thread is ever executed at a given moment by the Python interpreter - multiple processes, on the other hand, are run at the same time if the target machine allows it[*]Separate Python processes are easier to coordinate than threads using Python's multiprocessing module[*]A multi-process approach is stabler, too: Say we use the multi-process approach, and someone is hosting a LAN tournament on the same computer with which they compete. For some reason, their client crashes. However, the other competitors can continue to play due to the fact the server is a separate process. This is admittedly not a large concern for now, but refactoring threads into processes can be a pain

Well, if processes are easier to coordinate than threads in Python, then by all means, let's do that! In most other languages, the easiest way to coordinate multiple processes would be to use networking, which would defeat the purpose of this. Edited by Jedi Knight Krazy

IrMSNn3.png

Link to comment
Share on other sites

Well, if processes are easier to coordinate than threads in Python, then by all means, let's do that! In most other languages, the easiest way to coordinate multiple processes would be to use networking, which would defeat the purpose of this.

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...

 

If the Kanohi masks are a type of technology and most of the MU citizens are Biomechanical beings then how would a Kanohi mask recognize the difference between a Matoran and a Toa?

Muffin button

Link to comment
Share on other sites

I vote processes, but Windows CPython (except Cygwin) lacks an os.fork function.

That's okay - Python's multiprocessing module takes care of that for us.

I don't have enough experience with the multiprocessing module to know if that makes a significant performance difference.

If anything, the multiprocessing module improves performance, but that's not what we're concerned about - we're trying to figure out how to spoof a client and server without actually adding networking, and running the server in a separate process seems the best way.

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

Quick question: Now that this topic has been so diverted from its original purpose; wouldn't a name change and/or new topic be in order?

A name change? Perhaps. We cannot make a new topic because we have no tangible progress, unfortunately.

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

So, once we actually kick off, I think everyone on the team should have a specific role - obviously P962 is our only artist right now, but since we have three programmers, I think we should split up the work according what what we like to do.I'm assuming UltraHau will want to be involved in structural and framework design - and even if you don't like that, you're pretty much doing it anyways :)What I'd like to focus on in development is player controls - I find that's my favorite part of game design and I can spend hours tweaking it until it feels just right to me.I also tend to like improving graphics; picking the right shaders and lighting can go a long way towards making an amateur game look amazing. Since Panda supports dynamic shadows and post-process effects much more easily than Unity Free (read: it's possible in Panda), I'd also like to try my hand at that.I'm not sure about alpha - if I'm not mistaken, you're the only one out of all of us who's gotten a multiplayer game working (unless Combat Zone doesn't have networking implemented yet), so that might be a big part of your role.Classes and abilities will probably have to be shared among the programmers, though. There's too much content there for one person to focus on it.

IrMSNn3.png

Link to comment
Share on other sites

I'm not sure about alpha - if I'm not mistaken, you're the only one out of all of us who's gotten a multiplayer game working (unless Combat Zone doesn't have networking implemented yet), so that might be a big part of your role.

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.

If anything, the multiprocessing module improves performance, but that's not what we're concerned about - we're trying to figure out how to spoof a client and server without actually adding networking, and running the server in a separate process seems the best way.

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.

 

If the Kanohi masks are a type of technology and most of the MU citizens are Biomechanical beings then how would a Kanohi mask recognize the difference between a Matoran and a Toa?

Muffin button

Link to comment
Share on other sites

I just want a BIONICLE RTS (BTW I only read the first page of replies so if you guys are discussing something, I have no idea what to say) which I think someone mentioned before.

My name was Z, Got wounded, put my mind in a Vahki and switched my name to Reptor, edited my model into a Matoran friendly one, changed my name to Reppy Tor, Got wanted in three cities, Then they said I could be anything I wanted, became a Shape-shifter named Pony Hank. I am Pipped

Link to comment
Share on other sites

I'm assuming UltraHau will want to be involved in structural and framework design - and even if you don't like that, you're pretty much doing it anyways :)

Sure, I like doing that anyway - I enjoy figuring out how to make extensible and flexible architectures :)

I also tend to like improving graphics; picking the right shaders and lighting can go a long way towards making an amateur game look amazing. Since Panda supports dynamic shadows and post-process effects much more easily than Unity Free (read: it's possible in Panda), I'd also like to try my hand at that.

Okay - Panda support shadows and quite a few other graphical effects out of the box (so you don't have to write your own shaders for most effects), but you should keep several things in mind:
  • [*]Some post-processing effects - SSAO most notably - will really kill your framerate, and will make B:CoD unplayable on computers with mid to low-end GPUs. Shadow maps (cascaded, parallel-split, or simple) are fine, but baked shadows + ambient occlusion is the first approach we should consider - it's much cheaper, and looks much better.[*]There are very few (if any) debugging tools for shaders. If something doesn't work the way you think it should, you don't have too many ways to figure out what's wrong.[*]Baked/pre-calculated effects is what we should consider first, especially considering the nature of our game. Most FPSes bake ambient occlusion and shadows/lighting into their maps and models, and I think it's what we should consider first.

I just want a BIONICLE RTS (BTW I only read the first page of replies so if you guys are discussing something, I have no idea what to say) which I think someone mentioned before.

Sorry, we've already decided on a game genre - in fact, we're about to start development in a day or so :)

I'm not sure about alpha - if I'm not mistaken, you're the only one out of all of us who's gotten a multiplayer game working (unless Combat Zone doesn't have networking implemented yet), so that might be a big part of your role.

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.
Panda has a built-in MMO API - Disney uses Panda for both Toontown Online and Pirates of the Caribbean Online - so adding networking functionality should require very little work on our end.

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

Wait you guys are actually making a game? I thought this was just a question thread.

My name was Z, Got wounded, put my mind in a Vahki and switched my name to Reptor, edited my model into a Matoran friendly one, changed my name to Reppy Tor, Got wanted in three cities, Then they said I could be anything I wanted, became a Shape-shifter named Pony Hank. I am Pipped

Link to comment
Share on other sites

Wait you guys are actually making a game? I thought this was just a question thread.

Not anymore - enough developers agreed on an idea, so get ready for a Bionicle FPS :)

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...