Easy to design, hard to program

Hello Guys,
I need a favor. Could you show me a few examples of easy to design, hard to program type of games. I mean, you can name generes (for example: RTS, turn-based strategy) or just like that: tetris-like, cuphead-like. I'm looking for not so big games (max 5/10k lines of code). I would be very grateful for some responses.

 

All games. I'm guessing you haven't made one yet?

Try making the easiest game you can think of. Tetris, perhaps. Can you?

 

Actually, I disagree a bit here. I don't think anything is really hard to program. It just takes a f***ing long time.

 

Easy and Hard is relative term.
For you making few lines of code may be hard, while for @hippocoder making tetris will be easy.

Try make moving cube for example, you can figure out, if is hard or easy.
With practice anything become easy of course.

But sorry, have no such examples on hand.

 

Yep but I think Tetris for me would be difficult, relatively, because for me, making Tetris is not just the game mechanics, but also the scoring, the menus, the whole thing. People tend to dramatically simplify the amount of work involved during a concept phase...

But if you wanted just the game mechanics, then no problem!

 

Well thats true.
It can be found on forum numerous times that developing something takes x times longer, than normally expected.

 

A couple examples of easy to "design" games (as in, easy to say what you want it to do):

A narrative game where you just talk about anything with a single NPC using freeform natural language.

An augmented reality scavenger hunt game where you point the camera at objects on the list, and the game recognizes whether it's a correct object.

 

And this is why programmers find it considerably easier to be game designers than those who aren't. Assuming the programmer has experience enough to be identified as such

 

Clones. Any time you copy someone else's idea verbatim, you have a task which takes more effort to program then design.

Otherwise it doesn't matter what genre you are in, game design is hard work.

 

I can move cubes tbh. I've made several games but with step-by-step tutorials. I wanted to do smth more by myself, like real project and to start with generally "easy".

 

Just about everything will be hard to program if the most you've done is follow step-by-step tutorials. My recommendation is to start with Pong, followed by Breakout, followed by Arkanoid. Each step adds something more to the previous game.

After that you could try recreating games from the golden age of arcade or creating new games from scratch that merge mechanics from two or more of them.

https://en.wikipedia.org/wiki/Golden_age_of_arcade_video_games#List_of_popular_arcade_games

 

That's what I was looking for, thanks m8!

 

Is any of that "hard", though? I'm with @LurkingNinjaDev, the issue is less "difficulty" than it is required time. Putting together a nice menu system isn't hard from a programming perspective, but it does require doing quite a large number of simple tasks for something that seems trivial from the outset.

Great examples!

For a more traditional game programming example, any interactions which need to be implemented with simulated physics. For one of my games I've written a player controller for a Wall-E style character where the player inputs a direction and the character controller controls the tank treads to orient and move in the desired direction. Conceptually it's really simple...

 

Dynamic lighting in a stealth game that works fast and effectively from the player's perspective.

 

Just copy games that have already been made.

Designing a fun game and programming are two totally different fields. One is carpentry, the other is architecture. You wouldn't learn both at the same time, right? It's too difficult. Do one, get comfy, then work on the other. Forget about easy and hard, forget about time... just keep working, assessing yourself, and that's as good as you can do.

 

The best way for me personally to learning Unity was to think of something very specific, and then research how to do it.
99.9999% of things you want to do, chances are, have been done.

So for example. Think of a really cool mechanic you want. Lets say Teleportation.
Google ("Unity Teleport Player"). And you'll find all sorts of various examples, ranging from transform.position to raycasting to teleport.

I've found over the years with Unity, that a majority of the time, I'm re-using the same exact stuff over and over, a raycast is a raycast, a spherecast is a spherecast, and transform.position is a transform.position... Which is really cool, because it makes simplifying actually hard to grasp ideas down to the basics in how their mechanics work.

So generally, making even a basic concept demo gives you the knowledge to complete most games, so long as you realize how to utilize that knowledge, and be unique with how they work, piece the puzzle together and there you go.

Of course this is just my opinion. So I may not be the majority here lol.

 

All games are easy to program until the polish stage. I can prototype all kinds of stuff in a weekend, but then if I want to actually turn that into a game it turns into months and months of tweaks, content, then art problems followed by more tweaks, weeks of UI crap. On and on again and again.

 

There's no such thing as something that's easy to design, and hard to program. Unless by 'design' you mean writing down a brief adjective-filled description, in which case you're really designing it as you code it.

If you start with a brief description of a game that you would like to make, I bet it would take much longer (and many more iterations) to define the nuts and bolts of what you're after, than it would take to code it.

 

It really depends on what you mean by "design". Are you referring to deciding on the experience the player should have (ie: "game design") or are you referring to how to implement a piece of software to result in that experience (ie: "software design").

These are both "design" activities, but they occur at different levels of abstraction and require quite different skills and focuses. People make more work for themselves or poorer products when they mistake one for the other or think they're the same thing.

@TonyLi's examples would indeed be pretty easy from a game design perspective (his statements aren't designs, but making designs based on the statements would be fairly easy), but very difficult to do well from a software design and programming perspective.

 

For me, difficulty IS time. There isn't any dev subject I can't surmount given time

 

Bingo.

Let's assume the OP and everybody here has the persistance of a badger. They just ain't gonna F***ing quit until all the snakes are dead, okay?

So the question isn't, "does killing snakes suck?" It's, "how much time will it take to kill all the snakes?"

So OP's question is really smart I think, just asked in a way that is easily dissected by semantics. I think the real question they meant to ask was, "whats the most time- effective way for me to learn programming and game design?" to which, reiterating myself, I think the answer is separate the two and learn one at a time.

 

Well, all I'm saying is that concept is not the same thing as design.

For example, I understand @TonyLi's examples were given in the form of concepts, but for the sake of argument, here are some questions that would need to be answered at the level of design - what is 'freeform natural language', what is its purpose, and what are the rules that structure it? For the second example, what is object recognition - how can objects vary while still being the same 'thing' - and what are the range of conditions in which they will be analyzed?

There is something in between concept and coding that will take much longer than either of them. And even concepts are fairly meaningless unless people already are familiar with what you're referring to.

I suppose that goals, and perhaps range of possible actions, can be fairly simple to define and remember - which is what is usually meant in the similar 'easy to pick up, hard to master' definition of certain kinds of gameplay. But unlike playing games, coding requires a bit more planning of exactly what is going to be done by the player, and what might happen as a result, beforehand.

 

I definitely agree that a concept isn't a design. I'm saying that there's more than one type of design that goes into making a game.

By my training "programming" involves more than just writing the instructions. Once you know what the instructions should be then writing them should be no problem. Figuring out what instructions to write often involves detailed planning, research and/or experimentation.

I don't think that the examples in question would need a heck of a lot of design work in the context of a game design. In the context of figuring out how to make a computer recognise a bird... yeah, that requires a lot of technical design, and that's going to be hard.

My current project uses a lot of physics. My game design doc doesn't go into any physics detail because I don't consider collision detection algorithms and the like to be a part of the game design. That's the perspective I'm talking from.

As an individual, sure. Imagine a studio has just hired a graduate, though. There are certain tasks most seniors would happily give them (hook up our game's GUI to in-game events), and certain tasks they almost certainly wouldn't (design and implement the networking architecture for our upcoming MMO), and while you can argue that the reasoning still all ultimately boils down to dev time there's a bunch of intermediary stuff you'd consider along the way.

 

Complexity is a better term than hard. Most game mechanics add complexity, complexity takes time.

Edit: when you have added 20 mechanics without thinking about abstraction, arcitechture and continues refactoring, then things start to be hard

 

I suppose you may be right.
I would look also at difficulty tern, which is related to familiarity, I think.

For example we can play Mario first time, and may be difficult (hard).
Then we become familiar and it become easy.
And depending on the our take on the matter, Mario may be complex, or simple in design.

Hence, if we more familiar with coding, we can take more complex design.
It become easier. Time span will vary of course.

 

You know what I understood the first time I read the first post (quoted below)? That the guy was looking for something really hard to code, as some kind of challenge they would throw at themselves...

English is not my mother tongue.

 

What about flappy bird with < than 100 lines of code

 

I wasn't going to waste space by fleshing out designs. My point was entirely different. These are examples of unsolved research problems. Top universities and multi-billion dollar companies have been working for decades to solve them, unsuccessfully so far. Thus, easy to say "do this," but hard to actually do it. It was a somewhat facetious answer to the OP's "easy to design, hard to program" request.

 

Well, technically it's possible to fit everything in one line. Not sure people should do it though.

 

Well yes. I didn't want to say that. I consider that a cheating
Let say that every semicolon and curly bracket are new lines.
lets ignoring includes in counter

 

@AnneSchmidt ,

Full agreement. I understood the same thing. But then I ask, "ok, why does a person want to challenge themselves just on the programming side?" Because they want to learn right? That's why anybody challenges themselves. And if they want to focus in just on the programming, but not the design, then I see the question more clearly. But you've got people debating semantics about totally unrelated things, which makes it harder to find a clear answer, IMO.

 

You're right, but i'm grateful for this feedback anyway guys. Some answers were valuable

 

I would say RTS games with autonomous AI's. Programming itself seems straightforward but debugging is complicated when two AIs conflict with one another. Programming an actor to cut down a tree, stack the wood, and build a house is easy. But when two or more are working from a similar set of goals, now you have to worry about claiming individual instructions to do things, claiming resources, etc. Now add god mode where you can interrupt things. You then have to make sure you can unwind claims so as not to create any leaked resources, etc. Bugs become timing, priority , and action related. And without could tracing, your left with a puzzle of problems to deal with.

 

well, although I don't follow through flow discussion however you should consider "design is easy" words, it's not easy really, you must create things which you never see, it's tedious & tired, sometimes I bite pencil throughout time but could not bump out any amazing idea... If you're indie dev, there's ton works which you must finish before relaxing with coding, from plan ideas, paper drawing to making sprites on graphics tools, graphics run parallel with development progress, see everywhere you also see graphics.

 

First 30s of this;

my boss: "Okay Team! Build it, Easy!"
Unity 2020 roadmap?

 

I thought of that xkcd as soon as I read the post.