ID:1346635
 Aug 6 2013, 10:41 pm
|
|
I was curious on what developers tackle first when designing a game. So, when you decide to make a game, where in the game do you begin working on? Do you start from the infamous grass tile and literally work from the ground up? Or would you rather begin with login() and work your way to logout()?
| |
I agree with everything Multiverse7 has said, in principle, but in practice, I've never worked that way.
I just typed up a message to someone just yesterday describing my game-making process, so I'll just copy-paste it here (note that I am skipping the necessary game designing part of the process; all of that occurs before I ever touch Dream Maker; I've got stacks and stacks of notes written on scrap paper, and a few notebooks lying around (I'm a bit of a hoarder with some things) with nothing but game design outlines, brainstorming, pseudo-code, map sketches, etc.; but I feel that doing that stuff should be a given, so I'm just starting from the moment I am ready to jump into DM) Anyway, here it goes: "I am very progress-oriented. I'm not happy unless I can see/use what I've just programmed. I write a little, compile, and immediately run the game to check out what I've just added. So, I tend to work in exactly the order in which I need everything to be done, and in the order in which the game will use it, from login up through the game's main focus, running and testing it step-by-step. So first is to define the basics of the player's /mob (no verbs or procs or custom vars just yet; just setting up the mob, its icon, icon_state, etc. I then define very-early stuff that occurs at run-time, like any custom Login() actions, any movement restrictions, etc. Sometimes I'll work on communications stuff at this point (a Say() verb, or simillar) I also need to define a basic turf and make a map. All of this is so I can compile, run, and walk around (even with nothing to do!) I just need to see it working at every step, just to know that I'm actually getting somewhere (I'm all about the end result; the process to me is just a chore between me and getting to a finished game, so truth be told, I don't much enjoy programming. I just do it because I have to to finish the game!) I also use HUD objects almost exclusively for my games (no verbs and verb panels), so very early on, I also set that all up (otherwise, I won't have access to my game's functions) So then from there, I just start adding the functions in the order of importance (as I judge them), and tack on any new vars that any new system will need as I go. I do all of my own graphics as well, so a lot of time is spent at each step (especially mapping) in drawing icons. whenever I add something in the code that requires an icon/icons, I stop programming, and draw the icons. I don't like using placeholder icons, so I usually draw my icons to their finished quality (though there's no guarantee that I won't go back later and edit them, but I try to draw them "perfect" the first time) This, of course, tends to slow development progress way down. And so on, and so on, until everything's in and working. I actually place admin verbs at an incredibly low level of importance. In fact, my games tend to not even have any admin stuff. I'll add in a basic ability to boot/ban people, but past that, I don't care for having any admin powers. Along the way, I might program in a special verb that I can use to test something, but these are only temporary." So, see? I break almost every rule that Multi just pointed out...lol But I can't do it any other way. | |
I'm in that same boat, sort of. I brainstorm all of these ideas and write them down whenever they occur. When it gets down to creating these ideas, I usually start with the idea that is the easiest to create. After I clean it up, I pick the next idea from my notes and repeat.
| |
When I first used to make games on this I'd start with some random idea I had, instantly start coding it and giving it place holder art. In the end the code turned out rubbish and the whole thing never felt worth completing. Don't start coding before you know exactly what you're doing is my advice on that. With that being said though, you can still make pieces of test code. Like if your game is going to have oxygen and vacuums you might want to test that and write a small simulation program. That's positive coding for design, prototyping.
What I then did after this is sit down with paper and pen writing out a general outline of the game. Most of it's specifications, some diagrams etc. Then I'd work on that for a week or two fleshing it out into a design document written in such a way that anyone should be able to read it and make my game, not just me. If by the end of this period I still felt inclined to do the project, I start and follow the guide I've written. The guide contains a set of goals so that each time I sit down to write code I can tick off a goal from the list. That's how I do it nowadays. Along the road I also make changes and add extra things but be careful with that, sometimes you get caught up adding functionality in really niche parts of the game while completely neglecting the main reason why anyone would want to play it. | |
Zecronious wrote:
With that being said though, you can still make pieces of test code. Like if your game is going to have oxygen and vacuums you might want to test that and write a small simulation program. That's positive coding for design, prototyping.I can't count how many personal demos I have on my computer from doing this. Which reminds me, I should back these up! | |
I'm pretty sure the other thread is not worth posting in anymore...
I start with mechanics, and generally the first part of that is movement. Moving around is often the most basic game mechanic, so that's what I code first. This generally involves using pre-written code anyway, so it only takes a minute, but that is almost always the first thing I do. Then I move on to other fundamental things. If I'm making a shooter, I work on projectiles next. Then I will work on basic AI if applicable. So, relatively quickly I can run around and shoot things and be shot at, before going into the details that would make it a unique game (like actual goals, where the enemies come from and how, etc). I would follow a similar route for any type of game - get general mechanics working solidly first, before moving on to specific features. I am definitely guilty of spending time on graphics or interface too early in development. For my current project I am just using placeholder graphics (literally an arrow for the player, big letter M's for monsters, and wall and floor tiles that I drew in ten seconds just to have something to look at). It is really nice to ignore that stuff and just focus on programming...especially since I barely have any spare time during the summer. | |
I agree with Sofa. Basic mechanics are the best things to code first. Everything else is built from them so get your foundations secure first!
| |
I'm one of those people who kinda do everything at once. Not that I'm proud of it. I'll literally start with the grass tile icon, then make a few other icons, then a map. While I'm doing that, I'll program all the variables I want the players to have, and the deathcheck proc, and then, after that, I'll make a few other icons while adding another gameplay mechanic.
| |
I learned to code when I started my current project, so I can only say how it's been for me so far.
I knew exactly what kind of game I wanted to make when I started this. Not all the systems were figured out, and a lot of the design appeared after starting work on it. I booted up with some tiled-icons and begin working on the bases for the characters. Then I started programming in the structure of the game... core systems that would shape it. Throughout development things have been cluttered from different points, but developing things on impulse has kept my dedication high and my optimism high. On a professional level I realize this wouldn't work, but the process is quite a bit different from being paid and creating a game you expect no return from. That being said, my style is just to develop on impulse, do what feels right when you open up your editor. | |
What I do is start from the center, and work outwards.
What I mean by this, is in the center you have the core, fundamental systems that are needed for other features of the game to work, but themselves do not rely on any other systems. Once I have what I consider the core features, I work outwards from there. The core systems are needed by most things, but need nothing. Then I add systems that need nothing but the core systems to function, then I add systems that rely on these to work and so on and so on until I eventually get to a point where I have systems that rely on a lot of other things to work, but nothing needs this system to exist to work. Two examples of this in a RPG would be stats, and the UI. A lot of systems need stats to function, you cannot have items/equipment, combat, skills/abilities and so on without stats. Stats however do not need any other systems to work, it's basically just math and is not reliant on anything. So stats are one of the first things I work on. The UI is the total opposite. The UI needs all of these systems to function because it's job is simply to display the information these systems provide. But no system requires the UI to function. Due to this the UI is one of the last things I work on. | |
All you do is make a text file with all the basic systems thought out. Like mechanics, stats, items etc. Then mathematically explain the game.
afterwards you can start programming or do/wait for art. Doesn't really matter it just depends on how experienced you are at programming on your choice. Personally I would do art first if im doing an rpg because for games like that i already have barebone systems ready to go. And the rest is just easy. | |
Try to get a working, playable game as fast as possible. It doesn't have to look good, play good, or ever be fun, but just having a little guy you can walk around is amazing for morale. Then you iterate. Plan out a feature or system, add it, fix its bugs, then release. Repeat until you've got a game. Only on the end should you work on gloss and polish and other niceties.
| |
This is smart advice. A lot of the time, people making a game aren't even making a game, they're just making a bunch of systems. And when you ask them where the game is, they'll reply with something like "w-well I got my henge justu system added!" and then you're like, so where is the game and they'll tell you "i got graphics for my sage system added!" but where is the damned game to play? "i'm adding another map for the hidden smokey leaf village!"
Make a game. You can fix things like graphics, maps and add new content when the actual core of the game is finished. | |
I've been programming in DM for around 6 years now, and I just recently figured out a system that works for me. My biggest problem in the past has always been that I get to a wall in my programming where I either get so frustrated or so tired of working on the same thing that I just abandon a project altogether... Recently, though, I've just been working on whatever the hell I want. I have a huge game in my mind, so why limit myself to working on one feature?
Every time I open my project, I take a second to just think about what I'd have the most fun accomplishing today, and then I do it. Sometimes it's what I was working on last time, sometimes it's something completely new. This keeps everything from feeling stale and repetitive for me. Since I've started doing this, my dedication has increased dramatically, and I've been getting a lot more done in a shorter amount of time. | |
Well ive been coding for 3 years now in Byond DM & well i used to start all of my Games off with Npcs & Clothing of course that was my noob instinct & id jst get lost within my lines of code & it jst looked like absolute crap .. Now I would advise new comers to Start With Planning what is your game about what is it generated around What do i have to do first im not going to lie i used to do things to early of the first version of NOA , but 6 weeks i got an few tips on starting an game off better but yeah as i was saying start from somewhere such as Combat Proc and the needed Variables .. you can code an Login() when you need to test an little demo of your project .. I hope this gives you guys an heads up :)
| |
SuperSaiyanGokuX wrote:
"I am very progress-oriented. I'm not happy unless I can see/use what I've just programmed. I write a little, compile, and immediately run the game to check out what I've just added. I work in very much the same way. Although I tend to work on certain ideas or core features at a time rather from start to finish. In my current game I'm working on I actually started out with the general look I wanted it to have, so I could easily visualize how my game would look and also to see if I could actually get byond to do what I wanted it to do. I actually have a picture I'll link so you can see what I mean. Pictuuuure | |
I know people would criticize your artwork, but for some reason I love the aesthetic you have there. Is that the actual graphics, or just a sketch?
| |
Magicsofa wrote:
I know people would criticize your artwork, but for some reason I love the aesthetic you have there. Is that the actual graphics, or just a sketch? I'll assume you were commenting on my picture. It's the actual graphics, just not quite at their final version. Since none of it really has any shading of sorts. | |
Absolutely not! You should never start by making the art when designing a game. While it may be more fun, unless that art has code to make it function, it's not going to mean anything.
Not that either! You should never ever begin by writing Login() code, unless it happens to be vital to the functionality of your game, or if you just want to test something out. You don't want to go about designing your game chronologically. You shouldn't be designing any kind of startup interfaces, such as title or character selection screens, until the end, when your game is actually functioning. Those things just add polish to your game, when you are ready to actually release the first version.
So, what you need to be doing first is deciding what kind of gameplay your game will have. You should take notes on what the core features will be, then expand that by listing all of the systems that will be necessary to enable these features to function. Next, you can actually write down some pseudo-code that describes in detail the processes that will make up these systems. You should then attempt to make a real working prototype in Dream Maker, using all of your notes to guide you through the process. You should remember to always test each time you write a new proc or modify an old one, to ensure that it works as intended. Then you can debug things along the way, until you have some actual gameplay to work with. You can't call something a game if it doesn't have any gameplay, which is why you should always be starting with that. Once your prototype is complete, works as intended, and is free of any bugs, you can then begin the next step, of turning it into the beginning of a full game. To do this, you will probably need to be doing some refactoring, or even rewriting altogether, to make things more modular, readable, and efficient. You should try to ensure that your foundation will be compatible with any new code that you will add later. Comments are also going to be especially important in these core systems, so that you don't get lost in your own code at some point in the future.
So to put it simply, when you begin making a game, you begin with the gameplay itself, and specifically, the most important or critical part of that gameplay. When you are working on the game, just pretend that you have already gone through the initializations, such as character creation. Those can always be added later. You should always work towards having something that you can actually play, as soon as possible. If art is absolutely needed to make this happen, then keep it very minimal. Making art assets is a time consuming process, and you can always add the real art later. Also, you may realize as you are programming, that your original plan for the art wasn't really going to work out, so this is another reason not to start with art. You wouldn't want to have to recreate all of your assets after you realize that they won't work for your game!
What you actually start with, depends on what type of gameplay your game will actually have. For example, if you are working on an RPG or action game, you might want to start with combat and controls, and when that's complete, work on the NPCs and quest givers, then everything else required for the game to function as intended. If you are working on a strategy game, just ask yourself what the strategy actually is, and start working on it! In the case of platformers or racing games, you probably want to start with the physics, so that you can actually jump around or crash into things.
Basically, the sooner you have a working game to play, the better job you are doing at designing it. You would obviously not be doing very well if you didn't even have something to call a game! I hope this helps to clear things up.