12
votes
If I wanted to make a game like Wordle, where would I start?
A lot of game engines are geared towards making full-fat games with 3D graphics and animations and sound effects and all that jazz. What if, instead, I want to make something dead simple, graphics-less, and minimalistic -- like Wordle? What's the best way to get to something like that (almost more of a digital toy than a full-fledged game)?
It doesn't have to be web-based at all (though it can be if that's easier? I'm genuinely not sure). My preference would be for open-source engines/tools, but that's not a necessity.
I would recommend starting with just vanilla JavaScript for the prototype. For something like wordle you should be able to get it working in less then a page of code. There really isn't much complexity to the game and the bulk of the code will be UI.
Some of my friends recently golfed a wordle game down to only 214 bytes of html and javascript, not that I would recommend going for that small initially!
https://xem.github.io/MiniWordle/wotd.html
For a slightly larger game I'd recommend checking out my open source javascript game engine LittleJS.
https://github.com/KilledByAPixel/LittleJS
Seconded on this comment.
Just HTML, CSS, and JS is all you'd need for something like this. I wouldn't start with a JS framework like React or Vue at all--what they bring to the table is just not going to be necessary for something like this, and will only add an up-front setup step just to use 1% of what they can do, and you'll still have to use HTML, CSS, and JS anyway while working with them.
I'd maybe recommend a CSS framework like Bulma if you want pretty UI elements right away, but even that's going to be an up-front setup step that will still require you to know CSS anyway and introduce confusion as to where base CSS ends and the framework begins, so possibly just skip that too.
Taking a beginner course in HTML and CSS for the interface and then focusing some learning into vanilla JS for the game logic will get you to a great starting point. Then if you ever need more presets from CSS frameworks, or more modularity and data handling from JS frameworks, you'll already have the fundamentals down that will make learning those simpler.
Web based will be the easiest. Games like wordle are more UI than traditional game - it’s all about buttons and text, and modern browsers are far better at rendering buttons and text than any game engine is or ever will be. UI in games tends to be pretty painful and requires a great deal of custom assets and hard coded dimensions.
Any modern web framework will do. By now, React is old (by web standards), battle tested, and mature so I’d recommend React. Large ecosystem of components as well.
This isn’t an enterprise application. There is zero need for a heavy framework to get a simple word game to work properly.
React is light, but mainly it’s about the support for a mature framework. Manually modifying the DOM is a bit of a lost art by now. There is, however, an almost infinite number of guides, stackoverflow posts, and tutorials for react for practically anything you could ever want to do with React at this point.
What? I'm sorry but this does not make sense to me. The DOM is not anywhere near as complicated as React's model, in part because it is a strict subset of that model! OP would be fine either way but this statement really boggles my mind.
It's not a subset, though. It's like the difference between an API like OpenGL's and manually filling in pixels in software rendering. At some point, pixels need to go into a matrix. But the API is entirely around different primitives, and the rasterization is done transparently deeper in the stack.
Modern shadow DOMs do at some point modify the DOM, but like a modern graphics pipeline, only after using the internal model to compute the final result. Using the shadow DOM to compute the real DOM diff is like rasterization.
In any case, just as throwing around polygons in OpenGL is very different from a developer point of view is from manually rasterizing bitmaps, working with react's shadow DOM is not particularly close to manually modifying the DOM.
Manually modifying the DOM is in many ways simpler from a conceptual point of view, that's not really the optimization here. The optimization is resources. If you want to do anything particularly complicated, that path is paved in React, whereas the old jquery style of web development has fallen by the wayside, and so has resources like SO posts or the ever increasing avalanche of oddly specific blog posts. You could certainly make wordle without React, it's not particularly complicated in UI, but in recommendations for a beginner I greatly value never having to walk where no one else has walked.
I really think this is not a good analogy. When you use something like OpenGL, you may never have to think about rasterization or pixel coloring at all. OpenGL replaces software rendering. When you use React, you still need to understand the document. React is strictly an additional technology, on top of HTML and CSS on the layout side and JavaScript and TypeScript on the behavior side. It is a very useful additional technology - I've used it extensively in school and at work - but I do not think telling someone who wants to, essentially, lay out a web page and change the colors of some
<div>s, that he needs to learn about JSX,useState/useContext, the difference between HTML elements and components, and reducers in addition to the existing complexity and weirdness of JavaScript and CSS, is at all helpful.Yes, it is. OP says: "I want to make something dead simple." React may be better in some meaningful way, for some projects, but it is decidedly not simple.
Calling the foundational technologies of the web a path "no one else has walked" is just not accurate, either. There is much written about React, it's true; but there is far more written about the baseline APIs the browser provides, and more than that, the code one needs to write in order to display a grid of colored tiles, whose colors change with input, is dramatically less when not using React.
And, of course, none of this is to mention the build process. The build process for a HTML page with vanilla Javascript is... nothing. You need zero tools. You can write the entire thing in one, single HTML file, and distribute it to millions of people that way. If you want to use React, and especially if you want to use React libraries, you need to think about
npmor content delivery networks.React is fine, and it's great for some things, but frankly it is much more complex than the HTML/CSS/Vanilla JS alternative, and recommending it to someone whose focus is on simplicity is unhelpful at best.
I think we'll just have to agree to disagree because I still firmly disagree.
It is true that OpenGL diverges more from rasterization than React does from jquerying your DOM, but the latter are still fundamentally very different things, especially since the domain is not the document model as a whole, but specifically how DOM modifications happen. You will, of course, need to understand the HTML document structure regardless, but there is a world of difference between how the updates happen.
Manually inspecting the document, then mutating it is very different from the declarative structure of React, where from a developer point of view, you are essentially rebuilding the entire document structure every update (of course, this is optimized into mutations behind the hood, but you need not know that).
If you know how to write React apps… you really don’t know how the equivalent raw dom mutations work and vice versa. They’re not transferable, and I would certainly not call either a subset. You need to know the document structure in both, but the updates are just completely orthogonal.
Yes, the JS ecosystem is always a pain, but it has gotten significantly better now. With something like Parcel, you do very little finagling with the JS toolchain.
Finally, the most important thing is that it is very much an untrodden path these days. JQuery is relegated to relatively minor UI elements, whether it should be or not. Just a google search for "react worldle" nets you a bajillion responses, from which OP can look to for inspiration. Having working examples of wordle when you’re trying to make something like wordle is pretty damn useful. You can see how others did things, or even clone the repo and play around with it.
https://github.com/cwackerfuss/react-wordle
https://bestofreactjs.com/repo/hannahcode-wordle
https://medium.com/@haniyehasemi/clone-of-wordle-game-with-reactj-77ca3de99fa9?source=topics_v2---------22-84--------------------e3247cbc_8613_4327_a13b_45ee69d2fb35-------19---
On the other hand, it's difficult to even search for some no framework, raw DOM mutation style of javascript interfaces. "raw js wordle" gets nothing useful, "jquery wordle" also gets nothing of use.
React's developer community is just way more active, and it's way easier to find resources. The extra setup of libraries is easily worth being able to walk a few steps and find twenty people you can ask for help.
Okay - we can agree to disagree, but I do want to make a final point for other readers.
First, a clarification: I am not talking about JQuery. I am talking about native browser APIs. This means that the entire development process is much simpler. When you say:
you are missing the point completely. No matter how much easier it is to search for help with problems you might encounter with the JS toolchain you have to install, that will never be easier than not having to install or use a JS toolchain and ending up with less code anyway!
.html.getElementById.Whereas, with React, at minimum, you need to:
This is ridiculous. It doesn't matter how easy it is to crib from someone else in the actual coding step when the process of setting up the dev environment and distributing the software in one process will take more effort than the entire lifecycle in the other!
EDIT: Also, searching "vanilla javascript wordle" turns up four full tutorial videos and, if you prefer text content, several posts and repos. I don't really understand why you said that "it's difficult to even search for some no framework." That seems to be simply incorrect. (And, again, I did not mention jQuery even once.)
There was once a point in which I was upset that my duties had moved away from actually building software to managing prewritten enterprise software and SaaS. With vanilla javascript now being relegated to the "Wizard" section of my resume, I no longer have regrets.
React is the most popular, but I think if OP is a newbie then Vue's all-in-one components might be easier.
cc: @Adys
This is spot on for what I want. Basically I want to be able to make buttons that take and respond to input, and then play around with my options from there. While I could do the Wordle-specific stuff on the command line, the end product I'm envisioning does have some sort of UI because that's more of what I'm interested in exploring.
This is thinking WAY down the road, for example, but if this is something I take to, I could see myself making tools for my students to practice different skills in (something like ThatQuiz, for example).
I recommend some separation of concerns. Starting without a UI at all will allow you to grok the game logic side of things.
Once you have that to a T, then you can move on and start thinking: Okay, how do I turn this printed output into (for example) HTML elements that look pretty?
At that point, I second the recommendation of playing with react. But that itself requires quite a bit of setup.
When you're starting with development it's extremely important to keep things small and contained. Otherwise, you will be absolutely overwhelmed by the massive amount of new information, and eg. start putting game logic in UI, UI logic in game code, and the whole thing will become a frustrating mess to work with.
In fact, if you were designing a real new game from scratch, a common advice from game designers is actually to start with a pen & paper prototype!
I want to throw my voice in here in support of Adys's approach. If you've never programmed before, it's going to be a challenge just figuring out the basics of how the game logic should work. Get that figured out with a simple text-in-text-out program first, without the distractions of HTML, CSS, DOM manipulation, state, props, etc. Even simple web applications can be really complicated to a beginner.
Once you have the working command line application, then there's nothing stopping you from taking what you've written and changing it around to be a web app.
Just to nitpick a tiny bit, I think it's quite useful, depending on the game, to actually think about state. It's the one thing that's inherently tied to the game logic and super important. Basically, find a game you can do in text mode - wordle, TicTacToe, whatever - and identify the state and the state transitions. State and state transitions are the game logic.
But agreed, the rest is kind of unnecessary and will initially be a distraction.
Ah yes, I meant state as in the React construct, not general state of the game. You're completely correct about game state; you can't make a game without that!
Start with what you know.
If you know some python or a similar scripting language, you could make a simple CLI prototype. In fact, I started one for you, in 30 lines of code.
Spoilers: https://gist.github.com/jleclanche/9e84bc8018137e12ea12be1708248d9a
Start from there, try to add a dictionary, randomize solutions, try using termcolor to add some colors to the answers, add a max guesses, add a time limit, etc :)
Who's your audience, and what programming skills do you already have? I think my answer to this question would be "use what you know, and if it's not sufficient, use what you want to learn."
I mean, I think React would be a great framework to write a game like Wordle in. Of course, I'm a professional React developer. If you've never touched the modern JavaScript ecosystem, there's a lot of prerequisite learning that could be avoided if you already know Python or C++ or HyperCard or something. If there's a language you've been wanting to pick up, building a simple game is probably the best (and funnest) way to dive into it.
If you want to build for a particular audience, obviously that will influence your decision too. I would have fun building a command-line exclusive game but that would limit my playerbase significantly. Likewise if you build a non-web game you'll need to find a way to get it in front of people.
My audience is me, wanting to tinker around and scratch a long-standing curiosity itch. It existed way before Wordle, but now that I do it every day I'm reminded of it.
My programming skills are as basic as they come. I took some CS classes a long time ago and know some ultra-simple stuff, but that's it and I never kept up with it or moved past that. Essentially I'm asking as a novice starting from almost scratch, but it's less about programming basics and more about which tools I should use. I learned on Java back in the day, for example, but that's the last thing I'd want to write a Wordle-clone in.
In that case, I'd suggest you dive into vanilla JavaScript (or TypeScript if you're feeling it). There are plenty of tutorials available to get you up and running quickly. If you're intimidated by HTML/CSS, you might even consider stripping away the GUI altogether and build a CLI game with Node.js. This has become a favorite environment of mine when I just want to compute something quickly... it's nice to run JS directly from the terminal.
Alternately, and this is heresy in some circles, you might consider PHP. It's somewhat Java-like and dead simple to get into quickly. Of course, this would mean your Wordle game would run server-side and require form POSTs each turn, but that's a perfectly valid approach too.
If you just want to fuck around a bit and see what you can pull off, start looking into general purpose programming classes. Basically, you'll want the basics of programming, and you'll need I/O. That is, reading input from the user, and outputting info back to the user. To make a simple game like TicTacToe or Wordle, console I/O would be sufficient, that is, you'd play the game by reading from and typing into a command-line. If that is sufficient for your demands in terms of aesthetics and UI, you can already get going. If you end up doing this, be sure to show us the code you came up with; for an absolute beginner project, there's bound to be tons of useful improvements one could make.
A common problem after learning the above skills is conceptualizing the task of making the game and breaking it down into smaller steps. Some useful avenues here, looking at the above games, would be: How do we store the state of the game - that is, the state of all things we have to keep in memory while running the game? How do we display the state? How do we gather input? What state-transitions do we need to do in between the above steps, and when? And most importantly, if any of the above results in a multi-faceted or complex setup, are there any commonalities and regularities we can exploit?
Mentioning only because it’s pretty different than other advice in the thread. If you’re looking for something that can kind of maximize fun value and ease of getting to a real game, I had a total blast with PICO-8, which I did with my son.
https://www.lexaloffle.com/pico-8.php
It is intentionally very slimmed down, and it won’t make you learn good programming practices, but it is fun to follow some of the tutorials and play around with them.
I'm making a game inspired by Wordle right now too!
I feel like an actual game engine would still probably be the best option for you. A lot of people are saying web frameworks but these can honestly be a hassle to setup, where most modern game engines are easy to install and run without almost any fuss. Plus if you end up wanting to make more complicated games, you'll have the environments setup to do that already. Not to mention, all of the boiler plate code for event listening (key press, mouse click, mouse move, etc.) and graphics are already taken care of in most cases.
I use Unity because I have toyed around with it for years and work professionally with C#, but I know Construct and Game Maker can be used with little-to-no programming. A lot of people also seem to like Unreal, although I've never used it.
The only downfall of using these engines is that they can be kind of confusing to navigate at first, but there is a ton of resources to get you started. If you're still not sure, and can provide more info on what you already know, I can help specify a bit more for you!
Unity is a neat game engine to start with but has a steep learning curve.
You could play around with Scratch, actually!
But really, for something minimalistic like Wordle, you don't need anything. Recommending JS or game engines is crazy overkill already. You just have to get to the root of the game logic and start with that. You don't really need anything beyond a way to input a 5 letter word, and a way to output a text response. Wordle is some deadass simple IO.
Yeah unfortunately even something as simple as Game Maker is going to have a pretty big learning curve for anyone not familiar with game dev.
That being said, I did miss the part where they said "graphic-less", so any game engine would def be overkill. You had mentioned Python else where, which I think is the correct answer here. Would be a simple program even for someone with no coding experience.
There is no "best" way, but rather many different ways, each with their own tradeoffs. Any of the methods described in the comments so far would work.
That said, I've made a few simple toy apps before that run completely in a browser with just HTML/CSS/Javascript and no server-side help. For example:
I've also thought about making a small wordle clone so that I could add a feature to the game, and would use the same approach if I went ahead with the idea.
But that's just me, I find frameworks to be limiting and I prefer going with the basics for a project if I can help it. I know there are many who prefer frameworks for the structure and reusable components they provide. For someone like yourself who's just starting out, you don't know yet which way is best for you, and it will take some time to learn what suits your needs and preferences.
So rather than trying to figure out which way is best and trying to optimize the choice of language/library/framework/engine for your game, I think it's more important to just pick a solution and go with it. That you make a choice is more important than the choice made at this point.
I see a lot of "Js, css, and html" here, which is to be expected, but I'd actually suggest you focus on SVG specifically. It allows you to make any kind of basic shape and it's going to be better for laying out games than hacking html/css.
Just to clarify: SVG is a great format for graphical assets, but it's not a programming language. You would still need JavaScript for the game logic, and HTML as a wrapper around the whole thing.
Some of the advantages you get from working with SVGs, like animations and style overrides, are fairly advanced techniques I wouldn't recommend for a novice. And they still involve JS and CSS, so you really can't get away from it if you're targeting the web. I absolutely recommend using SVGs for lots of things, but for someone who's just starting out maybe focus on the good old HTML/CSS/JS trifecta and only add complexity when they're comfortable with that.
Side note, if someone was really interested in building for the web, and also really averse to using HTML/CSS/JS, they might want to play around with WebAssembly and see how it suits them. You can write all your logic in something like C++, Rust, or AssemblyScript and compile it down to a binary. Render everything directly to a
<canvas />. I've never done this but I'm curious to try it sometime. I have no idea how natural it would feel to someone with Java experience but not much else.It's not Turing complete, but it's pretty unequivocally a language in which one can provide instructions - programs - to computers.
Yes, you would still need JavaScript, but saying something isn't a programming language because it doesn't have loops is not really a useful distinction in my mind.
I think we're splitting hairs here. As a subset of XML, SVG is a markup language whose purpose is defining the presentation of data. It's in the same category as YAML, Markdown, or to stretch things a bit, DOCX or PDF or UTF-16. Technically all of those provide instructions to computers, but we don't designate them as programming languages. Not just because they don't have loops, but because they don't receive and transform any input; they are fully self-contained blobs of static content.
Yeah, absolutely. I don't think it matters that much, but I do often see people gatekeeping frontend design and development as "not real programming", and I try to nip that kind of thinking in the bud when I see it.
You can write lots of things that are unequivocally programs which can also be described this way. For example:
I hear you, and I think we're more or less on the same page then. I'm a frontend developer by trade so you won't see me gatekeeping myself out of a job, lol. Probably best not to derail this topic too much with semantics.
That said, I do want to address your example code because it's genuinely interesting (this isn't a flame war, just a fun thought experiment)... I think an argument could be made that, because it doesn't accept any input, it's not a program (even though it's written in Python). It's just an unconventional format for static data. A highly optimized format, roughly equivalent to a .zip file. It's still wholly deterministic and produces the same output every time you run it.
In this specific case the analogy's a bit strained because of the infinite recursion, but it's not so different from a zip bomb in that regard.
So according to that definition of a program, I think it's valid to say that a programming language CAN be used as a format for static content, but a markup language CANNOT be used to write programs. Which I guess is another way of saying Turing-completeness should be the differentiating factor between the two.
See, this is exactly the kind of philosophical discussion I love to have about this stuff! You're absolutely right, I think there's a real distinction to be made there. But I think that if we think of a program as something as an input and output, why couldn't we define HTML+CSS like this:
I think it's ultimately down to personal preference. But it's super interesting to think about, and depending on what you count as input I think you could expand "document format" to almost all programming languages or, inversely, "programming language" to almost all document formats!
HTML/CSS is meant to lay out print. And Canvas is way overshooting the mark IMHO. You need JS to make SVG "interact" in a lot of ways you'd expect a game to, but taking someone with 0 knowledge and facing a path of either:
A) Learn HTML => Learn CSS Block layout => Learn How to hack it up in an ugly way to make fun shapes for a game and layout pieces "spatially" (which it is not meant to do) => Then add JS on top of that
B) Learn just enough HTML & CSS to position an <svg> element in the middle of a page => Make some shapes in SVG (literally "<circle>") and in the declarative way that SVG prvides, indicate the coordinates you want it to be at... it's just much more intuitive and has a lot less "stupid surprises" than CSS does. After doing CSS for like 30 years you tend to forget how many of those there are. "Make a shape, put it there" is much easier to learn from scratch than "Block, width 80%... oh wait wait, but box-sizing: border-box... and don't forget the outline yada yada yada". I'm not one of these guys that "looks down" on CSS - I actually love it. But I'm sticking to the recommendation of SVG just on the grounds that it correlates directly with making a game more. You want to be a professional Web Dev? Sure, go hog wild at CSS, but that's not what the OP asked for. I bet they would have a lot more fun with SVG. You can see it immediately and start making funs shapes and move the numbers around as you like - it has lots of easy free editors and it's open source as OP asked for. OP asked for something that would be fun to play with and everyone jumped at them with their favorite convoluted Web stack. The recommendation for SVG stands.
Hey, I did something similar recently! I built a dead-simple quiz game for practice for university - no flashcard program or similar did exactly what I wanted, and I had been looking for an excuse to play around with JavaScript. Although I have a fair amount of programming experience, I hadn't ever worked with JavaScript itself before.
The two sites that helped me the most were javascript.info (JavaScript tutorial) and MDN Web Docs (reference for everything web-related). I already had a solid understanding of HTML and CSS, but if you don't, I recommend Interneting is Hard as a great introductory tutorial. Other than that, I looked up a tutorial for a simple JavaScript flashcard program to give me an idea of where to start, and then just played around, starting off with the UI, and then getting my program to update it, bit-by-bit.
Building it for the web is probably the way to go for a couple of reasons:
I will say that JavaScript is probably not the best introductory programming language. It has a lot of weird quirks that can be hard to move past. When I first was learning programming, I started with JavaScript and quickly gave up - until I tried out Python a few months later and loved it. But, that was many years ago, and "modern JavaScript" has become more widespread.