How does one "Stick" to it?

Newbie & Debugging Questions
#1

This is my biggest downfall, I am going to go ahead and say I honestly think I have awesome ideas and I get them constantly but I can never start a project from start to finish! (my idea of an awesome idea is something that I might have or might have not seen before, maybe something a game SHOULD have had or should have been like).

How do you guys stick a project out?

I currently have 2 projects, one is a 2D topdown space shooter, with character levels, xp, customizable ships, different solar systems etc etc…second is a platformer “racing” game, similar to Hill Climb Racing except you are a genius hobo that builds rocket engines and uses them to race across the map on various trolleys.

My space game I started from the gameplay right off the bat, I made all my classes that handle renderering and UI, then started working on the base of the game, the ship and player. I pretty much hit a stand still there when I realized my Java knowledge in certain areas is lacking, saving the state for one and secondly my math skills are a little naff.

For my other game I decided to start with the splashscreen > menu’s, I got as far as to the Game screen before I hit a problem and so far have been firing up my IDE and sitting there scratching my head.

So how do you guys stick to one project? I have tried writing down ideas and leaving them for later but the urge to start working on it right away is ridiculous :frowning:

Am I making games that are too complex? I have made basic games, I have made Pong, Tic Tac Toe, Mole Smash, Blackjack, Snap, Got halfway through texas hold em’ but done a ton of code refactoring (I used the same shuffle algorithms and card/player classes from blackjack/snap) and then got bored lol.

Seriously…how do you do it?!

#2

I think of cool things I could do. Like my 3D project, I am terrible with that, but the one thing that keeps me going is thinking: “Wouldn’t it be cool if I could ______?”.

That and soda.

#3

Get a following on your project that would be sad if you quit.

#4

You made a spashscreen AND a ui? Seriously? WOW!!!

9/10 of all my ‘projects’ doesn’t get that far! But you’ll notice the one day that you finally start on something truly worth it. I know. I did.

Been working on my little secret game for over a year now, and I have to really control myself not to go full apes on it all the time I’m infront of my keyboard. I’ve done as you, multiple times. Sometimes I’ve walked away from nearly finished games, just in need of that final touch…

I stopped beliving that an unfinished project was a failure years ago. Every little effort you put into game programming/designing makes you a little bit better then before, it’s just finding that energy to put in to finally bring yourself over that edge - after that it’s just the same, it just becomes easier to abandon projects :slight_smile:

I belive that all JGO nuts has to go through a few stages:

The Newb
Everything goes into the same class file. Weird method names, short variable names and you don’t hesitate to call ‘new’ on any object inside your main loop. Duplicate code is no worries, you’ve got cut & paste! Favourite IDE tool - Compile

The Object Oriented Oracle
Everything is as object. Inheritance makes your world. The base class derived into gazillions of subclasses is atleast 8kb in size. Can’t belive that he/she ever cut and pasted code. Favourite IDE tool - New Java class file

The Abstractionist
Tries to abstract all functionality out of every class. Reuse and generic design is your lead star. Ends up with an abstract implementation of a game, that really would be a killer - it’s just a pity you can create an instance of anything. Favourite IDE tool - Refactoring

The Zen Master of Java
After going through the above stages you’ve seen the light - you start to actually make your abstractions work, and find the golden way between inheritance and abstraction. Simple code is for Newbs only. A toString() method makes use of about half the standard library. Your compiled classfiles are together larger then the 3rd party jars you use, and if you can make a generic out of it, you probably will. Favourite IDE tool - UML builder

The Perfectionist
Less lines, same functionality. You strip everything down to the bare bones and try to identify the common divisors between your objects. You start to grip things like interfaces, static inner classes and design patterns. Nothing is left out for the fantasy - every little line of code is carefully studied. Favourite IDE tool - Profiling tool

The Jarhead
You realise that perfection makes fast games, but fun and fast isn’t really interchangeable. That method you optimized down to 4 lines of obfuscated Java really doesn’t make or brake the game. You start to write small classes that do their job, no fuzz and no bs - abstractions are used when neccessary, inheritance is used with caution and interfaces are designed in an generic way. You write beautiful code, and well functioning classes. You also start to write wiki-posts. Favourite IDE tool - Code analyzer

4K God
You win a 4K contest. Ludum Dare dedicates their front page to you name, you’ve got more medals then the bandwidth of the JGO server can handle. You’re like the Chuck Norris of the Java world. Favourite IDE tool - IDE? Who need it?

:wink:

#5

Wow. You just outlined my entire java experience, minus the last one.

#6

I’m stuck at the end too :frowning:

#7

That was a fanstastic post! It has described my path so far lol. I think I am around the Abstractionist, that first stage is bang on. I managed to create Blackjack within about 3 classes, now I have about 15. So much easier to have a class for Card, Deck, Player, Chip etc etc hehe.

I started working on a UI, all the base code was there but nothing was visually implemented on the screen, well nothing major. For my spaceship game I did get as far as having HP, speed and stuff on the screen. As well as FPS. On top of that I EVENTUALLY got the right click menu to work, so now you can right click and select/lock targets.

But yeah, hit a hurdle when I moved away from that and started to work on a way to save the state of the game before I ended up with a stackoverflows (which always happens if I try to write to a json file of a very complicated object, working on that…lol)

#8

Rickmeister: hahaha spot on! I especially like your “favorite tools” for each section. :slight_smile:

Gibbo3771: I belive you need a couple of things to really stick with a project. You need experience from all parts of the process, so you can recognize what stage of the project you are in. It´s a real killer if you think you´re getting close and then realize that you´re only halfway. This is also important to let you take a step back from what you´re doing and letting you see the big picture. You also need experience in producing the basics really fast. If you keep getting stuck at each and every part of the code… Well, that can make anybody quit. If you can get a basic prototype with basic game physics, collision detection and a couple of mobs up and running relatively fast that will keep momentum going and let you focus on the important parts. And of course you need an idea you really belive in. Really, really belive. :slight_smile:

I´m actually a big fan of pen and paper, draw stuff out and write what I want to do. This let me have a more abstract way of thinking about the project instead of sitting in front of the computer and stare at Eclipse. That´s my way of looking at the bigger picture.

#9

Pen and paper are seriously underestimated tools! Can’t really see how Einstein would have worked out his theory without them…

#10

[quote] I pretty much hit a stand still there when I realized my Java knowledge in certain areas is lacking, saving the state for one and secondly my math skills are a little naff.
[/quote]
These seem like useful “detours.”

I don’t know what aspect of the math you are feeling insecure about, but if you are in autodidact mode, there are several game books with decent math-review sections, as well as online courses and library textbooks.

The main danger I guess is finding a stopping point. I try to limit my detours to things I directly need for my projects, or are just intensely interesting for some unknown, yet-to-be-disclosed reason.

#11

Strangely a funny little psychological “trick” I learned early on in what laughably could be called my “game development career” was to do all the boring, shitty, tedious stuff first. The very first things I always got working in a game project were the title screen, credits, help screen, etc. - all the dull UI things. Then all I had to look forward to was more and more exciting stuff like blowing stuff up and so on.

Works for me, doesn’t work for everyone. Riven didn’t like it.
By which I mean nothing bad about Riven, just that some (maybe most?) people prefer to start with the explosions and fun stuff and do the dull stuff afterwards. Try it both ways and see what works for you.

Cas :slight_smile:

#12

I have got three answers.

  1. Discipline. If you are serious with a project, e.g. if you plan to make money from it, there is the point when it’s not fun but work. So it’s like every other job - sit down get the work done. Set up a schedule of work times, keep it.

  2. Be a slacker - if it’s a hobby project, it’s just for fun and entertainmnet, or personal education. There is no need to have progress or finish it in a certain frame of time. There isn’t even a need to finish it at all. So just do whatever you feel like doing most at a time.

  3. Be responsible - if the project is closed source but there is some interest, you might feel responsible to the people using it (playing it, if it’s a game demo). The feeling of being responsible to the people who wait for the finished product can be a good motivation to work on it.

You can mix all three of course. For me, personally, (3) is the best way to stay motivated with a project. If there is no interest in a project that I have advertised, I sooner or later quit working on it. Maybe not quit, but rather dig it out every few years, add a few features and then try something else again.

#13

Which really accounts for quite a bit. I’d also say: “Be partially sane”. About your knowledge base and skills and don’t try to overreach (by much). In another thread I was bitching about “code tinkerers”. They eventually burn themselves out by not really making progress. If you start feeling like you’re on a hamster’s run or that the real goal is a mirage in distance that you’re not approaching…you’ll quit. People with the similar “not-made-here” syndrome have the same problem.

#14

These seem like useful “detours.”

I don’t know what aspect of the math you are feeling insecure about, but if you are in autodidact mode, there are several game books with decent math-review sections, as well as online courses and library textbooks.

The main danger I guess is finding a stopping point. I try to limit my detours to things I directly need for my projects, or are just intensely interesting for some unknown, yet-to-be-disclosed reason.
[/quote]
I agree that those could be called “detours”, i’ve taken a step away from main projects and made pet projects that are revolved around certain things I struggle with. I have written fully fledged programs based completely off math/arithmitec (test code for HP as percentage, fraction just to see how it would be coded) and even saving objects to json but can never seem to get that working.

Thanks for the replies so far, some good stuff in here.

#15

As you only wrote about lack of knowledge the question should not be how to stick to projects but how to improve your programming skills.
There, nothing helps but learning, practicing, reading, asking. Again and again. For many years.
Simple as that.
Most likely you underestimate programming efforts like most beginners (and professionals in fact as well) and should thus start with simpler games.
To keep up motivation and to get results as soon as possible, do not start with menus, ui, splash screen, saving and loading, but with the game core. Implement the game mechanics and logic at first. Use dummy graphics, sounds, buttons, etc.

#16

I would start with making a playable prototype.
The earlier the game is playable, the more fun it is to stick to the project.

Of course, once the “dull stuff” has to be implemented, the more you have to force yourself.
But better to have a workable “core game” with poorly implemented fuzz around it, than a
nicely organized, abstracted and encapsulated engine framework, that never reached the stage of something playable.

If the prototype is fun to play, it can be reorganzed in a more propper implementation.

Well, in the end, the best motivator to finish a game is either a $$$ amount waiting for payout,
or some deadline for a competion or some other “fame feedback” generator.

But even abandoned projects could serve later as junkyards for later code-copy-paste or asset reuse.

#17

I found the OP’s questions particularly close to my heart, because I used to reach the same roadblocks with almost every project I undertake.

I had to medal Rickmeister’s post because he made a tremendously good point. I stop working on many ideas that I feel are ‘killer’ at the time I start writing them, if the interest peters out during development then clearly it’s not the right time for me to be working on them.

However, what Rickmeister hit on particularly well is the point that no code you write is necessarily bad code - you learn from it, make mistakes, refactor and improve what you’ve written.

I’ve saved so much time reusing and improving classes I’ve written for older projects, which makes prototyping and reaching that ‘sweet spot’ in development that much quicker.

What do I mean by ‘sweet spot’, exactly?

Well, many developers will probably get the gist of what I mean. You’ve implemented all your boiler-plate code, got your project environment sorted, and you’ve got things happening on the screen. You think, ‘It’d be awesome to add this in…’, and you grab a soda/coffee/energy drink and sit there boppin’ your noggin’ to some good tunes and code away. A zen-like state of coding bliss.

But invariably, you can get burned out, and yes sometimes don’t always pan out the way you want. But every line of code you write you learn a little bit more - and failure can only teach us how to succeed next time, even if those steps are small and incremental.

Eventually, your combined knowledge and skill in programming, in terms of both persistence and capability, will see your projects complete.

I love the OPs ideas, and would love to see some games come from him in future!

#18

I belive prototypes are the key to making a good game. If you can get a quick “sketch” up and running then you can decide if it´s fun to play or if it´s just not working out. You don´t have to be under the burden of a fancy look. It just have to work. If it´s fun, continue or start fresh with the know how. If it´s not fun, then at least you probably have learned something on the way and not lost too much time on getting the fancy animatios just right. :slight_smile: