Snap!
A case study of software development, featuring YOU and an idiot.
|
Snap!
A case study of software development, featuring YOU and an idiot.
|
Let's look at a software development case study. It's pretty basic, but draws in all sorts of interesting SD issues. Links ending with * indicate a slideshow download. |
|||||||||||||||||
| Feedback? Suggestions? Additions? Fixes? | |||||||||||||||||
I decide I want to create a computer game. So, that's a start. Me: I want to program a game. You: What sort of game? Me: I don't know. Just a game. You: That's useless. Be specific: first-person shooter? Board game? What? Me: A card game. You: Poker? Solitaire? Five Hundred or Bridge? Uno? What? Me: Something easy. For kids, maybe. You: What age kids? Me: Kid kids. Little tackers, like my nephew. You: That narrows it down a bit. All right, he's about six, right? What sort of card games would suit a six-year-old? Me: Oooh, I know. Cards Against Humanity! You: Age-inappropriate and copyrighted* . Have you ever even met a kid? Or a lawyer? Me: OK, smartypants. You come up with one. You: Snap. Me: Snap? I don't know that one. You: Did you have a deprived childhood? The rules of snap are really simple. Each player turns over the top card from their face-down pile. When someone turns over a card that matches a card already face-up on another player's pile, players race to be the first to call "Snap!" The player who calls "Snap!" first wins both piles and adds them to the bottom of their face-down pile. Me: OK. So what do we want our game to achieve and be like? You: You mean Functional and Non-functional requirements? Me: Probably. What's the first one? You: Functional requirements - what the game should be able to do. Me: Play snap. Duh. Do we want it to be able to email the results of each game to its players? That would be cool. You: Is the email stuff really essential? Me: Maybe not. And non-functional whatsits? You: Non-functional requirements: the qualities the game should have. Like accuracy, speed, ease of use, fun. Me: OK. So - kids. Not too smart. Not too dextrose. You: "dexterous" Me: Is that a word? 'Clumsy little people' is what I mean. You: NFRs in this case, considering the target audience, would include age-appropriateness, ease of use, affordance*... Me: What now? You: Affordance* - the ability of software to cater to the individual needs of its users. For example, to anticipate and deal with typical user errors. Me: I can see that. Dumb kids do dumb things all the time. Our game definitely needs to be able to deal with dumb users. You: So do I. Anyway... Other NFRs? The game needs to be fun. 'Cos it's a game. It needs to be responsive. Me: Responsive? You: It needs to react quickly and appropriately to user input. If it takes five minutes to play a card, it's not a good game. It also needs to be accurate. Me: So it follows the rules...? You: Well done, my little half-wit. Can you think of anything else? Me: I can think of that Barbie movie. You: Please don't. Right. We have a bit of an idea of what we want to create, what it can do, and what it should be like. Me: So, we start programming! Yay! I like that bit. You: No. We've done the analysis phase. Next is design. Me: De whatnow? You: We know what we're trying to achieve. Now we need to think about how we can best achieve it. Me: Oh, design! I love design. I designed this! You: Yes, that is a lovely skirt and it fits you perfectly. Me: (blushing) Oh, you are a tease. But, no programming yet? Sigh. You: Would you start laying bricks to build a house before working out the size of the house, what the foundations will be, and what rooms will be needed? Me: Probably... You: That's why I'm here. Let's start designing. You're going to say "How?" now. Me: How? You: Excellent. What needs to be designed? The algorithms. The user interface. Data structures. Me: Can I have a toilet break for a day or two now? You: Let's start with algorithms. Me: Must we? |
|||||||||||||||||
Coming up:
|
|||||||||||||||||
You: So algorithms. Me: No. They're dangerous! You: What? Me: They eat people. You: Not alligators - algorithms. An algorithm is a step-by-step strategy for solving a problem. For example, the algorithm to to convert Fahrenheit temperatures to Celsius: Subtract 32 from the Fahrenheit temperature. Multiply this number by five. Divide the result by nine. To work out if a year is a leap year or not: IF (year is evenly divisible by 4) Me: But looks like programming, but I don't know that language. Is it C? You: It's no particular language. Its pseudocode* - SYOO-DOE-CODE. It's a way of describing an algorithm without using the syntax of a particular programming language. Me: What are the rules of syoo-doe-code? You: There aren't any. Me: What? Hang on. VCE Software Development is ALL rules and stuff. You: Pseudocode has no rules. As long as it clearly describes the necessary logical steps to be taken to calculate an answer, you can write it anyway you want. Me: So, what instruction should I use to get data from the user from the keyboard? You: You decide - just be clear and consistent. You could use the commands INPUT, GETFROMKEYBOARD, GET, ASK - whatever. If you don't think your pseudocode instructions are clear, use internal documentation. Me: Anything internal sounds icky. You: Internal documentation*- comments in the code that explain its purpose. They are intended to be read by programmers but are otherwise ignored by the program. Me: So, what's an example? You: // this is a comment // user enters value from keyboard, stored in variable X INPUT x Me: So, I have to use "INPUT" in pseudocode to show a user inputting data from the keyboard? You: No. You could've used READ or REQUEST or other keywords, as long as the meaning is clear and you use the same keyword for the same purpose consistently. Like this: INPUT x WRITE x //write x to text file OUTPUT x //print x to printer DISPLAY x // show value of x on screen Notice how the internal documentation explains the intention of the keyword. The word itself is arbitrary. Me: Right. No rules at all for internal docuthingy. You: Except... Me: I knew it. I just knew it. You: There's a convention in VCE Software Development internal documentation. Assignment is shown by a left-arrow ← rather than by an equals sign =. Me: Dare I ask why? You: Many real programming languages show assignation - the storage of a value in a variable - using the equals sign, like this: X = X + V Meaning the value of variable X is replaced by the value of X plus the value of V. But the equals sign is also used as a comparator, like IF X = 0 THEN PRINT "X is Zero" So it's a bit confusing to use the same symbol for two different purposes. Some people might look at X = X + V and say, "How can X equal X+V? Surely X can only equal X, not X+V" So, VCE has a tradition of using the assignment symbol - the left-arrow - to replace the equals sign for assignation. It's not a rule... as such, but... OK. It's a rule. Just go with it and save yourself trouble. Me: Got it. I like rules. They make life easier. So, what sort of keywords are common in this pseudocode? You: You might often see keywords like this, all taken from real programming languages that most people already know: INPUT - get data from the user from a keyboard READ - get data from a data file FOR x = G to N - a counted loop using x as the counter, starting at value G and finishing when x = N WHILE condition ... WEND - an uncounted loop that continues while the condition (e.g. X>0) is true. You might see END WHILE instead of WEND. This is called a "test at top" loop because it only starts if the condition is true. If the condition is not true, the loop is never executed even once. DO... WHILE condition. This is like WHILE...WEND but it's an uncounted "test at bottom" loop because it's always executed at least once, and only stops looping at the end if the condition is not true. Other versions might be like LOOP WHILE...END LOOP and so forth. If their meaning is obvious, or explained in internal documentation, it doesn't matter very much. Just avoid strange pseudocode like LWT...EL - meaning "loop while true" and "end loop" that no-one will understand. Me: So, if pseudocode has no rules, how can it be compiled into a real working program? You: It never is. It's not meant to be. Pseudocode is a quick and easy general-purpose way of explaining an algorithm without relying on any one real programming language. The whole point is, a programmer can read the pseudocode and think, "OK, I get the general strategy. Now let me write this up in the appropriate real language using its correct syntax." Pseudocode is an artificial universal language that must be translated into a real programming language before it can become a program. Me: So - why are there so many different programming languages anyway? Do they do different things? You: Good question. Me: Hey! Yeah! What? Why? You: At the moment, there are about between 250 and 2,500 programming languages. Me: On Earth. You: Yes - what? Anyway, in the old days there were only a very few: some only worked on one particular computer. They often used machine code or assembly language to directly instruct the CPU - central processing unit - what to do. Machine code is the most primitive - it talks to the CPU using the instruction numbers that the CPU knows. e.g. Carry out instruction 164 using memory location 17129. No other manufacturer's CPU would know what instruction 164 meant - unless it was a clone of the other chip. So Intel's chip's instruction 179 might mean "erase", but AMD's chip''s instruction 179 might mean "copy". So, machine code was completely tied to a particular CPU and could not be used anywhere else. Assembly code was a little removed from specific chip instructions. So, the command "ERASE" might be written and on one Intel chip it would be translated to instruction 179, but on a different Intel chip it might be converted to instruction 88 because the chips were different even though made by the same company. So, assembly code would work on a variety of CPUs. We call that a "higher level" language because it was a little more removed from the really basic structure of the CPU it was talking to. The software that converts assembly language code to machine code is called a compiler. It's a translator. It takes human-understandable instructions and converts them to CPU-understandable instructions. Nowadays, hardly any programming is done with machine code. Most of it is done with high-level languages that are easy for humans to understand, but need to be compiled and translated for the CPU to carry out. It''s a bit like when your mum yells "Get ready!" at you in the morning. That's a high-level language. Your family's brain has been programmed to compile that instruction to specific actions: 1. Get out of bed 2. Get dressed. 3. No, you're not going out looking like that. Try again. 4. Eat your breakfast. 5. Take your lunch. 6. Give mum a kiss. 7. Now get out! So, there weren't many old high-level programming languages that could be compiled for use on many different types of CPUs. Some big ones were COBOL and FORTRAN. Me: So, they did different things? You: They were designed to make particular tasks easier. COBOL stood for Common Business Oriented Language. It was designed specifically to do calculations with money and finances. Imagine you're buying a calculator. You need it to do the taxes for your shop. Would you rather have a calculator with buttons for SQUARE ROOT, TANGENT, SINE, or one with PERCENT, PROFIT, GST? Each has its specialisation - one for science, one for business. FORTRAN (''Formula Translation") was designed to make scientific calculations easier. COBOL was designed to make business calculations easier. In a pinch, FORTRAN could calculate business stuff, and COBOL could do scientific stuff, much as a cat could theoretically fetch a stick and dog could theoretically walk gracefully along the top of a timber fence. It could be done, but it would not be easy. Since those early days, spin-offs of languages have been created to serve different needs. BASIC - Beginner's All-Purpose Symbolic Instruction Code - one of the worst acronyms ever invented - was a simplified spin-off from FORTRAN and intended as a simple language for teaching students. It ended up growing into a big, powerful language that could rival FORTRAN. Other languages appeared like C (and spinoffs C+, C++, C#) PASCAL (and its related languages), JAVA (not related to Javascript), Python, Scratch (a visual drag-and-drop language for youngsters), Ruby, Perl, SQL (for databases) and new ones evolve every year. Some are "higher level" than others, and programmers choose a language for a particular job. For example, C can do really low-level operations like reading particular memory locations and manipulating the bits in bytes. BASIC can't do those things because it's not not designed for that sort of work. It's like choosing a tool for a task: like, a hammer or a sledge-hammer. But the point is... Me: Yes? You: All programming languages all do much the same things. Me: No! You: Yes. They all have basic shared similarities, even though they may use different names for them. Like sports cars and tractors - they all share the same basics. Me: LIKE WHAT? You: That's next. Meanwhile, here are some more bananas.
|
|||||||||||||||||
You: So, what concepts do all programming languages have in common? Me: Dunno. That's what I asked you. You: Fair enough. Let's start with... Data needs to be stored while it's being processed by a program. But data comes in many different shapes and sizes. It would be very inefficient to store every bit of data in the same sort of container. Think of boxes. You need to pack everything in your house before you move - would you use the same size and type of box for every item you own? Glass, shoes, wide-screen TVs, jewellery, live fish? No - each needs an appropriate and space-saving container. Data comes in many types: like - integers - whole numbers with no decimal places. Counting numbers 1,2,3 etc. - floating point numbers - with decimal places, like 3.14159 - text - alphabetical letters, symbols and punctuation, like A, @, é Most programming languages support most of these basic data types. Others offer more specific variants because their users want or need them. Such as: - dates and times - like 11:34am on 12 May 2010 - Boolean - simple true/false values - Currency - for money And some languages offer subtypes, such as: - byte (numbers between 0 and 255) - short integer (-32,767 - 32,767) - double precision (bigger numbers, bigger storage needs). - character (a string with lenth = 1) - timestamp (combined date and time) - pointer (a reference to a memory location) If you store data in the appropriate data type, the programming language can store it in the smallest possible space and manipulate it more quickly. e.g. If you store a date as in a string variable... Me: String? You: Two or more text characters. Me: All right. these nanas are really tasty. You: If you store a date as in a string variable... like "12/5/2021" - that's fine. If you just want to look at it. But don't expect the programming language to be able to understand it. It's just a meaningless series of characters. But if you saved it as a DATE variable, the program would be able to interpret it and do calculations with it. e.g. Date2 - Date1 = the numbers of days betwen the two dates. Me: What about phone numbers? Store them as numbers, obviously. You: Obviously not. Phone numbers can contain parentheses, spaces, dashes, leading zeroes: none of which can be understood in numeric variables. e.g. +613 0243 6964 can't be stored as a number. Anyway - when would you ever need to do calculations on a phone number? Phone numbers are always stored as TEXT to allow the inclusion of special characters. Me: By the way - what exactly is a '''variable? You: A stored value whose value can be changed. Most stored values are variables. Me: "Most"? And the others? You: Some languages let you define CONSTANTS - values that can't be changed. Me: Why would you want those? You: It''s a story that will take more than one banana to explain, but - briefly... If you define a constant (e.g. PI=3.14159) knowing that its value will never EVER change, the program's compiler will not waste storage space for it. The compiler will just scan the source code and replace all references to "PI" with ""3.14159" whenever it appears. So, constants consume no memory. Me: Source code? You: The human writes source code. The compiler translates the source code into executable code (ex-ek-you-ta-bull) code that a CPU can read and execute. Me: I think I need another banana. And a snooze. You: Totally understandable. It has been a hard 5 minutes of education.
Me: So what delights do we do next? You: Juicy stuff like data structures. Oooh yeah... Me: Calm down, bananaboy. |
|||||||||||||||||
Data structuresYou: Let's start with designing data structures. You know about variables, I assume. Me: Sure do. I'm a legendary programming dude. The values stored in variables can have their values changed. Ha! Ask me a hard one. You: And constants. Me: Who's Constance? You: Constants. Me: Yeah! Of course I know - her. Um. You: A constant is a value that is assigned a value once in a program and its value can never be changed. Me: With all due respect, which may not be a lot, what is the point of such a ridiculous idea? You: A couple of things. Neither of which are worth the time to explain. Basically, using a constant prevents the changing of a value that must not ever need to change, such as Pi. Also, it makes a program compile slightly more efficiently. Constants are not very commonly used, but they can be handy at tunes, Me: I fully agree. You: I ever so glad.Now, a variable can store a single value, but when dealing with massive data sets, that won't be enough. Imagine you have to find the average shoe size of ten thousand people. How do you do that using variables? Me: Average = ShoeSize1 + ShoeSize2 + Shoesize3 + ... You: OK. I'm back from my holiday. How are you going? Me: ...ShoeSize9998 + ShoeSize9999 + Shoesize10000 divided by 10000. Whew. Where did you go? You: Bali. So, what is your conclusion? Me: I'm really hungry and need to go to the toilet. You: Exactly. When dealing with large quantitities of data, individual variables are useless. Me: You couldn't have just told me that? You: That would not have been nearly as much fun. So. We have arrays. Me: Yippee. Can I go to the toilet? You: An array is a data structure that can hold any number of values of the same data type. Each value is addressed by its index number. This lets you use loops to refer to all of the values automatically. For example, to simplify the shoe size example, you could use an array and a loop to do the job far more simply and quickly. Me: I really do need to go to the toilet. You: Like this: first we create an array called ShoeSizes with 10000 'slots' for its values. In pseudocode it might look like this: DECLARE ARRAY ShoeSize(10000) Now we can, for instance, read data from a file and store them in the array. Like so: FOR i = 1 to 10000
NEXT i To refer to an item in an array, give the array name and the desired index value in brackets, like Shoesize(3956) or Shoesize[3956], depending on the language you're using. As far as I know, all programming languages have arrays and loops. Loops and arrays are best friends. Then we can use a loop to cycle through all the values and calculate the average: BEGIN Total FOR i = 1 to 10000
NEXT i Average END Me: A couple of questions... You: What a surprise. Me: What's with the BEGIN and END stuff? You: Tradition. Not important. You won't lose marks if you leave them out. Me: And the Total You: Initialisation. It sets the starting value for a variable. Some languages' compilers automatically set a numeric variable's value to zero, or a string variable to null (empty) - but some languages don't, and a variable can contain a rubbish random value when it's first used. It's good practice to explicitly initialise variables before you use them. It guarantees a known starting value for a variable. Me: That's wonderful. Now if you will excuse me, my bladder needs a holiday in Bali.
|
|||||||||||||||||
Data structures continuedYou: Next: Stacks. Me: Stacks of what? You: Stacks of data. It's a very low-level data structure. Me: Do I really need to know about stacks and Linked lists? Could it be on the exam? You: It's mentioned in the study design's 'Terms used in this study', so maybe yes. I've asked VCAA if glossary terms are or are not examinable (2023-09-27). The Curriculum Manager says that glossary items are only examinable if they also follow "including" in a KK dotpoint. Stacks are listed in the glossary but not in any KK so they're not directly examinable. But they're nice to know... Me: So, what's next? You: The study design says for U3O1 (Unit 3 outcome 1) you definitely need to know:
Me: Records? Like the Beatles? hehehe. Dadstuff. LPs and vinyl? You: Records as in a collection of fields that describe an object. e.g. a record may be about a person with fields such as surname, given name, date of birth, address, suburb, postcode, account number, etc. Me: And associati-vays? You: Associative arrays? They are pretty basic arrays with at least two dimensions that let you look up one value and retrieve a corresponding piece of data. Me: Doctor Who what now? Dimensions? You: We mentioned before that an array is like a list of data items in a single structure. Like the rooms in a block of flats: flat 1, flat 2, flat 3, etc. Me: I remember something about bananas... You: So, a basic array has one column. But many or most arrays have more than one column, so they're like a table. And no - no legs. Me: Awww. You: A typical table, or two dimensional array (which has multiple rows and columns) may look like this:
Me: So - are there three dimensional arrays? You: Don't worry your pretty head about those. They exist - e.g. TEMP(location,year,date) but you don't need to worry about that just now. Me: I need bananas. You: Of course you do.
|
|||||||||||||||||
More information: - Arrays Program flow, e.g. loops Logical tests Functions Modules |
|||||||||||||||||
Data structure
Includes
|
|||||||||||||||||
Me: Are we EVER going to get back to programming a game of SNAP? You: Maybe, maybe not. We have barely begun design. So - what needs to be designed? Me: Bridges! You: Well, yes. Has anyone ever told you that they have furniture that's smarter than you? Me: No. You: That's a real opportunity missed. Anyway... Me: I'm a stable genius. You: No doubt, you belong in a stable. Anyway, what needs to be designed when developing software? Me: Tell me. You: Two main things: the front end and the back end. Me: Are you allowed to talk about those things with children listening? You: What I call the 'front end' is the interface: the part of the software visible to and controlled by the user. What I call the 'back end' (stop sniggering) is the programming that lies unseen but controls the processing and creates the user interface. A good front end makes a program attractive and easy to use. A good back end makes a program accurate and efficient. I told you to stop sniggering. Me: Sorry. hehehe You: Let's start with the front end - the user interface. The exam is most likely going to ask you to produce a mockup* for a screen display or a printout. It is an annotated visual representation of what a program or its output should look like. For example, this is a student's hand-drawn mockup of a screen interface:
Note how the relative positions and sizes of text and objects are demonstrated, and notes are attached to explain formatting features. You don't need to endlessly repeat yourself for every similar thing: you can just say something like "All body text is black, plain font, medium size", or "big fancy font, blue" to get your idea across. Me: But are mockups really done with pen and paper in the real world? You: Not really. Most professionsals use software to create mockups, but we're talking about students in fantasy Exam Land, where everything has to be quailtly old-fashioned. I doubt that VCE IT exams will be done on actual computers before a few decades have elapsed. Me: Banana time? You: Exactly.
You: So, the design of the interface for our game of snap is pretty basic.
Me: We both have ridicuously-expensive computers available, and you drew it by hand? What sort of cowboy outfit is this? You: Yes. Professional programmers will use software for most of their design, but we (i.e. you) have to get used to designing with pen and paper because - exam. That reminds me - it's wise to take a variety of ink colours for the exam so you can make your design a little more expressive. Me: What's the "H1" stuff? You: It refers to "Heading 1" style. Maybe it is a bit obscure, I admit, but as long as the examiner understands your intent, it may be a safe abbreviation to use. Keep in mind that your MAIN OBJECTIVE in an exam is to persuade the marker that you understand the key knowledge of the course. The markers are usually experienced IT teachers and will understand standard jargon and expressions, but don't try to too clever. And especially don't mis-use tech terms. Confusing bits and bytes, efficiency and effectiveness, data and information - you will suffer. Me: OK, So what is "Heading 1 style" stuff? You: O - K. ELI5 time... Me: Explain 'ELI5' to me like I'm a five year-old. You: Styles are common in word processing, desktop publishing, web design - any medium where you want to define the appearance of text or an object. You could, for example, throughout a document or website, format the text of every main heading as "Bold, 20 point, black, sans serif, italic". That would work. But what if you wanted to change the appearance of every main heading in a 1000 page website? That would be a monstrous amount of editing. BUT! What if you could define the style of a main heading, a sub-heading, etc once and just mark text as using that particular style? In that case, one change to a style definition automatically affects any text or object that uses that style. It's perfect. In webpages, it's done using CSS (cascading style sheets). Here is what this site's CSS style choices look like:
For example, on the vcedata.com site, whenever text needs to be formatted as programming code, it's just marked as using the CSS tag called 'code' which currently looks like this: .code { font-family: "Courier New", Courier, monospace; color: #0B419F; font-size: medium;} So, the line above, when tagged with the CSS ".code" style, would look like this .code { font-family: "Courier New", Courier, monospace; color: #0B419F; font-size: medium;} To make all code on the site look different, a simple change to the "code" CSS tag will immediately show up for every piece of code on the site. In word processing it's done with style definitions. Try it. It will change your life. Me: So, styles are like veganism? You: Yes, but far less annoying to have to listen to. But, back to design. Me: Yay? You: In the case of Snap!, the appearance of the interface is basic. Most programs are far more complex and need to handle factors such as different screen sizes, resolutions, and orientations. Printed output also needs to be mocked up, but it's not relevant to this case study. So, what else needs to be designed? In this case, the menus, and the program's algorithms. Me: Can't we just skip it and jump straight into programming? That's the fun bit. You: We covered this. Starting to program without thorough design is like starting to swim the English channel without any training or support team. You will probably drown, but even if you eventually get the job done, it will be slow, expensive, painful and ugly. The person paying you for the software will NOT be impressed with the delays, errors, unnecessary extra costs, and incompetent performance, and you will NOT be hired again. And many programmers are freelance and get hired based on their reputations for efficient and effective output. Me: So, menus? You: Right. Menus. What do you know about menus, and don't say appetisers and dessert. Me: Damn. OK. All programs have a File menu. Most have something like Edit. And they all have Help. At least Windows programs do. You: Have you every wondered why? Me: I wonder about lots of things. Like why you dress the way you do. Really, dude. Jeans and a top hat? You: I call it 'casual chic', but shut up. Menus follow pretty strict conventions. Users expect certain things, and if you decide to be 'creative', you won't impress them: you'll really annoy them. Imagine if you were are car designer and decided to switch the positions of the brake and accelerator pedals because it's new and exciting. People will hate you - if they lived that long. Rule number 1 of programming: give users what they expect. Me: You have a lot of Number 1 rules. You: Yeah, and there are many more to come. Do not try to be cute and imaginative with your user interfaces. Make them traditional and predictable. For example: where would you go to find the current version of the software you're using? Me: Easy. HELP > ABOUT. You: Why? Me: Um. Because that's where the version information always is. You: And why is that? Me: Is there some sort of law? You: Maybe there is. Computer platorms like Windows and Apple have style guides that lay out how software written for them should look. Some guidelines are just recommendations, but others are more like rigid laws, and the companies will not publish software that ignores their style guides. So, that's why users instinctively go to HELP > ABOUT to discover the version of their software, and they go to FILE > EXIT to quit. Follow conventions. It's not being boring and unimaginative: it's helping all of your users. Users do NOT want to have to learn where each programmer cunningly hid the version information, or how the programmer creatively invented a totally new and mysterious way to end their program. You do not want your uses to hate you. Me: So, menus for Snap? Let me have a go. FILE
EDIT
WINDOW
HELP
You: I'm strangely impressed. Did your mother help you with this? Me: She hasn't done any serious software design for months. You: I need to sit down and have a banana. Me: I have that effect on people.
You: So - next thing to design - data structures. What is the most important data that needs to be stored for a card game simulation? Me: A deck of cards? You: Surprisingly good answer. And what available data structure would best do that? Me: An array? You: Good. Let's use an array called DECK with 52 elements, or slots, to represent the cards. What data type should the array be? Think about what information the data needs to store about simulated cards. Me: Thinking... well. We need to be able to say that a CARD(44) is like, 'the four of clubs'. So - string? You: Makes sense. Be aware that there are different ways to solve the same problem. Some use less memory and/or are easier to program and/or run more quickly. We call those solutions "elegant" because they''re efficient and clever. There are also "brute force" solutions that get the job done but are wasteful or ugly. We always aim for elegance when we can. So, let's think ahead to how we will need the data to work. When playing Snap, what information about the cards is crucial to gameplay? Me: Umm. We need to see whether the top two cards in the 'discard' pile are the same... You: Same... how? Colour, suit, rank? Me: Rank. Like a pair of sevens or Jacks. Suit is not important. You: Right. So to compare two cards, we need to be able to access their rank, but we also need their full identity (suit and rank) so we can draw them onscreen. If we only stored each card's information as a string like "four of clubs", can we access the card's rank to determine when we have a Snap event? Me: Oooh. Well, we could cut off the first part of the string before the first space and use that as the rank. Sort of like: Function FindRank(cardname)
End Function So, FindRank("four of clubs") would return "four". You: That could actually work. Me: Don't sound amazed. Remember, I'm a stable genius. My mum told me so. You: Your strategy is heavy on processing to get the required information. An alternative would be to store the rank of each card separately, for example in a two-dimensional array. This would reduce processing needs at the expense of storage needs. These sorts of trade-offs are typical in programming: you can either save processing or save storage, but rarely will a technique save both. The functional requirements of the software will guide you in your choice of solution strategy. Me: I agree. You: And your understand? Me: Partially? You: All I mean is that in programming, you have to balance processing and storage needs to reach an optimal solution. Right. For the moment, let's go with your data design and move forward to algorithms. Right. We have an string array to represent a deck of cards. We need to initialise the array - give it its starting values. Something like "Ace of Hearts" down to "Two of Spades"... Me: Hang on. You: What? Me: This seems to be getting really complex - with the suits and the ranks. But Snap doesn't refer to card suits, does it? We don't need suits. We just need ranks. And we don't even need the ranks of a standard deck of cards! We don't need to slavishly simulate a deck of standard cards just because in real life it's easy to find a deck of cards. We can create our own deck digitally for the game. We could have... instead of two, three four... jack queen, king, ace, something better for our target audience: kids! What about 13 different animals? We could have a deck of 52 cards made up of four copies of 13 animals. Kids could go Snap! when two cows or roosters are dealt. They could even yell out the animal noise instead of saying "Snap!". You: Go on. You fascinate me. Me: And it doesn't have to be just animals. We could have any class of objects with 13 different instances: like actors... You: Tractors... Me: Nuclear reactors... it doesn't matter. In fact we could produce a series of versions of the game with different themes: Tractor Snap! Actor Snap! We could corner the Snap! market. You: It seems that brainstorming can be a useful tool. OK. Let's reconsider the data structure design then. We need storage for ... what? Me: The cards in the player's hand. The cards in the program's hand. The stack of cards laid down by the players... You: So - three arrays? Why don't you sketch out what you have in mind. I need a ripe banana.
|
|||||||||||||||||
|
All original content copyright ©
vcedata.com This page was created on 2023-09-15 |
0
s
Hash tables
