Personalization is nice but make sure you have a clear cut set of easy and accessible controls at the start.

There are some things that ultimately you won't be able to macro such as clicking, the way I like to think of it is simply:

Using your control scheme, does the user have to either A: move their left hand, or B: move their right hand, to accomplish any repeated task.

If the answer is yes, you're doing it wrong.

Also controls should make sense. I'm playing Payday 2 at the moment and I keep pressing T to throw the held bag, and it opens the chat window. For some reason G is throw and it keeps confusing me.

I am a simple man. :(
In response to A2J2TIWARI
Control goes way beyond what keys you use...

Here are some examples in a game that only has a single button

Press "space" to jump.

1. how much time is space being held down to be considered a tap? what happens for a tap?
2. the time that space is held down after this "tap" time is considered a hold, and what happens for this hold? how long? do more events change, morph, or occur as this time continues to increase? if so, what and by how much?
3. how much time between "taps" is considered to allow a "double tap" and what happens when a double tap is performed? do we look at holding time after the second tap of the double tap? if so, what happens then?
4. how fast do we respond to the tap, hold, double tap? how does it "feel" and does the user like the interaction between the visuals, audio, and the control timing?
5. how long do we wait to enable this key as a separate action (pressing space to begin or restart the level), does this appear smooth or confusing?

I really could keep going but you get the idea.

Another issue with control isn't about the physicality of performing actions, its about the effectiveness of your responses to how well (or how bad) the player is utilizing the controls. Meanwhile, you must be able to balance the experience for both cases or your game becomes too catered to a niche crowd.
In response to Ter13
Ter13 wrote:
Rushnut wrote:
I'm afraid I'm going to need an A.D.D. edition.

It's actually Edition 3.5.

*rimshot*

In response to FIREking
FIREking wrote:
Control goes way beyond what keys you use...

Here are some examples in a game that only has a single button

Press "space" to jump.

1. how much time is space being held down to be considered a tap? what happens for a tap?
2. the time that space is held down after this "tap" time is considered a hold, and what happens for this hold? how long? do more events change, morph, or occur as this time continues to increase? if so, what and by how much?
3. how much time between "taps" is considered to allow a "double tap" and what happens when a double tap is performed? do we look at holding time after the second tap of the double tap? if so, what happens then?
4. how fast do we respond to the tap, hold, double tap? how does it "feel" and does the user like the interaction between the visuals, audio, and the control timing?
5. how long do we wait to enable this key as a separate action (pressing space to begin or restart the level), does this appear smooth or confusing?

I really could keep going but you get the idea.

Another issue with control isn't about the physicality of performing actions, its about the effectiveness of your responses to how well (or how bad) the player is utilizing the controls. Meanwhile, you must be able to balance the experience for both cases or your game becomes too catered to a niche crowd.


Woah! Now I understand why controls are given importance... If they dont function according to the games theme they really feel boring. Also controls will decide the pace of thd game...

Reading your description I realize that creating games and that too a good one isnt a peice of cake.. you need to have everything clear in your head to create a game and to be honest most of the devs here are just like me eho have no clear idea of what they are doing which leads to failure..

Anyways I have to make another document about how controls will be in game. But before that, brainstorming!
Back with another question!

Can you guys please tell me the step-wise process for game designing and developing. For now I am considering this:

1. Gameplay - Battle Mechanics
2. Environment i.e. Map Objects
3. Gameplay - Quests and Sidequests.

If what I think is wrong, then please tell me the correct one. The question itself might seem silly but it isnt as it really gives a great idea about what to do and how to do it correctly.

Well, I suppose the best way to decide what aspect of your game to design first (or spend the most effort on) is to figure out what it is that your players will be doing the most often, or with the most emphasis.

In most games, that likely will be battle, so your battle mechanics are probably your key feature. It really depends on the game, though.

But one thing to keep in mind is that you don't want to really compartmentalize your work on the various game design aspects, because you ultimately want a game where everything works together. If you develop each aspect essentially by itself, then tying them all together could end up feeling like a tacked-on, last-minute kind of thing. (sort of like how a console game that was not made for motion controls getting ported to a console with motion control, they tend to slap on some stupid gimmicky controls that use the new control options, but you can always tell that the game was not originally designed with those in mind)
In response to SuperSaiyanGokuX
While I still agree with you, I want to make sure not to suggest that modular programming is bad. Programming each system as if it were a library and tying it into your game with very little effort is a great plus.
In response to Albro1
Albro1 wrote:
While I still agree with you, I want to make sure not to suggest that modular programming is bad. Programming each system as if it were a library and tying it into your game with very little effort is a great plus.

I'm not speaking in terms of the actual programming. Modular programming is great. I'm speaking in terms of actual design.

You don't want to have a battle system that was designed by itself, alongside of a quest system that was designed by itself, alongside of an economic system that was designed by itself.

You want them all to complement each other, and the best way to do that is to design them to work together from the ground up.

But once you get to the actual programming, sure, make them as modular as you possibly can.
AJ, for the most part, you can paint your house any color you want, so long as the theme itself is visually appealing.

The thing that makes said house nice or not, is whether it suits the needs of the occupants.

The biggest thing when designing a game is to make sure the gameplay is fun before even worrying about what decorations you are going to put on it.

Prototype your gameplay without graphics for the most part first. The reason for this is simple: Most game ideas people have just aren't fun.

Don't waste your time making graphics/sound/interface resources for something that isn't fun. Get your core mechanics down, THEN make it presentable.
In response to Ter13
Ter13 wrote:
AJ, for the most part, you can paint your house any color you want, so long as the theme itself is visually appealing.

The thing that makes said house nice or not, is whether it suits the needs of the occupants.

The biggest thing when designing a game is to make sure the gameplay is fun before even worrying about what decorations you are going to put on it.

Prototype your gameplay without graphics for the most part first. The reason for this is simple: Most game ideas people have just aren't fun.

Don't waste your time making graphics/sound/interface resources for something that isn't fun. Get your core mechanics down, THEN make it presentable.

What would you consider as 'Core Mechanics'. I assume GamePlay, right? But Gameplay consists of various things such as Quests, Combat Systems, Side Quests etc, right? I have divided the whole GamePlay into parts and we are completing each part one after other 'Programming Wise' based on priority.

Sounds good?

Now for everyone:

I've completed the combat system that I had thought of but I need few more ideas, which are fun instead of just basic 'hack n slash' which is too common nowadays. I read too many articles on Gamasutra but couldn't find anything which seemed new 'even for BYOND'.

So, if you have any good ideas please let me know.

EDIT:

Please let me know what shall be completed 'Graphics Wise' after completing combat system. I am thinking to complete Map Icons while completing some Quest NPCs on the other hand so that certain areas can be completed.

One more question: Would it be better idea to hire a Mapper instead of doing the mapping work myself? Although I am not too sure due to various reasons:

  • Most of the BYOND people are not good at mapping(I think so)
  • Trust Issues
  • Hard to difficult the Information exactly the way I have in Mind?

In response to A2J2TIWARI
Sure, hire a mapper, although I don't find the task particularly hard.. Just time consuming. I agree though, I've seen a lot of BAD maps made in my time.. it kind of baffles me, since it comes natural.
In response to A2J2TIWARI
A2J2TIWARI wrote:
One more question: Would it be better idea to hire a Mapper instead of doing the mapping work myself? Although I am not too sure due to various reasons:

  • Most of the BYOND people are not good at mapping(I think so)
  • Trust Issues
  • Hard to difficult the Information exactly the way I have in Mind?

If you're ambitious about it you could port the turfs and such over and create a separate project used for mapping. I believe that to be the best idea in this situation.
In response to Kozuma3
Kozuma3 wrote:
A2J2TIWARI wrote:
One more question: Would it be better idea to hire a Mapper instead of doing the mapping work myself? Although I am not too sure due to various reasons:

  • Most of the BYOND people are not good at mapping(I think so)
  • Trust Issues
  • Hard to difficult the Information exactly the way I have in Mind?

If you're ambitious about it you could port the turfs and such over and create a separate project used for mapping. I believe that to be the best idea in this situation.
Agreed. If you need to "hire" an outside mapper, only provide them with the bare minimum of your code that is necessary to create the items on the map. If your turfs (and mapped objs/mobs/etc.) have functions attached to them, strip those functions as well, and just give the mapper the basic definition structure (plus all necessary icons, of course)
In response to SuperSaiyanGokuX
SuperSaiyanGokuX wrote:
Agreed. If you need to "hire" an outside mapper, only provide them with the bare minimum of your code that is necessary to create the items on the map. If your turfs (and mapped objs/mobs/etc.) have functions attached to them, strip those functions as well, and just give the mapper the basic definition structure (plus all necessary icons, of course)

I don't actually agree with this. At least this isn't the way it should be. Properly designing and developing any map involves vigorous playtesting and numerous iterations of tweaking and adjusting. You can't playtest a map with having only the graphics and object definitions, without sending the map to a programmer and waiting for the programmer to send the dmb/rsc back. Additionally, there are many aspects of maps that need to be coordinated between the level designer and some programmers because the level designer doesn't have access to the source code, like sound emitters, particle effects, parallax foregrounds and backgrounds, NPCs, and so forth.

This solution is not ideal and not time-efficient because the level designer is constantly waiting on the programmer, and the programmer is kind of wasting his time by not programming.

It's just the silliness of the BYOND community that has created this situation, where no one can be trusted and loyalty to the project/team is nonexistant.
Sorry I missed your request for input, AJ.

I agree with splitting development up into sections. This allows you to split up development and parcel it off to other people, as well as ensure that your code is modular so you can recycle it into other projects later.

As for graphics, you don't need much graphically for gameplay testing. Colored squares works for me.

Your graphics should complement your gameplay, so you want to make sure how the gameplay "feels" before blocking out your final artwork.

As for mapping, mapping is an artform in and of itself, and has to fuse your graphics and gameplay into one fluid element. I wouldn't recommend contracting it out to just anyone. It's about more than just plopping stuff down on a grid. You really have to understand a lot about environmental design, as well as the psychology of your players and the flow of your gameplay in order to design great maps.

I'd just say run with it, and don't worry about it for now. Get gameplay good and ready, make sure your gameplay is fun FIRST. If the gameplay's not fun, re-vamp it. If it is fun, move on to tweaking and perfecting the inelegant parts while you graphic and map.

Don't spend time worrying about what you are doing right, or whether you are on the path to success. Don't worry at all. Just spend that time worrying instead on finding a mix that works.
Page: 1 2