Skip to main content Link Menu Expand (external link) Document Search Copy Copied
YouTube Logo Google Group Logo Facebook Logo Twitter Logo

Ideas Page for Google Summer of Code 2016

We are thrilled to share our carefully curated project ideas for this year’s Google Summer of Code.

Idea Overview

General Knowledge Prerequisites for all Projects

  • Knowledge in the usage of Git and GitHub
  • Basic knowledge in the concepts of software testing (e.g., test doubles) and test-driven development
  • Basic knowledge in app development (for Android and iOS projects)
  • Java, JUnit, Mockito, Robotium and Espresso for Android development
  • Swift and Objective C for iOS development
  • Also please check that you have the proper hardware for the development (e.g., a Android/iOS smartphone for testing, Mac for iOS development)

Project Descriptions

Raspberry Pi Feature extension

Brief explanation and expected results:

  1. use GPIO pins: set pin, read pin, set PWM values
  2. Extend Raspberry Pi Features
    • sensors: allow to attach several sensors which can be enabled/configured within the preferences (I2C, onewire bus, thermometer, microphone, …)
    • actors: allow to attach several (more complex) actors and configure them via preferences (IR-sender, …) -> see sensor/actor examples
    • play sounds on RaspberryPi
    • run user-defined scripts on RaspberryPi
    • encrypted communication (TLS)
    • allow to use multiple RPi’s
    • attach a camera on a RaspberryPi, add commands to take a photo and use it within Pocket Code
    • attach a display on a RaspberryPi, make it available in Pocket Code
    • add a discovery protocol to the RPi: Avahi/Zeroconf/Bonjour
    • use HDMI output of RaspberryPi (similar to chromecast project).
  3. Demo application: build a small Robot using Raspberry Pi (including a tutorial)

Possible Mentors:

  • Roland Urbano

Social Media Features

Brief explanation and expected results:

List of diverse social media features:

  1. “Upload & share” of Pocket Code programs (existing upload functionality + user-defined post on Facebook/Google+ with link to the program)
  2. Social Challenging System: After “Upload & Share” functionality a challenging system can be build: Add a possibility to challenge friends with games directly created in Pocket Code (e.g. with a highscore displayed by Show-/Hide-Variable Bricks) via in-app notifications. This should include a link to the uploaded program and a short text.
  3. Create a possibility to add looks and sounds from flickR (Creative Commons content), Picasa, Facebook (via Facebook Graph API) and Instagram.
  4. Likes & Sharing of programs on the Pocket Code website (pocketcode.org) (UX guidelines already existing).
  5. Add more social media platforms: e.g. Twitter, Instagram, WhatsApp (depending on the social media platform-related activities of Pocket Code’s target group, which is currently being analyzed).
  6. Facebook & Google+-Login for iOS

Possible Mentors:

  • Annemarie Harzl

Brief explanation and expected results:

The feature/brickUI branch is waiting to get implemented. It will improve our usage of Android, removes a lot of code, eases new brick creating and also any adaption (and fixes) in bricks will be more quickly and less error-prone.

In detail: This feature branch separates the bricks from the UI. The whole logic will be located in the fragments, adapts classes and in the ViewProviders of the bricks. All checkboxes will be replaced by checkable layout and therefore the test classes have to change as well. Especially all brick related tests must be refactored and it is recommended to change them to espresso tests.

Currently there are a lot of JIRA tickets waiting to get fixed and implemented. Fixing refactoring tickets will fix other bugs and ease testing automatically, improving the overall quality. Choosing a proper Student and Mentor is essential. The existing JIRA tickets

  • recommend test refactoring or implementation of missing test classes
  • concern with performance and code quality issues or inconsistancies
  • clean up and fixes e.g. packages and certain files like format of XML files
  • include checkstyle rules for naming conventions, code formatting issues etc.

Possible Mentors:

  • Robert Painsi

Groups & Scenes in Pocket Code

Brief explanation and expected results:

Object grouping:

Object grouping is a feature to structure one’s Pocket Code program at object level. The purpose of introducing object grouping is to keep them together and make the object view more concise and overseeable. The depths of groups is limited to 1 which means there no nested groups (subgroups) are possible. A group is like an object but it can be expanded and collapsed to either show its containing objects or hide them. A group looks like an object with the only difference that it has an expand/collapse widget. The group’s icon is inherited from the first object in the list of containing objects. The selected group could be coloured in a different way.

Scenes:

The introduction of “scenes” in Pocket Code should ease the creation of large programs by abstraction of semantically coupled objects including code, looks and sounds into independent sub units. This makes programming of different scenes (levels) of a game insofar easier that only those backgrounds and objects which are used in this particular scene (level) are active, can be accessed by scripts and are subject to execution. A scene can be seen as an independent Pocket Code program. A Pocket Code program containing scenes can be seen as a collection of independent Pocket Code programs (scenes) where a smooth transition is possible during program execution

Possible Mentors:

  • Christian Schindler

Pocket Code Usability improvements

Brief explanation and expected results:

To create a better user experience and improve the navigation in Pocket Code, some usability improvements should be implemented in the project. The main points of these improvements refer to the quality of the navigation in the Pocket Code app, programming with Pocket Code, other points for representation and new Bricks.

Navigation:

  • remain at the same place in the menu (e.g. script view, list of objects/programs, …) after having switched to some other place or deleting an element of the list
  • rename the current program
  • graphical hints/toasts, like a long press dialog to show the opportunity to use long press and find more functionality
  • swipe gesture to switch between program overview and current program or to switch between scripts and hints
  • change the behaviour of short-/longpress on bricks for moving a brick or opening the brick menu

Programming:

  • send variables within messages to improve the interaction between objects
  • re-organization of the control bricks to separate events from other control bricks (improve the overview of the bricks)
  • moving an “if-statement” should move the whole if-block
  • showing also the value of a local variable on the stage
  • set the color and size of the shown variable on the stage

Representation:

  • remove the colon after variable names
  • possibility to show long comments within the note brick
  • show project details like description, author, screen resolution, …
  • increase the limit of the length of a text that should be shown at the stage

New Bricks and Loops:

When working with pupils/students in our workshops it has been shown that some more features are required in Pocket Code to improve the experience with Pocke Code. Therefore new bricks should be implemented in the project:

  • wait until / repeat until

With these bricks its easier to create loops or sleeps with a termination condition. This could be essential e.g. for making games, where you often have to wait or repeat something until a condition occurs.

  • if then (without else)

Create a separate if-brick without an else brick, like we know it from common programming languages. This brick increases the overview of the bricks, especially with some encapsulated if-conditions.

  • switch to previous look

Like the brick “next look” there should be a brick “previous look” to switch also backwards in the list with the different looks for an object.

  • switch backdrop to ___

With this brick it’s possible to change the backdrop without using a broadcast-message from an object to the background.

Possible Mentors:

  • Anja Petri

Feature Completeness (Scratch)

Brief explanation and expected results:

There are still several bricks and features which are available in Scratch, but not in Pocket Code. First, These features and bricks are needed to have an more improved programming experience and second in order to have a working Scratch2Catrobat programs converter. // The following features and bricks will be part of this project:

Pen/Stamp:

Pocket Code is missing the pen bricks from Scratch. The aim of this project is to implement these missing bricks. Pen blocks in Scratch 2.0 are used to draw something on the screen, much like in Turtle graphics. There are eleven bricks in this category. Pen bricks allow to take various actions:- Stamp the sprite - Put the pen down - Release the pen // One example of a one sprite one script project is a simple drawing program. See http://wiki.scratch.mit.edu/wiki/Pen_Blocks

Cloning:

Cloning in Scratch 2.0 is a feature that allows a sprite to create a clone, or duplicate, of itself, while the project is running. This can be useful in tower defense games, for example, for a wave of objects. Clones of a sprite will be the same as the original, or parent sprite, but as a separate instance (see http://wiki.scratch.mit.edu/wiki/Cloning). 3 additional bricks are required - these bricks are “create a clone”, “delete clone” and as script brick “when I start as clone”, just like in Scratch.

Object collision / with color / movement:

To detect collisions between object is an essential game element - every shooter, race or skill game needs this feature. There are three different kinds of collision detections planned:

  • (touches) with other object: like in Scratch: Brick “touching finger/edge/object”,
  • object collision (touches) with certain color e.g. like in Scratch: Brick “touching color___”,
  • Camera look in combination with movement, extension: camera onsprite/onstage (see Scratch)

Ask Brick:

Possibility to have a text input field in state. The user can reply to this answer via the text input field. After that this answer is stored in a program variable (like in Scratch, Brick: “Ask____” + answer)

Missing Bricks:

To ensure brick completeness with Scratch the following bricks are missing:

  • Move Brick: “go to ____” - finger/object
  • Sensing Brick: “distance to ____” - finger/object
  • Sensing Brick: timer + reset timer (timer is a variable in FE)
  • Sensing Brick: current (minute, month, date,….)
  • Look Brick: change/set color
  • Move Brick: set rotation style: don’t rotate, left-right, all-around

Possible Mentors:

  • Bernadette Spieler
  • Thomas Hirsch

HTML5 Player Release

Brief explanation and expected results:

HTML5 Player first release.

  • Testing Sprites, RenderingImage, Canvas GameEngine, Device
  • Find and fix issues with Sprite positioning on the canvas
  • Support for device sensors, testing
  • Testing User Interface
  • Testing Sensor Bricks for upcoming catrobat releases
  • Handle compatibility issues with certain audio formats

Possible Mentors:

  • Annemarie Harzl

Remixes Web

Brief explanation and expected results:

Feature to split remixed programs into their components.

  • In Pocket Code, a remixed program is the result of two parent programs which were used by a student to craft a hybrid version of these two programs.
  • The aim of this project is to properly split the result of the remix process into its two parent programs.
  • Analyze components
  • Match contained objects with the ones of the original programs
  • Split remix apart
  • Testing

Possible Mentors:

  • Marko Burazer

Gamepad / Overlay

Brief explanation and expected results:

The idea behind this feature is that the the user can create a game or app with additional gamepad controls. While playing their game an overlay gamepad is used to control the movements. To minimize view obstruction by the overlay joy-pad, it would only be visible if the user taps screen. The joy-pad location would be determined by each tap and the following gesture (e.g.: swipe up) would be taken as the movement. When the screen is not tapped the joy-pad would be almost transparent.

Possible Mentors:

  • Thomas Schranz

Screen touched (Single Finger) & Multi-touch finger positions

Brief explanation and expected results:

New sensor variable is to be developed indicating if a finger currently touching the display and representing x- and y-position of the finger currently touching the display. The sensor names are:

  • is_finger_touching
  • finger_x
  • finger_y

If more than one finger is touching the display the is_finger_touching is true until ALL fingers are removed from the display. If more than one finger is touching the display the x and y coordinates of the finger which hit the surface last will be stored in finger_x and finger_y Implement multitouch recognition and the use of current finger positions as sensor values. Furthermore basic gesture recognition (e.g.: swipe up) could also be implemented allowing the users to create more complex and fun games and apps.

Possible Mentors:

  • Matthias Müller

Expert Mode for Pocket Code

Brief explanation and expected results:

Experts or people that are spending a lot of time in Pocket Code or with larg projects will benefit from the following options:

Bricks 2D:

This feature is a “Mission Control” view mode. Each object has a set of scripts which can only be scrolled through at the moment. This list can easily get long and very difficult to overview. A two finger pinch inward gesture (zoom out) would be used to enable this view, where all the scripts would be displayed side by side on one screen. By tapping anywhere or a two pinch outward gesture (zoom in) would take the user back to the original view. Fluid animations would ensure a smooth look.

Comment out:

Each object has a set of scripts that define its behaviour. This “comment out” feature would allow to disable a script and make it visually distinguishable from the active ones. This would mean that the users would no longer have to delete a script if they would want to temporarily disable it.

Debug Mode:

When pausing the game a new “enable debug mode” button would display a set of useful information. This includes variable values, sensor data and the momentarily executed scripts. Additionally a step by step code execution could be implemented.

Possible Mentors:

  • David Marogy

Pocket Code - Integrate S2C

Brief explanation and expected results:

The ScratchToCatrobat converter is one of our most important undertakings and exists to fill the gap between the well known Scratch system and our Pocket Code project. It empowers kids to run their self-made Scratch projects on their own phone. Our converter service is hosted on one of our servers that provides a very simplistic web interface for our users. In order to convert a Scratch program users have to perform the following steps:

  1. search for a program on the Scratch website
  2. visit the webpage of our converter server on their phone/tablet device
  3. enter the URL or project ID of the Scratch project
  4. Download the converted Catrobat program and open it with Pocket Code

This workflow is very cumbersome/tedious for users and requires using at least two different apps (browser and Pocket Code) which leads to unwanted media disruptions. Tasks for this project:

  • integrate Scratch search (with Autocomplete) into our Android Pocket Code app
  • list of all converted programs (app)
  • progress view for currently converted programs (app)
  • websocket client (communicates with our converter web service) (app)
  • websocket service (server)
  • Google Authentication (used to identify users and to store & share converted programs with other Android devices) (server & app)

Possible Mentors:

  • Wolfgang Slany

Small Sumo Drone

Brief explanation and expected results:

The goal for this project is to provide functionality and integration of the Parrot Airborne Drone for the Catrobat project. The most important parts include the connection to the drone, the transmission of the controls as well the visual data transmission.

The basic structures for the drone support on the application side is already given by the previous work. The challenge will be to create a clean interface for the communication between application and drone.

After the project it should be possible to control a Airborne Drone in the same way as the already implemented AR.Drone2.0. This includes the basic movement as takeoff and land, gain and loose altitude, change direction in which the drone is heading and the actual movements (forward, backward and to the sides). Each of this movements should be completely customizable through one individual Catroid Brick. Furthermore the video transmission of the drone should be displayable anywhere on the screen in different sizes.

Possible Mentors:

  • Markus Hobisch

HTML5 Player - Compatibility / Feature Completeness (Scratch)

Brief explanation and expected results:

The HTML5 Player uses a costom JSON project format that was design to be compatible to both, the original pocket code as well as the current scratch file format. Most of the features (differences) between PocketCode and Scratch are already part of our current HTML5 players design. There are still several bricks and features which are available in Scratch, but not in Pocket Code. First, These features and bricks are needed to have an more improved programming experience and second in order to have a working Scratch2Catrobat programs converter. The following features and bricks will be part of this project:

Server (PHP):

Unzip and convert/parse a Scratch project file into a HTML5 project file. Add serverside DTOs for bricks currently not supported.

Client (javascript):

Extend the look object to provide PocketCode/Scratch compatibility. Override the current Sprite object to generate Scratch based redering output (sprite positioning, direction, brightness, filters) if not implemented yet. Add missing bricks (described below) in cooperation with the PocketCode team working on the same stories in PocketCode:

Pen/Stamp:

Pocket Code is missing the pen bricks from Scratch. The aim of this project is to implement these missing bricks. Pen blocks in Scratch 2.0 are used to draw something on the screen, much like in Turtle graphics. There are eleven bricks in this category. Pen bricks allow to take various actions:- Stamp the sprite - Put the pen down - Release the pen // One example of a one sprite one script project is a simple drawing program. See http://wiki.scratch.mit.edu/wiki/Pen_Blocks

Cloning:

Cloning in Scratch 2.0 is a feature that allows a sprite to create a clone, or duplicate, of itself, while the project is running. This can be useful in tower defense games, for example, for a wave of objects. Clones of a sprite will be the same as the original, or parent sprite, but as a separate instance (see http://wiki.scratch.mit.edu/wiki/Cloning). 3 additional bricks are required - these bricks are “create a clone”, “delete clone” and as script brick “when I start as clone”, just like in Scratch.

Object collision / with color / movement:

To detect collisions between object is an essential game element - every shooter, race or skill game needs this feature. There are three different kinds of collision detections planned: (touches) with other object: like in Scratch: Brick “touching finger/edge/object”, object collision (touches) with certain color e.g. like in Scratch: Brick “touching color___”, Camera look in combination with movement, extension: camera onsprite/onstage (see Scratch)

Ask Brick:

Possibility to have a text input field in state. The user can reply to this answer via the text input field. After that this answer is stored in a program variable (like in Scratch, Brick: “Ask____” + answer)

Missing Bricks:

To ensure brick completeness with Scratch the following bricks are missing:

  • Move Brick: “go to ____” - finger/object
  • Sensing Brick: “distance to ____” - finger/object
  • Sensing Brick: timer + reset timer (timer is a variable in FE)
  • Sensing Brick: current (minute, month, date,….)
  • Look Brick: change/set color
  • Move Brick: set rotation style: don’t rotate, left-right, all-around

Possible Mentors:

  • Christopher Immervoll

HTML5 Player/Project browser: UI Extensions

Brief explanation and expected results:

Extend the current HTML5 Player to provide several new UI features:

  • Search/browse/load projects within our player application
  • Store latest projects executed using a HTML5 local store
  • Provide a quick start (home screen) icon for mobile to launch our player directly
  • Provide a menu or buttons to select UI language
  • Provide a menu or button as well as logic to switch to full screen (mobile)
  • Extend the Page object to provide a mobile alike navigation
  • Write a visual (HTML, css) represention for existing bricks so users can also browse the projects code (read only)

Possible Mentors:

  • Thomas Hirsch

HTML5 Player: Rendering + Physics

Brief explanation and expected results:

Our player currently makes use of the fabricJs library to render sprites to our viewport. We only use fabricJs to draw sprites and handle click/tab events- therefor the wohle framework is a huge overhead (even if custom compiled). Our application was already designed to replace this library to enable individual caching logic on sprites and looks.

  • make a desition on how to replace the fabricJs library with an individual rendering engine (design)
  • replace fabricJs and
  • write/rewrite all required test cases

Physics is going to be release soon and there is currently no support:

  • Extend the serverside code (PHP)
  • Override the current sprite object to get a physics enabled sprite object based on the PocketCode (java) implementation
  • Implement missing bricks
  • Implement unit tests for all extensions made

Possible Mentors:

  • Paul Schreiner

Your own Project Ideas

Please do not hesitate to bring forward your own ideas and discuss them with the Catrobat team members at #catrobat on Freenode or by contacting us via https://catrob.at/mailinglist!