I am really getting a lot from using version control. Being able to look back over the commits and see what was updated and what was changed is very informative. I know that in the software world this is standard but there is always a first time for experiencing even things that turn out to be ordinary.
Commit
Imported the UE4 room from the content examples project as it will look nice for videos showing features
Fixed an access none error that was happening when a soldier who is not part of a squad is killed and tries to reach for a squad mate to shout ‘man down’.
Fixed access non error when the killed soldier tries to check that the fire team is dead but he does not belong one.
Moved the squad and fire teams into the new space and all the decals and features seem to work except for the squad clean up
Squad leader was being spawned outside the room and was not dead when the player was entered the clean up volume
Added is valid check to the ‘Dex lost’ call to the Dialogue Manager, as it runs on a re-trigger-able timer and the owner can be killed before the timer cycle runs its course.
Added is valid check to the ‘found soldier body’ call to the Dialogue Manager as there is a delay to that call in which the caller can be destroyed.
Added is valid check to the weapon base class for when the reticle is trying to cool down but the owner may have already been destroyed.
Added an ‘Enable blood’ bool on the bleeding component that can be set in the details panel of any actor that uses it.
Took out the behaviour in the Soldier that was polling the Music Manager so that it would change stat at the right time, this needs to be changed to Event Dispatchers instead.
Began setting up the Gore Profiles in the Bleeding Component but its not finished yet.
I have completed my very first Unreal and C++ tutorial! I am very pleased with this simple game as it is a significant milestone for me and is the first fully functioning project that I have been able to put together. Now before anyone shouts ‘but it was just a tutorial, anyone with eyes and fingers could have done that!’. That’s true. They could have. But here’s the good part (for me at least). I understand it.
Im not scared of you, no, Im not.
Not much more than a little while ago, there would have been no way that I would have looked at something like this and thought, yeah, I see whats going on there. I didn’t know basic C++ so following Unreal ‘version’ of it was painful and not really possible. This problem came about mainly due to the learning curve that I would have had to experience while on the BA Top Up course. I could not learn about the Unreal editor, Blueprint (which even when using C++ needs to be understood and used) and then a mighty language like C++ over the top of all that. I just would not have been able to produce anything worth showing.
Since graduating from the course, I still felt that learning the code in C++ would be too much of a challenge and so I resigned myself to working in Blueprint only while carrying on the development of Serial Link. It was not really until I was experiencing the reality of thinking about what would happen if Serial Link did not work that I thought, oh dear, I still cant code in anything but a very specific tool for a very specific engine.
So, shortly before taking on this MA, I grabbed a course on Udemy that I have already covered here, and started the climb to coding stardom. Ok, that’s a touch over the top, but you know what I mean. I thought about Unreal and C++ together and thought that I would save myself a ton of headache’s if first, I got used to the C++ language on its own and then stepped into the fray with Epic, the makers of Unreal. I expected that I would be able to break into coding for Unreal once I understood a little bit more about the language itself and for the most part I’ve been right. I think that I am ready to start a C++ project in Unreal or, and this may be a better move, refactor some of the logic in Serial Link into C++ one small feature at a time. I would rather have something to show for it at the end that I could use professionally.
Just a quick note to say that I went through the content examples project on the Unreal Marketplace and found out how to add physical hit responses to the Soldier characters. It would be better shown in a video but I dont have the time to sort that out at the moment!
Commit
Added a very rough version of physical hit reactions. I think it needs more work but its a good start.
Spotted a problem with the logic that makes that soldiers hang in the air. when they are thrown using the fling ability, and the collide with anything that causes the hit event to fire, they are executing the ragdoll in air feature. I need to come up with a way to validate the thing that its striking.
I have been interested in this sort of thing. I mean that I have been interested in finding some structure to the place that is just a step back from the Kanban board, just a bit further away. I find that when I think about planning for a project, I think in a blend of ‘wouldn’t it be cool if’ and ‘we need to implement’. I have a good grasp on breaking down the implementation side of things but I think that I could benefit from learning a bit more about structuring the part of the project that leads to how the user should interact with some feature and how they should feel about it. That last one, ‘feel about it’ is very important to me as I already understand that games, once boiled down, are really all about feelings.
The MA content requested that I watch the video on Personas from the Pluralsight course ‘Creating Effective Stories’ and upon having watched it, I think that I could get a lot of benefit from watching the whole course, so thats what I am going to do.
Thinking in Stories
A user story is a placeholder for a conversation. Thats a great quote and is really helping me to understand what this is about.
Design is deferred to the Last Responsible Moment giving the team the time to find out as much as possible about the real requirements.
The key to the flexible, high level story is that it is an encouragement to the team to interact with the customer and find out more about the requirements as the quickly implemented builds are delivered.
Its important to remember that you should define Acceptance Criteria as the first step of starting development work on the story. Note that the Acceptance Criteria should be created and confirmed before any coding begins. More on that later.
Users Stories: The 3 Parts
1. As a …
2. I want to …
3. So that …
This tends to reduce frivolous requirements that can be created using a feature list.
As a player, I want to be able to shoot bad guys, so that I can level up and get more abilities.
Types of Stories
What are Roles?
They represent groups of users rather than individuals
They are derived from the characteristics of the group
From the example
Users – Customers
Dont use the word ‘users’ in encompasses everyone really
Service People
Owners
How to evaluate the stories using INVEST
Independent
Independent: They are self contained and don’t rely on other stories. This is very useful due to the fact that User Stories may/will need to move around in the backlog, changing their prioritisation. Its useful if there are not another set of stories that have to move because of that. I can imagine that in game development this may be difficult as one system builds on another but I am keen to see how this can be resolved. It actually links in a little to the Single Responsibility principle in terms of how I should think about it.
Negotiable
Negotiable: This means that they should be available for change as the true requirements are honed in on, but that it should stabilise as the team get closer the Last Responsible Moment before implementation begins
Valuable
Valuable: This makes sure that the story has real value to the User defined in the story, removing superfluous requirements and wishful thinking from the backlog and therefor the application. This also prevents the occurrence of too many technical requirements and makes sure that there are ‘downstream’ benefits to the User defined in the story.
Estimate-able
Estimate-able: The team should know enough about the story and it should be small enough so that they have a good idea of the work involved in delivering it. Note that if it is not Estimate-able, a Spike story may be required. I talk about this later.
Small
Small: This is linked in with the ability to estimate the work required to implement the story and serves to reinforce that its scale is directly related to that outcome.
Testable
Testable: The story should be defined enough so that developers could define tests that could be used to prove that the value in the story is being delivered or be able to highlight where that is not the case.
Epics
This is a User story that is too large to be completed without further breakdown into separate stories and consideration of its dependencies. An Epic could be the story that describes the entire value proposition, overlaps several smaller stories or is just too vague due to the assumed, smaller activities that would be required to have it work properly.
What are the qualities of an Epic?
The Epic story captures a complete workflow towards a goal, and can be broken done into the beginning, middle and end.
Its not deliverable until all the stories are complete
For a game that Epic might be something like: As a player, I wantto experience a great story and complete the adventure using puzzle solving skills, so that I can experience satisfaction when I reach the end.
Themes
Themes are a way the think about stories that are related but don’t need to be completed together. This is the crucial difference that makes them different to Epics, in which the Epic is not delivered until each story is complete. A good example the presenter gives is performance. In games that could relate neatly to delivering a high FPS lets say. There may be multiple areas of the game to consider while completing this work but each part of the game can contribute to the improvement in performance individually, which would make the collection of stories a Theme and not an Epic
Personas
What are they?
What is a persona? Its a fictional character that can represent a person that is going to use the product we are developing. They are different from Roles, covered earlier as they represent groups instead of individuals and can give the roles depth. The development team should be able to relate to the invented persona more easily with an aim to getting closer to what the customer wants from the product. Create personas for roles that are coming up in conversation frequently.
Relationship Mapping
This allows a visual representation of who is using the product. It can identify new users and their influence on the product. It also shows the interactions between the users to reveal insights about what each of the users, or roles, need from the system and that should lead to a better design.
Choosers Vs. Users
Choosers are the ones that are paying for the system
Users are the people that will be, yep, you guessed it, using it.
Im game development, this could be the publisher vs the player. The publisher would want financial return from the ‘system’ (game in this case), and the player (user) wants the fun. Its common that the needs of the choosers are placed above the need of the user as the choosers have greater influence on the system at the time of design and are the ones signing it off. This can be frustrating for the poor user/player and cause the product to fail as without users, whats the point?
How to create a Persona?
Give them a name, a photo (of a real person doing something that matches the feeling they should get from the product), which Role they belong to and a description of what they want to get out of the product. You can also include a ‘key quote’ from the user that explains what they want. If appropriate you could add a title and demographic information. Dont use pictures of celebrities, the team will already have preconceived ideas about who that person is. Make sure that the Personas are visible to the team and keep them up to date should their needs change.
Splitting Stories
Why would you need to split it?
Larger stories are more difficult to estimate, can be too narrow in expertise required causing one person to have the bulk of the work and can be much more noticeable if not completed on time.
Smaller stories offer more flexibility, are easier to negotiate with the product owner and can save a lot of work as the additions to the story that were planned may never actually be needed in the end.
When might you want to split a story?
When the team gets nervous about estimating completion times.
When the proposed completion times and the actual times dont match.
When the number of Story Points reaches some number, say 3. I didn’t know anything about Story Points and have found another resource I hope to cover here soon.
How to split stories?
Vertically
Don’t split the task ‘horizontally’ meaning that you should not define a story like ‘build database’ if there is also a UI due. Better to define a story ‘vertically’ which allows some database and some UI to be built so that the team is left with an ‘end to end’ piece of work when its completed. This would also be easier to test as its a complete feature at this point and allows the team to maintain their flexibility demanded by Agile. But it can lead to an initial drop in productivity as team members have to learn about areas of the project that they are unfamiliar with.
Finding Seams
A Seam is an logical separation with a larger story. There are a few different types presented here and they are:
Workflow
This is good for when there are many steps in the workflow ,move to weapon, select weapon, equip weapon, target with weapon, fire weapon and so on…
‘illities’
These are the qualities of the product that are not so obvious. For instance
Security
Reliability
Scalability
Positive and negative cases
Splitting the story along whether some action in the system is successful or not. The example given is successful vs. failed login attempts. In a game it could be getting to the end of a level, having outstanding tasks and being able to notify the user.
Third party dependencies
This makes sense if there are other external parties involved who are not part of the core team or who are remote. The example given is that of a UI artist who will only be focused on that part of the product. This also makes sense as contractors will be less influenced by the core teams day to day needs and changing priorities and more concerned with delivering the work that was agreed within some previously agreed window or deadline.
Roles
This one is straight forward and is just splitting up the story based on the roles, or stakeholders within it. The only consideration is that the new stories should not rely on each other.
Spikes
A Spike is a special case of story that is useful when the team is tackling a story that requires some skill or technology that the members of that team are unfamiliar with. Because of this lack of experience, its not possible for the team to give a good estimate on how long the work will take to complete. A Spike story can be created that uses time boxing and allows the developers a chance to explore the problem with the specific goal of learning enough about how it will be solved that they can give a completion time estimate.
Getting to Done
Meeting the expectations
Customer
The customer will require qualities from the product such as it being easy to use, reliable, meeting the latest specification, clearly adding value and so on. This is implemented using Acceptance Criteria which are best extracted from the product owner using conversation and questioning. These can be created along with the story and can be written on the back of a sticky for instance.
Acceptance Criteria
This allows the team to go back to the high level user story and fill in the gaps to make it more detailed and specific. As mentioned above, they should be created as the first step in actually executing the story and should be fully accepted before development work begins. The format for this is
Given
What has to have happened in the product first, what is the prerequisite?
When
Some particular action happens
Then
Some expected result
Given that the Soldier is patrolling, when the Soldier sees the player, then the Soldier shoots at the player.
How to get it right
Be specific and make sure that everyone is clear about what the criteria means. They should be measurable so that the team and the customer are clear when a criteria has been met. It must be realistic and within the scope and constraints of what the team can deliver.
Developer
This allows the team to be happy that the features are robust and easy to maintain and develop in the future. The Acceptance Criteria are often called ‘Done Rules’ and are also common on Kanban boards, I have some of my own on the Serial Link board. These should be created by the team, allowed to evolve, be made public and kept informal which encourages the feeling that they can change if needed.
Done Rules Common Examples
Testing
Has the code gone through automated testing and passed.
Peer reviewed
Has someone other than the original developer looked at the code or was it pair programmed.
Deployed
Is it staged checked in for deployment and have the changes to the core code base been made if any are required.
Has the Product Owner reviewed the feature and agreed that it meets their expectations.
In Conclusion
I really got a lot of value from this course and have a much clearer understanding of how to set up an Agile project from the perspective of the value that needs to be delivered rather than the tasks that need to be completed. Although I found the course a little dry, the content was worth the time. I will keep these things in mind for the next project that I find myself in.
I have succeeded! Thank you, thank you… Its fine honestly, sit down, please. No, please. Flowers? You shouldn’t have. Im allergic to them for a start…
I have succeeded in confusing people about what I want to do and where I want to be in my professional life! Not great. But repairable. So, lets lay it out and have a little chat about it.
Having had some feed back about the journal and talking its content through, it seems that a post regarding an overview of where I am and why I am looking at the things that I am, is in order. I can take you back to the video that I did for my personal case study where I introduced myself and said ‘… and I want to be a generalist with a focus on coding so that I can make my own games…’
What does Generalist mean to me?
I have been thinking about this and its pretty simple. I means two things to me. The first is that it means ‘being able to make a game from start to finish on your own’. So that means being able to design a game, work out the mechanics and implement them. Then you need to be able to work with the animation, audio, particles, decals, post processing, AI, navigation, UI and so on and so on until you have touched almost every feature in your engine of choice. Then you should be at point where someone could sit and play something that you have created. This is very different to being a modeller. Very different to being a programmer. I want to able to model, animate, maybe create some music. I want to understand and be able to perform in most areas to a good standard. However…
The T shape
I read a very interesting article while I was thinking about this and you can find it here. It talks about seeing your skill set as a T shape and it really resonated with me. It also says to try not to be a specialist or a generalist but some sort of hybrid, biological catastrophe of nature, sort of specialising in something but then being ‘aware’ of the other areas. I’m not sure I agree that completely but I do like the structure of what the author is saying.
Having had a shower and coming back to this draft he’s right. Thats exactly what I want to be. Very strong at logic and coding and ‘alright to pretty good’ at the other bits.
Since I started in my young game development education (and hopefully, career) it was obvious to me that programming is a key skill, even if you are interested in many things. The reason is that an audio engineer can make great audio, but they cant make a game. An animator can make things move beautifully, but they cant make a game. But, before jumping to programming as the Almighty vocation, it, on its own, is not enough to make a game either. Thats when I found this term ‘Generalist’ and thought (in my brain, as my 4 year old would say) yes, thats me, or at least, that’s what I want to be but with a little tweak as I said above.
The article I referenced talks about making sure that you are ‘really’ good at one thing and then starting to branch out and understand other related areas. Thats kind of what happened to me when I was on the BA top up course. I had already started to look at Unreal Blueprinting and out of the class I was in, I clicked with it the best it seemed. That naturally make me the logic guy in all of the projects in which I worked and started me down that path of being good at that ‘one thing’. I am happy with that and have not deviated much from that role at all. For now.
My Vertical axis (depth)
This is logic. To me that means Unreal’s Blueprint at the moment. I have decided that I want to take this to the next step and that means learning to code in C++. There are two reasons for this. I want more access to the Unreal engine and I want to learn something thats industry standard and portable.
But, having had enough experience of creating mechanics, bolting some more on, and some more, attaching this to that (and it shouldn’t go there) and generally creating a Frankenstein’s monster of a prototype in Serial Link, its clear that learning a language is not enough. I am now just as concerned with learning how the think properly as I am about understanding the pointy end of pointers and a bit of bit shifting.
The solution to this problem is Design Patterns and the SOLID principles alongside the study of the C++ language itself. Its worth mentioning at this point that the development of Serial Link, a blueprint based project, is my stomping ground to exercise many of the goals that I have, particularly Version Control, Design Patterns and the SOLID principles. So I will be posting about that project and linking the work done there to those goals. For one thing, I want to take Serial Link forward professionally (I haven’t decided what that means yet) and the other is that its the most developed project I have ever worked on and so is that place that I am most often finding the sort of challenges my SMART goals cover.
The SMART goals that are associated with this axis are:
This one is much less fleshed out on the MA. And I’m not sure that’s a good thing so maybe I need to have a think about that. I think that the area that I feel the most limited and restricted in when developing Serial Link is animation. I would really, really like to learn how to animate 3D models. I have some interest in modelling but it is limited, as there is just so much out there in terms of assets and things that create them. But I have found that although, yes, there are also animation assets available and I already own a really good one, when it comes to getting close to the unique, special bits of the game, I have found that I need custom animation more than anything else. I think I have just found the need for a SMART goal.
Audio is another area that I would like to learn a bit more about but I am not finding at the moment that my lack of knowledge in this area is a serious limitation. I have some tasks of the Serial Link Kanban board to sort out some of the audio in Serial Link, ducking, occlusion and some other things and once I get to that task then I will learn (and be able to make immediate use of) those things. I think a SMART goal for that would be over the top and I am confident that I will just pick it up in this case.
Particles are another area that I feel that I wish to understand more deeply and actually on reflection, yes, it is a little limiting not knowing how to put them together properly. I think that it would be quite sensible to look at this as what I do know about the system is that it works in a programmatic and logical way. That means that its not much of a jump from where I am at the moment in terms of what I learning and how I am thinking. I do want to understand more about the artistic side of things too and how to create say, my own blood splatter or muzzle flashes and so on. I considered getting a tablet a little while ago and I just might do that as I can draw a little and I have used one before to draw this…
I drew this with a tablet a while back. Ibuprofen I think it was…
I think that I have just found another SMART goal for learning how to create basic particles.
In conclusion
I will be more sensitive to making sure that the content that I post is linked explicitly to the goals that I have set up while on the course. I will set up SMART goals for learning about Animation and Unreal particles system. I think that this post clears up some things for the reader and I am happy that it has allowed me the space to think about the other, less obvious areas of game development that I need to have a look at.
Continuing the work on making a component with a Single Responsibility, there has been some updates to the Bleeding Component. There is a link to the SOLID principles smart goal here.
So that this component is as portable as possible I have used variable types that are as high level as I can. Ultimately, I suppose that I would be able to pass the Bleeding Component a location vector only and that might be the way to go thinking about it. However, this is an Unreal BP and I would only be putting this on an Actor as its a Actor Component so I really don’t have much of a choice there! My point is that the only thing that I am passing to the events in that component that are specific in any way are Actors. Actors are defines in Unreal as ‘anything that can be represented in the world’. I think in this case that is high level enough. It makes the component very flexible and I’m happy that it would be able to be added to any type of character, robot, turret, vehicle or anything else, and work fine. The event prototypes are:
The ‘Projectile’ input is an Actor object reference and not an actual projectile blueprint class. That means that anything thats in the game world should be able to be used as the initial location for the trace.
Again, the Actor is just an Actor, but I think that’s a bit more obvious here! This event just traces straight down and find the first positive response to the Valid Blood Surface channel.
This one is a little more specific but I don’t think that its a problem. It needs a hit result to break inside the event and I am comfortable that a hit result is a standard UE4 data structure and would be valid in most situations. This could be changed to use the impact point and impact normal which now that I type this might be worth considering. Thats what I like about journaling, its that moment when I am thinking something like this through in order to explain and you spot some obvious improvement that could be made. However its worth mentioning that the Blood Spray is totally optional and if the user does not specify one, one will be chosen from the array that should be populated when the component is used.
This event is the one that would be called by the actor that was using it when that actor registered a hit event and determined in its own logic that a blood splat should be placed there. Again, this may be able to be slimmed down but to be fair, the hit event that would have triggered it in the first place would produce a Hit Result so it may as well just be passed right in, unless I find out that’s really expensive for some reason.
Commit
Drawing blood under the soldier when he is hit now happens from the bleeding component.
Drawing blood from projectile penetration from the bleeding component.
Enabled all of the physics bodies for the UE4 guy so that they generate hit events. I was only using the chest and head and then testing the velocity of the hit, but if he hit with his shoulder for instance, he would lose a lot of that force and not draw the blood when the chest did make contact with the surface.
Changed the penetration check to that if it does not draw blood, blood is drawn underneath the location of the projectile instead.
Added the suspended in the air effect to the weapons so that they can be plucked from the air. – Updated the weapon suspend in the air feature so that they can rotate a little, looks more natural
This was another small(ish) task that Jamie suggested would be good exercise and yes, it was. This is related to my ‘Learn to code in C++’ SMART goal and supplements the course that I have been taking on Udemy. So the idea was that I would create a simple console version of noughts and crosses that could be played in two modes. Easy, in which the computer would choose a random square based on the ones that were empty and Hard, in which the computer would seek to actively block the player usually leading to a draw, just like in real life. I wont show all of the program, includes, menu display functions and such, just the main function and the more important functions so as to illustrate the structure I went for. I wont be posting code like this in the future unless someone finds it useful as I dont think that the journal is really about that. I think that in the future I will post about the things I am finding challenging and what I am doing about that. I’m posting this because, if I’m honest, I’m kinda proud of this one. It took a while to get it all straight in my mind and it was a really worthwhile thing for me to do.
This is what I can up with…
1 of 2
2 of 2
I enjoyed this task and I learned a lot. I think that the next task is the Unreal Battery collector tutorial as I think I am ready to start learning about Unreal’s flavour of C++.
This is the problem. The Soldier actor is a crazy mess of tons of functionality, some of which is right, some of which is wrong and some of which just needs the plain ol’ delete key. But, I have a SMART goal regarding SOLID principles that is tackling this atrocity of a class. Ok, Blueprint. You know what I mean. I am applying what I am learning on the course and my own research to fixing as much of it as I can.
Single Responsibility Principle
This is the idea that each component, class, actor and so on is responsible for one, defined, activity. I understand this to mean that it should make common sense that a Weapon object could not reach into the Character object and make changes to the character directly, that sort of thing. If the weapon was heavy and needed to change the characters speed then there should be some other method by which that can happen without the Weapon being made to have a hard reference to the character or some logic that requires that the Weapon ‘cast’ to a very specific implementation of a character. Now, I may have some of this wrong at the moment and thats because I am still very much a beginner in thinking about these kind of design choices but I thought that I would start with something easily defined, not super complex but could be very portable if designed well.
The Bleeding Component
I decided to remove the following features from the Soldier actor and implement them in a component whose ‘single responsibility’ was producing gore in the world. Its a dark place to start I know, lets get on. So the functionality that existed was
Spray a blood particle from a location
Draw blood directly under a projectile hit location
Draw blood that would travel due to projectile penetration
Produce gore at a location, usually in response to a head shot or explosive going off.
Its not quite finished but now that majority of this is being handled in the Bleeding Component. This means that there is one place to edit the blood samples that are used for decals, one place to handle the tracing and other environment querying logic and so on. The other benefit of this is that is does not have to be just red, human like gore. It could just as easy be blue, dragon gore in another game and thats the point. I have really tried to take the Single Responsibility principle to heart and think in those terms now. I am very keen to start the course I have found on Pluralsight. I talk about that in the SOLID principles post.
Commit
Added logic to be able to track if the bullet casings are suspended in the air or not.
Added a new sound set of light metal taps that can interact with the weapon when it taps the casings when the casings are suspended in the air.
Used the velocity that the casing is travelling with to determine how loud the audio should play, this worked well and I would like to apply this to all the other sounds that are ‘hit’ based
Added a small delay to triggering the suspended in air effect so that the casing could leave the barrel a little further and it looks really cool, give the player much more of a chance the notice the feature
Came across a node called ‘get reflection vector’ and have used it on the kids bullets shield to properly deflect bullets and its better than the implementation I was using before.
Created a ‘BleedingComponent’ that I hope to use the centralise all the blood effects that are spread throughout the soldier actor. That way I could make anything ‘bleed’ like a robot that bleeds black oil and so on.
Have soldier’s body impact blood working from the new bleeding component – Have soldier’s blood spray from wounds working from the bleeding component
Yeah, I’m catching on that this is not the way… Image
Specific
I will learn about the SOLID programming principles so that I can write better software which will allow me to make better games and reusable components. I will do this by finding a beginner level course on a tutorial sight like Pluralsight and I will complete that course over the next 4 weeks.
Measurable
I will track my progress by making sure that once I have understood one or more of the principles I will use it in the design of my own code and logic. I will also know that this is complete when I can explain each of the principles to someone else.
Achievable
This is achievable because I have already created projects that are complex and show that I think in the right way. It could be argued that I have learned to create logic ‘the hard way’ and that the introduction of the combination or SOLID principles and design patterns will make writing code easier for me.
Relevant
This goal is relevant because I am actively pursuing a career in software development, primarily in games and I need to deeply understand the foundation of good design principles so that I can write better products.
Time bound
In reality, the study and practice of something like this will last for quite a long time and should be present in a lot of my design thinking, but I can say that I will complete a course and have a rudimentary understanding that will be a good jumping off point within 4 weeks.
Update – I have found a course that looks like its just the thing I need and you can get to it from here, there and everywhere.
After speaking with Jamie a while back on how I might go forward with learning how to code, he told me about some simple exercises that he would give an aspiring student. So, here is it.
This ties into my SMART goal of learning to code with C++ which can be found here.
But why?
Well, its a simple concept and the rules are very clear. The menu driven nature of the game makes use of loops with checking the win condition makes use of selection methods. The program is small enough that I should have been able to hold most of it in my head but large enough so that I would need to (or should at least) use functions to break up the common logic. Its a lightweight program to test the basics, perfect.
The program, well some of it.
I included all the headers I would need for basic stuff like input and output and I declared that I would be using objects from the ‘std’ namespace although I have already been taught to only declare the things here that you are actually going to use and not the entire namespace.
Then I created and enum for the choices so and created the function prototypes
This is the main function, simple stuff really. I like to break things up as much as I can so having all the menu choices lead to function call’s was good.
This is the first part of the play game function
And it finishes checking the win state
This is how the AI (if you could really call it that) made its choice:
And if the game was over, this was called:
what did I find difficult
The thing that I found difficult was the temptation to consider really slick ways (that I don’t know really) to find out if the win condition had been met. I was convinced for a while that there was some magical one of two lines of code that would be ‘the way’ to do this. Its a common problem from what I read about people who are learning to code like me. I like the way that Ben Tristem (Udemy Instructor) talks about it. Red, green, refactor. Although on closer inspection that appears to be a whole approach to software development. Mr. Tristem talked about it like this: When the code is red, its not working, do what you have to do in order to make it work. When it works, its green. Now its working, go refactor it into something elegant and efficient. I keep reminding myself that I have to write bad programs in order to write better ones and then when I have written enough of those, my code might be ‘good’. I get the feeling though that ‘good’ means different things to different coders…
Chronicles of a Sofa Ninja 