Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics


A topic by Eva Knight created Feb 08, 2017 Views: 466 Replies: 15
Viewing posts 1 to 14
(1 edit)

I have a few questions but since the FAQ is locked I thought I'd make a thread. If anyone else has any feel free to ask them here too.
My questions:

To what extent must the project be similar to the starting project? Eg could we change the genre, camera angle, etc as long as it's via modifications to the existing project?

What level of secrecy must we maintain about our projects? Obviously we have to use private repos, but could we make a devblog for example, or share our progress?

Who legally owns the game? Since it is derived from the given starting project and made for the competition it's a bit unclear.


Thanks for the questions. Going to stick these in the FAQ as they're all good points.

1. You can modify the starting code as much as you want. If this ends up as a radical departure from the original concept, that's fine - this is one factor that contributes to the 'Creativity' marking criteria. The key thing to bear in mind is that it must be clear to the judges that you've worked from the original source. If in doubt, always comment the changes you make for clarity.

2. There's no enforced secrecy on the projects and you're welcome to maintain dev blogs & share progress updates if you wish. In previous years we've even had some entrants livestream their coding sessions. They are non-collaborative, individual projects, so actively sharing your project or encouraging plagiarism is obviously a bad idea. You are, however, more than welcome to share ideas, talk about your approach to the project and discuss your work with others (I'm going to go set up a general discussion board now). Alternatively, if you want to keep your whole project private and work on it in secret until a spectacular reveal, that's fine too.

3. You retain all rights to your game. The starter project is provided free for your use. If you use any additional third-party assets in your project you must ensure they are licensed appropriately.


Out of curiosity, is the code base for Rising Star and Search for a Star the same? As I was linked to sfas2017

Yep, it's the same base project used for each competition. It's only the assessment groups that differ - SFAS entrants are graded seperately from Rising Star entrants.


I have a question, How much of the original assets do we need to use? Can we go abstract from the original design, but use say 1 or 2 original scripts?

You can adapt and modify as much as you feel necessary. Part of the assessment criteria, however, is on your ability to read and understand the existing code base, which will be difficult to demonstrate if there's not much of it left. It should be clear from your code that you've used the original source as a base, rather than started from scratch and copied in some of the scripts from it.

Are we allowed to used any version of Unity? (Free, Personal, Pro)

Yep, you can use any version of Unity.

(1 edit)

Hi All,

There is no difference between Personal and Pro nowadays, except for the skin. But the project was created with 5.5 and will be marked in 5.5 so please do stick to this version.

I was wondering, is there a particular code style wanted for this project? The style given in the base project doesn't really correspond to the Unity API codestyle (eg, in the base project, there are fields that have uppercase starting characters, whereas the Unity API style uses lowercase starting characters for fields and uppercase for methods), and also has some confusing rules such as some member fields having "m" at the start and others not.

Hi Alfie,

This is the style I generally use in my code:

- Serialised Member Fields (values specified in the inspector which shouldn't be edited runtime) Start with a capital letter and camel case

- Private Member Fields (values for tracking runtime state) Start with lowercase m and then camel case

- Locals (values that are local to the current scope) Start lowercase and then camel case

- Functions, enums, constants, etc Start with capital and then camel case

Basically anything that shouldn't change starts with a capital and things that can be changed start with an m to indicate that they are members or lowercase to indicate that the values are local to the current scope.

When I write code into an existing project, I usually try to copy the style that surrounds it so that it doesn't look out of place, therefore making the code neater and more readable.

Hi Lizi,

The brief mentions "Project submission will require a link to the code repository of your finished project." Where does this go exactly?

Hi Neil,

I'm not sure if there is a notes box for you to add a link like that to when you do your submission but the repository should be private anyway so a link isn't that useful.

I wouldn't worry though as you have already shared your repository with me and I can see the changes you have made. I might need to give you an additional username to share access with while we judge. I'll let you know if I need you to do this.

Anyone who hasn't shared their repository with me should do so now (Beeski)!

Okay, thank you. Hopefully you like what you see!

Was just wondering, how long is the judging period/when are results expected?

Hi Alfie,

We've got a lot of entries to get through but we are going to do our best to let you know within two weeks.