Getting started on indie projects

Discussion in 'Indie Basics' started by Macro, Jun 11, 2014.

  1. Macro

    Macro New Member

    Joined:
    May 20, 2014
    Messages:
    31
    Likes Received:
    18
    FREE tools to assist in getting indie projects started

    I was looking through but could not find much listed on this topic so wanted to condense some lessons learnt over the years and some good (and free) tools that can be used for an individual or a team to get the best start on a project and to help keep everything moving along smoothly.

    So you have come up with a great indie game idea and you have done more than the 99% and have decided to go from the "thinking" phase to the "doing" phase, now rather than rushing in to some implementation based on some torrent of ideas from your mind, lets have a look at some of the areas that make up the indie game and how you can be best equipped to start an indie game project.

    Managing the Design, Scope and Progress:
    It is great having a head full of ideas, but without quantifying them and how they all fit together it will be VERY tough for you to make real progress, and this is even more important if you are working with a team of people.

    Generally a good idea for managing the project is to have some sort of central ideas hub, and its important to not just have ideas but information around those ideas, like how long you think it will take, who is working on it, what dependencies that has on other tasks etc. There are plenty of free (or paid) Agile (Agile is just a term for a specific type of project management) tools which help solve this problem, such as Trello, Asana, Teamcity, Jira. (I will just focus on Trello here as its a free hosted solution).

    So imagine that you have started on your prototype and you have done some animation bits you have some basic AI and you are needing someone to come in and implement some sort of inventory system. How do you tell this person what you want? do you just give them a verbal description? write it all down in a word document for them? just tell them high level ideas and hope they get it right?

    If you use a project board like the ones above it is very easy to just create a some small encapsulated tasks which explain to anyone on your project what you expect from it, and is also helps everyone know how far along a project is and if someone comes up with an idea everyone else can comment on it in one place and track it's progress.

    Look at this picture

    [​IMG]

    How easy is it for everyone to know what's going on in the project? even if you are just a single developer you can at least plan out your project ahead of time, and then if you get stuck on something, go work on another task. It also helps you easily change your focus from the minor details (which you will become absorbed with when you are implementing) and look at the bigger picture.

    This sort of approach has helped me on so many projects know what else needs to be done, how far along I am, prioritise functionality etc, and its benefits become exponentially better the more people who are involved as everyone knows what everyone else is doing and can see that if the guy doing pathfinding is being too slow it will delay the guy doing the defensive AI task etc. You will also pre-empt some major obstacles because you will have to think out roughly how you will solve each problem so rather than hitting roadblocks in an ad-hoc manner you can ask the questions early on so you have the answers ready for when you get to those bits.

    Also it is worth noting some of the tools above (Teamcity, Jira) can hook into your source control so as you compete issues/tasks they will update the board automatically and tie in your commits.
     
    #1 Macro, Jun 11, 2014
    Last edited: Jun 11, 2014
    Casszune, Phuzz, Anders Dahl and 3 others like this.
  2. Macro

    Macro New Member

    Joined:
    May 20, 2014
    Messages:
    31
    Likes Received:
    18
    Quantifying your tasks:

    So we have gotten over the first hurdle of actually creating the notion of tasks so our team can work in parallel, however one area which is often overlooked is the quantifying of tasks. As it is all well and good having a task called "Create Inventory System", but what does that inventory system need to do?

    So here is where quantifying your tasks comes in handy, and will also force you to make hard decisions about your project without even having to waste time implementing it, which sounds harsh, but how many times have you or someone you know had a great idea, ploughed weeks/months into something with just a rough idea of what they want, without sitting down and thinking what will this game actually consist of?

    So for me personally whenever I start a task I want to know:

    • What is it I am doing?
    • Why am I doing it?
    • How will I know if it's done?

    So the "What is it?" can be simple or complex, if it ends up being complex it will show you that your task is probably too big and needs to become multiple smaller tasks. The "Why am I doing it?" should be pretty straight forward, what does this achieve? in the inventory system example it allows your player to hold items which is pretty important in most games. Then finally the "How will I know if it's done", which is what most people struggle with. As you will always have more ideas the more you work on something, but sooner or later you have to say its finished and move on to something else, so how do you measure that completion of the task, how will you know when you have done everything that is required?...

    I am sure a lot of you will be thinking that I am over-thinking this problem, and that this is all a big waste of time, which may be correct if you are some game design/developer/audio/modelling savant however I will let you decide for yourself after you have read the rest of this waffle.

    So here is an example of something which I have seen before as a task, which is poor-average:

    Now that tells us at the bare minimum that we will need to have a GUI display of some kind, and the player needs to be able to equip items and trade items, but it doesn't really quantify the HOW part of our questions above, and only just about covers the WHY section.

    So lets look at another example of how to lay this task out in a far better way using a well known pattern for requirements gathering known as BDD (Behavioural/Business Driven Development/Design gotta love the permutations of these acronyms).

    Now the above example is pretty succinct, we use a common set of patterns here known as "As a... I want... So that" which cover the what and why, then we use another pattern known as "Given, When, Then" to describe how we will measure success. Now in the example shown the 2 ways, I have had to make some up front decisions now because I am being FORCED to measure completion. So I have had to specify that I will be using drag and drop functionality to move items around, and that when an item is equipped it is no longer in the inventory. I have not even covered the trading aspect, nor have I described how items make their way into the inventory, how a user drops items, if they can be stacked, if they are icons or 3d models, and there is no information there discussed about the design of them.

    This kinda shows that we often think about tasks as big blocks of unknown, we associate some keywords to it, like Inventory, Trade, Equipment, Use, Drop etc but we rarely think through how we want this to function. One other major point to touch upon here is that this "Inventory System" is probably not just a 1 man/skill job. The logical implementation of the handling of items and equipping of items would probably be a programming job, but how the GUI for the inventory looks and feels is more of a UI designers job. So if you have trouble working out what your Inventory should do and look like, maybe you don't have as clear an idea of what you want and may need to ask people of that discipline to help you out, as there is no harm splitting this into many smaller tasks like:

    • Create logic for picking up items
    • Create logic for dropping items
    • Create logic for trading an item
    • Create logic for equipping an item
    • Create design for inventory view
    • Create design for item style in inventory
    • Create design for trading window
    • Create design for equipment window

    There are an awful lot of things which go into this one feature, and each one of those tasks would require quantifying so you know when you run your game each one of those use-cases will be working. Which may seem quite daunting at first, but would you rather spend months of your time churning out code with no clear guide on what you want and just going by gut feel (which also makes it difficult to collaborate) or would you rather spend a week or so making all the difficult decisions up front so you know before you start how much work there is to do, who can do what and when it will all be finished by?
     
    #2 Macro, Jun 11, 2014
    Last edited: Jun 11, 2014
  3. Macro

    Macro New Member

    Joined:
    May 20, 2014
    Messages:
    31
    Likes Received:
    18
    Collaborating / Source Control:

    Now there are lots of ways for people to collaborate on a project, from as simple as just emailing files around, or sharing on a network. However most people these days tend to use source control systems. Now there are lots of different types of source control systems (GIT, Mecurial, SVN, CVS, Perforce etc etc) however unless you are setting up your own server for this it is usually easier to use online source control systems so you can access your code anywhere.

    Now the main one which most people will have heard of is Github, which is great for collaboration, however a free account means that your repositories are public, so anyone can see or fork your source code. So you would have to pay to have a private repository. Now Bitbucket is another alternative which is fairly well known, and provides free git repositories but you can have private repositories for free, providing your project team is less than 5 people. You can also get the normal issue tracking/wiki etc which helps with project collaboration.

    There is also a good app which uses bitbucket issues to display in an agile way, as described in the first post here (http://www.bitbucketcards.com/).

    So assuming you are using source control already you are half way there, now you need to make best use of your VCS.

    Here is a BY THE BOOK example of how to use GIT with projects:

    [​IMG]
    Whole article at: http://nvie.com/posts/a-successful-git-branching-model/

    Now thats great and I tend to adhere to it for large projects, but for smaller ones or one man projects it is recommended to at least follow the dev and feature branch strategy. This allows you to keep each feature isolated and if someone breaks their build, it wont effect you. This is easy with GIT as you can just make these branches locally so the server does not need to be aware of them, just merge back into the development branch once your task/feature is complete and everyone will always be up to date.

    GIT is not that great with binary files, you need tools like perforce to make best use of versioning binary files, but unless you are a VERY large project, and hosting is free this isn't a major concent.
     
    #3 Macro, Jun 11, 2014
    Last edited: Jun 11, 2014
    a1clark1a likes this.
  4. Macro

    Macro New Member

    Joined:
    May 20, 2014
    Messages:
    31
    Likes Received:
    18
    TESTING YOUR STUFF!

    Now this is often overlooked by most people, as testing is something seen as being sooooo far down the road that people wont think about it until the last moment. Now I will pretty much be speaking to the devs from this point on as we discuss AUTOMATED TESTS!!?! (BY GOSH!) and what they can do for you!

    So lets take a scenario, you are making a space game, and you have lots of different guns with lots of different effects, some plasma some physical, laser, ion etc etc, and each of these gun types needs to react differently to different types of armour, such as physical, shields, reflective coatings, lead paint etc etc. So you have started doing your code and you have come to the point where you are flying around shooting things and you notice that your ion cannon is doing 0 damage to a ship... so you go to you re-start, faff around setting up your debugger to run, equip your ship with the same items and fly off to find the closest other ship to shoot. You hit it and it does 0 damage so you trace through the stack working out at which point the calculation went wrong, then you realise you made a typo and instead of doing 0.5f you did 0.

    Not the end of the world, but this sort of thing could be caught earlier on in your development cycle, before you even run your game. Also writing your code in a way which lets it be tested makes your code better, you instantly write more separated and easier to maintain code and you can also then benefit from dependency injection techniques if you write your objects in such a way that they can be mocked. (If you don't use Dependency Injection you should look into it, IoC is best, ServiceLocator is bare minimum)

    So how do we go about doing this? As depending on your engine you may approach this problem different ways, so in Unity you may have written this bullet firing logic as a script and attached it to a weapon so it is a MonoBehaviour (this makes it almost impossible to unit test properly and we will get on to that later), or if you have your own engine it may be some fancy pants private method put into your ship object or something, or you may have gone for something all together different.

    However if we look at the bare bones of what we are trying to achieve here, we have a Weapon which has an ammo type, a damage amount then we have some armour which has a defence type and an armour amount (being very simple here). So rather than making these parts of another class lets model these as they should be done in code (I will use C# to demo).

    Code:
    public class Weapon
    {
    	byte DamageType { get; set; }
    	float Damage {get; set;}
    }
    
    public class Armour
    {
    	byte DefenseType { get; set; }
    	float Armour { get; set; }
    }
    
    So those seem legit, they do the bare minimum and have no knowledge of a ship, space or have any logic applied... now some of you will rush in and add a method to weapon or armour to handle the interaction between the 2, but really it should be another entity entirely that handles the damage between the 2, as these are just models of the LOGICAL REPRESENTATION OF A GAME ENTITY. Those letters are in caps because they are very important. If you are going to write good code you should split the LOGICAL representation of your entities from their PHYSICAL/RENDERED representations, this way you do not even need to render things to test your game, and if you dont need to render things you dont really need to run your game either... you could do it all from a console app OR A UNIT TEST RUNNER!

    So this is NUnit's GUI test runner, it has a console test runner (or if you are super cool you will own Resharper for Visual Studio which is far better).
    [​IMG]

    So with this you can write some isolated tests, to prove that what you THINK happens in the logic, will actually happen, and you can run these tests every time you re-build your code, you check in your source control, or if you are super swanky you may have a build server and pipeline which you can plug it into.

    Anyway so lets get on with a very simple implementation of a component to handle the interaction between weapon and armour so we can do a dummy test:

    Code:
    public class DamageCalculator : IDamageCalculator // You may have different implementations
    {
    	float CalculateDamage(Weapon weapon, Armour armour)
    	{ return weapon.Damage - armour.Armour; }
    }
    Now that doesn't take into account the type of armour or damage, but if you imagine your implementation would have that stuff in. You can clearly see here that if we ignore the rendered stuff at the heart of the interaction where one entity attacks another, there will be resulting damage which can be applied to the victim, or could be passed over to some other entity to handle to check for shield reduction and stuff. However the key is that this is isolated logic, it is not tied to some mono behaviour, it is not tied to some inheritance chain, it is something very simple that encapsulates a single responsibility.

    So how do we test this?

    Code:
    [TestFixture]
    public class DamageCalculatorTests
    {
    	[Test]
    	public void should_correctly_calculate_basic_weapon_damage()
    	{
    		var weapon = new Weapon { Damage = 10 };
    		var armour = new Armour { Armour = 5 };
    		var damageCalculator = new DamageCalculator();
    		
    		var expectedResult = 5;
    		var result = damageCalculator.CalculateDamage(weapon, armour);
    		Assert.That(result, Is.EqualTo(expectedResult));
    		// This will pass
    	}
    	
    	[Test]
    	public void should_correctly_calculate_ion_damage_vs_shield_defense()
    	{
    		var weapon = new Weapon { DamageType = 2, Damage = 5.5f };
    		var armour = new Armour { ArmourType = 3, Armour = 2 };
    		var damageCalculator = new DamageCalculator();
    		
    		var expectedResult = 1.5f; // Lets pretend our game design document said that shields are x2 defense against ion damage (5.5f - (2*2))
    		var result = damageCalculator.CalculateDamage(weapon, armour);
    		// This will fail as the actual result with our current implementation is gonna be 3.5f
    	}
    }
    So this above test fixture (what NUnit calls a class of testable methods) contains 2 tests, one which passes and one which fails. If you run this through the test runner (go google how) then you would be able to see without even running your game that this logic is not 100% right, and whats better you can then refactor your logic to make it pass the second test. This can be run as often as you like, so if you get some new guy on the team who decides to go re-write the weapon logic, does it still adhere to the game design requirements, and this is where those requirements mentioned earlier on really come into play, as if you have requirements like:

    Ok maybe you dont need to be explicit with the numbers and I am not sure if Ion is meant to have the above properties... but if you were to write a task like the above you can easily see if the developer has succeeded in doing what you wanted. So that new guy who has re-written all your logic may have buggered up your Plasma type damage but without a suite of unit tests to prove that this stuff works you wont know until you manually play the game and find it out. So this can REALLY SAVE TIME in the long run.

    This doesn't mean you don't need testers, you still need them but they would do more exploratory testing to make sure the game functions and feels right, not having to go off shooting every type of weapon against every kind of ship every time a new release is made (regression testing).

    So save yourself time and resources, and design your code well from the get go and separate your LOGIC from your PHYSICAL entities, I wont go over mocking here as I would need to make a contrived example with a player, but this is enough to get you started down that road. If you were to do this in unity you can have all your logic in another project and just put your logic dlls into your unity project and add the logical representations to your physical representations at runtime, so your monobehaviour now contains a Weapon class as a property, not as a hardcoded method within itself.
     
    #4 Macro, Jun 11, 2014
    Last edited: Jun 12, 2014
  5. Macro

    Macro New Member

    Joined:
    May 20, 2014
    Messages:
    31
    Likes Received:
    18
    Where do you fit in the team?

    So you have had your idea of what indie game you want to make and you are sure your <insert genre here> is gonna be great.

    So now you need a team (you can go it alone but sooner or later you will need some other people), and you need to think where you will sit in this team and where everyone else will sit.

    So generally your skill set will fall into:

    • Programming
    • Audio
    • 2d Art
    • 3d Art
    • Game Designer


    If your skill set does not fall into any of those parts then chances are you are what we like to call an "Ideas Guy". You can do 2 things at this junction, you can either go and attempt to pick up at least 1 of the skills on the list so you can actually bring something to the project (and I don't see *Project Management* as a required skill, it helps but it is not specifically needed), or you just accept you are an ideas guy and see if anyone will join your vague project in the hopes of some profit share at the end. Long story short just don't bother starting a project if you can not contribute to one of the above, as you will have people asking you what you wan't and if you are not ready to get involved in the meat and potato of the project it will fail and you will waste everyone's time.

    Now assuming you are not an Ideas Guy and you have a skill, then its time to start trying to make some sort of starting point for your project before you get a team together. Do not fall into the trap of doing 0 precursory work and just hoping you can get a group together AND THEN start putting it together. Here are some ideas of what you can do depending on your skill set.

    - Programming
    If you are a programmer then start by making a super simple prototype, so for example if you are wanting to make a space game, make a simple prototype showing how your combat works and how the gameplay feels. It may take you a couple of weeks but at this point you will realise if this is still something you want to work on, if so then show off your prototype with your boxes flying around shooting other boxes and see who wants in.

    - Audio
    As someone related to audio it is not as easy to represent your game with music alone, however if you were to make some music setting the scene and provide a few small bits of gameplay information to go with it and you should be good. This way people will know what sort of theme your game has and can see you have already spent some time thinking about it and putting some pieces together.

    - 2d Art
    This is a very good position to be in, as you can create a lot concept art which will portray the sort of art style, the themes and the sort of world the players would be experiencing. Ideally put a few blurbs down to go with it, but generally this will put you in a good position to start recruiting a team as you have something to inspire the rest of the team.

    - 3d Art
    You can make some 3d models for your game and show off some animations of the characters, again put a bit of a blurb down to go with them and you are good to go.

    - Game Designer
    A great position to have when starting a project, just do as you would normally do, create a set of documents detailing the functionality, the overall aspects of the game for each member so everyone will know what they will need to do and what the end sort of project will look like. As a game designer you may not be able to create any of the actual content, but you can at least document how it all fits together, and if you can't then maybe the project wont work.

    Ultimately you can see the theme here is use your skill to make something to turn your project from just an idea to an implementation, if you are relying upon everyone else to take your idea and run with it, then you are not needed, ideas are easy to have. It is the implementation which is the tough part so keep that in mind when you have your next idea, and ask yourself if YOU are ready to take the projects first steps into implementation.
     
    #5 Macro, Jun 12, 2014
    Last edited: Jun 15, 2014
  6. Macro

    Macro New Member

    Joined:
    May 20, 2014
    Messages:
    31
    Likes Received:
    18
    -- Reserved --
     
  7. Squishychew

    Squishychew New Member

    Joined:
    Mar 9, 2015
    Messages:
    3
    Likes Received:
    0
    Hi Marco,

    Just wanted to thank you for this thread you posted.

    It was the deciding factor on me joining this community as I found this board through googling "Help with starting an Indie Game Project"

    with my background and studies pertaining to Business and also my long standing interest not just in programming but in the actual Science behind computing, If I do actually get something published using this as my starting point I will be sure to credit you.

    Once again, big thanks for this "how to"

    Squishychew
     
  8. CanDoNoWrong

    CanDoNoWrong New Member

    Joined:
    Aug 31, 2016
    Messages:
    1
    Likes Received:
    0
    I appreciate this post a lot. I've reread it just now a second time while I begin to lay out a concept onto paper before I get started.
     
  9. spartanx

    spartanx New Member

    Joined:
    Nov 20, 2016
    Messages:
    2
    Likes Received:
    0
    great share,just the thing i was looking for to control my ADHD lol
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer