A while back, I bought the domain name hack euch.re. I figured I was one of relatively few people with a direct connection to Michigan, who played Euchre, and who had strong enough ties to the EU to buy a .re domain name, and seeing that the domain was free, I grabbed it while I could.
Now I want to build a simple online Euchre platform for people to play with their friends and families. In addition to being something that I myself would use, this project also lands in the ideal zone of being small enough to start and finish in a reasonable amout of time as a solo developer, while still being complex enough to be interesting — both to me and to potential future employers.
A project like this is not going to happen overnight, but I hope that by keeping a public log of my progress on here, I can motivate myself to keep coming back to it at regular intervals. Most of my personal software projects that don't fill an immediate need tend to languish due to the abundance of other stimuli in my life drawing my attention elsewhere; here, I am hoping that making a semi-public commitment will suffice to counteract that.
On top of liking Euchre as a game, I also desperately want start a project not under any time pressure, so that I can actually slow down and do things the way they should be done. When developing for an immediate need, there is too much incentive to build something "quick and dirty", which cuts corners to get to a "just good enough" state as quickly as possible and then never evolves beyond "just good enough". But right now, the world needs less of that and more software done right.
This time, I'm going to Do It Right (tm).
When I publish the next installment in this blog post series, I don't intend to have written any code other than — perhaps — very small test runs of tools I haven't used before or have become rusty with. Instead, I'm going to write an actual spec, complete with the full rules of the game I am building a platform for, a high-level design, and at least some amount of component-level design sketched out. Too many developers talk about the importance of doing this and then either skip it or let someone else do it for them; I am going to buck this trend.
Doing it right also means building a fully extensible game. While there are limits to this — I am not designing for future developers who want to play Chess or Risk — I do intend to write a Euchre platform that could easily be converted into a Bridge platform. I also expect to design and write components that I might factor out for use in future projects, and will always be keeping that aspect in mind.
Doing it right also means writing comprehensive documentation as I go. While I don't know if I will feel comfortable straight-out open-sourcing my code with the knowledge that it might get used as AI training data, this is still a project I will want to share with other human beings. And they have a right to know how it works without doing code archeology.
Last but not least, the resulting game must actually be nice to use. This does not require following any particular aesthetic or fitting the fleeting fashions of web design in this very moment, but it does mean a clean user interface, actual images of cards presented visually as if in a hand or on a table, and styling beyond a very basic wire frame. I have minimalist tastes in web design and this game will tend towards minimalism, but it must not be ugly.
First and foremost, the resulting game must work, and allow the user to play the game of Euchre as I know it, over the internet with three other remote players. It must also work well enough that someone actually would play Euchre with it — no UI slowness, moves displayed to other players without unreasonable latency, etc.
The game must also be trivial to deploy, from scratch, on a fresh VPS. I like my current VPS provider, but I know I probably won't be there forever forever, and I want this project to still be as easy to move as a static site 10 years from now. This is also, and for good reason, a requirement of the general "doing it right" rule set out above.
The game does not need to support all possible variants of Euchre (of which there are many, depending on how you count). I would like to make rules like farmer's hands and sticking the dealer configurable, but would still be willing to consider the project done if only one configuration were available. As per the previous section, however, I will hold myself to software best practices regarding extensibility, and will not write spagetti code in which rules are hardcoded because adding options would break everything.
Finally, while I haven't made any decisions yet regarding the stack for this project, if forced to choose between two equally-promising options I will prioritize the tool most likely to get me a job. This will not always mean choosing the most widely-used tool — picking something entirely new and learning it along the way also fulfills this requirement — but it is a question that will always be in the back of my mind.
I've never written a public devlog before, so I will probably run headalong into blogging conventions that I have never heard of along the way. This is fine, but I do ask that people be kind if I break an unwritten rule.
Otherwise, I greatly look forward to this project. I have been meaning to start it, in various forms, for several years, and now it seems like it will actually happen. I have been away from Michigan for quite a while, and don't get to play Euchre very often these days; I'm hoping to use what I create to play more games of cards with family members and friends whom I don't see enough of.