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 2020

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

Idea Overview

General Information

These ideas are just some topics we came up with, where currently nobody is working on. However, Catrobat is a project with a wide range of possibilities and we’re aware of our blindspots: So let’s live the spirit of Open Source and come up with improvements (e.g. new features, extensions,…) that are related to the project and you’re interested in. We do have many senior-contributors who would be happy to mentor such a project. Don’t be shy and check out the last point on the list: Your idea!

General Knowledge Prerequisites for all Projects

  • Knowledge in the usage of git
  • Basic knowledge in the concepts of software testing and test-driven development
  • Basic knowledge in app development (for Android and iOS projects)
  • Java, JUnit, 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)

Your Application

Please find the mandatory template for the application and additional information on this shared Google Doc.

Project Descriptions

Awesome Demo Game Project

Spend the whole GSoC time developing and designing one tutorial game for coding using the Luna&Cat IDE app, i.e., programming in the Catrobat visual programming language. The game must be playable both on a phone as well as when cast from the phone to a smart TV.

The game should be strongly inspired by a hugely popular recent 2D game, your own suggestions of popular games are highly welcome. You may also get inspiration by search for lists of the best OR popular 2d games.

If you have your own original idea about a game, please feel free to suggest it. Note, however, that the focus in GSoC should be on coding, not story design. Also, reusing existing already successful ideas will tremendously increase the probability that the game will be popular, and allow you to get much further in its implementation. Also note that the game will be published under Catrobat’s licenses as described in detail on Licenses and that the game will thus become part of the Catrobat FLOSS project’s source code. Thus, all artwork, sounds, character names etc must be compatible with our licenses, i.e., freely publishable under our licenses, the AGPL version 3 and CC BY-SA 4.0, or under a compatible, possibly even freer license such as CC0.

The artwork, sound effects, and background music must also be of high quality and high resolution, but do not have to be necessarily have been created originally by yourself, as long as the rights are compatible with our licenses.

The development of the game may possibly also be a community effort, but that’s up to you. This means that if you want, you may involve a team of people who want to work together with you on the game, either coding extensions or additional levels, contributing media assets, testing, creating promotion videos of it, etc. How you put together your team is entirely up to you, and you alone are responsible for the recruitment of and coordination within your team. Some Catrobat games have been created by large crowds. You and your team working together on the game would be perfectly fine and welcome, as long as you by yourself spend the full GSoC period working 100% on it too, and you do the main part of the coding, since Google wants GSoC projects to basically be single developer coding subprojects. However, most FLOSS projects are community efforts, and collaboration has always been one of the tenets of such projects. Also note that there will be no T-Shirts etc from Google for the other members of your team, so all contributions by other team members must be motivated intrinsically, or by additional means left to your discretion.

In summary, this GSoC project’s game should become an incredibly awesome & amazing demo game that showcases what kind of mind boggling games can be created with Pocket Code.

In your GSoC application, please add a link to a proof of concept for such a game in landscape mode (because it should be playable when cast to a TV screen) that you have created on your phone using Pocket Code. Also describe shortly your ideas for the story of the game you want to develop in your GSoC project.

Boyakasha!

Mentor contact: wolfgang@catrobat.org

iOS: Landscape Mode

Users of the iOS implementation of Pocket Code should be able to choose between a landscape and a portrait mode when creating a new project, just like in the Android implementation of Pocket Code:

  • According to this choice, the whole stage should be in a landscape or portrait orientation.
  • In order to enable this, changes need to be done in the UI, the persistence level and most importantly, a lot of sensors (both for the device and for the objects) need to be translated according to the given orientation.
  • The student needs to come up with a design to enforce testability and enforce the use of mocking.

iOS: Integrate Google Sign-In and add tagging for projects

Users of Pocket Code should be able to sign-in and upload their projects both with their Catrobat accounts and with their Google accounts. In order to accomplish this, at least the following tasks have to be accomplished:

  • The authentication providers and the project upload have to be refactored and a suitable test framework needs to be introduced.
  • The student needs to come up with a design to enforce testability and enforce the use of mocking and API client testing with fixtures.
  • Additionally, similar to the Android implementation of Pocket Code, the user should be able to choose between a predefined set of tags (e.g., Game, Animation, Art, Experimental) prior to upload their own projects. Again, the upload functionality needs to be refactored to enforce testability and API client testing with fixtures.

Android: Redesign landing page for Pocket Code

The first page of Pocket Code should be redesigned so that parts of the community page are shown, e.g., featured projects, most recent projects, including “My projects”:

  • New UI for the first page of Pocket Code
  • Fetch projects using the API from the share
  • For legacy users who are only updating, i.e., who have had Pocket Code already installed: After the first time the app is executed after the update, show the legacy users a selection option with screenshots of the old and new interface, and ask whether they want to continue using the old, or whether they want to try the new interface.

Android: Separate and modularize interpreter and IDE in Pocket Code (Refactoring)

Modularize Pocket Code so that we end up with one separate module for each the IDE and the Interpreter:

  • In Pocket Code the IDE is seen as the interface for creating/editing projects, as well as the Pocket Code Community
  • The Interpreter is responsible for interpreting and executing Catrobat projects. So basically that’s where the action happens. The user created projects gets executed in this module.

This projects includes planning on how to split up the code base to modularize Pocket Code and come up with a step-by-step refactoring:

  • Planning Interfaces to communicate in a more generic way
  • Building Wrappers around classes where functionality lies in Background for easier Refactoring
  • Begin of detailed Refactoring

Web: Implement new OAuth Provider and refactor Google Sign-In

The current OAuth provider is outdated and should be refactored:

  • Implement new OAuth2 Provider for Symfony (preferably HWIOAuthBundle)
  • The authentication providers have to be refactored and suitable tests need to be written
  • Additionally, the currently used Social Login Provider needs to be refactored/thrown out and documented thoroughly
  • Optionally, expanding social logins to other platforms, e.g., Facebook, GitHub etc.

DevOps: Automated Deployment Chain

The overall idea is to make it possible for the Product Owner to release an APK of a certain release candidate to the production channel of Google including all necessary steps of signing and aligning the APK.

The workflow to do so shall be kicked off by a Product Owner who logs into the Jenkins and starts a release-job, which:

  • builds the release candidate in DEBUG version
  • runs all RELEASE-relevant tests on this DEBUG version
  • when it is OK, a RELEASE version is built - the signing and aligning of this artifact takes place in a secure sandbox which is NOT easily accessible from the outside
  • after previous step the signed and aligned APK is once again tested with the RELEASE-relevant tests to ensure the release-version DOES NOT BREAK any functionality covered by the release-relevant tests
  • when the release-relevant tests with the RELEASE-APK ran green, the APK is automatically deployed in conjunction with its Metadata (prepare by the initial Jenkins job (there exists a working POC)) to the Google Play release-channel

Remark: There are several options for doing so: E.g., a dedicated Jenkins slave for building, signing, aligning the RELEASE APK; a small virtual machine (externally inaccessible) hosting a web-service which either fetches the RELEASE built be Jenkins, signs and aligns it and uploads it back to Jenkins which in turn uses Fastlane to release it to Google Play OR any other APP-Store; OR the web-service triggers the Jenkins instance on this particular server to build, sign and align and deploy it to the Google release channel….).

Part of the GSoC project is to find a viable AND SECURE way do achieve this tasks in the Catrobat infrastructure internally and not with external tools. The keys MUST NOT LEAVE the Catrobat environment and MUST be stored on an externally inaccessible server.

Web: Refactoring of test system and alternative API testing

The test system needs to be refactored and split up to speed up testing processes with the already existing docker container.

  • Tests need to be split up in more sections/test suits so that we can execute them in parallel using our docker container
  • The underlying FeatureContextFiles need to be refactored, cleaned, adapted where necessary and code duplications need to be removed
  • Since we are on our way to introduce APIv2, it is a good time to check if our current Testsuite (Behat) is adequately equipped to extensively test our new API. If not an alternative should be found and implemented (in accordance with the rest of the team)

DevOps: Fully virtualization of the CI & CD

The overall idea is to fully virtualize the Jenkins setup and to streamline all jobs for that the development team has the most benefits and can easily incorporate the jobs into their workflow.

The only physically remaining server will be the server with the hardware-testing box and the robot-arm for physically testing devices’ sensors and actors, e.g., speaker, flashlight, vibration, micro, gyroscope, magnetic sensor, proximity, etc. It will be also a part of the GSoC project to create a meaningful test-suite which is incorporated in various scenarios like - smoke tests and regression tests and probably release tests.

Reasons:

  • The current Jenkins hardware in the team room is physically accessible by various people and cannot be safeguarded.
  • The new hardware (dedicated physical server) can be partitioned with VMWare virtual machines to resemble a useful setup.
  • The hardware resources of the new server outperfom the current setup.
  • The Jobs must be refactored to match the increased requirements to usability of the development team.
  • The virtualization must be conducted in regard off the Automation of the deployment pipeline.

Embroidery Robot Programming

Spend the whole GSoC time developing huge Embroidery Designs using the Pocket Code IDE app, i.e., programming in the Catrobat visual coding language:

  • If you have your own original idea about an embroidery design, please feel free to suggest it.
  • Note, however, that the focus in GSoC should be on coding.
  • This GSoC project’s Embroidery Design should become an incredibly awesome & amazing demo design that showcases what kind of mind-boggling embroidery designs can be created with Pocket Code.

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!