Recurring issue with making games

General Discussions
#1

I invest a lot of time into each of my projects. The issue is I seem to abandon them really quickly after a lot of work (I have not ever come close to finishing a game for the last 4 years). Mind the Gap was abandoned after building the first level, a separate project (Stray) was abandoned after 3 levels, and right now I am considering halting Project MP (a multiplayer terraria-like game) in favour of a new one. Right now Project MP has very minimal gameplay features but a ton of behind-the-scenes stuff I worked on which makes it super easy to add things into multiplayer. I want to work on something unique, not just a Terraria clone.

I’m torn whether I should continue Project MP or start a new project using most of the code for framework related things. In a few days I’ll be on vacation and won’t have access to my computer for around a month so working on anything will be impossible. I was considering using the time to think about what I could do, but I’d like to see how you guys cope with wanting to work on another project.

I want to actually have a game with actual gameplay for once and post it here. Mind the Gap was somewhat polished, but it only had one level. Stray (never released) was a platformer that was supposed to have a story but ultimately given up for Project MP for a sandbox quality.

Any ideas on what I should do?

#2

You got quite positive feedback on Mind the Gap… I can understand being distracted by shiny new things, but old projects are never dead, you can just start work on them again. :slight_smile:

As an experiment, why not return to Mind the Gap and add a couple of levels and fix a couple of the worst bugs?

#3

I looked back at Mind the Gap and I just sat there. I didn’t know what to do. It was so… strange seeing the thing I built just over a year ago. I looked back at Project MP and realized how much of a change it was between the two games. Even though I didn’t complete either one, it still had a lot of progress made between the two.

I tried to fix a camera jitter bug but I have no idea how any of the code works any more (I might’ve made it worse :persecutioncomplex:).

Mind the Gap by now is kinda dead (I really don’t remember how anything works, let alone trying to package it and distribute it). I seem to make a sandbox game so there’s “unlimited possibilities” but realize the possibilities are too much and decide to make a linear game. I give up on the linear game because I don’t want to make levels for it. The cycle viciously repeats itself.

I need to find something new to work on, that’s why I’m looking for feedback on what to do. I tried to experiment on MTG but it just didn’t work out. I also tried to make another level for Stray but I lost interest really rapidly. I just don’t have the desire to make levels (for any game for that matter).

Thanks for the feedback though. It just doesn’t feel the same to work on an old game because you know that old game has none of the new framework things you added in the most recent game and it just feels icky to touch the legacy code.

#4

Don’t like unfamiliar and badly written legacy code that makes no sense? How will you ever get a high paid job at a bank as an enterprise hack? :slight_smile:

#5

Sounds familiar… jumping from one project to the next is something I’ve done all my life. Ironically, for me the big “down” usually comes right after you manage to overcome some big technical challenge, in theory leaving the way open for more development, but in practice facing you before a lot of things to do, some requiring lots of tedious hours.

But I wouldn’t worry if I was you, providing you are making progress in term of skills.

Eventually, the right project will come, at the right moment, if you keep trying, learning, and enjoying what you do.

#6

Well, without going into “hard works trumps talent” and all that - here’s a few ideas you could try.

  1. Do code jams - with restrictions/time limits. Restrictions set you free
  2. Simple simple simple. Stop making frameworks, make games.
  3. Try making a canvas (javascript/web) game or two. It’s easy and fast to get feedback.
  4. Don’t work on or think about the project full time - code on it every day for only 5-15 minutes. Do a little change, fix a thing, add a comment, debug a thing - baby steps
#7

@topic yeah we all know this problem… cows go moo :3

Thats interesting - I really dread making anything in javascript because javascript is weird, has no real OOP, is hard to debug and all.
What frameworks do you recommend?

Also sound programming seems to be a mess, I guess it would imply minimal or no sound…

#8

Surprised this one hasn’t been mentioned already: make a small, shitty game. Something you can finish without giving up. My first few games were projects with underestimated time investments and they all ended up in the scrap pile. Making something terrible (e.g. poor Tetris clone) and actually FINISHING it completely will help you. It took a few of those to even begin to have the energy for a full-blown project. It’s akin to trying to run in real life. If you try to go too fast without already being practiced, you WILL burn out. I know it feels lame to go “slow” in game development but it is so worth it. Try it. :slight_smile:

#9

yeah improving and adding features upon a “finished” game is easier than starting something big from the get-go

#10

Thank you all for the support. I think I need to stop making huge games and just try little things for once. I’ll halt PMP progress for now since as a framework it’s as complete as I want it to be and use it for the next small game.

This so far has gotten me the farthest on Project MP (gotta get that github streak :point:).

Again, thanks for all the feedback. Now I just have to find an idea for said small game… :stuck_out_tongue:

#11

You could pick an old game (from Gamboy, Atari, etc) and clone it. Adding features you always wanted to see in that game makes it even more fun.

#12

One thing that I enjoy is a good racing game. Try to make one in 2D or 3D and trust me, it’s way more fun than it sounds.

RPGs, adventure games, etc… need content and lots of work which is usually difficult for one person. That’s why a physics simulator like a racing game would work because all you have to do is learn most of the math behind kinematics and then apply it. The bugs are funny to look at because, for example, your car will spin uncontrollably or something like that, it keeps you happy. Also, making a racing game doesn’t give me that feeling of “oh crap i have a lot on my plate”

#13

I feel the same way but with voxel engines. Have I ever managed to even getting close to completing one? Nope. But I’ll eat my shoes if I ever catch myself saying that generating voxels from a noise map ain’t fun. It’s actually the reason I started programming in the first place, I always had the dream of creating a voxel engine.

#14

Like has already been said: start smaller. Work on prototypes instead of games. Try to always have something that works versus constantly working towards an elaborate end goal. Your scope should be a weekend or a week instead of months. Not finished after that? Too bad, publish it (remember, always have something that works) and move on to the next thing. If one of your prototypes captures the crowd’s attention, then maybe start thinking about putting more work into it.

Ludum Dare is in 3 weeks, and it’s a great way to force yourself to work on smaller games. But smaller game jams are happening all the time: try http://jams.gamejolt.com/browse/active or http://itch.io/jams for a start. Also check out One Game a Month.

#15

The suggestion is based on my personal experience. At the beginning I didn’t like javascript either - but I’ve found web development to be the most fun I’ve had with programming in a long time. And the most rewarding too in terms of quick feedback, development and work (aka money).

It’s not necessarily harder to debug although the dev setup may take a bit more work/getting used to than a fully fledged IDE provides out of the box. Browser (Chrome especially) dev tools are great (even have hotswapping nowadays) + you can use pre-processors like jshint/lint to catch bugs immediately.

You can do OOP with javascript. Javascripts prototype system can mimic classical OOP. And now with ES6 (and Babel.js) it’s as easy as using the familiar keywords ‘extend’ and ‘class’ (it still uses prototypes behind the scenes).

If you’re specifically into game development Phaser.js or the Create.js suite are great alternatives. Another great rendering framework with game dev in mind is Pixi.js (which Phaser.js uses) or three.js for 3d. Or simply not use a framework at all.

For large projects (> 1000 LOC) you’ll definitely want to be using some kind of bundler that will sort out your dependencies for you such as Browserify (my fav), WebPack or RequireJS.

As a side note, the web dev environment requires familiarity with the terminal/console or you’ll struggle (at least at the start) using stuff like these bundlers and preprocessors.

A few things you might get inspired from:
https://www.youtube.com/watch?v=RTxtiLp1C8Y (JS wizardy)
https://www.youtube.com/watch?v=avwDj3KRuLc (talk by a dude who makes a kind of minecraft clone with javascript (software rendered, aka no webgl))
https://vimeo.com/105955605 (space invaders game from scratch, no libs)

#16

If you’re afraid of JavaScript, you might want to check out Processing. Its syntax is based on Java, and in fact by default it is Java. But it makes it much easier to get something visual and interactive up and running without all the boilerplate of Java.

You can also deploy Processing as JavaScript using Processing.js. This might be an easier gateway into the JavaScript world, especially if you have a background in Java.

Also note that you can deploy libGDX as JavaScript.

#17

True enough; Javascript works on a basis of prototypes rather than inheritance. And if you take the time to understand how that works, I think you’ll find it actually works quite well for game design purposes. Its rather powerful to have an object and just be able to swap out its parent prototype for something else after its creation, thinking for example about AI behaviors.

http://sporto.github.io/blog/2013/02/22/a-plain-english-guide-to-javascript-prototypes/

As for debugging: Chrome has rather powerful built-in debugging features (including setting breakpoints), and so does the awesome Webstorm IDE. Its not as poor as it was 10 years ago. Plus nowadays you have the standardized console.log() as the alternative for the super debugging tool we know as System.out.println() :slight_smile:

Still, sound and especially music output is and remains a rather icky thing to do in Javascript games. I wonder how LibGDX solves that.

#18

I think the focus on languages/platforms of most of the replies are wrong. At least, that was not my problem when I jumped from project to project for years.

It is more a matter of motivation, organizing your time, setting yourself realistic goals.

Motivation is the most important thing. Making any game, even a simple one, is a lot of work, for (probably) no material gain. You must absolutely love what you’re doing, be your project’s biggest fan, or you’ll never finish it. So begin sorting out that, if you don’t feel that unstoppable drive for making a certain idea become a game, you’ll probably never finish any project, no matter the genre, programming language or platforms you choose.

Once you’re there, and the concept is clear in your mind, you muse be realistic and have a plan. A small project may take a few dozen hours, but likely you’ll end up making something that involves hundreds of hours. Based in your spare time, understand from the beginning, even if approximately, that this is going to take weeks, months, or more, because if you start the project believing you’ll end it very quickly, the realization of truth may end up crashing down your motivation.

Your biggest assets when you build games are not your tech skills or your intelligence, but your motivation in the project. Keep it strong and the rest will be sorted out.

#19

I don’t disagree with you. But, choosing the right language can go a long way towards helping you stay motivated.

That’s why I recommend Processing to people just starting out. You get immediate feedback: 1 line of code and you’ve got a ball displayed on the screen, following your mouse around. No boilerplate, no worrying about how classes and objects work. And then you can deploy it as JavaScript and send that link to people without worrying about the mess of Java deployment.

So yeah, motivation is key, but choosing the right language is definitely part of staying motivated.

#20

Likewise, I don’t disagree with you either, and certainly will look into Processing, which I don’t know. But as this was developing more and more into a language choice thread, I felt I had to give my opinion, as the “soul” behind a game is everything. And I see what you mean, it is true that everything is connected in the end. When I started my own project, I “knew” java only superficially, as I’ve developed for decades in C, C# and Delphi. Learning a new language has given me a lot of satisfaction.