Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


How do YOU do it?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
18 replies to this topic

#1 Munchkin9   Members   -  Reputation: 125

Like
0Likes
Like

Posted 27 February 2012 - 12:40 PM

Hey there,

Programming/game designing as a hobby is proving rather tricky. All too often things in my life get in the way of my time to program, this results in me often not finishing projects simply because I've lost my strand of thought, found some new interest and in general just can't seem to get motivated in the project again.

While I've been able to reduce this a bit by properly commenting my code so that I know how everything works and what I was doing it really isn't enough. At the same time I find that the bigger the project the harder it will be to make and the more my own limited capabilities will get in the way. This all results in my getting almost nothing truly finished. Though I know this is normal to a limit, I think I've reached that limit.

The obviouse solution, for me, seems to be to design and program really small games. Things that would take me one, or at most two, days to complete and would be fun and addictive but not truly mind blowing. Five minute games basically.

Problem is, try as I might, I can not seem to come up with any. I know the general idea of what a small game should be like, but whenever I try to sit down and design one the game either ends up being uninteresting or too 'big'. Very quickly I notice I'm adding extra 'small', fun features left and right. These 'small' features quickly accumulate though, the project gets too big, then somewhere along the line I realize that the original idea, while probably a good one, is in itself too big and I scrap the entire thing. Its like feature creep at the design process, on crack.

So I'm seeking some tips from you guys. How do you design a small, quick game and get about making it without it turning into a major project?

Sponsor:

#2 Stormynature   Crossbones+   -  Reputation: 3413

Like
0Likes
Like

Posted 27 February 2012 - 12:54 PM

Check the following website. They run an annual competition to build games from scratch with 48 hours.
http://globalgamejam.org/

#3 Munchkin9   Members   -  Reputation: 125

Like
0Likes
Like

Posted 27 February 2012 - 01:25 PM

I've looked into gamejams. The Ludum Dare and its MiniLDs sound particularly nice but I'm not sure it would actually help me design the game to be small. Rather I'd probably just wouldn't be able to finish.

#4 kseh   Crossbones+   -  Reputation: 2195

Like
1Likes
Like

Posted 27 February 2012 - 02:42 PM

The game that I'm working on that I mention in my journal was intended to be a quick project that I was hoping to have done in about a month. The first prototype was all sorted out in about a week or so and I could see the basic game play in action and I found it very exciting. But it was far from being a polished game, features needed to be added, and there were a number of things in my base code that I've been meaning to fix up for some time so it's taken longer than expected. I'm approaching week 11 and I don't have as much drive to finish as I did when I started but I still have the determination to get it to what I'd consider a finished state. The goal seems to have shifted from seeing the basic concept that I had in my mind working to making a complete game.

Still, additional features will continue to be added and I worry about it a bit sometimes that it's going to get to be too much. But if nothing else I figure that down the road I'll be working on some other project and I'll eventually say something like, "Hey, that code I had in that one old game would probably be perfect for this new feature." So if I had any recommendation it'd be to try and make sure that any feature that you work on is something that you can probably make use of down the road. Eventually you'll have enough stuff all set to go that it'll be much easier and faster to throw something together.

#5 Munchkin9   Members   -  Reputation: 125

Like
0Likes
Like

Posted 27 February 2012 - 03:54 PM

Hmm...I see your point. Thanks for the advice. I have been noticing that the more I program the easier it becomes and the more resources I can draw on, so that I can copy paste large portions of code with very little tweaking to get it working.

Not sure if it answers my problem about designing a small game though. I very much appreciate the advice about the programing side of it, any tips on the design side?

#6 Heath   Members   -  Reputation: 344

Like
1Likes
Like

Posted 28 February 2012 - 01:27 AM

Tell me about it.

I definitely feel like my interests rise and fall with each week. One week I'll be totally interested in comic books -- Oh I'll scour through my copies of The Dark Knight Returns and How to Draw Comics the Marvel Way and maybe end up with a few semi-interesting sketches that would need a lot of work before being called a finished product. The next week, I'll move onto writing a story, and I'll read something like The 90-Day Novel and maybe end up with 5 pages that interest me much more than the sketches I drew the week before. And the next week, I'll look for some game ideas, possibly in the comic book and story ideas I had previously considered. And maybe the week after, I'll remember the car in my carport and look for parts online to restore my old VW bug. :)

This is so because it's all a hobby, and I'm really just entertaining myself. Looking back, I have done this practically all my life. My childhood was spent much like this. So, call me a lover, call me a dreamer. Maybe one day I'll find that rainbow connection..... Oh, also I have a banjo I play once in a while. :P

#7 Acharis   Crossbones+   -  Reputation: 3965

Like
4Likes
Like

Posted 28 February 2012 - 05:06 AM

this results in me often not finishing projects simply because I've lost my strand of thought, found some new interest and in general just can't seem to get motivated in the project again.

It's very simple. You either desire to finish games or you don't. I'm all for small projects and such, but if your limit is 2 days then it is not a question about game design tricks, it is simply a short attention span. At the very minimum aim to make a game in one month (but no less). You start working on it and take on no new projects until you finish it (or the deadline is reached and you have to admit a failure).

Tip: Making a game only for your onw enjoyment never works. If you want to finish it make it for other people to play and enjoy (or for money or for whatever other external reason not directly related to you). In a long run sitting in front of TV is more enjoyable all the time, while making games has also the dark hours sometimes you have to survive, if you are doing it just for entertainment then of course you will always quit in the middle when you encounter the first obstacle.

Europe1300.eu - Historical Realistic Medieval Sim (RELEASED!)

PocketSpaceEmpire - turn based 4X with no micromanagement FB


#8 J-dog   Members   -  Reputation: 120

Like
0Likes
Like

Posted 28 February 2012 - 08:11 AM

It depends on you! I have to disagree with the last post, because if you're doing something for your own enjoyment, you're doing it out of love and for the fun of it. If you're doing it for others, it's easier to be driven - yes - but it also makes it more of a job and more of a chore.

Personally I've struggled to finish small projects - I have two "ailments" - first, I suffer from what you have: the feature creep. I cannot help but dream big, and even little projects begin to rise to unrealistic heights. Second, I lose patience. This is related to my games becoming too large quickly, but I sometimes realise that I've gone off on a tangent and my work has become unmanagable. Eww.

The best way to mitigate this, I feel, is through planning. Writing ideas down into a game design doc and giving it some thought before the offset really gives me grounding. In that case, I find myself removing features more than I add them, and even if I do add something, the document keeps me grounded so that I do not go overboard.

That's my suggestion, and it works quite well for me. I wouldn't stress too much about it though - there is much to learn from failed attempts, and I do not look back on mine with regret. I learnt from them, and I enjoyed doing them, and sometimes it's also better to cut something lose than to try and revive a long dead idea - besides, your tendency to experiment and grow projects should help you better understand game design... so no loss, right? :)

#9 kseh   Crossbones+   -  Reputation: 2195

Like
0Likes
Like

Posted 28 February 2012 - 01:50 PM

I'm not sure what sort of advice I could give on small game design because each game is going to be different. And it really depends on what you're trying to put together. So I'll just start typing and see what comes up.

Perhaps what's needed is a way to keep you from getting too sidetracked. Something as simple as a deadline or a central vision or mission statement of sorts. When you find yourself wanting to add a new feature, look at your deadline, look at your central vision, and ask yourself how would adding the feature affect these things? Is pushing back your deadline or deviating from your central vision going to be worth it? Do you "think" that adding the feature is going to make the game more fun or do you "know" it is going to make the game more fun?

I'm wondering if maybe you'd benefit from making a couple of clones. More of a precise clone rather than your interpretation on someone else's game (some differences are of course inevitable). Idea being that you know what the end result is supposed to be. You don't have to worry about adding in a few extra features here and there, you know what the game is supposed to contain, you can focus on getting code working and making it so that you can port it over to original projects later. In addition to building a code library maybe you can also pick up on how these games were designed in the first place and the considerations that were involved. In short, learn design by studying how others designed their work.

For some reason I can't help but think of all the competition shows my wife and I watch on food network. They have a time limit and a central theme or a couple ingredients to work with and they have to make something to impress the judges. You have these talented chefs putting stuff together that sometimes look amazing but isn't that great tasting, something that shows great technique but doesn't work with the theme, or maybe various components taste great but they don't work together as a whole. The principals for what you want your game to be aren't that different even if you take the deadline away. You want things to present well (not necessarily meaning you require super graphics), you want it to be entertaining, you want to show a little technique, you need to get all the necessary elements for your genre, and it all has to come together as a whole. Actually, maybe you do need a bit of a deadline too because what good is it spending a ton of time mastering all those things if nobody gets to see the results?

#10 Munchkin9   Members   -  Reputation: 125

Like
0Likes
Like

Posted 28 February 2012 - 04:50 PM

Wow, all great responses thank you.

Let me quickly explain how I usually get about designing and making a game for comparison's sake:

-Where the original idea comes from can vary massively but usually it comes from *wanting* to play a certain game, where you do a certain something and not finding that satisfied in any existing game.

-Sometimes it also comes from seeing a few different features in unrelated games and thinking that these features would be really cool working together in the same game.

-At this point I grab my notebook (I prefer writing when I'm just sketching ideas as opposed to typing) and start considering the facets of the game I want to make. I consider what the beginning reason is for making it, what might make it fun, challenging and unique. I start sketching out possible features though usually at this point I'm just writing out what I want to be in the game not how to do it.

-Once I have a decent idea of how the game would look, feel, function etc, I go on google docs and start typing out a more in depth design document. I look at the literal goal of the game, what the player is told to try and achieve, I look at each major feature and plan out how these function and how they relate to one another.

-Then I let it sit there for about a week. On purpose.

-One week later, about, I come back to it and reread it, revise it and polish it (and add to it, usually)

-After that it usually goes to programming, if I've found the motivation.

-I work on the project for sometimes a week, sometimes a few months. Hitting snags along the way and gradually overcoming them (which is probably the part I like the best actually).

-Then at some point I look at what I've done. Show it to a friend or a family member. I find that: for all the time I spent on it there is hardly anything to show because its mostly "under the hood stuff" or they just don't understand what I'm trying to make and so don't like it.

That's usually the point where my productivity starts to tapper off.

Now the problems that occur, I mostly know why they're there and how to get around them. It comes from a combination of classes, or jobs getting in the way. And showing an unfinished product before it should be shown. I also know I have a really hard time making people understand what I am trying to make, something I REALLY need to deal with before I properly head into the industry.

I've also found that one thing that usually makes me lose interest/heart is that after a few weeks of programming the project doesn't LOOK any good. Filled with glitchy graphics and poor art (my own), usually no music or sound effects and no actual gameplay as I was too busy setting up the fundementals and game mechanics to worry about turning them into a game.

Recently I made a small "visual poem" which approached designing from the other side, I started with the art, sounds and music, made the product look good before I started working on the gameplay. I am actually fairly happy with the result, the game is pretty, sounds nice, and didn't take long (about 3 days). Having said that, its not a game, there isn't anything to do in it. And everyone I showed it to has told me that they don't see the point. My hopeless whinning that "there IS no point" doesn't seem to make things any better. Tsk can't they see the greatness of the vision of the artist :) .

Anyway, long story short I thought that making 'quick' games would help me: streamline my design process, get it done before stuff gets in the way, help me work on getting a project presentable quickly. Not to mention that it would give me more stuff to put in a portfolio or on a website (that I am planing to put up eventually). That's the part where I realized that I couldn't come up with a single 'small' idea.

Where was I heading with this?

I do like the snags in projects. In fact its the part I enjoy the most and as soon as it turns into 'making the game world' or anything which I consider repetatitive then I lose interest.

I do have a sort of deadline: I want to put up a website with some games before I head off to college next year. I was supposed to go this year but we missed the deadline :P .

On the point about having a challenge set for you as in the cooking competition, that is what I'm hoping gamejams will provide, some 'theme' to work with and a very limited time. But as I have to wait around until one starts up I'd prefer do something until then. As for coming up with my own 'themes' and challenges that doesn't seem to work for me. It doesn't work if I came up with it.

And I hate remaking game someone else has made. I don't know, its a psychological thing. I feel like I'm wasting my time even more than if I was just sitting on my hands, so to speak. I do plenty of research on other designers' work by strudying games I play (hard to convince people you are really working and not playing but whatever). Remaking them though, sorry can't do that.

And @Acharis: I'm not sure I agree with you. It is entirely possible to design I game that takes you all of 2 days to make. Just look at free online flash games and things like that. I'm not worried about how long the design takes me, that, I never lose interest in (if the idea works). I'm talking about the programming part. Which is why I was asking if people had 'tricks' to coming up with a way to design small... In hind sight I'm realizing that the question is ridiculously vague. But hey! I'm getting plenty of great tips anyhow.

#11 lrh9   Members   -  Reputation: 174

Like
0Likes
Like

Posted 28 February 2012 - 10:52 PM

I'm new at game development, and I have encountered a couple of the problems you have mentioned.

I think that in any project - big or small - it is easy to get distracted by the monolithic idea and presentation we have in mind. Yes we want to make a game, but unless we stop thinking about that game as a single entity and instead start focusing on the individual components we cannot begin to create it. It would be like trying to step across a room in a single step; it can't be done.

So what I am trying is decomposing my game into components. Instead of thinking, "I'm going to make a game.", I think, "First I need to play an intro movie, then I need to present the main menu, and in order to do that I need to..., then I need to..." and so on. I too keep a design and technical document, and I write down each "piece" or "step" in order. When I get finished I hope I have a document that lists everything that I need to implement to create a complete game.

It sounds like you are on the right track. You keep a design document. It seems to me that you get off track when you code. It is possible for us to encounter the same problem I just described when we code. Instead of keeping source files small and focused on a single task, we can write monolithic blocks of source that are difficult - if not impossible - to understand and work with.

I think there are two major contributors to this. The first is that we might not use language features that help us keep source files small and focused. In all languages I have seen, there are ways to divide source over multiple files and use them to create a whole program. In Python - my language of choice - we can create modules that we can later import and treat like a namespace - each one containing the functions, classes, and objects we created in them. In C++ individual source files can be compiled to an object file, and linked together using a linker.

It is important to make use of this functionality. If I put the code for my project in one source file, I would have several pages of source just to play movies, display a main menu, and perform a few other tasks. That is probably less than 1% of everything a game has to do. However, if I put movie related code in one file and menu related code in another I can keep my main source file under a page at that point. Much easier to understand. "Here I'm playing a movie. Here I'm displaying a menu." If I design and code well enough, I can make minor to moderate changes in one file and the others will still work.

The other major contributor to monolithic source is the lack of separation between code, data, and the way data is represented. We have all seen beginning efforts at game programming where each entity in the game is represented by a dozen variables, and each variable has a unique name. "//Goblin1; goblin1HP = 5; goblin1MP = 0; ..." The major problem with this is that it makes data difficult to change. We have to locate the specific thing we want to change in our source. In some languages, we might even have to recompile the entire game just because we changed one monster. The minor problem is that it clutters the source. "goblin1 = Monster.fromFile("goblinstats.txt")" is better than a dozen lines setting each stat.

I have also considered the problems of adding visuals and sounds to my game. There is nothing wrong with programmer's art. If the lack of quality graphics and audio breaks our game's fun, we need to try to improve on our game content. Pacman would be the same game if it consisted of a blob eating dots and evading squares and chasing triangles, and people would probably still play it and compete for high scores. Even Pong is enjoyable, and it's just a dot bouncing back and forth between two lines. A game's entertainment value is not linearly proportional to its graphics and audio quality. Increasing quality provides diminishing returns.

I intend to use programmer's art myself. We can separate the data about how objects work from the data about what they look like and sound like. My game is set in space, but for my early work I am probably going to use a simple sphere textured with a smiley face to represent stars and planets, and a random model to represent spaceships. For all I know I might use a cow model to represent a spaceship. I could call my game "Cows in Space". The game will still play the same. If we lose a pawn for our chessboard, we can substitute a coin. We still use it the same way. Same principle.

Of course, I understand the desire to present a compelling graphics and audio experience. After we complete the core content of our game, we can go back and replace programmer's art with stand in art. There are tons of free models, textures, and sounds on the Internet. As long as we respect intellectual property rights, we can use many of those resources to take our game one step closer to what we envision. Sure, one modeler's spaceship might be inconsistent with another modeler's spaceship. At least I have spaceships.

At that point, hopefully we can show off our working game and attract interest. Maybe we can entice better artists and modelers to create better art for us, or we can attract investors and purchase services to help us complete the game. We could release it for free and see if a modding community develops around it and improves upon it. The point is, we can make a game without being modelers or musicians.

I hope this helps. Good luck, to both of us.

#12 kseh   Crossbones+   -  Reputation: 2195

Like
0Likes
Like

Posted 29 February 2012 - 02:30 PM

Recently I made a small "visual poem" which approached designing from the other side, I started with the art, sounds and music, made the product look good before I started working on the gameplay.


You know what, this sounds great, perhaps you should do more of these. If for no other reason than that it gives you the opportunity to derive inspiration from art resources that you are proud of. If the typical audience you're showing things to is family and friends then unless they're programmers they probably won't get it. Find a different audience. It might be hard but it does you no good to be getting opinions from people that aren't relevant to what you're trying to do. In the end, family and friends might be representative of the people you want to play a finished game of yours, but you're not at that stage yet. Jumping the gun on that is decreasing your productivity and motivation.

I do have a sort of deadline: I want to put up a website with some games before I head off to college next year.


If you can't do up full games in time then consider putting up a bunch of very small projects that demonstrate basic game elements like accepting user input, displaying images, animation, scrolling, collision, music and sound effects, or if you're up for it some more advanced path finding, quad trees, scripting or whatever. Use the resources you have that you're proud of and build upon them. You're more likely to be able to hammer out a few demos within a month than you are two games you're happy about within a year. If you have something that can tie it altogether like the art assets from the poem project then so much the better. Especially if you're able to build upon your assets at the same time.

#13 Heath   Members   -  Reputation: 344

Like
1Likes
Like

Posted 01 March 2012 - 12:13 AM

Tip: Making a game only for your onw enjoyment never works. If you want to finish it make it for other people to play and enjoy (or for money or for whatever other external reason not directly related to you). In a long run sitting in front of TV is more enjoyable all the time, while making games has also the dark hours sometimes you have to survive, if you are doing it just for entertainment then of course you will always quit in the middle when you encounter the first obstacle.

I like this advice. Like I said, if I try only to entertain myself, I'll go on for years and I know it. It'll drag out and I'm never totally satisfied with it (which is ironic).

If I'm writing something for someone else, I'm much more pressed to get something done. And I'll very probably still enjoy it. In fact, one of the few open source games that I would call "complete" was Abe's Amazing Adventure, which was made for its author's son as a present. :) I always thought that was cool when I heard it.

#14 amile duan   Members   -  Reputation: 95

Like
0Likes
Like

Posted 01 March 2012 - 09:04 PM

Lots of designers have faced this problem before,for me,I will ask some friends for advice.

#15 SuperG   Members   -  Reputation: 560

Like
0Likes
Like

Posted 05 March 2012 - 03:44 PM

Some points I recognize.
Short attention span, mostly dreaming about. Dream about something much to big. Actualy even bigger then Triple A. And havent even finished one little game. That's me.
It seams like it the barrier for the masses. Big titles are well known. So we think first of so big hit. So the advice of starting with something small is push more starters over the edge of get something finished. After some reality awareness. And the tasted of archievment getting it done. I can imagnine what it would feel like. As I did finish some dos utility tools. Wich was a nice feeling. But a small game is still bigger then that. with much more untouch ground.

But also if not finished you gain a code base. wich get richer wenn you go along also with just tryin.

The problem I have, my atari 2600 times are decades in the past. And now I play mostly big titles with fancy Graphics on PC. Old game and small stuf I don't touch. Not my thing. Until someone put angry bird on my shared ipad. Nice for a short killing time. But gaming I do prefere on game PC. Consoles well because my fellow online players prefer that way so I got a console. For me step back but I am not alone.

So it seams for my game project I am the main target. If you make games for yourself all the choice will be your own preferences. And tunnel vision a pittfall lures around. But I have no problem with this. I tmight be it will be more fulfilling a niche market and the focus on creativity. Starting to fast with a team might lead to multi captain project. But also broad view on your thing.

So for me doing small is not what I like to do. Or aim for. So I think beyond the problem but the key is still start small. And seek ways to surpass this limitations. As you know I am not a expert more a noob but no fool either. So small seams to me unavoidable but there is more.

Wenn you are alone you are even more limited then even a small team where there can be specialisation and doing stuf at the same time. If alone you must get every aspect of game development. Jack of all trades.
Possible solution or give a efficentcy boost or a trade off.
* I would not aim for a full game but a demo. At some point you will get to the point that you must produce a lot of content to make a full game and something like a production efficent content pipeline gets important. So to avoid or push that further down the road aim for demo. Get more features in instead. So the first dozen of iterations will be some kind of prototyping to demo.
* You still need some content and being alone the procedural way give you a production boost also in the long run.
* Along the way you refactor a lot to make it extensible and filter a frame work to a game engine out of it.

Then choose the next feature with care as there can be strong dependicies.
Some where I read about production methods and some thing stood out, Iterations. And with it milestone and a playable state. Also something called agile method with scrum? Then I played once a game called America army started at 1.2.1 and now 3.x. So you get a idea where I am going to. You can scale that idea up. Each iteration could be a game release. Like the AA series. A deliverble game. In my case also scaled down to demo or even prototype. So if you got a cool Idea wich is often someting way over your head. Split it to a base feature set or prime features and filter the minimal game out of it.

The hello 1.0.0.0. My little game - - - - - - > 19.8.9 a full game 7 years away.

How it would work. Well you got your game vision you work that out to the big thing. Wenn that master plan is done. Not fully it will have changes. You work out the first release spec.
Example, want to make the next Elite xseries 3000AD thing.
1.0.0 would be something simple very basic
I bit demo or proto type would at least have this.
GFX & sound something very basic simple but fun to do as interaction.

So a space ship like a flat shaded cube against a flat shaded sphere. Just a black background. knowing that in the long run you would go for DX11 features wenn you are 3 to 4 years along DX11 wil be so mainstream So you might choose to dev it with C++ and DX11 basis. No fall back.
Somewhere in the middle you shift your focus to the Mplay feature. Most people think about MMO. wich I dislike.And a huge feature step. But even a full Team deatmatch something is a large feature not something implemented that easy. First thing would be to get the architecture refactord for Mplay supporting framework. A small feature would be a client observer. giving you just a bit extra info. something you can experience wenn you play the next deliverable. Under the hood there is some decent amout of change. but using the new client server achitecture with a light feature is more managble step forward.
But it could turn out differently. It might be that you got problem with extending on AI and one on one Mplay thing seams more feasable.
Of course this would be a small fictional example out of the whole adventure of making something bigger then small teams or loners normaly do.

Of course getting excited and into it for many years seams very unlikely to reach. But quiting after 2 years or 3 it might be that you have reach playable something that is bigger then you could do after version 9 if you would do it in one release. Might be that adding feature give you the feel of disrupt gameplay and rather would focus on content polish and balancing.

So thats bit of my wild Idea how to aproach it.

#16 jefferytitan   Crossbones+   -  Reputation: 2242

Like
0Likes
Like

Posted 05 March 2012 - 04:22 PM

I tend to dream too big too. I heard the sage advice (forgive the paraphrasing) "Add features until it's fun, then remove features as long as it's still fun". For example, you've got a great idea for a game, but does it *need* to be a 3D MMORPG, or would 2D single player do the job? Consider if each feature is integral to the fun, or if you just added it because it fit the theme. Then think about controls. Does your game *require* 20 separate actions? Can you knock it down to 6? to 4? Less? Less actions means less animations, less code, less potential bugs.

#17 Dir3kt   Members   -  Reputation: 166

Like
0Likes
Like

Posted 07 March 2012 - 03:03 AM

Hi Munckin9,

First of all I'm quite at the same level as you: trying to get one game done! So I totally understand how you feel about all that.

You described how you go about designing games which is nice. The methodology in itself seems right, I'm mean idea -> design -> implementation. However this looks like the classic waterfall approach. Do you do this only once for a given game design/idea?

I think it is much better to take an iterative approach where each loop is a sequence of "idea -> design ->implementation". Start with very short loops and as the project advance take longer and longer loops. This helps a lot keeping the motivation because each loop is an 'achievement' in itself and you have something (a prototype) to show.

Each loop should be used to validate/test a part of your design. This way you can quickly find out eventual flaws and correct them before going forward. If you find out that something is not fun, discard it, anyway you didn't lost that much time because it was just a loop. Sometime you might also be surprised because one part of your design is more funny that you originally though.

Hope it helps!

I'm not a native English speaker, hope I'm clear enough.

#18 Lane Spangler   Members   -  Reputation: 114

Like
0Likes
Like

Posted 10 March 2012 - 08:02 PM

Hey there,

Programming/game designing as a hobby is proving rather tricky. All too often things in my life get in the way of my time to program, this results in me often not finishing projects simply because I've lost my strand of thought, found some new interest and in general just can't seem to get motivated in the project again.

While I've been able to reduce this a bit by properly commenting my code so that I know how everything works and what I was doing it really isn't enough. At the same time I find that the bigger the project the harder it will be to make and the more my own limited capabilities will get in the way. This all results in my getting almost nothing truly finished. Though I know this is normal to a limit, I think I've reached that limit.

The obviouse solution, for me, seems to be to design and program really small games. Things that would take me one, or at most two, days to complete and would be fun and addictive but not truly mind blowing. Five minute games basically.

Problem is, try as I might, I can not seem to come up with any. I know the general idea of what a small game should be like, but whenever I try to sit down and design one the game either ends up being uninteresting or too 'big'. Very quickly I notice I'm adding extra 'small', fun features left and right. These 'small' features quickly accumulate though, the project gets too big, then somewhere along the line I realize that the original idea, while probably a good one, is in itself too big and I scrap the entire thing. Its like feature creep at the design process, on crack.

So I'm seeking some tips from you guys. How do you design a small, quick game and get about making it without it turning into a major project?

While I will not answer your ultimate question, I may be able to help you with your problem. If you are getting lost in your code you should think about implementing a more modular game engine. For example in my java game engine each game state is represented with a separate class, as well as each object that requires drawing such as a tile, block, wall, character etc. Sometime I find myself doing too much in one class and the code becomes very hard to read. I don't really think that making small games is a satisfactory solution because even games that most would consider small require an amount of persistance on the part of the programmer.

#19 OmarShehata   Members   -  Reputation: 205

Like
0Likes
Like

Posted 11 March 2012 - 08:29 AM

I think the trick is prototyping.

Think of a simple game mechanic first. Prototype that with a quick and dirty engine. See if that mechanic is fun. If it is, build onto it. If it's not, trash it and start over.

You could come across a really huge game, or even a simple but financially successful game with this method. It all depends on how much you build upon it.

That's why I find using something like Flash would be better for your case, since you can easily pump out these quick games (or even build on them if you wish) without really having to waste time doing all the grunt work of a language like C++.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS