PlaneShift
Development => Development Deliberation => Topic started by: redhound on January 06, 2015, 04:17:40 pm
-
Exploring PlaneShift project pages on the SourceForge, I've personally missed some basic things (after some experience with GitHub), like ability to fill an issue and propose a code change for it - and start thinking...
I understand PS have it's own long history, development infrastructure, and there is much more than just client / server code that makes The Game, but... Is there any plans to make the contributing process more simple and development process more open - make things more "agile"?
To be more specific, I name some things (most are CI-flawored):
1. Switch to SVN to git.
2. Separate repositories for client / server applications, libraries (like Cal3D), game content (restricted?), website, related projects (dev tools, default skins, etc.) - the smaller, the better.
3. Issue tracker, integrated with code repositories.
4. Unit tests, at least for some code parts.
5. Automatic build system for main development platforms (simplifies testing).
It's just outsider's look and I've probably missed The Main Thing, but I'm almost sure what any item from this list, if adopted or implemented, could greatly influence project future.
-
Thats great! Sounds like it will be a great help. How soon do you plan to start?
-
I'm not a member of development team, verden :)
-
Hi redhound, thank you for your ideas
I will try to address the issues you point at:
To be more specific, I name some things (most are CI-flawored):
1. Switch to SVN to git.
Personally I don't see the need to move from SVN to GIT, but I've also noticed when it comes to speak about one or the other some "religious" arguments arises because somebody favours one and someone else the other.
2. Separate repositories for client / server applications, libraries (like Cal3D), game content (restricted?), website, related projects (dev tools, default skins, etc.) - the smaller, the better.
Repositiries for cal3d and CS are separated, about client/server repo separation I personally find it handy to be able to update both of them with a single SVN command, also there are specific jam commands to build only the client or the server so it's not necessary to recompile them both all the time.
3. Issue tracker, integrated with code repositories.
Ok I admit I don't know what you're talking about (but I'm not engine dev at least ;D ), can you tell me more?
4. Unit tests, at least for some code parts.
These would definitely be handy, but they are not high in our (long) priority list. Is there someone able and willing to code them for us?
5. Automatic build system for main development platforms (simplifies testing).
we have 2 testing environment (servers) one which mirrors the production server and one with nightly builts of the latests code, of course both fulfils different purposes (data testing & setup/code testing).
-
Thanks for your answers, Eonwind!
1. Well, maybe the only killer feature of git is easy branching - but it is something what will be required in case there will be a plans to accept code contributions directly.
2. Separating client and server repositories may not be primary thing, but with smaller repos it will be easy to delegate their management to various developers / contributors.
About Cal3D and CS - I meant it would be nice to have a forks of them, compatible with current PS version and supported by the PS team (but maybe a cost of maintaining them will be too high?)
3. Under integration issue tracker with core repositories I meant ability to link commits / branches / pull requests with issues directly, and also using tracker to do some project management (set milestones, link issues with them, see what should be done to get to the new release, etc.) It should make development process more transparent.
4. I'd be grad to help, if my ten-years-forgotten C++ coding skills could produce something useful, in testing or other parts. Could you provide a link to that long priority list?..
5. Do those testing environments and nightly builds are public?
-
If I may chime in:
I use Git at work. It is really easy to create branches and I usually create a local branch to handle a bug fix and then tie that back to the main branch I'm working on. It makes it easier to manage small changes and I can switch branches without creating a series of dependent commits. Like Eonwind said, it does come down to a personal preference.
I work in enterprise software and I can say having everything split out into smaller "libraries" is much, much easier to manage, especially when some of the code doesn't need to be changed very often. That being said, I work in Java and we use Ant/Maven to handle dependencies and the building of source, so it's just generally a lot easier. If it's easier to just leave PlaneShift source as it is, that's a fair enough assessment.
An issue tracker integrated with the repositories sounds a lot like Rational Team Concert or even Pivotal. You set up Epics or Milestones and put all of the bugs or work items in their specific milestone or epic. Even better would be adding in Gerrit (if using Git) for Code Reviews. Code gets submitted, someone higher up looks at it and approves or denies it. If it gets approved, it gets merged into the main branch.
Once I finally get everything set up and working, I can help a tiny bit with unit tests. I'm used to Java so I'd have to figure out what C++ uses for it all and learn it.
Would an automated build system be something like Jenkins? I've worked with that and I actually work on a build tool on a daily basis. They're really nice because they compile the code, run tests, upload the reports, and send out notifications if something fails.
-
About Cal3D and CS - I meant it would be nice to have a forks of them, compatible with current PS version and supported by the PS team (but maybe a cost of maintaining them will be too high?)
Nope having forks of CS would not be good at all. We work along the CS team to make sure PS can always compile with latest CS revision. Sometimes it's not possible due to the fact that CS must continue its development process and it may take time to find out where the problems are. Forking CS will only lead to PS unable to use the latest CS features on the long run.
4. I'd be grad to help, if my ten-years-forgotten C++ coding skills could produce something useful, in testing or other parts. Could you provide a link to that long priority list?..
We would be glad to receive any help :)
Best way to help us is finding us at #planeshift-prospects and asking for a task. Usually the list of short term priorities are discussed by the devs meeting and are for internal use, however you can find a list of features we would like to see added on the long term to the game here: http://planeshift.top-ix.it/pswiki/index.php?title=GSoC_2014 (http://planeshift.top-ix.it/pswiki/index.php?title=GSoC_2014).
5. Do those testing environments and nightly builds are public?
No, the testing environment is where we also test new content (quests, rules stuff, spells, etc.) and they're only accessible by who really need to work with them (this may include a few prospects if needed). The nightly builds are maintained by a dev at his place, content is mostly SVN based except a few "experiments".
-
About Cal3D and CS - I meant it would be nice to have a forks of them, compatible with current PS version and supported by the PS team (but maybe a cost of maintaining them will be too high?)
Nope having forks of CS would not be good at all. We work along the CS team to make sure PS can always compile with latest CS revision. Sometimes it's not possible due to the fact that CS must continue its development process and it may take time to find out where the problems are. Forking CS will only lead to PS unable to use the latest CS features on the long run.
That's not entirely true. The way a lot of projects work nowadays is they fork a major project, add their own stuff, and then merge in changes from the main repo they forked. It you look at Libre Office, I believe they forked Open Office and merge in any changes Open Office makes. Other projects do the same thing. It would, however, be a lot more work because devs would have to track when CS has new releases and then merge changes in
-
Three times I have started to post a reply to this describing our internal processes and movement toward anew agile-like methodology . The replies have been long and detailed and I have gotten pulled away and lost the post. I'll try to put my reply in here in smaller chunks in the next few days.
-
Thanks anyway, waiting for it :)
-
That's not entirely true. The way a lot of projects work nowadays is they fork a major project, add their own stuff, and then merge in changes from the main repo they forked. It you look at Libre Office, I believe they forked Open Office and merge in any changes Open Office makes. Other projects do the same thing. It would, however, be a lot more work because devs would have to track when CS has new releases and then merge changes in
May not be true for other projects but it's true for PS. Remember we're a little team and there's no way we can maintain forks of CS, we have PS devs with commit accesses in the CS repository and that's all we need right now.
-
The first thing to keep in mind is, as eonwind says, we are a very small team.
I'm one of three active engine devs. Weltall is strictly envolved with builds and releases, and Jilare has very little free time these days. We have two active prospects : Natoka, who is working on a big project for us, but recently was overtaken by RL ( ;) ) and Enio, who has little time for big projects but has done a number of very nice bug fixes for us. We also receive valuable code contributions from Shkirr and Neeno.
The second thing to keep in mind is that there is a long established history, as you say. Let me start with an overview of how the current process works and a little of why. Keep in mind that I have only been with the dev team for about 2 years, so lack most of the knowledge of why things are done the way they are.
- New feature requests come in from players via flyspray, from devs and gm's via flyspray or direct request, and from Talad's direct request in our developer team meetings.
- Requests are prioritized by potential impact to the community and developer preference. Critical fixes get immediate attention whereas feature requests that affect a very small number of players take lowest priority. Note the "developer preference" part, because it's important. It is often the case that a prospect will work for us as long as they like the project. Assign them something they don't like and they may leave. This is sometimes true of full developers as well.
- Features are worked on informal branches of the source code stored on the dev's machine. This works because we typically assign only one dev to a given project at a time.
- Code contributions are accepted from the community.
- All code has to be reviewed and tested by a full dev before it can be checked in. The reason behind this is one that none of us wants to think about, but the reality is that opening the code base would invite malicious code insertion.
- In the past we have collected newly developed features until an agreement is reached within the dev team that now would be a good time to release. Release candidate clients are built and distributed to the dev team who test against the release candidate server in the full test environment. If they seem ok, they are released.
- We build on top of other libraries but do not attempt to take our own forks of them because of manpower and expertise limitations. (ie, I'd rather work on PS than CS, and don't know enough about CS anyway)
- Jilare has SVN access to the CS project and has worked with them to implement fixes we need
Now a little about our current direction :
- feature requests and bug reports will still be managed as they are at present.
- A Rapid-development (not truly 'Agile' but borrowing some from it) environment has already been setup that serves both as a second-level dev sandbox and build environment combined:
- provides daily client builds from the latest SVN, currently linux32 & 64 and windows 32. windows 64 and MacOS/X are in work
- provides daily server and npcclient builds from the latest svn.
- provides a safe sandbox for the development of scripts and other content (often descructive and involving lots of server restarts), as well as a place to debug the working npcclient and server.
- tests new functionality with more load and persistence than individual dev-environments.
[li]Once code, scripts and features are shown to be stable in the Rapid-development environment they will be promoted to the test server in incremental internal releases. There they will be tested against a copy of the prod database. - When a release is deemed good enough, the latest clients from the Rapid-development server should be easily moved to the update server.
This approach has already proven itself in both development of scripts and quests, as well as detecting and correcting clent crashes due to new code.
Next time I'll address the items above specifically.
-
1. Switch to SVN to git.
The biggest question is, given the size of our team, would we get enough benefit to make it worth the time and effort to convert ?
With our current approach each dev/prospect/contributor essentially takes an informal branch to build their local environment then the changes are merged back in manually by the reviewing dev. I'm not sure how formal branching would change things and my experiences with anything other than manual merges have been disastrous.
One final consideration, admittedly minor : we get a lot more project starts than completions. If we did a formal branch for each project we'd have a great many dead branches. I guess that's not really an issue for any source control system. It just feels untidy to me.
2. Separate repositories for client / server applications, libraries (like Cal3D), game content (restricted?), website, related projects (dev tools, default skins, etc.) - the smaller, the better.
Considering the high degree of sharing betweent the client, server and npcserver...how would we accomplish this without creating more work for ourselves?
Something I neglected to mention in my last post is that we do have seperate repositories for art, content, GM console, dev console, and other assets that are not open.
As for the libraries we depend on I think I addressed that in last post, but yes, what eonwind said:
Remember we're a little team and there's no way we can maintain forks of CS, we have PS devs with commit accesses in the CS repository and that's all we need right now.
3. Issue tracker, integrated with code repositories.
This would be very nice. I have begun referring to the flyspray issue number associated with the bug in commit notes. It's a poor substitute. Do you know of anything that integrates with SVN ? Better yet, would you be interested in investigating the possibility of tying our current bug track to our current sourc control system?
4. Unit tests, at least for some code parts.
This could be very helpful in detecting and preventing new bugs as well as driving stability into the code base. It is also an area in which I am very weak. If you would like to help us implement this, please, please, please apply as a prospect. I will be overjoyed to enable your work on it.
5. Automatic build system for main development platforms (simplifies testing).
(addressed in my last post)
So of the 5 issues: agree and already moving on 1, agree and open to help on 2 others, lack resources and recognition of benefits on the final 2. Hey, we agree on 3/5, that's a winning score! ;)
It's not as good as the first writeup I did (and lost) but I think that's a pretty thorough basis for further conversation. Thoughts?
-
Regarding unit testing, I've done some in java with junit and found that while very useful, you end up writing tests for each and every method/function and the tests are only as good as you make them. Ie. A test might test basic functionality (does it compute for one set of parameters) or the range and scope of the function (does it work for any combination of parameters including zeros nulls max and min values). I'm curious about whether or not there is a better way of doing this in c/c++ or if this is just the price to pay for added assurance.
-
I do hope my long posts didn't kill this topic. :oops:
-
Thanks for detailed explanation, Eredin! :thumbup:
About repository separation again - the high degree of sharing between various applications could be resolved by creating a set of "core" libraries. In perspective, it could provide clean internal API and better testablity, IMHO.
But even in the current state, some stuff may be moved to separate repos: website, forum (well, maybe, just forum theme), default skins, public web art assets (think about something like "PS Fan Kit"). Definitely, there are more PS players with some web development skills, than with C++/CrystalSpace ones.
Also, it could be very helpful to have a public list of concrete missing art assets of the game, like: "We need a 3D model for two-handed sword. We need a texture of red wood." - plus concrete tech requirements. The bug tracker can be used to organize that.
-
This would be very nice. I have begun referring to the flyspray issue number associated with the bug in commit notes. It's a poor substitute. Do you know of anything that integrates with SVN ? Better yet, would you be interested in investigating the possibility of tying our current bug track to our current sourc control system?
AFAIK, FlySpray do not provides VCS integration out-of-the-box, even its latest version. But some others do, like TheBugGenie.
-
Also, it could be very helpful to have a public list of concrete missing art assets of the game, like: "We need a 3D model for two-handed sword. We need a texture of red wood." - plus concrete tech requirements. The bug tracker can be used to organize that.
Certainly helpful, but not that simple. Years ago, a big flaw in the organization of different departments was the lack of "inter-disciplinary communication". One example: A task to make an icon for an item called "Ruby Ring". Okay, make a metal ring containing a ruby ... wrong. Later in the quest I got to know that the ring was cut out of a huge ruby crystal. That looks completely different, of course. So before an prospect artist gets the task to make a model or texture, first the different departments need to collect enough base knowledge to enable the artist to understand enough of the context, without e.g. spoiling a whole quest where this item may be involved. The ABC license protects the game content as a whole. It is hard to release too many details before they are meant to be known in public...
-
Well, discommunication happens. Although, from your description, LigH, I understand how that "Ruby Ring" should look like - yet you don't spoiled anything. I think in most cases it is just about clear specifications, don't you agree?
I understand what closed art license is greatly influencing current development process, but... anyone who don't care about licenses could just open PlaneShift art and data dirs from released client and re-use the contents for any gods-known purpose. So at least client-side art assets are public (although, still under ABC). Most server-side text art (books and quests) could be "stolen" relatively easy (book could be saved to text file, NPC quest dialogs could be taken from logs, etc.) So I think about those assets as of public too.
On the basis of that, why don't make certain pieces of art public to allow developers to work on them openly? It's not about making another game on the PS base, nor I see anything about spoiling game content in ABC license (it's about Game policy 11).
-
The biggest question is, given the size of our team, would we get enough benefit to make it worth the time and effort to convert ?
With our current approach each dev/prospect/contributor essentially takes an informal branch to build their local environment then the changes are merged back in manually by the reviewing dev. I'm not sure how formal branching would change things and my experiences with anything other than manual merges have been disastrous.
You can actually convert from SVN to Git pretty easily nowadays. I believe Git can just check out the SVN repo and go from there. We migrated 100s of repos to Git at work and it didn't take too long.
One final consideration, admittedly minor : we get a lot more project starts than completions. If we did a formal branch for each project we'd have a great many dead branches. I guess that's not really an issue for any source control system. It just feels untidy to me.
You could have devs do local branches for their features/fixes. The branches are only on their machines until they get pushed up to the Git repo. You could also handle this the same way we do at work where you create a feature branch locally and just push to any branch of your choice.
Considering the high degree of sharing betweent the client, server and npcserver...how would we accomplish this without creating more work for ourselves?
You use some tool that has dependency management, like Maven, and have it pull down dependencies as part of the build. You can also modify those projects locally, push a locally modified version to a local Maven, and then the local builds for Planeshift would pull down the new version
This would be very nice. I have begun referring to the flyspray issue number associated with the bug in commit notes. It's a poor substitute. Do you know of anything that integrates with SVN ? Better yet, would you be interested in investigating the possibility of tying our current bug track to our current sourc control system?
I'm not sure of anything that integrates well with SVN. Honestly, I'm not sure of what integrates well with Git off the top of my head. I've used Pivotal and RTC. Of the two, I prefer Pivotal, but the only way to tie it together with the SCM system was through a build tool called AnthillPro and it's not free. A free alternative would be something like Jenkins, but you've already discussed automated build systems
Regarding unit testing, I've done some in java with junit and found that while very useful, you end up writing tests for each and every method/function and the tests are only as good as you make them. Ie. A test might test basic functionality (does it compute for one set of parameters) or the range and scope of the function (does it work for any combination of parameters including zeros nulls max and min values). I'm curious about whether or not there is a better way of doing this in c/c++ or if this is just the price to pay for added assurance.
I'm pretty sure what you describe with unit testing is exactly how it should be. Your methods should be easily testable to prove out that they do whatever minor function they have been designed to handle. You could add in libraries like Mockito to mock out full objects and test behavior based on mocked input/fields. You want as much code coverage as you can get and tests should be short and simple, whenever possible
All of this being said, it sounds like the team is a lot smaller than I expected and it's probably not worth the time and effort to change things right now, but it's something that could be considered if more people got on board.
Sorry my reply was so late. I stopped getting emails about replies for some reason
-
I am going to try to answer to this point by point by expanding the excellent considerations from Eonwind, Eredin and Serneum. I tend to write too much and this is a thread with a broad topic so I apologize in advance for the wall of text :P .
1) In general, I agree with Eredin on this one. Git is great to implement the feature branch workflow, but given the size of the team and the fact that each developer works on a single feature, this wouldn't provide a great benefit right now. But it would make sense to switch to git if we decided to completely change platform and migrate the code to github (as suggested by redhound). Github has the advantage of making the "fork and pull request" workflow very easy which IMHO fits very well the current PS development process and adds few advantages:
- It's clean: instead of creating a lot of branches in the main repo, the prospect/anybody can create a copy of the repository in its own github account, and if he drops the task he doesn't leave dead branches anywhere.
- The pull request is basically a work-in-progress patch. Github creates an open discussion associated with each pull request and anybody is able to check the current changes in the code and suggests modifications to add to the pull requests on-the-fly. Once everything is ready, a member of the official team can merge the pull request into the main repo.
- The main repo remains clean. Each feature requires several commits, and (especially for complicated features) there can be commits that introduce bugs and break the build of the main repo. The pull request is merged only at the end, so this possibility is greatly reduced.
- The project would never miss a bit of a contribution. Working on its own online repo, a prospect can make as many commits as he wants instead of creating big monolitic patches. If he drops the task, those small contributions are not lost because github creates a local copy when a pull request is submitted, so they can be merged and picked up by someone else.
Moreover
- On github there is a fully-featured, easy-to-use issue tracker integrated with the repository.
- I don't have numbers, but I have been involved in several projects using svn and git, on sourceforge and github, and some developers tend to stay away from svn simply because they don't like it. Moreover, I have the feeling that the developers community is gradually moving to git and github in particular, so all the "kool kids" hang out there :P .
To sum up, I think moving to git not only would speed up and simplify the workflow, but also that it would be better suited to attract new developers (which is IMHO the killer advantage considering how much lack of "manpower" is slowing down PS ).
Ah, and as Serneum pointed out, moving an existing svn repo to git is very easy https://help.github.com/articles/importing-from-subversion/ (https://help.github.com/articles/importing-from-subversion/).
2) I agree with Eonwind on this one. There are many cases in which the same feature in order to be implemented touches multiple parts of the code: client, server and common libraries. Splitting them could make it difficult to track the changes in the history.
3) Everybody agrees on this one :) .
4) Unit testing is great and I loooove test-driven development \\o// . This being said, doing decently comprehensive testing in complex videogames is generally tricky. All the existing PS code has beed tested for many years in-game, so I'm not so sure that all the hours needed to write all the unit tests at once are worth being spent this way. Not to mention that writing tests is crazy boring and it would be hard to keep a coder motivated on this project :P . Also, unit tests work best when they are written by the same person who writes the code tested.
IMHO the best way to gradually introduce test-driven development in PS would be to assign to somebody the project of setting up the unit testing framework with a simple example. Then it is simply a matter of changing how contributions are accepted. When someone writes a patch with a new feature to be reviewed, a dev can ask him to add few tests about it. When a bug is fixed, a test can be written to ensure that there won't be any regression with future contributions. This way also the critical existing part of PS code would gradually be tested.
As a final consideration, PS is in the process of porting to a different engine (and a different repo). I think this is a great opportunity to start pointing the project in this direction. Unreal Engine also has its own testing framework https://docs.unrealengine.com/latest/INT/Programming/Automation/TechnicalGuide/index.html (https://docs.unrealengine.com/latest/INT/Programming/Automation/TechnicalGuide/index.html)
5) Eredin said it all :) .
I'm currently doing a big code refactoring of the music code, but once I'm done I could volunteer to help with github migration or with setting up the testing framework in the new repo in case you guys would be interested.
-
I'm currently doing a big code refactoring of the music code, but once I'm done I could volunteer to help with github migration or with setting up the testing framework in the new repo in case you guys would be interested.
that would be great :thumbup:
-
Sounds promising!
-
1) In general, I agree with Eredin on this one. Git is great to implement the feature branch workflow, but given the size of the team and the fact that each developer works on a single feature, this wouldn't provide a great benefit right now. But it would make sense to switch to git if we decided to completely change platform and migrate the code to github (as suggested by redhound). Github has the advantage of making the "fork and pull request" workflow very easy which IMHO fits very well the current PS development process and adds few advantages:
- It's clean: instead of creating a lot of branches in the main repo, the prospect/anybody can create a copy of the repository in its own github account, and if he drops the task he doesn't leave dead branches anywhere.
- The pull request is basically a work-in-progress patch. Github creates an open discussion associated with each pull request and anybody is able to check the current changes in the code and suggests modifications to add to the pull requests on-the-fly. Once everything is ready, a member of the official team can merge the pull request into the main repo.
- The main repo remains clean. Each feature requires several commits, and (especially for complicated features) there can be commits that introduce bugs and break the build of the main repo. The pull request is merged only at the end, so this possibility is greatly reduced.
- The project would never miss a bit of a contribution. Working on its own online repo, a prospect can make as many commits as he wants instead of creating big monolitic patches. If he drops the task, those small contributions are not lost because github creates a local copy when a pull request is submitted, so they can be merged and picked up by someone else.
Moreover
- On github there is a fully-featured, easy-to-use issue tracker integrated with the repository.
- I don't have numbers, but I have been involved in several projects using svn and git, on sourceforge and github, and some developers tend to stay away from svn simply because they don't like it. Moreover, I have the feeling that the developers community is gradually moving to git and github in particular, so all the "kool kids" hang out there :P .
To sum up, I think moving to git not only would speed up and simplify the workflow, but also that it would be better suited to attract new developers (which is IMHO the killer advantage considering how much lack of "manpower" is slowing down PS ).
Ah, and as Serneum pointed out, moving an existing svn repo to git is very easy https://help.github.com/articles/importing-from-subversion/ (https://help.github.com/articles/importing-from-subversion/).
Agreed. In fact, everyone could contribute to the game more easily with git.
-
So, any news about changes in PS development process? Maybe there are some planned changes in moving source code or bug tracker to the new platform, using continuous integration, etc.?
-
Just want to suggest the new item to the list of services to consider. The GitLab.com SaaS (https://about.gitlab.com/gitlab-com) looks very promising - along with unlimited number of free private or public git code repositories with issue tracker and wiki, it also offers unlimited number of team members and free CI services.
For those who don't already know, Neeno is hosting there PSExtended client (https://gitlab.com/GreatShift/PSExtended) and also the last compatible version of the CrystalSpace 3D engine with PlaneShift (https://gitlab.com/GreatShift/CrystalSpace3D).
-
TLDR: No updates.
As you may or may not already know, the development team has gotten a little smaller still, and half of the effort is probably going into unreal, not the current SVN code. I personally don't see any advantage of using GIT over SVN for the current team in the current situation, though it might happen with unreal (yep, speculation).
As for the unit tests, it's probably really simple, as long as no one writes them, we won't get them. Yes, there are advantages to them, but just like documentation, unit tests are hard to come by on a volunteer project.
Integrated bug trackers are really nice, but even they need someone to set them up, migrate all old stuff, etc. Currently, I don't see that happen for the current version of PS, that would also be something that could be set up a whole lot easier when we migrate to unreal (and would be starting on a whole new set of bugs/features anyway).
As it was said before, if anyone wants to contribute anything to the code, you are more than welcome to do so. If you need any additional information regarding that, come find me on IRC.
-
As you may or may not already know, the development team has gotten a little smaller still, and half of the effort is probably going into unreal, not the current SVN code.
Is this the same for future art assets? I just spent a week relearning Blender and am going to jump back into it, but I would really prefer optimizing assets for Unreal rather than something the game is going to switch away from eventually.
-
Is this the same for future art assets? I just spent a week relearning Blender and am going to jump back into it, but I would really prefer optimizing assets for Unreal rather than something the game is going to switch away from eventually.
Blender is a tool both CS and unreal can import from. The big real difference with unreal working with art models and animation is the pipeline to import them in game is shorter and there are more powerful tools work with them after they have been imported.
But still until there will be a working demo or version of PS on unreal everything made with unreal tools will be miles away from being usable on PS.
Therefore my suggestion is using blender and working for current PS, any art made developing with it will be usable by the new PS unreal engine anyway and it won't be trashed.
-
Let's hope the migration to Unreal will also brings some freshness into the development process also!
As you may or may not already know, the development team has gotten a little smaller still, and half of the effort is probably going into unreal, not the current SVN code. I personally don't see any advantage of using GIT over SVN for the current team in the current situation, though it might happen with unreal (yep, speculation).
Well, that depends on what we call "the team". Moving code to some kind of git-enabled public service and allowing peoples outside the core team to make pull requests will effectively make "small team" somewhat larger (an example: https://github.com/OpenMW/openmw/graphs/contributors). And it's all about the code, so there are always things to make better: https://github.com/arx/ArxLibertatis/commits/master - always, I really mean it.
-
Well, this thread looks dead, but for posterity...
I have several years experience building large-scale enterprise applications. In my experience:
* Git: Yes. Branching is a very good thing. Dead branches are the best place to put false starts anyway and often provide inspiration for new branches. Not everything makes it back to master, and it shouldn't.
* Issue Tracking: Yes. Github can provide some of this. Even their simple issue tracker keeps things moving along and all major open source projects (think Apache Foundation) use issue tracking and release management.
* Nightly builds: Yes. Jenkins is fine and Travis integrates with Github for a small fee. As a non-profit, it would probably be free. This is one of the best ways to enforce good coding practices.
* Unit tests: Well, duh, yes.
Another thing, issue tracking allows people (like me) with an interest but not a lot of time to jump in and participate. I asked how to contribute the other day and there were only "big lifts" available. The new generations of developers (whom it would be nice to attract) think in terms of agile build/deployment cycles, issue tracking and code review. Those are good things.
Thought I haven't the time to manage it, I'd be happy to participate in both product and project mgmt, and throw in some code now and then.
-
Well, since I'm getting indirectly quoted, lets add another reply.
We have issue tracking already ( http://www.hydlaaplaza.com/flyspray/ (http://www.hydlaaplaza.com/flyspray/) ). Most of the issues there are "small fixes", and you (or anyone else) is welcome to make them, and send them my way. If they check out, they'll be added to the code, and you'll be mentioned in the commit notes/etc.
However, you specifically asked for Unreal porting tasks the other day, and that indeed has currently need for people who have more time to lay a proper foundation. So just be clear, there is plenty to do, even for people with less time. Also any non-coders are more than welcome to join our settings and rules teams (if you are interested, come ask about it on IRC).
-
I work in a company whose main product is open source - it's vital for us to keep in touch with the community. One of our measures for success is actually how many open source contributors we can get.
You don't fish in an empty pond, you go to where the fish are.
github is where the open source developers are.
https://www.google.com/trends/explore#q=svn%2C%20git&cmpt=q&tz=Etc%2FGMT%2B4