Is it okay if I fork a version of bitfighter for experiments

So, I understand that bitfighter is open source, but I just want permission to dig into the code and make my own changes, then we can do a review on it. I don't think I'll actually get to making any changes until tomorrow, but I just wanted to put the word out. Also, I know there is the features thread, but are there any higher-priority features that people want to see in bitfighter that is either under time restraints to develop, or just haven't been done because of other priorities?

Here is my list of things I'm going to play with currently (I will keep this list up to date by editting this post).

The Repo Can Be Found Here: https://github.com/mrozbarry/bitfighter-experiments (This will not compile, as of Thursday, April 3, 2012 - I will let you know when I have the first working version)

• SUPER HIGH PRIORITY: HUGE code-base cleanup
  • I've been going over the code with sam686 and there are a lot of things that need to be cleaned up, and removed.
    
  • [s]Restructure project directories for organization[/s] (completed Sat April 28, 2012)
    • TODO: Fix various project files
      
  • Remove all global variables (yuck!)
    
  • Replace all applicable pieces of the engine with SDL-based code, emphasis on threading.
    
  • Update TNL (? may not be necessary)
    
• Performance:
  • Conditional Compiles:
    • Benchmark current physics handling with Chipmunk physics
      
    • Benchmark current lua scripting with gamemonkey script
      
  • Multithread the server:
    • Each client (or client group?) gets a pooled thread
      
    • Physics run in a separate thread
      
  • Moving voice communication to a separate socket (most games I've worked on used a separate socket, but this may also be a threading issue)
    
• Revamp editor to make it easier for larger level design, as well as including support for any new feature
  
• Rethinking how we handle resolution changes (because stretched images suck!)
  
• Add a match recorder (physics snapshots)
  
• Adding scripting interfaces for weapon definitions
  
• Changing the game HUD a little
  
• Examining the map format to see if it's extensible and if it is not, if there are any ways to update it without breaking older maps (See thread Changing the map format)
  
• Adding more map-based events
  
• Adding power-ups:
  • A single-round weapon to deploy large shield bubbles
    
  • Temporary increased power regeneration
    
  • Create a limited use wormhole/portal
    
• Experimental/Toys:
  • Kill camera
    
  • Gravity wells
    
• Game flow:
  • Default loadout (thanks Heyub)
    
  • Delayed respawns
    
• Aesthetics:
  • Paralaxed map backgrounds
    
• Backburner (these may or may not be done, and are considered very low priority):
  • Moving game modes into dynamic libraries (meaning new game modes don't need the whole game to recompile!)
    
  • Modularizing the code, which will include:
    • Moving different game components (rendering system, network, server, physics, map handling) to dynamic libraries that are loaded by the main executable
      
    • Adding test cases for each component (hurray, we can find out quickly if we broke a part of the engine)
      
    • If possible, I'll play with the update system to only update the individual components and files, rather than just grabbing a brand new installer.
      

This list is highly dependant on the amount of free time I have, and will certainly not be done by the end of this weekend, but I am going to be working on it, and let you know which pieces I have done and which have either been scrapped or removed from the list (I'll give reasons, don't worry).

This isn't really a request thread, so don't just give me what you want in the game, but do link me to feature request threads that are viable and I'll explore those options if I can.

-Beard

*EDIT*
I am also going to add a bug list of what I've found (yes, I'm looking in every nook and cranny).

• Cannot use the space key in input fields (noted in UINameEntry)
  
• Cannot use keys corresponding to menu items in the host game menu (letters D, L, C, M)
  
• Null pointer issues while exitting

[/list]

Important Note
The code structure changes have came to the point of no longer being a branch/fork of the original code. Although my code will be sharing the network protocol and some drawing code, my code base is distinctly different. I will be attempting to emulate as many things from the current version of bitfighter, BUT I can't guarantee that everything will work just as it does currently. This is largely due to how the physics environment is handled. As much as it pains me, I think this is a few steps in the right direction, but I'll leave that up to you gents to decide.

[raptor]

Hi,

You can do a server-side clone in Google Code here:

https://code.google.com/p/bitfighter/source/clones

That way you can keep track of your change for anyone to see, and it is easy to merge them into the mainline.

Hi,

You can do a server-side clone in Google Code here:

https://code.google.com/p/bitfighter/source/clones

That way you can keep track of your change for anyone to see, and it is easy to merge them into the mainline.

That was my plan I'm more of a git/github guy, so fork was the term I'm used to, yeah, I'll do a repo clone on gcode.

-Beard

[Skybax]

do link me to feature request threads that are viable and I'll explore those options if I can.

http://www.bitfighter.org/forums/viewto ... f=4&t=1071
Pleeeeeeeease

do link me to feature request threads that are viable and I'll explore those options if I can.

http://www.bitfighter.org/forums/viewto ... f=4&t=1071
Pleeeeeeeease

It appears like this could theoretically be done with bots, do I don't know if this is particularly high priority, but I can look into it.

-Beard

[watusimoto]

Hey there, IAmBeard,

I used to be the main developer around here, but that label doesn't really seem to apply any more since others are so active. But thanks for asking, and since you did, I'll share my thoughts.

First, yes, of course you should feel free to fork the code and try some new ideas. You have a long list of very ambitious sounding ideas, most of which sound really awesome, and some of which I'm a little more skeptical about. We would welcome successful ideas back into the main trunk, and generally welcome all constructive contributions.

Bitfighter has been around for many years, and over that time we've tried to maintain a few core concepts. First, that the game should remain stylistically conherent, both visually and sonically. Second, that the "rules of the game" (physics and such) should remain constant so players know what to expect (for example, inertia should not change from game-to-game or server-to-server). That said, if we found a better (i.e. more fun) way to change inertia, we would do so, as long as it was applied consistently, and we have been discussing a special "dungeon mode" where this rule might be relaxed a tiny bit. Third, the game should be "fair" in the sense that you can't accrue skills or weapons that are not available to everyone -- the game should present a level playing field for all players (especially new ones). I generally extend this idea to include things like secret walls that you can fly-through (an oft requested feature) because it gives players with secret knowledge an advantage. (That said, I'm currently working on a feature that might make them possible). And fourth, sam, raptor, and myself share an irrational dislike for computational inefficiency, though it's not always apparent from our code

I write these not to limit what you can do, but so you will know what have some ideas of things I would consider when evaluating adding code to the official trunk.

But our most important guideline is to have fun, so if you stick to that, and keep in touch, I think you'll create some great stuff!

Welcome to the community!

PS I tried gravity wells at one point, but couldn't make them work well with our physics system. I'm looking forward to seeing how your ideas on how they should work.

Welcome to the community!

Thank you

I write these not to limit what you can do, but so you will know what have some ideas of things I would consider when evaluating adding code to the official trunk.
[...]
But our most important guideline is to have fun, so if you stick to that, and keep in touch, I think you'll create some great stuff!

Yeah, I'll keep those guides in mind. I don't mean to change the flow or feel of the game, just looking to add to the experience. I'll be branching those individual features in the list, so we can always just merge the ones that work, and toss the ones we don't.

PS I tried gravity wells at one point, but couldn't make them work well with our physics system. I'm looking forward to seeing how your ideas on how they should work.

I've actually successfully had this working using the chipmunk physics, so I'll work on trying to integrate that code in here.

And don't worry, some of those ideas are just brain storming, and are always subject to change. Some may not be feasible, some are the right idea and the wrong approach, but that'll all get weeded out once I'm a little more familiar with the codebase.

Again, thanks for the welcome, you gents here at bitfighter have been great so far
-Beard

[watusimoto]

We're lucky to have such an engaged community.

[sam686]

If you did change the game too much, it might be a different game, using a different title of the game, and not use the "Bitfighter" server (you can run your own master server), where you can make up any rules you want, which does happens on some forks of source code, just like "Zap" source code was forked and became "Bitfighter", using "Bitfighter" master server. Though, that would make us harder to merge some of your specific code to our "Bitfighter" game.

Whether or not you changed a lot, we could look at your code and decide if we want to use some of your code you make that works and fits "Bitfighter" coding and possibly merging your code with us if it is good.

I'm also adding a bug list to the end of my original post, some bugs may align with the current bug list, and I'll try and link the appropriate bugs where I can.

I will work on fixing these bugs in my repo, but it would be nice if they were fixed in the master repo.

-Beard

PS: Thanks sam, I'll try and keep my changes from being too far from the main repo.

[Santiago ZAP]

So, I understand that bitfighter is open source, but I just want permission to dig into the code and make my own changes, then we can do a review on it. I don't think I'll actually get to making any changes until tomorrow, but I just wanted to put the word out. Also, I know there is the features thread, but are there any higher-priority features that people want to see in bitfighter that is either under time restraints to develop, or just haven't been done because of other priorities?

Here is my list of things I'm going to play with currently (I will keep this list up to date by editting this post).

The Cloned Repo Can Be Found Here: https://code.google.com/r/alexbarry-experimental/

• SUPER HIGH PRIORITY: HUGE code-base cleanup
  • I've been going over the code with sam686 and there are a lot of things that need to be cleaned up, and removed.
    
  • [s]Restructure project directories for organization[/s] (completed Sat April 28, 2012)
    • TODO: Fix various project files
      
  • Replace all applicable pieces of the engine with SDL-based code, emphasis on threading.
    
  • Update TNL
    
• Performance:
  • Swapping off the physics for Chipmunk physics to test any performance increases or decreases.
    
  • Multithread the server:
    • Each client (or client group?) gets a pooled thread
      
    • Physics run in a separate thread
      
  • Moving voice communication to a separate socket (most games I've worked on used a separate socket, but this may also be a threading issue)
    
• Moving game modes into dynamic libraries (meaning new game modes don't need the whole game to recompile!)
  
• Adding Lua interfaces for weapon definitions
  
• Changing the game HUD a little
  
• Modularizing the code, which will include:
  • Moving different game components (rendering system, network, server, physics, map handling) to dynamic libraries that are loaded by the main executable
    
  • Adding test cases for each component (hurray, we can find out quickly if we broke a part of the engine)
    
  • If possible, I'll play with the update system to only update the individual components and files, rather than just grabbing a brand new installer.
    
• Examining the map format to see if it's extensible and if it is not, if there are any ways to update it without breaking older maps
  
• Adding more map-based events
  
• Adding power-ups:
  • A single-round weapon to deploy large shield bubbles
    
  • Temporary increased power regeneration
    
  • Create a limited use wormhole/portal
    
• Experimental/Toys:
  • Kill camera
    
  • Gravity wells
    
• Game flow:
  • Default loadout (thanks Heyub)
    
  • Delayed respawns
    
• Aesthetics:
  • Paralaxed map backgrounds
    

This list is highly dependant on the amount of free time I have, and will certainly not be done by the end of this weekend, but I am going to be working on it, and let you know which pieces I have done and which have either been scrapped or removed from the list (I'll give reasons, don't worry).

This isn't really a request thread, so don't just give me what you want in the game, but do link me to feature request threads that are viable and I'll explore those options if I can.

-Beard

*EDIT*
I am also going to add a bug list of what I've found (yes, I'm looking in every nook and cranny).

• Cannot use the space key in input fields (noted in UINameEntry)
  
• Cannot use keys corresponding to menu items in the host game menu (letters D, L, C, M)
  
• Null pointer issues while exitting

I wanna see your own version of Bitfighter! +1 to this guy!

Just a bump to let you know I changed to the repository to github for the time being, and I've changed a lot of the stuff on the list. The toppest top priority is a code cleanup/audit.

-Beard

Sorry for the double post, but I just wanted to note that I'm trying to schedule myself so my repo will have a working build by the end of the week (and by end of the week, I mean probably at some point this weekend).

Goals for the first build:

• It should get a valid connection to the master server
  
• A (temporary) sandbox mode that you can test physics with

Things that are going to be very very broken:

• Scripting
  
• Joining an internet game
  
• Possibly map loading

Anyway, those are things to look forward to. Sorry for the double post.
-Beard

[Skybax]

I, for one, love sandbox games.

I, for one, love sandbox games.

What he said.

[Little_Apple]

make it like a 2d version of garry's mod :3

I, for one, love sandbox games.

Well, it won't really be a game as much as just something you can fly around, interact with a few demo-able things, and that's it. There won't be any winning goals or anything that special. You won't be able to play against any bots or people, at least not yet.

-Beard

@little_apple I do like garry's mod, BUT this sandbox won't be like that. It will just be something to play around in, but you won't be able to spawn anything (there would be a lot of mechanics that I'd have to add to make spawning work properly, which would go beyond my minimalist scope for the time being).

[Little_Apple]

awwwww you make me a sad apple :c

@little_apple I do like garry's mod, BUT this sandbox won't be like that. It will just be something to play around in, but you won't be able to spawn anything (there would be a lot of mechanics that I'd have to add to make spawning work properly, which would go beyond my minimalist scope for the time being).

awwwww you make me a sad apple :c

That doesn't mean that it won't happen. I was toying with the idea of changing the flavour of the map editor to have a sandbox feel, but that is probably a week or two away from even coming close to hitting a priority.

-Beard

[Little_Apple]

apple happy again.

So I'm a little behind schedule - I had some unforseeable events happen this weekend with Mother's Day, so where I planned on doing programming Sunday evening, I actually had my sister in law over and my wife, myself and her ended up watching a movie and playing a few card games. Anywho, I should have something demoable this week, work-load permitting.

-Beard

So, a quick update for all you information hungry peeps.

I just made some huge progress on my rendering engine - so far, it seems to be nearly on par with the current bitfighter, but I also have not optimized any of the OpenGL calls, which means I'll be able to squeeze a bit more graphics power from the engine.

I'm hoping that next week I'll have something that's playable that hopefully you kind bitfighter people can give some input on some ideas I want to put into the game.

For now, if you are familiar with Microsoft Visual Studio and Visual C++, you can pull from my git repo and check out some of the background mechanics.

As it stands, I've been having trouble getting a Linux compile going, but maybe if I can coax raptor to peek at it, we might be able to get something for all the users. I don't have access to a Mac computer, so that'll also have to wait until we have a dev with a little free time and a Mac.

Anyway, I just wanted to update you all on the progress I'm making, so you know I'm not fading into oblivion.

-Beard

[ZoombeR]

Next weekend will be a nice long weekend for me.

Ill take a look at it on my ubuntu and centos VPS'es, and later take a peek at it on my iMac. Just won't be for another week or so.

Next weekend will be a nice long weekend for me.

Ill take a look at it on my ubuntu and centos VPS'es, and later take a peek at it on my iMac. Just won't be for another week or so.

Awesome possum! I've done a fair amount of Linux programs, but for some reason SDL2 is eluding me this time.

Thanks for offering to help

-Beard