The "impressiveness" of games

Miscellaneous Topics
#1

Here at JGO, we love every project we see: be it small and baby steps, or something large and advanced. Personally for me, I started working on the biggest project I’d ever undertaken which was ProjectMP - a fully multiplayer terraria-like clone. The challenge there for me was to make it completely multiplayer compatible. It lasted around six months but was fully multiplayer from the start. The only downside was that the game itself was something most of us could make in a much shorter time than I did: it really only had world generation, movement, and mining. It was more of a labour of love for me, but I felt that I couldn’t present it because it was so bare and lacking for the amount of time I worked on it. Adding any real features involved once again fiddling with networking which was a long process.

On the other hand, I could make what I wanted that project to be, but entirely singleplayer. Sure, it’s now all cool and stuff… “but where’s the multiplayer”?

This is what I feel is the difference between “technically impressive” and “fun”. ProjectMP is my biggest achievement, but I feel that no one would really see it because of how similar and plain it looks. On the flip side, anyone can do a Terraria-clone with enough time, but that’s because singleplayer doesn’t pose much of a challenge to me.

I don’t really know where I was going with this, but I often have to decide “do I want to make a lacking, technically challenging game” or “a flashy but not technically impressive game”. What do you think?

#2

I think it depends on what you want the final product of your game to be. If you plan to sell it and make millions, I would go with flashy but simple. If it’s something you will never release but just want to see what you can do with it, then make it technically challenging. Once you have made it technically challenging you can always go back and make it flashy :slight_smile:

#3

If this is just something done as a hobby or for learning (preferably both at the same time) - sure, go for technical challenge. :slight_smile:

If you actually want to finish and maybe even sell something, “fun” projects are usually way to go. On the other hand, if all of us followed this approach, we most likely wouldn’t have games like Dwarf Fortress or Minecraft (two examples that came to my mind as first) that push the genre forward, create genre/subgenre or even completely change the gamedev world.

#4

Thanks for your responses. I’m currently deciding if I should re-do Project MP but in singleplayer so I can add features much more easily and have more of a game, compared to doing something more advanced like multiplayer. I’m probably going to go with the former because what really matters to me is if I have fun making the project, and not poking away at it to make the networking work. :point:

#5

my 2 cents: try another genres! Shumps, rpg, rts, puzzles, etc…

I’m trying to do the same, btw!

#6

Almost nothing impresses me technically any more… I suppose VR is quite amazing but I’m really over tech-titillation now. I really just like to pass the time playing something dumb and fun.

Cas :slight_smile:

#7

On the surface, graphics and then sound are the easiest way to impress people.

But they are also the first to wear off, and then some games begin to shine witht heir depth and replay value.

And it depends on the auidience. A technician might be impressed by technology and it’s use, which is pretty irrelevant to the casual gamer, who only wants some fun, regardless how the game was made.

#8

There’s always a core audience that prioritize fun, for some definition of “fun”, over eye candy. The penultimate example is perhaps the loyal Dwarf Fortress player base. Players are so passionate about that game they donate money. If game making is what you’re after, make the games you want to play and then do what you can to connect with like-minded players. They’re out there if you can find them (and you follow through with the implementation).

There’s only so much time in a day, so many days in a year, and so many years in a life. Decide what it is you want to pursue and put your energy into it. Otherwise you’re just treading water and wasting time.

#9

Nothing is black and white. You spent six months on a project and gave up, what you wrote was probably (hopefully) technically impressive for you and if you had spent another six months then it could have been flashy.

The problem is you gave up. Most of us are here as a hobby, so you never “have to choose”, you just have to keep going.

#10

Sometimes one tries to ride a dead horse way too long.
Sometimes one gives up too early.

It’s not easy to tell when it’s right to give up a project, but wasting time on a bad project isn’t a good thing. But I agree, that sometimes there isn’t missing much to the point of success and I tend to give up too early, too.

#11

I try to create games that have not been created before (as far as I am aware of it anyway). I wouldn’t see the point in making a pacman clone because better programmers and better graphic artists than me have done it a thousand times already. But if I can come up with a new (to me) mechanic or a different way of interacting with a game, then I feel happy with what I’ve done. I’m never happy with the code I’ve written, I always have the sense it could be done better.

#12

Coming up with new ideas is impressive. At least to a person like me, who an only take an exisitn idea a step further but almost never can come up with a genuinely new idea. So that is a great skill that you have there!

Code must work. Particularly in game projects which end after a while, it only needs to be so good that it gets the job done. I think there is a big diference in application programming, when you face 10 or more years of maintanence, maintanence done by collegues who were often not involved in the firts development phase, and so rely on readable and well structured code, and mostly single person projects which have no long-term maintenence. There code only must be good for you, and only for some years.

Overengineering a solution is often as bad as writing sloppy code. The real trick is to find a middle ground, make it good enough to work, and simple enough not to have any extra effort with it. Unfortunately this is harder than it looks first.

Back on topic: New and interesting game ideas sure are impressive.