When creating foundations of a new game's architecture, we often find ourselves in a situation where changing something at a later stage of a project requires making modifications in many places. I'll show you how to avoid such a domino effect with minor changes, how to write code in Unity easily steering clear of errors, I'll tell you why you should be interested in reactive programming, and what are the available Unity solutions supporting it.
You can start a new project completely from scratch instead of keeping the old code? Lucky you)! I would like to share my experience and tell you how a well run project should look like from developers' perspective. For the purpose of this presentation, let's assume one requirement for a good project: a few years after the implementation and maintenance of the application, the newly joining person is not willing to escape with a scream. I'll tell you what it looks like to carry out the project from analysis to deployment, with a whole lot of things to remember about along the way. I will answer the question:' What should each project have? How it should function". I will explain which things can be made up for, and the introduction of which will be very expensive at later stage. the legacy code. With a bit of luck this knowledge will help you avoid "legacy" code in future.
So where is your documentation? It should has been done yesterday! – There is no documentation in Agile – replied a lazy developer. – “Working software over comprehensive documentation” – explained another agile one. – Let’s create a change request – PM rubbed his hands – you may generate a Javadoc! – Isn’t our code self-documenting, Uncle? – asked an XP developer. – No document unless it's need is immediate and significant – confirmed Bob. How many times have you heard such conversation? Probably you are not surprised with a common reluctance concerning software and code documentation. However, do you feel comfortable with Github projects having poor readme.md? This topic is addressed to developers who want to forget about documentation and return to the code. It may also interest people who feel that the time of docx files faded away. I will talk about modern and diverse methods or documentation replacements. I will show among others how to: create living documentation which won’t be outdated tomorrow; replace user stories and executable specifications with tests (still clear to business people); generate documentation elements without waffle; create graphs and diagrams without legacy UML; document API without Swagger’s hell of annotations.
This talk focuses on describing the process of designing and adjusting the combat system in Ancestors Legacy game, from the original assumptions up until final implementation. Key system changes will be analyzed, including reasons for those modifications and selected solutions. Multiple visual examples from within the game, and its work-in-progress versions, will be provided to illustrate the talk.