Omnimaga
Calculator Community => TI Calculators => General Calculator Help => Topic started by: V1mes on August 07, 2012, 07:04:38 am
-
Not sure whether this has really been discussed before, but I was just interested to see how people get their projects finished, how they plan them out, what order they complete the various parts in (i.e. title screen, physics, sprites, etc.)
Thanks!
-
Well, I always come up with some basic idea, and then start programming without planning :D
First I program the engine and then all the stuff around it like menus and highscore.
And yes, I don't plan at all XD
-
And yes, I don't plan at all XD
Nice! :P
Well they say 'A game starts with a good idea'...
What about reusing the engines you come up with?
-
I usually get the basic idea for a game, then I get all the low level stuff finished. Input handling, audio, drawing to the screen. Usually I'll import an engine I already have done though. After that I work on bits and pieces starting with the maps and movement, then to more high level stuff.
Edit: To expound a bit, I always try to do one thing at a time and work linearly. I try not to do >9001 things at once. Also, whenever I see a bug, I work on it until I fix it.
-
Personally, it depends a lot of the language I'm using. But I come up with a general idea first and storyboard it if possible. If the idea still sounds good at that point, I figure out how it could be implemented and what the major technical issues would be. This step generally involves me bugging some people on IRC and bouncing the idea off them. Afterwards, I'll get to work making a prototype as quickly as possible to test game elements. It's often just a hacked together piece of junk with all sorts of bugs, but it's short and easy to work with. Eventually I decide how to entire game will play out and start on the actual game. I try to get critical gameplay elements built first (map loading, displaying sprites, collision detection, etc) first in order of importance. But debugging these can get tedious, so when I want to work on the project without being bored, I'll fill in the less important stuff like intros and such. When I'm done, I'll put the game aside for a few days. Then I start playing it constantly as the user would see it, taking note of how UI elements could be made easier to use and other aesthetic things, fixing any bugs I find along the way. At the end of this, it's out of major development, so I'll release it, sometimes with a dev beta to collect feedback.
-
I pick up a piece of A4 paper, and a I write everything I should do. Before that, though, I choose the tools and libraries I'll use to make the game. It's also good to make a quick prototype before. For example, if I plan to make a 2D game, I could make a very quick prototype in Python (faster to make) to see how it feels, and then rewrite it using the final language and tools (for example Vala with OpenGL).
I also make some drawings on the very same A4 piece of paper, like sprites and levels. I scratch out things I've finished too.
-
I pick up a piece of A4 paper, and a I write everything I should do. Before that, though, I choose the tools and libraries I'll use to make the game. It's also good to make a quick prototype before. For example, if I plan to make a 2D game, I could make a very quick prototype in Python (faster to make) to see how it feels, and then rewrite it using the final language and tools (for example Vala with OpenGL).
I also make some drawings on the very same A4 piece of paper, like sprites and levels. I scratch out things I've finished too.
then you must have a very big kind of A4 paper :o i mostly use like 10 pages for every project, not counting the sketches i make on random pieces of paper i find :o
-
Not sure whether this has really been discussed before, but I was just interested to see how people get their projects finished, how they plan them out, what order they complete the various parts in (i.e. title screen, physics, sprites, etc.)
Thanks!
It really depends on the genre of the games. for example, RPG can take a lot of planning process (>30 pages of papers)
-
I usually come up with an idea, then jump in before planning. I usually make the title screen first, although this was not the case in Runespel and Kraphyko.
-
/me would usually say that this /\/\ is the exact opposite of what one should do.
when working with a big project, planning things out beforehand will almost always save you having to rewrite everything once or twice. also, saving fun bits like titlescreens for last and getting main game engines out of the way first will help to keep you motivated. however, too much planning things out and not enough actually writing will demotivate as well, as it pushes back the yielding of visible results. it's a difficult thing to balance, which is why so many projects get dropped.
-
/me would usually say that this /\/\ is the exact opposite of what one should do.
when working with a big project, planning things out beforehand will almost always save you having to rewrite everything once or twice. also, saving fun bits like titlescreens for last and getting main game engines out of the way first will help to keep you motivated. however, too much planning things out and not enough actually writing will demotivate as well, as it pushes back the yielding of visible results. it's a difficult thing to balance, which is why so many projects get dropped.
I always do title screen and other fancy stuff in the end. However, one cannot forget to implement the structure that makes writing a titlescreen easier from the beginning. For example, a variable "current_state" that defines if the player is in "titlescreen", "game" or "gameoverscreen" to make it easy to draw different things on different modes.
-
It depends of the type of game, but I always found out that having the title screen and copyright year too early seems to be some sort of a curse or something, as every project where I did that never got completed, but otherwise, in the case of an RPG (role-playing game):
1) Planning stages, where the story is written.
2) Planning stages, where the game variables are planned, along with other mechanics
3) Writing menu engine (in-game), except saving/loading.
4) Battle engine+magic/attack animations, using test monsters
5) Walking engine (with test maps)
6) One test event, for example a boss fight or NPC, to make sure transition between walking and events is going well.
7) Village shops
8) Saving/loading, to make it easier to test the game as you progress into development
9) Make more maps and implement the game story with intro and everything
10) Once you are comfortable with the maps, add events
11) Makes more map, events, shops, etc, until the game is done
NOTES:
A) During the entire development phase of the game, including planning stages, progress is backed up on the computer or a different hard drive, or as soon as I got a lot of progress done in a short period of time. In my case, if it was a calc game, I did a backup on a second calc via the link port every few hours.
B) ALWAYS Work on the game code in solo! Otherwise the project will fail, even with Github and co. You can get help on forums, though, but for safety reasons (ie. making sure you can still read the code), get the game optimized only at the very end. For team projects such as RPGs, teamates should only work on planning, design (sprites, storyline, names, maps, etc)!
C) Watch your RAM to ensure you have enough left, to not hit a wall like I did many times in Illusiat series. Notice how most Illusiat games ends abruptly after the final boss: Not enough RAM was left for the ending.
D) Avoid rewriting your project constantly. Falling under that endless rewriting loop will cause the project demise. I saw many TI projects die in the past 11 years because of that. Only do so as last resort, and to prevent it at all cost, always plan before coding!
-
I find that I invariably rewrite a project at least once before it's anything useful, simply because I get the perfect ideas on what I should have done differently. I still plan beforehand, but that just reduces it to one or two rewrites rather than three or four.
Rewriting usually goes 3 to 4 times faster than the original, though.
-
Yeah the rewriting part is quite nasty. It seems people will rewrite for optimization purposes, but then they fall under an endless rewriting loop (see E:SoR for example), where they eventually lose interest and the project stalls.
-
Here's usually what I do:
-It helps a lot (for me at least) to play a lot of games beforehand and take the best ideas/concepts and twist them in a way that will work together for a game
-Usually the tilemapper comes next, as well as a test level to screw around in
-Then comes the basic layout of a player movement engine, just enough to jump, move, and do other basic stuff
-Then I usually code objects (if there are any), perfecting player's physics/movement, and add basic movements of AI (assuming there is any)
-Collisions (this can take a long while if you have complicated stuff)
-Any other jibber-jabber that you haven't coded yet that is vital to the playing of the game
-In game menus, level editor (provided you want to have one)
-Main Menu, other menus
-Levels (evidently this is probably the longest part)
-Putting it all together so all the stuff runs smoothly together
-Saving/Loading
...and that's about it. It may seem like a short list, but in all reality, for a good game at least, takes a good portion of time.
-
I should take some notes here... Because I WILL finish a project before the end of this year! :p
-
lol I see your signature... it seems you are a bit of a procrastinator :P
-
It is also a good idea to not keep your browser open if you want to progress a lot on your project one day, unless you need help. Else you might end up procastinating.
-
It is also a good idea to not keep your browser open if you want to progress a lot on your project one day, unless you need help. Else you might end up procastinating.
I probably need to do this :P I tend to want to work on a project, lose track of what needs be done/how to go about doing it, then find myself play testing MafiaBot with Sorunome or something XD
-
What I do is really think through the project first. Is this something you'll have the time to finish to completion? Is it something that's creative and fun? These are often things people forget before the come out with a half-assed project, and I certainly made this mistake many times in my calc programming career.
Then, try programming out a simple engine. What does your game really revolve around? Is it possible given the limited capabilities of the system you're running it on? Do you have the expertise or access to help that can bring that engine to completion? Sadly, I've had quite a few projects that I just didn't know how to program.
Once you've got that down, the hardest part is imminent. Designing your game. Levels, storyline, etc. What I've done in the past is take a laboratory notebook with graphed paper and fill page after page with tilemaps. It's often much easier to plan out on paper, but you can program a level editor if you don't feel like doing that manually.
And then the easy part - optimizing and packing! Do some fine-tuning; make that creation really shine. Lots of games fail because they just don't have that spark. I try to put something interesting in my projects, whether it's the graphics or just some special particle effects. Share it with your friends, so they can tell you what sucks and what's good. Once you know people are definitely going to like your project, post your creation on the interwebs, and hopefully something will come of it!
-
Woah we could write a guide with all these different methods :P
At the moment, I find myself writing out each new feature (e.g. level generator) as a separate program and nailing that before moving on to the next big part of the game/engine...
Also for all of my ideas I always have a visualization of the final gameplay; I also play through any new ideas in my head before committing them to paper, and then before I start I run through them all as a check.
I suppose the key here is to get as much experience completing projects as possible.
-
As everyone is different, each person will have unique things that work better for themselves. I'd personally say that at least some degree of planning (and research) is good. That way it will be easier to reach your final destination. It also helps if you have a fairly clear idea of what you want to make when you set out.
I'd also go on to say do not under estimate the value of letting others test it as you go. It gives you the chance for someone outside of the project to give you feed back. Not only can the help finding bugs, but they can also let you know what doesn't work out gameplay wise or if something just isn't fun.
-
Another tip for on-calc, petit-computer and other similar projects where you code either on the device that runs it or another portable device such as a laptop:
-Please always keep an eye on your laptop/calc/etc! Never ever keep your calc in your pencil case on your school desk or in your backpack while it's on your back! Otherwise, don't be surprised if one day, it's gone due to somebody stealing it. The only safe way to bring a calc with you other than constantly keeping an eye on your calc or where it's in is having pants with deep pockets and putting it there (which is what I did).
A few cases of project demises and calc programming retirements in the TI community are stolen calcs.