Insights

Growing your staff complement is a positive sign of growth and should be embraced, however, it should be done with caution. Wrong appointments will have harmful aftershocks - not only in terms of time and cost of people performance management but in reputational damage to your brand.

In today’s technology industry, companies are looking for the best talent to join their existing team and at the same time, the potential candidates are looking to join the best company. Appointing new staff is a two-way stream which must be navigated cautiously. Below are a few tips to consider to ensure a positive outcome:

1. Look beyond the CV

So you’ve found the CV that really stands out and speaks to your needs. Qualifications and skills are important, but remember that they can be taught. Unfortunately, good character cannot.

Be selective and allow soft skills to be a strong weight, as they are key to establish a professional workforce and a pleasant work environment. Effective communication skills, being a team player and having a good work ethic are some of those soft skills that need to be measured during the interview process. Ask the candidate open-ended behavioural questions to get them to talk freely. This will allow you to evaluate their soft skills.

Your company has values which all staff should live and work by. Keep them in mind when you screen and interview new candidates. If “taking ownership” is a value, then ask a related question to assess if your candidate is willing to take ownership for tasks and even failures. Appointing someone who doesn’t live by “integrity”, if it's your company value, will be fatal.

ALWAYS, do a thorough background screening and reference check. It's a good idea to mirror your interview questions to a fellow staff interviewer to get a second opinion on the same questions.

2. Have an attractive Employee Value Proposition

Skilled professionals are in high demand providing your candidate with options from other employers. It could be reasonable to assume that remuneration is fairly aligned for the same occupations in the same industry. Therefore focus on the other aspects of employee satisfaction. Make sure that your employee value proposition beats your competitors.

Recent employee surveys (do you have a survey we can reference?) have indicated that when it comes to staff retention, monthly salary is not top of mind. People want to be part of a company that is willing to invest in them and assist in their career growth. A proper onboarding process and an effective support/ mentorship programme is non-negotiable.

People don't tend to make a lateral move in the market if you offer them their next big challenge and something to look forward to in the near future. Establish and encourage a thought leadership culture in your company allowing staff to give their views on aspects topical to your line of business.

3. Get your team involved in the process

Use your existing staff to attract new talent by introducing them to the new candidates. This interaction will give the candidate exposure to the culture, energy and experience (successes and failures!) of the existing team. Since the new candidate will form part of a team, it will be valuable for both parties. It will also empower your team and include them in the hiring process. Ideally, the exposure should convince the new candidate to join and become an asset to your company.

Finally, recruitment should not become basic or “old news” but should rather enjoy renewed attention. With so many options for candidates today, it's time to clean out the cobwebs and focus on attracting the right people for your business.

If you have ideas or suggestions on this topic, I would love to hear from you. Feel free to get in touch via LinkedIn.

A common misconception I’ve heard quite often is that gamification and game design are the same things.

Today’s decision-makers are faced with the necessity of making big business decisions faster and more accurately than ever with software solutions.

In this article, I'll discuss how design teams can adopt Agile and use the Scrum framework to achieve delivery in terms of customer experience journeys, prototypes (low and high fidelity) and services blueprints.

The background

When I first joined the design office nine months ago I didn't have a clue how I was going to be a Scrum Master to a design team. I was unsure of end delivery from a full design perspective. From past experience, I was used to working with technical teams (developers, testers, BA’s architects and one or two designers).

The first few weeks were spent trying to understanding what the teams deliver and handover and this left me somewhat confused. I then remembered no matter what needs to be delivered, if the Agile principles are followed anything is achievable with the right team and skills.

Let's look at how the Agile principles were followed within the design team:

Principle 1

Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.

From a design perspective, testing is always an important task that needs to be fulfilled as the customer's experience is extremely important, which requires improvement regularly.

Principle 2

Welcome changes in requirements even late in development.

Agile processes harness change for the customer’s competitive advantage.

When business requires a certain feature to be improved, the team then works towards a solution. Pitfalls are noted immediately and the direction is changed.

Principle 3

Deliver working software frequently, from a couple of weeks to a couple of months, preferably on a shorter timescale.

The team always aims to deliver a shippable product or feature after each sprint which can have an immediate impact on the customer's experience. As an example, suggesting the removal of steps in the customer journey which can improve turnaround times.

Principle 4

Business people and developers must work together throughout the project.

As a Scrum Master for design teams, we realised that most people within the organisation don’t understand what designers do. We then started to include the relevant stakeholders and decision makers during the problem and solution discovery. The benefit - everyone is kept in the loop until the final product or feature is handed over. Additionally, it eliminates the pressure from stakeholders pushing for timelines as they are then aware of the process.

Principle 5

Build projects around motivated individuals. Give them the environment and support that they need and trust them to get the job done.

This also relates to Principle 4. Once individuals are enabled and trusted to deliver, they will do their best. In our case, the design team gained trust among each other and with their stakeholders.

Principle 6

Efficient and effective method of conveying information is face to face conversation.

The team was co-located however two of the designers were based in Cape Town which had no negative effect on delivery. The team used a tool called Zoom for all ceremonies, ideation sessions and check-ins which allowed for face-to-face interaction.

Principle 7

Working software is the primary measure of progress.

Teams should always strive for the primary objective - improved customer experience.

Principle 8

Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace.

Working together effectively and maintaining consistency with business stakeholders and decision makers was key to our success. Aim to deliver consistently for customers across different channels and platforms to improve the experience.

Principle 9

Continuous attention to technical excellence and good design enhances agility.

Our team learned to design with reusability in mind, questioning fit for purpose. If the experience designed does not fit the criteria then the approach is adjusted to be fit for purpose.

Principle 10

Simplicity and the art of maximising the amount of work not done is essential.

For this team it was simple: ‘Is it fit for purpose?’

Principle 11

The best architecture requirements and design emerge from self-organising teams.

Our team became accountable and responsible to each other. Our biggest fear was to disappoint each other in terms of failing to deliver. This meant that we were cross-functional and assisted each other from time to time.

Principle 12

At regular intervals, the team reflects on how to become effective, then tunes and adjusts its behaviour accordingly.

Our team had different skill sets such as UX, UI and service design. The youngest team member was 23 and the oldest is 51 and the level of respect and value this team had for each other was incredible. They were open to learn from each other and to handle criticism well. They didn't get attached to ideas and learned from past failures.

Lessons learnt

Agile can be implemented and followed in design successfully. Just remember to stick to the principles and it will more than likely come naturally to you.

Account Manager – it’s a common title in our industry, and yet so often means very different things to different organisations.

Some account managers mainly focus on sales, others consider themselves project managers first and foremost. Some double as IT advisors, while others spend all their time nurturing customer relationships and keeping customers happy.

At DVT, an account manager is all of these things. But more importantly, the skills it takes to become a successful account manager have less to do with technical proficiency and more to do with the ‘softer’ skills that are critical to every single aspect of the role.

In our fast-paced, highly competitive industry, the human side of the business too often plays second fiddle to the technical. But as we seek to help our clients digitally transform their businesses to better compete and succeed, the process is as much about the human side of change and growth as it is about crunching numbers and coding software.

The following steps are used to guide the development of any successful account manager in our business, and could likewise be valuable to yours.

1. Working to a set of values

Every business, DVT included, has its own set of cultural values, honed over time and passed down to successive employees through recruitment and training programs. These values cover a range of different aspects, describing how we conduct ourselves personally and professionally. For example, ‘doing the right thing’, ‘making an impact’, keeping it simple’, and ‘work-life balance’ are all shared values common to the company culture and its employees. If you haven’t defined your values as a company, you can’t expect your account managers to follow them.

2. Emotional intelligence (EQ)

Perhaps the most important part of an account manager’s job is managing people. In fact, if you substitute the word ‘account’ for ‘people’, you’d get a good idea of how many account managers spend most of their days. Managing people requires a very different set of skills to managing numbers or IT systems, and yet too many account managers are only trained for the latter. Knowing when to push back, or when to give more; being able to read someone’s expression and reaction, their body language and the tone in their voice; and having the ability to think before speaking – these are just some of the critical skills that make up an account manager’s EQ.

3. Understanding culture and unique conversation style

No business relationship is ever the same. The way we speak with one person will always differ, even if only slightly, to the way we speak with another. This doesn’t necessarily come down to our level of seniority or skill, but rather to intuitively knowing (or learning) the best way to connect with a person based on their personality style, the history you have with them, or the way they treat you at face value. Taking the time to learn and understand how to speak to different people is a stepping stone to building lasting relationships with them.

4. Getting personal with consultants

We’re all pushed for time, and therefore making time to get to know our consultants is often last thing on our daily To-Do list. However just a little effort made to spend time with each individual on a regular basis to get to know them, and for them to get to know you, builds a rapport that encourages trust, openness and honesty. These qualities in a working relationship help keep consultants engaged and retain staff.

5. Understanding talent acquisition and retention

DVT recruiters make excellent account managers, not only because of the recruitment cycle they go through to on-board new consultants, but also because of the interview and assessment processes our consultants go through with our clients. Recruitment in the IT industry can be highly competitive given the skills shortage in South Africa, which is why it’s important to learn to connect to consultants on a personal level, and to constantly stay informed about their relationships with clients. That way, any ‘issues’ are identified and resolved before they escalate, and the cycle of trust is constantly restored.

6. Project management

This may not appear to be a ‘soft’ skill like some I’ve already covered. However, an account manager is, at some level, also necessarily a project manager. DVT account managers work very closely with each practise and competency team, along with several other teams: development, business enablement, data/analytics, testing and automation, and so on. To work effectively and equally with each team means the account manager must always be proactive, communicative, transparent and organised. Involving multiple teams on a national basis while managing an important assignment requires a high level ‘people’ project management skill.

7. Knowing when to say ‘No’

It can be daunting to say ‘No’ to a client (or a colleague or a boss for that matter) but it’s a skill that needs to be learned and used effectively for successful account management. It’s even harder to say no to new business, especially if you are measured and rewarded for the business you bring to the company. But if taking on new requirements from existing clients – or business from new clients – that is unrealistic, or compromises values, or negatively affects delivery standards on other projects, ‘No’ is sometimes the only safeguard. Using measurement metrics helps to identify which opportunities are worth focusing on, but the ‘art’ of knowing when and how to say ‘No’ is often just as important as the science.

8. Thirst for knowledge and personal development

There is an overwhelming amount of information available to us as account managers, and it’s constantly changing. It’s not good enough just to know what our company does; we should also want to know the trends and topics of industry. This improves our confidence and encourages like-minded conversations among peers and clients. As account managers we need to set aside time every day to upskill, learn and improve – so it helps if we have a natural learning instinct, or learn to develop one.

9. An Agile mindset

Agile is a word synonymous with DVT on a business level, but it’s also a critical component of the very human skills we instil in our account managers. As account managers we understand better than most how direction, goals and purpose constantly change, both internally and for our clients. This means that we don’t always have a clear view of what’s coming, regardless of how much planning we do. We therefore need to learn how to be adaptable and flexible every day, to be open to new, as-yet untried and unproven approaches, but most of all, we need to accept that there will always be a mix of achievements and missed opportunities in our line of work. If managed properly, the ups and downs make us highly resilient, humble and motivated to ensure continuous improvement in our way of work.

One of the burning questions for many project managers today is whether or not working in an Agile environment is a threat to their role. The short answer is no, but there’s more to this perceived ‘threat’ than meets the eye.

As a project manager, unless you’re particularly precious about your ‘title’, Agile is something you should embrace, not fear. After all, Agile is a project management methodology that uses short development cycles called ‘sprints’ to focus on continuous improvement in the development of a product or service.

But this is only part of what Agile is about; it’s a philosophy made up of 80% ‘culture’ and 20% delivery method, wrapped up into a way of being and doing that permeates every aspect of professional life – not just the project at hand

In this regard it’s a major departure from traditional project management in the way teams are structured, hierarchies flattened and tasks accomplished, and could be considered ‘foreign’ to you if you come from a strictly traditional project management background.

Earlier I mentioned this is only an issue if you’re precious about your title, because in this new Agile environment you’re no longer a project manager but rather a value generator and facilitator, working as part of a holistic web of teams all pulling in the same direction to achieve the same set of ever-changing goals.

If this all sounds like a lot to take in and getting used to, you’re right, it is. It necessarily requires you, as a traditional project manager, to change your mindset. Do you see yourself as a project manager or an enabler? A ruler or a leader? The latter is where you want to be, the former what you want to leave behind.

If, as a project manager, you’re helping facilitate people and teams through a process in the business by means of purpose and through trust, you’re already there – you’re an enabler – and in the Agile sense, you’ve arrived. If, on the other hand, you’re still obsessed with rules and structures, and like to think and act sequentially with a well-defined chain of command, then there’s work to be done….

That work involves actively changing the way you think, and therefore act. You’re literally going to be creating new neural pathways in the brain – a science called neuroplasticity, which we don’t need to get into here. It’s enough to know the old adage that ‘old habits die hard’, and so the work involves changing your habits.

Think of it like a new gym routine; the first few days are a real struggle as your body adjusts to a different way of doing things. By the third week, however, the constant repetition has created a new behavior, and within a year or less, the neural paths are set and the new behavior becomes your default. The only expectation of you is to unlock your mind so that it’s receptive to the changes it needs to undergo. The Agile frameworks that area available will help you create a new routine.

Make no mistake – Agile is here to stay, and is the way of work in the future. The days of planning, managing the plan, and sticking to the plan ‘no matter what’ are over. It is critical for you to be able to maintain a certain level of flexibility in order for you and your team to change course in response to demand. The only predictability you want to see, is the predictability in terms of the team validity. We no longer want a predictable and planned outcome in terms of scope.

The good news is that switching on an Agile mindset needn’t be difficult, and I’ve put together some pointers below that will make your journey even easier:

1. Get training.

Even if you start with a basic 1 day Agile bootcamp – Agile fundamentals training, for example – you’ll get some understanding and appreciation for what this ‘Agile thing’ is all about. It’s not a natural change.

2. Focus on keeping the scope flexible.

This is a fundamental departure from the world of traditional project management. Enable teams to ‘pull’ work rather than push work to them. Create a backlog of items that need doing, and enable teams to pull from that backlog on demand.

3. Be as transparent as possible.

Anything that you want to do, do it transparently, not only with stakeholders but with the entire team. Even share your thought process and build trust.

4. Value the voice of the project team.

Empower your people. Don’t be the know-it-all; they are the subject matter experts in what they do, so let them do it.

5. Facilitate business to prioritise the backlog

Facilitation is still 80% of what you do in an Agile project management environment.

6. Make projects fun again.

If it’s fun, your team is fully engaged. Many times in traditional environment teams are split between projects, so make them want to be part of yours.

7. Drive the minimum viable product (known as MVP) at all times.

Limit your teams’ output to something that’s functional. You don’t need to work to Rolls Royce standards if you only need a Ford to get you there. The quality will come when everything is working as it should because we did not try to be superman in the process.

Remember, drive value at all times, enable and trust your team to do the job, and don’t see yourself as more important than the team. If you think you’re always the most important person in the room, you close yourself off to changing your mindset, and in doing so, Agile becomes the threat it doesn’t need to be.

This article was written and published exclusively for ITWeb Insights on the 15 November 2018. View the original article here: https://www.itweb.co.za/content/JN1gPvO195wMjL6m

The AI, Data and Analytics technology space is certainly in the spotlight. A great deal of coverage is being given to the potential application of these capabilities and almost the necessity to do so in order for businesses to survive in the competitive, digital landscape. That pressure though to adopt, use and disrupt comes with dangers that are certainly not receiving the same air time.

Godot Engine V3 (Open Source)

Have you ever wondered how difficult it would be to create a game in 2018? Truth is, it takes some time and effort but it’s not really difficult. There are many popular game engines available today for you to choose from. To name a few – Unity, Unreal Engine, Godot, Construct, Game Maker, Amazon Lumberyard, ARKit etc.

If there are so many to choose from why use Godot?

Well, Godot is an open source MIT licensed multi-platform 2D and 3D game engine that provides common tools so you can focus on making your game. To put this in simple terms, Godot is free to use, which means you don’t have to pay any money to use it, and after you have created the game and hosted the game there are no royalty fees involved as with other game engines. Godot Engine also supports cross-platform compatibility and makes it easy to export the game to multiple devices. The official Godot website can be found here: https://godotengine.org.

You can download Godot for your platform of choice here: https://godotengine.org/download. Godot is also available for download on steam and can then be found and launched under your software section.

To name a few of Godot’s features:

• Godot comes with hundreds of built-in nodes that make game design an easy task.
• Create node configurations with support for instancing and inheritance.
• Visual editor with all the tools needed packed into a beautiful and uncluttered context-sensitive UI.
• Friendly content construction pipeline for artists, level designers and animators.
• Persistent live editing where variations are not lost after stopping the game.
• Create your own custom tools with ease using the tool system.

What does Godot use to create these games?

You have a few options to choose from in terms of programming language. There is GDScript which is a high level, dynamically typed programming language used to create content. It uses a syntax similar to Python. Its goal is to be enhanced for and tightly integrated with Godot Engine, allowing great flexibility for content creation and integration. You can read more on GDScript here http://docs.godotengine.org/en/3.0/getting_started/scripting/gdscript/gdscript_basics.html.

There are also other options such as full C# 7.0 support using Mono, full C++ support without needing to recompile the engine. There are also additional languages with community-provided support for Python, Nim, D and other languages.

Some other supporting development features that Godot offer:

• Visual scripting using blocks and connections.
• Built-in editor with syntax highlighting, real-time parser and code completion.
• Integrated documentation. You can browse and search the whole API offline, without leaving the editor.

In this article, I will explain a few concepts of the Godot game engine and show a few of its features. I will also show some GDScript coding examples and explain what’s going on in the script. I will provide you with a sample game that you can use as a reference for creating your own game or you can add to the existing game for practice. I won’t be able to explain every single line of code in this article but the game files are available to you and should serve as a good reference and starting point.

Getting started with game creation

So now we begin with the fun stuff. Where to start when creating a 2D game? There are a number of places from which you can start. Some prefer to first create the level with all the objects in it and thereafter create the characters and in-game items such as power-ups and so on, but I prefer to start with the character and its movements and adding to the game from there.

When starting your game ensure that all contents you use are free and don’t violate any rules or laws in the way you use them. If you choose to download the character sprite sheets or background image for your game, make sure it is not copy protected or you will get into trouble if you plan on selling the game.

Now we will start with our game-specific concepts. First off you can download my sample game here: https://github.com/DewaldOosthuizen/retro_mashup.git. You can follow along with this article and use the game files as a reference to create your own game, or you can request access to this repository and add new levels and things on to this game. This game cannot be sold as the content I have used are not my own and selling them will break the licence agreement of using them. Therefore, this game will always be freely available for whoever has the link to the repository.

It this article, I will explain some of the concepts of Godot using my character scene. Before we start with our character, Godot gives you access to 3 body types for game development. First of is the KinematicBody2D type. We usually use this type of creating a game object that can move around in some sort of way. The character we will be controlling in the game will be using this body type. The next type is the RigidBody2D type. This is used to simulate objects which are affected by physics that the game engine handles for you, such as gravity. Godot automatically assigns a gravity strength to the object and you can configure the strength of the gravity. These body types should only be used when needed as they are the most resource intensive of the body types. The last body type is the StaticBody2D type. This body type is used for objects that should not be able to move. These objects are stationary. The floating blocks in Mario are stationary objects and so are the staircases, they would be built from StaticBody2D body types.

The image above shows your character scene.

The character scene exists out of all the components and nodes you are seeing on the image. The KinematicBody2d being the parent node and existing of a few child nodes.

CollisionShape2D

The CollisionShape2D is used to draw a shape around your character which you would like to identify as the shape that can collide with other objects. If you want your character to stop when walking into other objects, this would be the CollisionShape2D’s job. If the other object also has a CollisionShape2D object, the two objects will collide and they will stop. They won’t be able to pass through one another.

Camera2D

The Camera2D (which is the dark purple line you are seeing around the character) is used to make the screen follow your character as you move forward and backwards in your level. If you move out of your game screen size (which you can configure under editor settings) your character will keep moving but you won’t be able to see your character. The camera object allows for your character to always be in view as you move the character around in your world. You will need to play around with the camera position around your character until you are satisfied with the results.

Sprite

The Sprite node is the image or sprite sheet of your character. A sprite sheet is an image that consists of several smaller images. Combining the small images in one big image improves the game performance, reduces the memory usage and speeds up the start-up time of the game. You can then specify how many horizontal sprites are in the image, and how many vertical sprites are in the images. These are then split up into frames which can be used to cycle through these images and create the effect of the character walking or firing a gun etc.

Once you click on your Sprite node you will see a few options underneath your scene. These will display under the ‘Inspector’ tab. Here you will see a Texture option where you can drag and drop your image (sprite) or sprite sheet. Under the ‘Animation’ section you will see the options’ Vframes’, ‘Hframes’ and Frame. ‘Vframes’ is used to specify how many vertical images can be contained in your sprite sheet whereas ‘Hframes’ is to specify the number of horizontal images. The ‘Frame’ option can be cycled to see all images inside the sprite sheet and identify which images are assigned to which frame number.

Area2D

The Area2D object has a CollisionShape2D node as a child node. This serves as an area around your character where you would want to handle some type of event or check some type of collision. For example, if you walk into an enemy and collide, the CollisionShape2D object of the KinematicBody2D will prevent you from walking through the enemy but what would make you decide if you need to respawn or not? This is where the Area2D comes in. You can check all objects within the Area2D and trigger some function or method to handle the event needed.

Next to the KinematicBody2D node you will see 3 icons.

The first icon indicates that the node has a group attached to it. This is useful to classify certain object into a specific group. When creating enemies, you would want to put them all in the same group. Reason for this is that when an object enters your Area2D, and you identify it as belonging to the enemy group, you can trigger the right action or event.

The second icon indicates that the KinematicBody2D has a script attached to it. This means that the node is controlled by this script. It does not necessarily mean the object can move when a script is attached to it. It could have some code that just makes the object do something or perform some type of event and/or action.

The last icon, which all nodes will have, will hide and show the node in the 2D view of your editor.

Views

If you open Godot you will see 4 view options in the middle on the top of your screen. These options are 2D, 3D, Script and AssetLib. The one highlighted in blue is your current selected view. For our 2D game, we will only be using the 2d view and the Script view.

Looking at our game character

Making the character move and do things such as sliding or shooting can sometimes be a bit tricky. You will need to create this movement or action using the script view and writing some code for it. Currently, 400 lines of code make our character awesome and can still grow when adding more features to the character.

The first thing you will notice about the Script attached to our character node is that right at the top we can see that this script extends KinematicBody2D. This gives us some build in methods, variables and features specific to the KinematicBody2D type which we can then use to make the development or scripting process even easier.

Numerous activities in Godot are started by call-backs or simulated methods, so there is no need to write code that runs all the time. Although, it is still common to need a script to be handled on every frame.

Types of processing

There are two types of processing:

• Idle processing
• Physics processing.

Idle processing is activated when the method _process() is found in a script. It can be turned off and on with the _set_process(true) method. This method will be called every time a frame is drawn, so it’s fully dependent on how many frames per second (FPS) the application is running at. The delta parameter contains the time elapsed in seconds, as a floating point, since the previous call to _process(). This is useful for doing some calculations regarding movement speed and gravity setups which we will look into shortly. See the screenshot below.

Physics processing with _physics_process() is similar, but it should be used for processes that must happen before each physics step, such as controlling a character. It always runs before a physics step and it is called at fixed time intervals – 60 times per second by default but can be configured. The method _process(), however, is not synced with physics. Its frame rate is not constant and is dependent on hardware and game optimization. Its execution is done after the physics step on single-threaded games.

Though, we won’t be using the _physics_process() method for controlling our character, as our 2D game is quite simple and does not require much physics handling. Now let’s look at controlling our character with code.

The image above shows the _control() method which we pass delta into once again. This is not a build in method of Godot like the _set_process() method. You will need to create the method yourself. Inside our _control() method you will see a few other method calls such as _jump(), _move(), _set_speed() etc. These are all methods we will need to create to control our character. We will have a look at some of these methods after this.

Movement and collision

The move_and_collide() method is again a built-in function of Godot. This method takes one parameter which is a Vector2 indicating the body’s relative movement. Typically, this is your velocity vector multiplied by the frame timestep (delta). If the engine detects a collision anywhere along this vector, the body will immediately stop moving. If this happens, the method will return a KinematicCollision2D object. Vector2 is a 2-element structure that can be used to represent positions in 2d-space, or any other pair of numeric values. Whereas the first parameter of the Vector 2 is the x position and the second parameter the y position. The reason why you are seeing two of these method calls in the screenshot above is that we want our character to collide with something on the x-axis such as crates and enemies and we want our character to collide with things on the y-axis such as the floor. Our character will fall through the floor if we don’t use the move_and_collide() method. The reason we aren’t passing both parameters in on one method call is that this will make the character move very slowly, while constantly colliding with all object it touches. Even jumping up against a wall and touching the side of the wall will make the character move slowly down the wall as if it is sticking to the wall, and we don’t want this to happen.

Instead of using move_and_collide() to move the character you can use the move_and_slide() method call. The move_and_slide() method call automatically calculates frame-based movement using delta. Do not multiply your velocity vector by delta before passing it to move_and_slide(). The reason I did not use this method over move_and_collide() is because of the return type of these two functions. The move_and_collide() method call will return a KinematicCollision2D object which is useful to detect if you walked into other player objects. You will see me passing the object returned to another method called _handle_collision(), which I use to detect what should happen when my character is colliding with this type of object. Although this will not work on all object types. If you collide with something that does not have a KinematicCollision2D object type you will need some other way of identifying the object you walked into. This is where the Area2D node is useful. You can read up on these movement functions on the official documentation here: http://docs.godotengine.org/en/3.0/tutorials/physics/using_kinematic_body_2d.html.

Area2D

This is a 2D area used for detection and 2D physics influence.

The above screenshot shows how I used the Area2D object to determine if my character has picked up a power-up. The get_overlapping_bodies() method call returns a list of crossing PhysicsBody2Ds, which we can then use to look through all objects in the Area2D and decide how we would like to handle them. In this case, if the object is a power-up then we will increase the character's power by one and destroy the power-up with the queue_free() method. The safest way to delete a node is by using the queue_free() method. This erases the node safely during idle. This will release the resources hogged by the power-up object as well. When a node is freed, it also frees all its children nodes. Because of this, manually deleting nodes is much simpler than it seems. Free the base node, and everything else in the subtree goes away with it. Be careful to create many game objects and move them out of the screen but not freeing the resources they have used. This can dramatically affect your game performance.

Applying gravity to your character

Remember: RigidBody2D types have gravity applied to the automatically which you can configure in the Editor. However, our KinematicBody2D character does not have gravity applied to him automatically. Thus, we need to create the gravity effect ourselves. If you have a look at the screenshot below, this is how I replicated the gravity effect on my character:

const GRAVITY = 800
const MAXIMUMSPEED = 400

First, we will need a few constants. We will define a constant with the name GRAVITY at the top of the script and assign it a value of 800. We will also require a max speed variable for our player. We can create another constant called MAXIMUMSPEED and assign it a value of 400. We will then set our playerSpeedY equal to itself + our GRAVITY constant times the delta variable (playerSpeedY += GRAVITY * delta). This will apply our gravity for each delta time section of our framerates (The delta parameter contains the time elapsed in seconds, as a floating point, since the previous call to _process()). This will make our character come down gradually after we jumped until we touch the ground again. Even when we are standing on the ground the gravity is still being applied to our character.

The clamp function call in the screenshot above is used to lock the value of something. I have done this on the playerSpeedX variable and I have used the MAXIMUMSPEED constant variable as the measure I would like to clamp it by. This means my characters speed will gradually increase as I hold down my arrow buttons to move left and right, but it won’t move faster than my max speed I have specified. This is useful for controlling and limiting certain values.]

Since I have decided to use move_and_collide() to move my character I would need to multiply my movement speed with delta and my movement direction which will be either 1 or -1 to determine whether my character is moving left or right. Whereas move_and_slide() would automatically multiply the velocity by delta and we would not need to do so ourselves.

Animating our character

To make our character have different movements we use a sprite sheet to allow for cycling of multiple images as mentioned earlier. Firstly, we need to know when to animate our player. The above screenshot shows my characters movement frames. This will make the character look like it is running in the direction you are pressing. We want to check that it is only changing sprite images every 0.065 seconds of our current delta time which we calculate in our process() function by saying deltaTime += delta.

We will need to know which frames in our sprite sheet we will need to use for animating our character. In this case the move frames are [60, 61, 62, 63, 64, 65, 66, 67]. This is then assigned to a variable called moveFrames. You will see an if statement where I check that the current moveFrame is not greater than the amount of move frames we have, and if it is I will reset our current move frame back to the first move frame which is 0 (Remember arrays start at 0 and not 1).

We then set our player sprite frame to the current frame and increment the current frame by one. We set the player sprite variable in the _ready() method by saying playerSprite = get_node("Sprite"). We then reset deltaTime to 0 at the end of our animation phase to allow for checking the next animation frame. Now when we hold down our movement buttons, our character will be cycling through all of the movement frames and restart these frames once cycled through all of them. This makes it look like our character is actually running in the direction we are pressing.

Input Mapping

Input mapping can be found under Project -> Project Settings -> Input Map. Here you will find a bunch of input mapping already done for you, you can also add some more of your own. You can also set up multiple keys under one mapping description.

What does this mean?

Looking at our _jump() method we check Input.is_action_just_pressed(“move_jump”). This is a build in function that Godot offers us for checking if a button is pressed. On the Input Map screenshot above, where we define our key mappings, we would then need to define a new mapping called move_jump and assign a key to this mapping. I have assigned ‘space’, ‘up arrow’ and ‘w’ for my jumping action. This way players can choose their preference and play the game with whichever they are more comfortable with.

Instancing

What is instancing in Godot and where do we use it?

Instancing allows you to create one scene in Godot and then reuse that scene multiple times on different places.

Take a look at the above line of code. Here we preload a scene into our character script. This is the bullet scene we use to create a bullet when our character fires his weapon. We preload the scene because we don’t use it yet at this point. We know that we will be using it in this script and that is why we preload a reference to the scene.

This is how we actually create an instance from the scene we preloaded. After we pre-loaded a scene and created an instance of the scene, we can then work with the scene by referencing the bullet variable we have assigned the bullet_scene instance to. This can be done multiple times and saves us the effort of redoing all the code for the bullet scene every time we want to fire a bullet. It is best practice to save all your objects as scenes so that you can create instances of your objects and use them throughout the entire game without redoing the code for your object.

After creating an instance of an object, it does not add the object to your current scene or game view. You would still need to add the instance of the scene to your current view. This can be done with the below code.

Once this code has been triggered the bullet scene appears in front of your character. This is useful for altering the scene before actually adding it to the view. Before we add the bullet scene to our current game view, we set some values such as the position of the bullet and the moving direction of the bullet. Only after we have set these values we add the bullet scene into our game. If we did not do this, the bullet would not appear in front of our character and move into the direction our character is facing. It would start at the beginning of our level and always move into the same initial direction.

Exporting your game for your platform

To export your game, you will need to click on the Export option under Project.

Once you clicked on the Export option, you will find a new window opening up. At the top of the window, you will see an Add button. If selected, Godot will display all available platforms to you. Looking at the image below we can see a list of all the popular platforms.

The end

Godot makes game creation easy and fun. If you have ever wanted to try game development I would really recommend Godot 3 as your first option. Not only is Godot open source and free it also offers a large number of sample games and demos to get you started. By looking at some of the game projects offered by Godot you can get up to speed with game creation in no time.

We have not touched on all concepts of Godot, neither all the objects and code in the sample game I have provided you. But the ones we have touched on are some of the more important ones to get you started. I hope this article was useful to you and that it will intrigue you into trying game development with Godot.

You can have a look on the official Godot YouTube channel to see what some people have been working on lately and what true potential Godot has. https://www.youtube.com/c/GodotEngineOfficial.

I do not take any credit for the images used in my sample game

The images found in my sample game, I have downloaded at:
https://www.gameart2d.com/freebies.html
For the game assets in Freebies section, it's under Creative Common Zero (CC0) a.k.a Public Domain license.

You can also create your own sprite character sheets here:
http://gaurav.munjal.us/Universal-LPC-Spritesheet-Character-Generator/
All art is dual licensed: GPL3 and CC-BY-SA3

Yes, this is not a slip of the tongue - the intended term in the title is in fact “Scrum Manager”. So what could potentially turn a Scrum Master into a Scrum Manager, something which most Scrum Masters don’t even realise they are slowly becoming? Is it the things that managers are traditionally tasked with that Scrum Masters are now expected to undertake in order to fulfil their role? Let’s break this down.

If one researches what a Scrum Master is responsible for, one will most likely encounter the following terms:

• Agile process manager;
• Facilitator;
• One who lives and breathes agile values and principles;
• Servant leader;
• Protector of the team;
• Remover of barriers;
• Change agent;
• Improving the efficiency of the team;
• Encouraging collaboration;
• Coaching on all things Agile.

However, if you were to inspect some of the current roles and responsibilities Scrum Masters are being tasked with you will most likely find a plethora of different things that do not coincide with the traditional list. Let’s investigate what some of these might be:

• Being responsible for the team’s Sprint deliverables;
• Explaining why project deadlines were missed (this is wrong on so many levels!);
• Mitigating (project) risks;
• Managing relationships with stakeholders;
• Approving team members’ leave;
• Being constantly aware of team members’ working hours (clock watching?);
• Scheduling and coordinating of meetings, not just the Scrum ceremonies;
• Being the communicator of any and all requirements (even technical ones) from external sources. As in, “Send this notice of the server decommission to the Scrum Masters and they’ll make sure whatever is required will happen”;
• Being the secretary for the team; i.e. getting any team requirements, be it hardware, software, stationery, refreshments and food catering fulfilled, arranging for office moves, taking minutes at meetings, arranging functions/celebrations, etc.;
• Raising complaints with the relevant parties, and ironing out conflicts between team members, or between teams;
• Ensuring compliance of team members with HR policies such as ensuring that leave is submitted when a team member is not in the office, etc.;
• Managing and communicating production deployments - i.e. arranging all activities around a deployment and communicating relevant info to stakeholders before, during and after those deployments;
• Keeping and communicating up-to-date schedules regarding any kind of required dev standby or testing roster.

I’m pretty sure many Scrum Masters have found themselves doing at least one or more of the above tasks. Also, there are presumably many more responsibilities and tasks which Scrum Masters around the world are currently finding themselves saddled with. These roles may not necessarily be within the scope of what they usually would have perceived or accepted as part of a Scrum Master’s role.

One can clearly see that there is a mismatch between what a Scrum Master traditionally is supposed to bring to the table, and what they are slowly, and probably unknowingly, becoming: managers. The question needs to be asked: should this be allowed, is it healthy, and should Scrum Masters accept these responsibilities even though it may inevitably mean that they will have less time, bandwidth and focus to concentrate on the things that really matter? The things which help their teams continuously improve and become better at being agile? Though one could argue that having the Scrum Master undertake these tasks does, in fact, make their teams more efficient, enabling more flow and should be done.

We all know, and research confirms, that there is a definite difference between project managers and Scrum Masters. There is a reason why people choose to become the one and not the other. One focuses on the project and its delivery, while the other focuses on the team, trying to improve efficiencies and turnaround. Do organisations really believe that taking a Scrum Master and giving them (project) managerial responsibilities is the equivalent of “being agile”? Moreover, are they not selling themselves short of what they really deserve, jeopardising their noble intent of becoming agile and garnering all the benefits? Can those organisations honestly tell the world, their stakeholders, their shareholders, their own people, that they have embraced Agile, simply because they have employed Scrum Masters, yet continue to assign typical project management tasks and responsibilities to them? Or is this an evolution where an organisation aiming to become Agile naturally progresses through? Is the final destination a place where Scrum Masters come into their own and do what they were always supposed to do – incrementally and consistently improve the team’s performance via inspect and adapt?

On the other hand, one could also argue that a Scrum Master should simply accept that they will do whatever it takes to help the team perform at their highest level, whether that includes any of these “managerial” tasks or not. Perhaps we should just ignore this discrepancy between the roles and simply accept that it’s “part of the job”. Maybe the role of Scrum Manager is, in fact, a legitimate one which has evolved out of necessity. If improving our teams’ performance and our organisations’ adoption of Agile means that we will do such managerial-type tasks, then so be it! Let’s give the benefit of the doubt and ask why not? Yet if so, we cannot avoid asking ourselves the following question: are we doing ourselves, our teams, our organisations, and our profession a disservice? Is there a price to pay for becoming and being a “Scrum Manager”?