Skip to Content
 

Are simpler games easier to design?

19 replies [Last post]
larienna
larienna's picture
Offline
Joined: 07/28/2008

I had a realization lately after working on a few very simple game with very little components, which could have a look and feel to classic abstract games.

I thought those abstract games would be easier to design. Sure, there is probably less stuff to design than a convoluted games with tons of stats. But still, there is a lot of work required to balance the game and making it fun.

It seems that both the simple and complex game would require an equivalent amount of time to design. Sure the time will not be spent the same way, but simpler games don't seem faster to design.

On the other hand the complex game with tons of stats could hide balance issues within it's design, but will be difficult to detect compared to the simple abstract game that is somewhat naked and requires more careful attention.

lewpuls
lewpuls's picture
Offline
Joined: 04/04/2009
My motto is:

My motto is: "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." Antoine de Saint-Exupery. Another form, about Japanese gardening actually, is "Your garden is not complete until there is nothing else that you can remove."

And others:

Everything should be as simple as possible, but not simpler. - Einstein

"Any intelligent fool can make things bigger and more complex. It takes a touch of genius - and a lot of courage - to move in the opposite direction." E.F. Schumacher

"Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple." Steve Jobs

When something is wrong with a game, the right way to fix it is to simplify; but designers typically ADD something, making it more complex.

At some point it's harder to make a GOOD simple game. But very simple games, often bagatelles, are not so hard to make if you're not wanting to design a game that can be played many, many times.

X3M
X3M's picture
Offline
Joined: 10/28/2013
Complex is simple, simple is complex

lewpuls wrote:
My motto is: "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." Antoine de Saint-Exupery. Another form, about Japanese gardening actually, is "Your garden is not complete until there is nothing else that you can remove."
I think I got an issue with removing my terrain. The 2 dimensions that I use for all my games, make it much simpler for me to design and balance. And I had all the freedom to experiment on stuff. But the basis was ALWAYS balanced. Even my public version that I sometimes worked on.

But now with the cardgame, the board is removed. And suddenly the complexity in play dropped a lot. Making the game simpler. But my mechanics are currently broken. I discovered that REMOVING the board made the game too simple. And thus the designing (for balance and logic) too complex.

lewpuls wrote:

Everything should be as simple as possible, but not simpler. - Einstein
And thus I arrived at this conclusion myself.

lewpuls wrote:
"Any intelligent fool can make things bigger and more complex. It takes a touch of genius - and a lot of courage - to move in the opposite direction." E.F. Schumacher
...am trying :D

lewpuls wrote:
"Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple." Steve Jobs
I know some hard workers.

lewpuls wrote:
When something is wrong with a game, the right way to fix it is to simplify; but designers typically ADD something, making it more complex.
Some might have confused my experimenting with adding something. As if something was wrong. But it wasn't.
So far, I never added something to fix something else. I often removed things.
With the cardgame, this is a different issue, if I am being honest.

lewpuls wrote:
At some point it's harder to make a GOOD simple game. But very simple games, often bagatelles, are not so hard to make if you're not wanting to design a game that can be played many, many times.
Well... not sure how I should read this. If a game is too simple, people will not play it??

questccg
questccg's picture
Offline
Joined: 04/16/2011
My answer to you...

It depends on what you are TRYING to achieve. If (for example) you are designing a card game in which you want players to DUEL well then it may be hard to later try to implement 3 or 4-player matches. Why is this relevant?!

As an example, your FOCUS is initially to DUEL. So your mind thinks up ways in which the game can play for 2-players. Let's say after this, you decide that for some reason you want MATH to be a part of this duel game. Again your mind goes into the mode that you start thinking HOW you can introduce elements of MATH.

So I would generally say that YES it is a bit difficult to design SIMPLE games with very few elements and/or components. While you start to choose your restrictions or the elements that MUST be present in the game (like it is a duel and there is some math, etc.) you kind of HONE-IN on a design.

As to the simplicity or complexity, I would say normally I start with very simple constructs. Usually I don't know the entirety of a design, only that I have VERY SPECIFIC GOALS that I want to achieve with a design. That's why I focus on making DIFFERENT TYPES of games such that they feel very different from one and another.

And I don't know if you remember a TOPIC I had posted like about 6+ months ago. It was when I spent some time re-working "Quest v2.0" and one of the challenges that I had was to DESIGN "mini-games". Well mini-games are hard to design because of Table Top restrictions. You can only ADD a handful of components and usually this means that it would be best if you could SHARE those components in different mini-games. But generally this ADDS complexity to how you can "design".

And therefore, I tend to agree that SIMPLER games with LOW component counts are much harder to design (as mini-games or a quick 30-minute game which is FUN and engaging at the same time).

What I think further... Is Abstract games are even HARDER to design because you need to have some kind of "innovation". What is this abstract game going to resemble??? Chess, checkers, Go, Backgammon, Dominos, etc. Creating something NEW that has NEVER been seen before... Is TOUGH!

That's why I tend to design MIDDLE-WEIGHT games. Where there are restricted amount of components (except TradeWorlds... That's a beast and was designed to make more expansions adding to the component stack) and mostly card-type games.

Even thought I TRY to make them with different mechanics such that there is little resemblance ... I try to keep things as SIMPLE as possible and then ADD when I get the impression the game is JUST TOO SIMPLE.

Too simple games offer up not enough DEPTH of STRATEGY or limits the amount of choices. And when this occurs, I look to ADD something to improve the game. But yeah I generally agree that SIMPLE games (mini or full like abstracts) are difficult to design ESPECIALLY if you are trying some make something NEW that has never been seen.

larienna
larienna's picture
Offline
Joined: 07/28/2008
To make a metaphor: Designing

To make a metaphor: Designing small board games feels like desiging the interior of a small room. You have little space to maneuver your furniture around, and you need to search for new products in order to optimise the space you have. Until you find those new products, you will have an non-optimised or even non-functionnal room. You have to wait until you discover the products you need to make your area functional. It can take years.

If you have a larger room, you can work with what you have to create a room that is good to live in. Sure, there are many ways to optimise your space, but the area can still be functional even if not optimal.

I think that is the major difference, the more space you have, the more flexibility you get and the less research you need, making the design experience less frustrating. This is why I find strategy video game easier to design because there is less restriction to deal with especially time and space.

In someway, I made a deduction that the more constrained is the game, the more mechanic searching will be required. Since I hate doing mechanic searching, creating loose design seems like the only solution. And so far, loose design seems only achievable using video games.


Quote:
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

I kind of disagree with that affirmation. I have refered this in the past as Additive design vs Subtractive design. I understand the idea of refining something to make it better and more efficient. This is what we call refactoring in computer programming. If you have something to work with, trimming what you have in front of you is logical, but when you start from scratch, you have nothing to remove.

In computer programming, additive design is more interesting because you can solidify your program at each step making easier to add new features to what is already working. The pattern is generally:

  • Expand to add new features
  • Test and validate the features are working
  • Refactor and optimise the code
  • Repeat

Using this method, after each iteration, you are using you previous iteration as the foundation for your next iteration. Which makes it easier to just add the new feature one piece at a time. It prevents the need to design the entire thing all at once.

questccg
questccg's picture
Offline
Joined: 04/16/2011
Clarification

larienna wrote:
The pattern is generally:

- Expand to add new features
- Test and validate the features are working
- Refactor and optimise the code
- Repeat

Using this method, after each iteration, you are using you previous iteration as the foundation for your next iteration. Which makes it easier to just add the new feature one piece at a time. It prevents the need to design the entire thing all at once.

This pattern and approach is incomplete. "Test and validate the features are working" assumes only testing of the NEW features. Regression testing and setup of a Test Bed Framework to regress and test ALL aspects of a piece of software is very important to ensure that local changes don't impact global coding.

In other words, by ADDING a Feature, you need to not ONLY test that feature but also ensure that the REST of the software is UNAFFECTED by your additions. Or in other words you should run a series of self-diagnosing tests that ensure that the REMAINDER of the code is still FREE from bugs and/or newly introduced problems.

I don't think you can use a Software Pattern to mimic TableTop Design. In my own view, they are totally separate and use different SKILLS in terms of what is required to bring a "design" to fruition versus writing software. I tend to work "piece-by-piece" when DESIGNING TableTop Games. Where as with Software, I usually have a Model of the Data (Object Modelling) or a series of Features that a coder wants implemented (Agile Development).

However I cannot comment as to the Design of Video Games... Since I have never done this before. Nobody has TAUGHT me anything about Video Game Design so I cannot determine HOW the implementation of this type of Software is to be done.

In this case, maybe your Implementation Pattern may work... Because a Video Game is a piece of Software primarily. Still while I think most applications that are designed do proper UNIT TESTING, regression testing often is done by hand (by a senior member who validates the OVERALL Functionality of the piece of Software). I'm not sure how much Video Games are tested for all features or is it just a group of unit tests combined together to say: "Yes all of the unit tests work and therefore the whole should also be okay too."

Not sure. So for Video Games it could be okay as an approach ... But for a TableTop game, I'm not sure there is ENOUGH complication to require something like a Agile Development Method... TableTop games tend to be very minimalist as compare to Software. This is both in requirements and overall TIME/EFFORT spent in making them.

Cheers @larienna.

Note #1: Every time I THINK about Coding a Mobile Game, I realize that SO MUCH "Framework" coding is required that I GIVE UP. What I mean by "Framework" coding, I mean like a "LOBBY", "LOGIN", "INTERNET SETUP", "KEYBOARD", "GAME CURRENCY" ... Just thinking that I need to IMPLEMENT all that Sh!t (pardon my French) ... Just discourages me from coding any kind of Mobile Game.

Even things that a BASIC like a LOBBY ... Are TOO COMPLEX to design for any MULTI-PLAYER type of mobile games. I looked into the Nintendo DS when they had "died" in terms of NEW Software... And You need to implement your own Keyboards, and no Internet Connectivity with the Toolsets... You have to DO EVERYTHING FROM START TO END ... And there are no shortcuts ... And therefore I've never been able to CODE or DESIGN any DS games (or Mobile Games for that matter too...)

Note #2: The MAIN difference is the level of complexity for a TableTop Game versus a Video Game or a piece of Software. When I DESIGN TableTop Games... I'm designing THE GAME. Not some essential FEATURE that is required for the game to work. If I need a Currency, I add Chips, Cubes or a Player's Aid... For a Video Game ... It's MUCH, MUCH, MUCH more complicated. You just can't say: "I'm going to add some Cubes and it's done...!" No you have to design a CONTEXT for this Object and ensure that the use is managed by the game in a way that BEHAVES like a "currency"... I mean it's so freaken COMPLICATED! And so very abstract as a concept that in a Video Game ADDING a "Currency" is freaken complicated. Why?

Look at it THIS WAY:

A> In a TableTop Game, I just add some Chips or some colored Cubes. And I say each one has a value.

B> In a Video Game, you need to create an Object that models the "currency", then you need to design them such that each Object when instantiated has a "value" (and maybe a color too), next you need to DEFINE WHERE in the game these Objects appear and how they interact with the entirety of the game.

It's VERY COMPLICATED. Simple in terms of a TableTop Game... HARD AS ALL HELL in a Video Game (Software).

And this is just ONE (1) Aspect of a "Framework" that you would require for a Video Game that is Multi-player. Again going from Single-Player to Multi-Player is so FREAKEN hard in a Video Game (or maybe I don't have the skills to understand how this is done)... But it SEEMS really HARD. In a TableTop Game, I just need to add an extra Player Chart or extra Cards, etc. SIMPLE and directly RELATED to what I am doing.

Not trying to figure out HOW each player has to interact with the different elements in the "Framework" and then subsequently in the Game itself. So very COMPLICATED. At least from a coder who is very proficient a procedural coding.

I'm not great at Object Modeling and creating objects for an environment... Haven't done a lot of C++, mostly C and Java Services (which are web-oriented functions accessible via the web)... So mostly procedural that's why I am comfortable with HTML/CSS/Javascript and PHP (again procedural PHP not Object).

Note #3: And if you ASK me ... "Why not design a SOLO scroller and be done with it?" Well that's not the KIND of games that I would want to "bring to market". Scrollers are so BORING... And yeah I've seen some Toolkits that allow you to do this... But the point is, usually you are limited to the Toolkit that you use.

Nobody has LOBBY, KEYBOARD, INTERNET, LOGIN, CURRENCY, etc. In their Toolkit. You have to develop and design ALL this "peripheral" stuff before you can begin to design the GAME. And then you need to CODE all of that stuff so that it works too...

Anyways... I'm sure you're going to tell me that it's not that hard. But as a Software Developer who has 20+ years of IT experience, I know how DIFFICULT it will be (for me at least) to develop all those concepts that are required for the game.

And so I stick away from LEARNING how to make Mobile Games ... Because whatever I want to DO, it is just too complicated. At least that's the impression that I get...

Note #4: And if you ask me... I can DESIGN and DEVELOP such a game as a TableTop Game: Monster Keep is the pure example of a DUEL game that is multi-player (Duel or 2-Players), features Monster cards, is logically configured to be played in consecutive Rounds, Uses MATH and all this with Deck-Construction PRE-GAME (each player has 15 Monster cards).

That's a pretty SIMPLE game (TableTop). But IF I was to PORT this to a Video Game (which is something that I really would LOVE to do!), it's impossible due to all the "Framework" extras that are needed to support such a game.

Meanwhile in the TableTop world, I have already DESIGNED and DEVELOPED the game and while it may be like 1 year in development effort (which is probably broken down into 3 to 4 years of design) part-time (among other games and duties)... It's still much simpler for this game to EXIST in Physical Form than make it into a computer game.

And funny thing was that I was approached to become a part of Ubisoft. They submitted my candidature a month ago thinking that I have TableTop Design experience, 20+ years of IT Software Development, have consulted for all kinds of large Canadian and US customers, etc... Yadda, Yadda. I still have heard no news from Ubisoft. So I doubt they are really interested in hiring me.

But clearly PORTING "Monster Keep" to a Mobile App game with Monster cards and Deck-Construction with MATH and Round-Play would definitely be something that I would love to do and help make it happen.

However ALONE... I could never do this. I have to be HONEST with myself and all of you! Congrats to all the Video Game Developers, you guys ROCK!

Note #5: And as far as Agile Methods that I know, we've followed "Kanban" methodology for the development of an Enterprise Software.

But yeah I get it: you define something: "We need 'currency' in the game" as one unit of work and estimate how long it could take. If it takes too long or the story is too abstract, you sub-divide it into a couple SIMPLER stories. And the iterate over those and figure out is again you need to make even SIMPLER stories from those, etc. The bottom line is that it is a VERY complicated way to make something that takes seconds in the TableTop World.

But I get how Agile Programming works... How you try to iterate to make simpler stories out of more complex ones until you get a unit of work that is like 8 hours (I believe) or 1 day. (Not 100% sure if that's the lowest time or this is something variable per project/per team...)

larienna
larienna's picture
Offline
Joined: 07/28/2008
OK, lot of things to un-dust

OK, lot of things to un-dust here. I am sorry for non-computer programmers out there, the thread might shift direction, still I wish to work on a library that is relatively accessible, so it might interest people with average computer knowledge.

Regression: Of course, adding new stuff can break old stuff. That applies to both game design and software programming. Automated testing can help find regression issues. Video games have less option to use automated testing because they are real time engines, but I might have find a way around the problem, keep reading.

Game Software priorities: I have identified 3 priorities that are important from my point of view. You will see their reflection through out this post:

  • Speed: Make sure the program runs fast. Most important for real-time engines which display 30+ frames per seconds
  • Portability: In an era where your watch can run software, being able to be portable across many different devices could be a desired feature.
  • Debug-ability: To be easily capable of debugging software or game design rapidly without playing the entire game every time you want to test something is a necessity. Testability also enters this category.

Object Oriented Programming (OOP): OOP is "de la merde" (like we say in French). All you say so far is true, if you use that paradigm. Of course, it's currently the dominant religion out-there, but more and more articles are denouncing the drawbacks, and most newer languages are going toward the functional programming path to avoid most OOP problems. OOP have more boiler plate code and makes you work more on the container than the content. I try to use Data Oriented programming, check out Entity-Component-Systems, and relational database which works like a charm for the kind of game I want to make.

Object model: OOP will promote making tons of diagrams like use cases, objects models, sequence diagrams, etc. This is what I call the top bottom approach. You do not need any of that crap when you do the bottom-up approach, like I said before: Explore, tests, refactor.

Android or not, that is the question: This is a huge dilemma I am still struggling with. Mobile devices being everywhere, it is a wonderful opportunity to develop for those devices. The problem with Android, is Android. It's friendly for the users, but a nightmare for the programmers. It suffers from overengineering. Loading and running a simple hello world project in android studio takes me at least 15 minutes. A plain C allegro hello world program takes me at most 15 seconds. There is a lot of step to bring a software from my computer to your device, which requires Gradle ... that is a pretty cryptic slow, and when things does not work, good luck finding the solution. This is why, I was thinking for now to stick to what I know, I am even considering the NDK, I know SDL can use the NDK on Android. It still requires Gradle, but there could be another way to do it. C programming with GCC works like a charm, I can even cross compile on windows from linux without a hassle.

Language: Platforms implies language. Android equals Java or now the interesting Kotlin language which I would like to give a try with LigGDX one day. It could be a good way to go the Android route. The problem is that if you want to go on the big consoles (PSX, XBOX, etc), java is not supported. So you are restrained to android and desktop. Else, I love plain C even with lacking features (no C++ since no need for OOP). Everything is easier, when C++ is not in the decor. This should be console friendly, and of course desktop friendly.

Realtime vs turn based: Video game engine are generally real-time engines. Which means the screen is being drawn 30-60 times per seconds. That allows animations, but the drawback is that the program flow is very different making it very hard to debug and test. Which is not good for solo programmers like us. So I was investigating the idea lately to sacrifice the feature of animation, to create entirely turn based game engine like my Wizardry Legacy used to work. It should be easier to develop, it will be testable via unit tests, And it would play lightning fast, since there is no need to wait after animations.

Event vs question User interface: Most user interface are event based, which means you wait for user action and react accordingly. This makes the use behavior unpredictable, and require attaching codes to various events. Again, it breaks the traditional program flow. What I intend to use, is the technique KOEI had used in its old video games. Once the user chose an action to do, he is now on tracks and must answer a series of question before the action is completed. This method makes it easier to program, since it follows natural programming flow. It makes it also easier to unit test too.

Agile Methodologies: One of the main differences in the development process is that you are your own client. You decide if you need to change the game design and you can anticipate the evolution of the needs. Once the game is working, there will be little new features required. In business applications, the needs always grow and you cannot anticipate the new requirements.

Development time: There is a lot of variables to juggle here. First, it depends on the platform you want to develop for which will determine which language, library or game engine you can use. The higher level you go (ex: game engine) the less work you have "In theory", the more it will look professional, you will have more tools, but the more expensive it can be, if the engine is not free, and more struggling is required when it does not work. The lower level you go, the more work you have, but the more control you get and the learning curve could be easier. It will look less professional and you will have less tools. So it's hard to judge, it really depends the type of software you want. For example, you can make a game with java swing widgets if you want, it will have a business app look and feel and will mostly run on PC.

Quick Modification: On the engine I am currently working on, adding "cubes" to a game would simply consist in adding a field in the data base table and the necessary formulas to compute that new information. I can make a dialog with only 1 format string (a la "printf") and 1 SQL query. And that information could be in a loaded text file instead of code. Slightly more work than adding a cube on the fly, but way less intense than in Object oriented programming.

Multiplayer: You mention multiple time the need of logins, lobby and other multiplayer features. Who said that you needed multiplayer? Of course, if you are adapting a multiplayer board game as a video game, I can see the need. But you can still use Artificial Intelligence to simulate opposing player. Or design games that are more solo oriented. Multiplayer is of course a pain especially if the game is in real-time and requires a server to host games. I gave some thoughts to asynchronous turn based multiplayer games, but it would still require a server.

Side Scrollers: I have a few side scroller ideas, and they are good engines to do the job (ORX is interesting). But I agree that it's a saturated market, requires a lot of assets and it's of course real-time. I am looking more into turn base strategy games because that is what is closer to board games.

About your programmer experience: With a simple engine that I want to make, I am sure that with your experience, you will be capable of doing something playable. I still have to work on my project, probably this summer while school is off for me. You could probably also make a small project with Allegro or SDL, especially non-realtime projects. It should not be that complicated, programming in plain C becomes a charm when you have experienced Object Oriented Programming nightmares. Sure it will not have the latest bells and whistle, but I use an SQL database that does all the record managing work. Once I have something more solid, I could make you a demonstration via zoom or a tutorial.

Enjoy!

lewpuls
lewpuls's picture
Offline
Joined: 04/04/2009
X3M: if a game is too simple,

X3M: if a game is too simple, often it isn't worth playing (or isn't worth playing more than a few times).

Removing the board can fundamentally change a game, IF it was a game of maneuver and geospatial relationships. Hard to have those without a board or something that accomplishes the same thing. (Most "board games" are only status trackers, not depictions of maneuver and geospatial relationships - think Munchkin Deluxe, which added a board to track something (character levels) that was formerly tracked in other ways).

lewpuls
lewpuls's picture
Offline
Joined: 04/04/2009
Larienna: I don't think

Larienna: I don't think computer programming and game design are sufficiently similar to make the comparisons you've drawn ("additive programming"). Games aren't something you keep adding features to. You must decide when you start what will be in the game; that may change (games, like novels, may do the unexpected to the author), but you shouldn't plan that it changes.

X3M
X3M's picture
Offline
Joined: 10/28/2013
lewpuls wrote:Removing the

lewpuls wrote:
Removing the board can fundamentally change a game, IF it was a game of maneuver and geospatial relationships. Hard to have those without a board or something that accomplishes the same thing. (Most "board games" are only status trackers, not depictions of maneuver and geospatial relationships - think Munchkin Deluxe, which added a board to track something (character levels) that was formerly tracked in other ways).

I remember that game. I should study it a bit.
And yes, removing the board truly changes a game, and challenged me.
The maneuver and geospatial relationships without a board are very hard to do. When it is a card game, some use mats and location on the mats. To me, this feels like using a board again.

I am going to try to have groups of 1 to 3 cards. Where a group or 2 can flank when another group is taking the enemy group head on.

questccg
questccg's picture
Offline
Joined: 04/16/2011
I agree but am not 100% sure...

lewpuls wrote:
Larienna: I don't think computer programming and game design are sufficiently similar to make the comparisons you've drawn ("additive programming").

I agree ... But am not sufficiently versed in Video Game Design to be able to say... "Yes" or "No" it is the same or even similar. Of what I know which is designing TableTop Games and Software Development, those two tasks or duties are not similar one bit. Software involves continually ADDING to the code base. While games, are usually about "tight" design. Meaning that whatever you are trying to achieve is very related to the mechanics required to play the game.

lewpuls wrote:
Games aren't something you keep adding features to. You must decide when you start what will be in the game; that may change (games, like novels, may do the unexpected to the author), but you shouldn't plan that it changes.

Game Design may be more like "Novels" because you probably know the STORY you are wanting to tell (the Game Experience), you have some ideas for characters (like the Game's Mechanics) and you've got to join all of this TOGETHER SOMEHOW. And usually you are waiting for INSPIRATION to help move the design forwards.

Very different than designing Software TBH. Like I said, I cannot speak for Video Game Design as I have never really done that before. So I'm not sure if Video Game is more SCIENTIFIC than INSPIRATION (when it comes to TableTop Games)...

questccg
questccg's picture
Offline
Joined: 04/16/2011
One thing that I can say for CERTAIN is...

That Video Game Design is VERY HARD to test. Because usually you are dealing with some kind of "Engine" and that you introduce NEW elements to that environment and it is the things that you ADD are what needs TESTING.

BUT... The problem is that it is HARD to figure out if any of the added NEW elements AFFECT (adversely) the engine and the game being worked on. Finding limit conditions is also NOT OBVIOUS when using a "Engine".

So I can't say for CERTAIN that games involving an "Engine" are hard to test... I looked at videos of "Fallout 76" in which people were showing BUGS or undesirable effects like lighting issues or wrong effects when deal with pools of water (for example).

Anyhow the bottom line is that my impressions is that Video Games are somewhere in between when it comes to TESTING but are MOSTLY "Scientific" in nature and are developed using the Software approach.

Note #1: Think of a Level in a FPS (First Person Shooter) and how one must TEST that level for bugs in the "Engine" and in the "Level". It is very complicated because it is HARD to "isolate" sections of code related to one particular area of the "Engine" or "Level".

Where as if you add a "Service" to a web platform, you are able to directly TEST this "Service" with a SOAP or XML call. And then you can leave Log statements to allow you to know how the "Service" behaves and which paths it took during its execution.

Video Games don't work like that AT ALL (From what I know behind the technology and into their "Engines"). You just can't isolate one bit of code and expect to directly test THAT "Functionality".

Anyhow if you have a Background in Developing Software, you'll probably agree that developing Software and Video Games is not quite the same in terms of how people go about developing them.

Stormyknight1976
Offline
Joined: 04/08/2012
Ah, to agree to disagree

I've read this thread quite a few times and everyone agrees to disagree and disagree to agree. Conundrum right?

Rules, regulations, guidelines, simple to complex to complex to simple and super simple that it's so complex but it makes the player think to themselves,"Huh? Or Wha!" Mind blown!"

Everyone has a way to design games from their own experience. May it be right or wrong or this way or that way.

To add or not to add? Change, remove or to the point: when it's done; it's done. Simple right? Of course.

In my game design thought process it's simple. But , your all may or may not tell me that how I design is not designing because my games are to complex or way to simple that it makes your mind freak out.

Some used to say, Well you just can't have 4 dice for a game and be that simple?

Or use 9 tiles, 1 d10 and 1 figure to move on the tiles is way to simple it has to be more complex but tactical or strategic, but simple? Nah, can I look at something else to understand your thought process in game design?

Or how about 12 tiles and 1 figurine for a n abstract tile laying game? To simple? Or just about right?

Or how about a bell slapping game?
Wait! What? How can this be a game?
Yep, I came up with this simple bell game for 2 players and yes a 3 and 4th player can join in the game.

But, wait , how can a bell be a game by just slapping it? It can't be that simple, right? Right?

Of course it can.

Players slap the Bell to make it chime, the person who slaps the other person's hand at any time during game play is out.

It's that simple. Points? Only keeping track on how many challenges you made to another player and bragging rights.

Slap Bell was on a whim. Literally. So , customers that come into our pizza shop would slap the Bell. So, to try not to get annoyed by the chime, I made it into a game.

It brings smiles to my staff members, customers when just slapping the Bell as fast as you can. Call and response. It's a comedy term.

When I read this thread more than a few times, I wanted to say a thing or two but hesitated to write anything other than my game updates or add something to some of the others posts. But I wanted to just jump in and say what I had to say.

Do game designers really think to themselves,"I want to design a simple game and how do I do that with out adding anything but the terms and guidelines of designing or writing a 400 page essay on how to design a simple game and not make it complex. Simple, cut to the chase, no hold bar non sense game design and talk your way into it and hope for the best? And if it doesn't work out, whelp, I'll just look at it later or literally trash it because it wasn't what I wanted because of the restraint guide lines I put my self to learn how to make a simple game.

Nothing wrong on putting restrictions, guidelines on how much or how little your next project will be or needs to be.

I read, I sit back and learn, study from just the people or members who have been in this group since 2012.

We all design differently but get to the destination to make a great project for people to play.

My game design process is the same as everyone here but I look at things differently. I don't ask myself all of those questions mentioned above.

If I see a few things on a table or store, the probability of those items can be made into a game for someone to try and just see them smile and make them think outside the box for a moment.

The video game programming and table top design for board games or card games or dice games is the same thing. The programmer has guidelines to set the perimeters of map, level design, encounters physical movement either it be humanoid, object or liquid, character movement, puzzle actions to reaction. Timing,

When you pick up a video game guide book, do you read it as a guide book? Or programming book or both? Depends on how you see it right?

Did you know, you can make any video game into a board game.

Well, No duh Right?

How do they do it?

From my perspective and comprehension and how I used to set up my game designs was collecting quite a few video game guide books and read the table of contents.

That's the general basic idea for studying on what went first into the video game design. Table of contents or guidelines / restrictions to what the game is on the surface.

I used to jot down the fundamentals of the table of contents for my games to know where to start.

That, I get how that works.

It's not difficult to design a simple game.

I wonder what the game designers were desiging Chess, Go, Othello and all of the oldest games in the world were thinking?

Think about it.

Did they say to themselves,"I want to make a simple game to move pieces on a board and challenge someone?"

Or

Did these designers just build something to see if it works or could work , throw in some rules or guidelines for movement and call it a day?

I build or design or create something with what I have in hand, throw some rules in and see if it could work.

I don't design to make it fun. That would stress me out. That's just plain work.

I have fun when I know it will work.
It's the rules that makes any game complex. How to setup, how to move a piece, what is the base attack? What is the base defense? How can a piece counter: if any?

What is the end game reward points?

Now all I read is in the last 10 years, A game must be designed with Fun, a catch up mechanic, know your audience of players, setup fast, take down fast, game has to be played with in 30 minutes or less and replayability or the game doesn't get replayed at all. If the game gets picked up from the FLGS or brick and mortar store and played at least 2 to 3 times a year or not, it's not the designers fault or the players fault , it's the taste of playing the game throughout the year.

A simple game play time can be from 1 second to win to 4 hours to several months or years to play. Depending on the game.

No one complains on how long a game session takes for D&D, Chess, Go, Othello, Go Fish, War, Slap Jack, Monopoly, Scrabble etc

It's just the designers and game publishers who warrant that.

Everyone has a thought process on how to design games. Or at least if taught can design a game. Either it be a simple, abstract, puzzle, complex kind of game or games you want to design.

To agree , to disagree.

A simple game design can be difficult and not difficult to design. How much effort you put into thinking makes it complex.

Jesse

Stormyknight1976
Offline
Joined: 04/08/2012
To Larienna

Awesome thought process

Jesse

larienna
larienna's picture
Offline
Joined: 07/28/2008
Removing a board in a war

Removing a board in a war game reminds me of "Frontline D-Day" which used cards to indicate range and terrain, or "W1815" where there is no movement. The system determines who can attack who.

If you strictly design board games, yes, adding constantly features, also know as "Feature creep", is not necessarily possible. On the hamd in video game design, it could be possible to use feature creep and have a playable game at each iteration. Depending on your objectives, at one point, it's the designer's choice to determine when he added enough. But for certain games, like MMORPG, you never actually stop which lead to balance and progression problems. "Maple story" is an MMORPG which I could say suffer from feature creep and they had to rework things to re-balance the game. "Forager" is also a game that suffer from feature creep where game play and progression changes through the game.

So it's another way of doing business that allows having a working game early in the design process, and where each iteration also have a working game, so it could be less frustrating to design (in theory, I still needs to validate). Feature creep would become the nemesis of that design method, and a good designer would know when to stop or redesign certain portions of the game.

Video games are indeed hard to test (the implementation) for multiple reasons: Mostly because they are realtime engines, and there is random stuff happening in the game. This is why play testers are used. But if turn based engine are used, the software becomes much more testable. Randomness can also be unit tested by using all random combinations. So in theory, it would make the game testable. Of course, there are different levels of tests, engine based test would verify for example that the right stuff get displayed on the screen. While game design test, would ensure that the game mechanics behave according to their original intention. A bit more complicated to test, but you could simulate multiple game actions with the same random sequence, and in the end, the state of the game should be the same to validate the tests.

Computer programming does add an additional step: You must make sure that your game rule is applied correctly by the computer.On table top, this situation only happens, when the players misread or misunderstood you rules.

As for design objective, I have reoriented my objectives and I try to design games for myself, so I don't care about the "Target Audiance" anymore. I am also very likely to design solitaire games. On the other hand, in order to make the design process enjoybale in early iterations, having a playable prototype soon in the development process is a necessity. Video games seems easier to make this happening even if programming is required which is a bit more demanding than prototyping. But the game plays faster and it's easier to modify once built.

pelle
pelle's picture
Offline
Joined: 08/11/2008
I think there is confusion

I think there is confusion here between the design of something and the work to implement that design. Comparing software PROGRAMMING to boardgame DESIGN is strange. You will find more similarities if you look at software DESIGN vs boardgame DESIGN. I think designing complex systems of any kind will always have many similarities.

Every collectible cardgame would be examples of games where someone keeps adding to the design btw. Or any boardgame with a steady stream of expansions being published.

I think I share many of OPs opinions of programming. C is indeed nice and extremely portable. Maybe Rust is going to be as well, but still waiting for a proper standard and platform support is still limited. Raylib is a nice framework for making games in C btw (or in many other languages that it has been ported to). It supports many platforms. Godot with GDScript is another nice multiplatform way of making games, and you can combine that with C as well (but I have not tried that much) if you want to keep part of the game even more portable.

Another thought: I do not think that a simple game is necessarily not worth playing. Hex for instance is extremely simple, yet unsolved. Simplicity in the design can still result in complex player interactions. You can also make extremely complex games that are pretty easy to play without much complexity in what players actually have to DO.

pelle
pelle's picture
Offline
Joined: 08/11/2008
The lack of automated tests

The lack of automated tests in games seems to mainly be for cultural reasons, and because most code for games is seen as a one-off thing that is thrown together and then possibly never modified again after the game has been released and the team starts working on the next game from scratch.

Look for instance at the code for web browsers (something I am familiar with) (the popular ones are all open source, so anyone can have a look). They have huge amounts of tests on different levels, from low-level unit tests up to complex interaction tests. And a browser has at least as much complex real-time graphics and audio to test that a game has. Difference is that when Google works on Chrome, or Mozilla on Firefox, they do not intend the next release they make to be the last one, but actually hope to be able to maintain their code for many years to come. That is why they do not skimp on the testing. Not because writing tests for complex real-time graphics is impossible or not worth the effort.

larienna
larienna's picture
Offline
Joined: 07/28/2008
Never heard of raylib. Sure

Never heard of raylib.

Sure automated tests are more convenient for engine or other reusable components unless you plan to maintain the game for a long time (EX: MMORPG)

jwarrend
Offline
Joined: 08/03/2008
Simpler games are, in my

Simpler games are, in my experience, much easier to /conceive/, and quicker/easier to playtest.

However, in my experience it's all or nothing: you either hit the bullseye with your first shot, or the design is DOA. Because if the game doesn't work almost perfectly immediately, you descend into iteration hell (or maybe iteration purgatory), where every change you make takes away the simplicity of the game and then you strive, hopelessly, to pare it back to what made it so simple to begin with.

X3M
X3M's picture
Offline
Joined: 10/28/2013
jwarrend wrote:Simpler games

jwarrend wrote:
Simpler games are, in my experience, much easier to /conceive/, and quicker/easier to playtest.

However, in my experience it's all or nothing: you either hit the bullseye with your first shot, or the design is DOA. Because if the game doesn't work almost perfectly immediately, you descend into iteration hell (or maybe iteration purgatory), where every change you make takes away the simplicity of the game and then you strive, hopelessly, to pare it back to what made it so simple to begin with.


Currently my card game.
Actually, my card game for years now.

My main problem is constantly the simplicity of the dice. In combination with other limits. If I can do a bucket of dice. I have no problem designing the games that I want to design.

Syndicate content


forum | by Dr. Radut