GSoC: Proposal
Max
I have been eyeing this project for some time now and finally decided
to chime in with a proposal. This is not the official one, so I'm just
listing some ideas I'm willing to implement to see if you might be
interested. So, here goes:
1-Insure portability through. I have used the package successfully on
Kubuntu & Windows XP, so this area might not be in need of much
improvement, but it's still a consideration for any future additions.
2-A clear and clean separation between the car's functionality and the
drawing routines. Right now there's pretty much just the update()
method on the car that takes care of it, but I imagine when the
project grows there will be bigger considerations. This also makes a
transition to 3D visuals that might come at some point in the future
much easier.
3-Non-car objects - trees, those wossnames (orange-conelike-things-
that-cars-shouldn't-touch), etc. These would allow maps to be
composited easier, since objects could be reused directly from inside
the engine. Like the rest of my ideas, this helps translation to 3D
since this way not every map would have to be redone from scratch.
4-Sensors. This would include pixel sensors and distance-from-pixel
sensors that are mentioned on the ideas page, as well as object
sensors. These last ones might simplify some tasks, but they certainly
make more sense if the graphics are translated to 3D and we can always
introduce some requirements for using them to force the user to use
both these and the pixel sensors - these requirements might be a more
strict distance limit, or perhaps a chance of failure (robots don't
have perfect recognition engines).
5-A basic 3D graphics engine (what you call 2.5D on the vision page, I
believe). The interactions (mainly collision) would still be modelled
on a plain 2D map, but the graphics would be 3D. I have not done any
3D apps in Python yet, but I have some experience with implementing
basic 3D engines using D3D API in VB6 & C++ so I imagine I can pick up
quite enough skills to implement such an engine (or use an existing
one?) in Python during GSoC's 3-month timeframe.
6-Improve visuals. I have basic 3D modelling and texturing skills
(I'll supply examples and such in the official app) and I can probably
do some borderline-usable flat 2D graphics as well if we're to
continue on that route.
7-A last but fairly important point would be to design the API specs
before any work begins and stick to them all throughout the project to
keep it from getting too complex from the user's side.
So that's about all I can offer. I'd love to hear your opinion on
these and whether you suggest I apply officially with this feature
set.
Regards,
Max
Toby Donaldson
Thanks for your interest in carcode. Here are my comments on your
application, which seems quite good:
1. Be specific here. Carcode needs to have a super-easy installation
on at least Ubuntu (the platform I use), and Windows, and other
platforms. Ideally, just replace this point with a commitment to
resolve this issue:
http://code.google.com/p/carcode/issues/detail?id=1
2. This seems like it might be pre-mature to me, since at the moment
there is no specific need for this ... I would move this to the end
and only do it if you run out of other things to work on.
3. Non-car objects sounds good. Give a few more details, e.g. what
exactly the objects, if they will have "moving parts" (it's fine it
they don't), and what happens if the car runs into them.
4. Adding sensors is important, and I am glad that you included this.
In fact, my main interest is in writing code to make these cars
navigate the environment autonomously, like robot cards. It needs to
be made clear how the sensors interact with the background and
objects. Having special sensors for objects is interesting idea that
hadn't occurred to me.
5, 6. Moving to 3D is a big project, and probably a project on its
own. So I would suggest leaving that out, or at least putting it at
the very end. For now, improving the graphics through pygame would be
most welcome, such as making the cars look more like cars.
7. Yes, the API for users is important, and needs to be designed
carefully. However, that can done in parellel with the development of
other features. That is, you can add whatever functions you need to
get things working, and then later a simplified beginner-friendly
layer can be added on top. So I think it is okay to leave this step to
the end, and combine it with creating tutorial examples and tasks
(e.g. a series of increasingly challenging coding tasks leading to a
carcode "driver's license").
Anyways, it seems like a good application ... it is nice to see you
mention your experience with other software (many applicants don't do
that).
Also, the more specific and concrete details you can mention about how
you plan to get these things done, the better. Your application will
be reviewed and rated by all the Python Software Foundation mentors,
and most are professional programmers treating these applications as
if they were applying for a job to work for their company.
Toby
--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)
Max
Thanks for your reply.
1-Well, I have experience creating installers only on Windows so I can
take care of that for sure, and knowing Linux I'm sure there's quite
enough utilities that can make the installer generation process easy.
In short, yeah, I can commit to making an installer for each supported
system.
2-I understand your concern but I'm sure that this wouldn't take more
than a day or two, and make working on different parts of the system
much easier in the future. What I'm thinking is pretty basic: making
each entity (arena, car, object) either own or be derived (perhaps
through multiple inheritance) from a renderer object which would
reside in its own file and handle anything connected to the graphics
(ie the sprite/model, the drawing part of the update() function,
etc.). This way we can work on fucntionality without touching the
graphics, and likewise work on graphics without touching the
functionality.
3-Currently my plans don't include any animated objects but that's
certainly a possibility. What I'm thinking about is a tree that looks
something like this (excuse the silly name):
-Thing (base object, would implement basic creation, own a
renderer, etc.)
---StaticThing (anything that does not interact with the car in any
way - may be merged with the base Thing)
---BlockingThing (objects which the car can never pass - ie.
fences, may implement some kind of action on collision)
---PassableThing (objects which the car can drive over but that
detect such collision and respond to it - maybe deduct points, change
the sprite/model, etc.)
---ActiveThing (objects that move around (along a simple path) and
interact with the car - mainly pedestrians)
4-Agreed. I have played around with very simple robot kits and sensors
are definitely very fun to work with.
5-I have to disagree somewhat with the opinion that moving to 3D
graphics (rather than 3D space) is a such a big change. The hard parts
of 3D is interaction; rendering basic scenes - especially using an
engine like pyglet - is just a matter of positioning models, setting
up the camera/projection matrix, very basic directional lighting and a
main loop. As long as we keep everything but the graphics in 2D it
shouldn't be that complex.
7-Well, I guess since it doesn't have to be backward compatible it's
not such a big problem, but I would still like to get a basic design
document for it before starting.
I'll try to get an official application in later today (well,
technically tomorrow for me).
Thanks.
Regards,
Max
Max
Sorry for the double-post/mail. I have submitted an official
application with some more details. If you have a free minute, I'd be
grateful if you could take a look at it. The full document is
available at:
http://vault.max99x.com/application_carcode.htm
Thanks.
Regards,
Max
Toby Donaldson
Your suggestions all sound reasonable to me. I don't have enough
experience with 3D modelling to have a precise idea how much effort it
takes, but being pessimistic is often wise, since it can cover
unexpected technical difficulties, learning, polishing, etc.
Also, while thinking about things learners are asked to do in drivers
tests, I realized recognizing two-point and three-point turns would be
useful.
Toby
Max
I do agree that it's best to account for the worst turn of events,
which is why I ended up putting the "move to 3D" part as optional in
my official application. I still hope to do it, but I'll have to
concentrate on the rest of the project, and only if I manage to finish
that before the time is up, I would proceed to trying to move it over
to 3D. Of course there's always the time after GSoC if I end up not
having any extra time.
As for your note about recognizing the different kind of turns, it is
certainly a valid point. I believe the easiest and most flexible
solution is to handle them in a given map's winning conditions rather
than building one into the core. For example a map file to check for a
two-point turn may look like this (using the system I described in the
linked application):
----------------------------------------------------
startingPosition = (15, 0)
mainRoad = PassableThing(sprite = 'res/road_wide.png', x = 0, y = 0)
sideRoad = PassableThing(sprite = 'res/road.png', x = 10, y = 40)
things = [mainRoad, sideRoad]
#Must be on the main road, facing 0 degrees (north) and "above" the
side road
winConditions[0] = [('ON', mainRoad), ('DIRECTION', 0), ('NORTH',
60)]
#Must be on the side road, facing 270 degrees (west)
winConditions[1] = [('ON', sideRoad), ('DIRECTION', 270)]
#Must be on the side road, facing 180 degrees (south) "below" the side
road
winConditions[2] = [('ON', mainRoad), ('DIRECTION', 180), ('SOUTH',
40)]
#Loss if on neither of the road tiles
lossConditions[0] = [('NOT_ON', mainRoad), ('NOT_ON', sideRoad)]
#Must finish all winConditions in order to win
winConditionType = STEPS
----------------------------------------------------
To make it clearer:
1-Initial positions: http://vault.max99x.com/carcode1.png
2-winConditions[0] acomplished: http://vault.max99x.com/carcode2.png
3-winConditions[1] acomplished: http://vault.max99x.com/carcode3.png
4-winConditions[2] acomplished: http://vault.max99x.com/carcode4.png
This is all processed by the engine as bite-sized chunks, and is
pretty easy to write and modify, while still accomplishing the
detection of the turn. Of course it is tied to certain tiles, but I
believe in practice we wouldn't need to detect the manoeuvre on
arbitrary point of the map, but rather on a predefined one.
Regards,
Max