Sharing custom code

Get help with installing and running the Cafu Engine here. This forum is also for general questions and discussion of all aspects regarding the Cafu Engine.
Post Reply
SoulRider
Posts: 95
Joined: 2014-04-06, 00:16

Sharing custom code

Post by SoulRider » 2014-09-28, 15:38

Hi Carsten,

I want people to have access to my game code etc, as part of cafu as default, but my ideas involve making a lot of changes to the component system, in terms of components used and the way they are constructed. So I was wondering how I would get this implemented.

So I had a thought, rather than making duel, I would write all the component code into deathmatch and create a pull request for it. As you are developing and progressing other parts of the engine, I thought I could take on responsibility of turning deathmatch into something that people can play off the bat, but also add all the other components that I have created, so even if they are not part of deathmatch, people can use them. This would include my CompTeamNumber and other things.

Obviously you would need to clarify and check the code when I submit it, but I thought it made more sense than trying to make a separate game requiring a separate build of cafu. It is not exactly user friendly:)

Other changes would be simplified players, without health, score & weapon/inventory components etc, to deal with pre-game/ready room scenarios. This is why I wanted to understand subclassing components, as with a central baseplayer, which only controls input, camera and model/physics ,could be easily scripted to add other components to make specific lifeforms for in game use. I would make health\armor\score and eventually movement components which would be ale to be scripted in to create completely unique player characters with a single sub-class of base player component and adding the relevant components in scripting.

Essentially, I would be looking to break down your current HumanPlayer component into a base player component, and like I have already turned score into a component, I will do the same with health and armor, and other non essential stuff for a basic controllable entity. Some games may not want weapons, health and score for example. I would also eventually like to make a movement component, where all movement is handled, so different movement abilities can easily be added and shared between players, by the simple adition of the component and a few variables.

Essentially while not making much of a game, I would be building up the basics of a very flexible component and scripting implementation, which should greatly simplify game creation for other developers.

If you think this will be a good idea, let me know and I will start constructing the game right away.
SoulRider
Posts: 95
Joined: 2014-04-06, 00:16

Re: Sharing custom code

Post by SoulRider » 2014-09-28, 22:55

So i went ahead and did it anyway, just finishing tidying it up and a pull request will be sent to yuo shortly so you can add it to the mainstream cafu.

For general reference the git is hosted here:

https://bitbucket.org/SoulRider/cafu
User avatar
Carsten
Site Admin
Posts: 2160
Joined: 2004-08-19, 13:46
Location: Germany
Contact:

Re: Sharing custom code

Post by Carsten » 2014-09-30, 17:13

Hi SoulRider,

wow, you've put an overwhelming amount of issues into your post! I would however like to try to take the speed a bit out of it, and start a bit more slowly, even on the risk that in this reply I cannot cover all the points that you mentioned.

First and foremost, the most important and proper step is that you've forked the Cafu repository. :up:
This is very important because it has many positive effects:
  • you can create your down developments and submit your own commits independent of the official Cafu repository,
  • you can still "follow" the official Cafu repository, that is, keep track of its latest changes, fixes and new features, and easily merge them in at any time,
  • we can easily and conveniently see what the other is doing,
  • I too can continue to work "independently", if desired.
All this is very important and worthwhile in its own right, but also because it positively affects everything else that you mentioned in your above post. This also gives us more time to discuss the details, while we both can continue to develop and submit arbitrary many commits, each at his heart's pace. ;-)

One big problem, for me to overtake code into the Cafu Engine, is that I must first understand the intention and the purpose of the change, and secondly of course, how the change's goals are technically achieved. While the text How to submit patches is in some regards a bit outdated, the gist is still true: Patches must explain why they are necessary and what they achieve.

Here are a few other texts that explain the matter better than I could:
Note that I care not so much about a commit message's line lengths and grammatical details as designed for the Linux kernel and similar projects, but I do care on a commit message's ability to explain what the commit is about and why it is a good and useful change.

This is also why I will probably decline your otherwise highly appreciated pull request: I think that we have to talk about its details first. It would have been ideal if the single big jumbo commit that you made were instead several smaller commits, each addressing a single feature or single (sub-)goal, but of course I realize that this is a consequence of the historical development of the past weeks, and was not possible at the time things were developed.

That being said, let me get into the details:
So I had a thought, rather than making duel, I would write all the component code into deathmatch and create a pull request for it. As you are developing and progressing other parts of the engine, I thought I could take on responsibility of turning deathmatch into something that people can play off the bat, but also add all the other components that I have created, so even if they are not part of deathmatch, people can use them. This would include my CompTeamNumber and other things.
This is very much appreciated, but wouldn't you prefer to develop your game also in subdirectory named "Duel", rather than "DeathMatch"?

I think that using another game "Dual" besides or in place of "DeathMatch" is possible with all the positive but without the negative side effects.
Obviously you would need to clarify and check the code when I submit it, but I thought it made more sense than trying to make a separate game requiring a separate build of cafu. It is not exactly user friendly:)
Why a separate build? It should be possible to have a single build of Cafu house both Duel and DeathMatch, and in a manner that is convenient both for users and developers!
Other changes would be simplified players, without health, score & weapon/inventory components etc, to deal with pre-game/ready room scenarios. This is why I wanted to understand subclassing components, as with a central baseplayer, which only controls input, camera and model/physics ,could be easily scripted to add other components to make specific lifeforms for in game use. I would make health\armor\score and eventually movement components which would be ale to be scripted in to create completely unique player characters with a single sub-class of base player component and adding the relevant components in scripting.
That sounds very good. It's clear that the current integration of player code in the client and server implementations are not ideal, but these are also things that must be changed carefully and in small steps. This may sound overly cautious to you, but both in general software development practice (see e.g. Linux kernel or Git development) as well as in my own experience, good commit messages and thus "rigorous" code reviews are a key step for successful collaborative software development. (This is also the reason for the big preamble that I wrote above. ;) )
[...] If you think this will be a good idea, let me know and I will start constructing the game right away.
Yes, as said above, this is very much appreciated! We just have to make sure that things are well arranged and well planned. With your forking of the Cafu repository a very important step has been achieved already.

I would like to suggest that as the next crucial step, now that I can for the first time see your code and in fact your whole project, I will familiarize myself with the code that you've written. It will take me some time to do this, but then we have a much better basis for further planning and decisions, both regarding the technical details as well as the procedure for integrating of some or all of it into the Cafu core code. :up:

I'm not sure if this is what you expected or if it meets you preferred course of action (please let me know!), but I think that this is the right method to achieve our goals.
Best regards,
Carsten
SoulRider
Posts: 95
Joined: 2014-04-06, 00:16

Re: Sharing custom code

Post by SoulRider » 2014-10-01, 00:22

That is exactly how I imagined it to happen. I want to make it clear, I am not really making a game. I have decided to focus on expanding the number of components, scripts and tools in the game code to make it easier for people to pick the engine up and run with it.

I am looking to essentially create a game framework for people to to use, although I will make very simple games demonstrating various aspects, I want to focus on creating an expansive framework for quick development.

This involves writing a lot of C++ components and the relevant scripts for people to use. As the components are a compiled part of the GameSys namespace, for people to be able to use them as a default part of the engine, they would need to be included with the cafu source code.

I think the simplest way would be to create pull requests for individual components, so I can discuss each of them, what they are trying to achieve, and how they work. You can then provide feedback and I can make changes if necessary.
User avatar
Carsten
Site Admin
Posts: 2160
Joined: 2004-08-19, 13:46
Location: Germany
Contact:

Re: Sharing custom code

Post by Carsten » 2014-10-07, 17:57

Hi SoulRider,

I read a bit further, both regarding workflows with "forks" in general, and about "long term forks" in particular. Here is a list of pages that I found useful, also noted here for general future reference:
And some related questions at StackOverflow:
To summarize, I think that you should configure the remote cafu/cafu.git repository as "upstream", your remote fork repository would still be "origin".
Then your local branch "master" would be tracking "origin/master", and you can occasionally rebase it on "upstream/master" (or merge "upstream/master" into your local "master").
(Please forgive me if this is your setup already. ;-) )

Pull requests for "master" would still not be useful though, as they would still be a matter of all-or-nothing. Such pull requests should still be made in bug-fix or feature branches.
Best regards,
Carsten
Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests