Tags: Betting, Cards, Coding, Games
Nearly everyone knows how to play Pontoon (otherwise known as vingt-et-un), and my game is a simplified version on a web page, where there is one player and a dealer/banker, but the person using the web app plays for the dealer as well; that might seem a bit odd, but my coding skill wasn’t good enough to automate the dealer’s play. I have adhered as closely as possible to the accepted rules of the game, and there is a link from the ‘front end’ of the site to a page which sets out the rules I have followed. It is possible to bet on the play, but not using real money, and it is possible to store a good score and return to it later. Although the game works, from a coding point of view, there is a significant drawback to making the game a web-based app, and that is that game play is often slow, and there can be long pauses when nothing seems to happen (hence the need for patience!); I only partially understand why this is, but most of it is the fault of the browsers themselves and, of course, they are not all the same. So I can only ask that anyone who would like to try playing my game can wait, if nothing seems to happen (some browsers will show you with a little message that the page is refreshing, or that the browser is waiting for more content to download), or with Firefox specifically, it is worth clicking on another tab, then clicking back on the game page, which usually shows the missing content: don’t ask me! Chrome and Safari seem to work best. The link for the game is this: don’t worry if your browser tries to tell you that my site is unsafe (because it is http:, not https:); and if you’re interested, I will give you below the background as to how I came to write the code for the game.
I should say that I didn’t set out to make a computer game, and I should also perhaps clarify that by saying that this most recent project is the latest result of my ongoing interest in what is now referred to as ‘coding’, after designing & building two websites: one for my publishing business, Wilfred Books, and the other for personal interests, including my acting, which I thought better kept separate from the publishing activity. You might well feel like asking: “Why would you want to go to all that trouble, when there are ways of making websites that are very simple, without the need for getting involved with computer code, and sometimes free?”; that is a very fair question, but I enjoy learning and being creative, and I know that I wouldn’t have found it in any way satisfying to just use someone else’s software that might or might not have given me the freedom & flexibility to design the site the way I want it to look, but also, I wouldn’t really have learned anything in the process (other than how to use that software, which I might never use again). Having the luxury of not being under any time pressure (apart from that of wanting a platform from which to sell the book I published in 2013) helped of course. Just as it’s not necessary nowadays to know how a car functions to be able to drive one, it’s not necessary to know how software is made (and there is a lot of it about!) to be able to use computers, but I’ve always found computers fascinating, so it was only natural that I would want to know what I could do with them, and on my own terms, wherever possible.
Just by way of a brief exposition of my background in amateur coding (in another life, I could perhaps have been a professional developer, if I’d started early enough, but I’m not going to do it now) I first started becoming interested in coding around 1986, when I was designing & selling built-in kitchens (as well as bedrooms & bathrooms) for a plumber’s merchant in York; the design element was of much more interest to me, given my background with a degree in 3D design, than the selling but, unfortunately, I had no other option than to do both. In the office I worked out of, there was a new Apple computer, the type that was then described as a ‘pizza box’, because the computer body was very similar in shape, with the monitor sitting on top. It had been bought, not to design the kitchens (that capability would take a few years), but to produce the lists of furniture & accessories that could be used for ordering & invoices, etc. The software had been made by a man in Norway, and it came on a large floppy disc, but resided in the computer’s memory while it was being used. The beauty of this computer was that it wasn’t a dedicated ‘workstation’, but a true personal computer (I will refrain from using the abbreviation PC, because that was the term the opposition, i.e., IBM, and later Microsoft, used), and it was possible to work with the system software at a code level, so I took the liberty of borrowing the manuals (and it was actually encouraged by Apple, at the time, to learn how to code for it) to learn the operating system, Apple DOS (Disk Operating System) and the code it used, AppleSoft BASIC. I wasn’t able to make any enhancements to the kitchen software (and that would have probably been a sacking offence, anyway), but I was able to make a very rudimentary word processor, in my own time, of course, which awakened my interest in what I could make computers do for me. When I moved to another company that manufactured mainly self-assembly kitchens, I was designing showrooms rather than domestic kitchens, and I was using the new Macintosh, which was reckoned to be the computer of choice for any design work (although much more expensive than the inferior Windows competition), and it was the confirmation of a lifelong preference for Apple computers.
I wasn’t able to do much more in the way of coding until the early 2000s, when I was kicking around ideas for a website, which was still a relatively new concept, but as I said above, it wasn’t until about ten years later, when I needed a platform to be able to sell my biography that I seriously knuckled down and learned how to build a functional website. The primary language for websites has nearly always been HTML (HyperText Markup Language), which is very easy to learn, and initially, it was possible to handle most of the screen formatting with it, but it was decided that it would be advantageous to separate that function from the content of the page, so CSS (Cascading Style Sheets) was born. Again, it is very simple, but over the years, its capability has increased almost exponentially, so that it is now possible to achieve very sophisticated page layouts with it; this takes time, much practice and plenty of patience to learn, however. That is all good, but it still is only able to produce, with some exceptions, a static web page that doesn’t allow for any interaction with the user, which is where JavaScript comes in; it is known as a ‘client side’ language, because the code can be embedded in the page, without any need to involve the server; i.e.: where the page is located.
Nowadays, many developers who use JavaScript use ‘libraries’ of code that have been tested extensively, and can be called upon to perform sometimes complicated functions that would be very difficult for the average developer to code; also: why ‘reinvent the wheel’? Having said that, using libraries is not a prerequisite: simple JavaScript code (such as I am able to write) can perform perfectly well. JavaScript can change the content of a webpage dynamically, but if input of data from the user needs to be processed, a ‘server side’ language is required. There are several to choose from, but when I was building my site, I was advised that PHP would be the easiest language for me to learn in a short space of time. This is where the story becomes slightly complicated, because computer languages are continually developing, so I had to make sure I was using the latest (but most reliable) possible version of the language which, inevitably, was somewhat more difficult to learn than earlier versions; also, because it is a server side language, any changes to the code have to be uploaded to the server first, before the web page will work correctly. This can be a time-consuming process, when a page is being developed & tested (and it is dependent on a good regular internet connection). There is a good alternative, however, for ‘local’ development: a server setup on your own computer, usually referred to as ‘localhost’. Luckily, recent Macintoshes have this facility built-in, but an easily-obtainable piece of software is required to use this facility.
So, having learned all this and put it into practice, I was able to produce two (mostly) effective, if not necessarily the most sophisticated, websites. Occasional maintenance & updating is required, but for the most part, these two sites can be left to function quite happily (although the ever-present need for security has introduced the necessity for me to consider moving the hosting of my sites, but that’s another story, involving cost, almost inevitably). I was ready for a new challenge, and learning a new language seemed as good as any. In the course of my reading on coding matters, I had seen that a language that was still relatively new, but well enough established to have been thoroughly tested and well regarded, was Python, and it is very easy to learn, but also capable of very sophisticated results, and there are many standard functions available, without the need for using libraries, although for specialised processes they are essential. Before I embarked on the learning endeavour, I needed a project to develop, and the game of pontoon was suggested to me, because whilst it would be relatively difficult, given all the permutations of card combinations, it would also be attainable for someone with my intermediate level of knowledge of coding.
First I made a text-only game, and this version wasn’t one I could share, because it isn’t a standalone app, but can only be used in the environment of a ‘terminal’ app; that isn’t as drastic as it sounds: it’s a way of emulating early text-only computers, where the user interacted directly with the processor, so a certain level of expertise is required, to avoid disastrous consequences, such as deleting all files on the hard disk! However, the code can be saved in modules that have been tested, so they’re safe to use, and the game was successful. I thought making a visual game would be far more complicated, but in fact, it wasn’t: once I’d designed the cards themselves, it was a question of providing a web page to hold ‘containers’ for all the cards (which aren’t visible until the cards appear) and writing a script for each new card, after the first four; however, being dealt an ace, and/or buying a card also required a separate script, so there are a lot of them! If I can be bothered, I might look at making a standalone app to play the game, that doesn’t depend on the vagaries of web browsers, but that won’t be for some time yet! So, if you do play the game, I hope you don’t experience too many problems, and I hope you enjoy it, such as it is.