I'd be willing to come up with an application for us if we manage to gather some project ideas and find some (mostly engine) developers as mentors.
Generally, I am very much for this idea and I'd try to support you as much as possible. However, for the application process, I can not help so much because until mid of March I am very busy with my bachelor thesis. After that, I will be in Middle America until May. When I'm back, I could probably help more f.e. act as a mentor.
I have to admit that I'm currently not very well informed about Google Summer of Code, what are the prerequisites, what kind of projects these have to be etc. I'll read their FAQ ASAP and give further comments then.
I think some of the foundations for Peter's settlement/base concept need some changes and new features in the engine. These prerequisites might be packaged into (several) projects. Also, some long-open issues in the bugtracker could be made into small projects (as they are not just bugs but bigger missing features): F.e. DX-support.
> Hmm, I feel that this is a topic which should be managed in the internal forum in detail.
Well, probably you know how I think about internal discussions. :)
> A person or group responsible for review and ranking of student applications, both those proposals which tie into the org's Ideas list and "blue-sky" proposals
> A person or group responsible for taking over for a student's assigned mentor in the event they are unable to continue mentoring, e.g. take a vacation, have a family emergency
> A person or group of people responsible for monitoring the progress of each accepted student and to mentor her/him as the project progresses
[1]
So, basically... more mentors and a pool of people who could jump in if something unexpected happens.
>3. What language(s) should a student program in?
>Talk with your mentoring organization about this and other technical style questions. Of course, the Python people will prefer Python submissions, and so on. Students should let us know in their applications what languages they're thinking about using.
Also, it is possible to post project ideas into the ideas list that are for programming in C4Script! I can think of quite a few projects that can be done in C4Script. F.e. this.
Also, note this:
7. Can students already working on an open source project continue to work on it as part of Google Summer of Code?
>Google will provide a stipend of 5500 USD per accepted student developer, of which 5000 USD goes to the student and 500 USD goes to the mentoring organization.
This is quite a lot. (It's like an OK paid student part time job of 16h per week for 4-5 months, IMO) I wonder, perhaps CK has bigger insight into this, how and where does the actual size (effort) of a project idea get evaluated? I mean, nobody will spend part-time 4 months to implement DirectX for mesh rendering. But if I understood it right, one accepted student does only one project? So do we need to create project ideas of a certain size or what?
>Also, note this: 7. Can students already working on an open source project continue to work on it as part of Google Summer of Code?
The relationship between the student and the mentoring organization should be mentioned beforehand, My guess is that they won't accept a student who is also part of the development team of the mentoring organization.
Regarding C4Script a combination between C++ and C4Script to implement content menus would also be a good project.
First sub-goal could be to re-wrap the Message functions using that.
e.g. http://www.gamecitylab.haw-hamburg.de/ or a international institution
1. rework the console/edit mode, specifically the properties window of objects. I don't know how it looks in GTK+ but Günther told me that it looks completely different. Perhaps future versions of the properties window should be realised on the same code basis, thus dumping the native windows frontend with a gtk+ frontend.
2. fix/enhance the Fog of war. If zoomed in and out, the fog just looks weird (view range is dependent on how one zoomed out), additionally it flickers all the time (especially while zooming). Also, it could be possible to completely rework the fog to be super-smooth (no idea how to do that).
Since I am not really an expert in any of the two areas, I don't really know what to write.
Please everyone feel free to add own ideas and/or to add yourself as a mentor to existing projects. It would be great if we had at least two mentors for each project so that we are not lost if one of them gets very busy (for example I have to hand in my thesis at the end of July).
Also we need a backup "organization administrator" (assuming I am the primary one). The organization administrator is the primary contact person for Google. Any volunteers?
On support: I am willing to help anybody that wants to do something in the engine, so I guess I could "mentor". The settlement concept is still pretty much in discussion, and will just be a boring concept-to-code-translation once we are through with it. I wouldn't recommend that to anyone.
To be constructive, here's two things that I could see a newcomer handling:
* Find a better way to encode menus. Do away with all the crappy CreateMenu stuff and build something nice from proplists. Ideally flexible enough to have user-defined layout, some basic interaction methods, etc. As we would throw the old interface away completely, this means someone wouldn't really have to bother about learning the details of the old Clonk menus. Basing in on top of Sven's GUI primitives could make this a fairly straightforward wrapper task. Interaction is a bit problematic, as it should work asynchronously.
* Finish implementing the landscape zoom shader. Could probably really use some fresh ideas from someone that has experience dealing with shaders. Landscape basics are easy enough to learn, and C4Landscape should be in good enough shape that new coders wouldn't be caught in too many traps (at least everything goes through _SetPix & co now). At least in case this won't instantly get obsoleted by polygons.
* More colorful messages
* Aim arrows, trajectory previews
* All HUDs
* Menus (obviously)
Right now you'd have to use clunky objects to emulate that. Using a simple proplist to say "draw that picture there and fill this and that with $BGColor and put a button here which closes the whole thing" would save you lots of headaches and could work better because we could shy away a bit from strict synchronization.
Note though that I wouldn't really want to directly "expose" the GUI classes - we won't be able to cover them all, so we should better think separately about how the script interface should look like.
> I don't want to sabotage anything, just want to set expectations straight
OK, I just meant that a discussion about this topic would be counter-productive now.
That the shader gets obsoleted by polygons will not happen anytime soon. There are many unsolved/unimplemented problems left like fluid simulation, general optimizations, snow (single pixels added/removed) and more.
Maybe show some screenshots and explain the current state of development where it's possible. Add sketches of what stuff could look like or provide to threads in the forum containing something alike.
I'd suggest a parent article as well, containing and summarising every information needed by Google. Give it a direct link from the menu bar.
Every mentor should give a personal introduction as well as we need to name an administrators and backup administrator. I will proceed writing after lunch.
> Finish implementing the landscape zoom shader.
Actually I was hoping you'd say that :D. I added this to the ideas page.
> On support: I am willing to help anybody that wants to do something in the engine, so I guess I could "mentor".
Great, I also added you as a secondary mentor to the first three ideas.
> Great, I also added you as a secondary mentor to the first three ideas.
Well, I'm willing, but not necessarily qualified. I know next to nothing about how all the rendering works. When in doubt, that was Sven's job :)
> Well, I'm willing, but not necessarily qualified. I know next to nothing about how all the rendering works.
But you know where to look, right? :)
I think that's OK and I don't think I will become unavailable for a larger amount of time anyway. But I think it's nice to have a backup mentor just in case.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill