39

This happens in almost every game -- as the artists become comfortable working with the tools, and as improved tools become available during production, the later levels to be constructed are almost always built to a higher level of quality in a shorter amount of time. To cope, you want to do all of the following three things: Assume that you'll have to ...


18

That is an interesting question. Mainly because answering it raises the shades-of-grey versus black-vs-white dilemma. is there anything wrong with building a game before I design it? If you think of that question as a yes or no type, the answer can only be: yes, there is. If the answer can be more nuanced, then it changes. Reason: you should never build ...


10

While of course there are no hard rules when it comes to pre-production, there are a variety of heuristics to help. Some feature creep is natural and necessary - no plan survives first contact with reality, and you may not know what would be "cool" until you see it. First, stage your development. Draw up your outline into a feature map, and then look for ...


8

Even with a manual process of model generation, there are some tricks you can use to maximize your output. We can follow the same basic rules for real life conservation. The three R's: Reuse - Take the same model and apply a different texture to it. This can save you the time it takes to generate a model. And will give a convincing "that's a different ...


7

The answer is in the MSDN entry for GameTime http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.gametime.totalgametime.aspx Fixed-step clocks update by a fixed time span upon every clock step. This results in uniform clock steps that may not actually track the wall clock time. Fixed step clocks were popular on console systems where one ...


5

WARNING: this answer can be depressing. It can be depressing in two fronts: A) Our tools and data on software (size and time) estimation are not that good, and B) It probably will take longer than you think. Positive aspect: expending extra time studying and familiarizing with development tools is probably always a good idea. Up to what extend it is unclear....


4

When doing complex projects like games, you often can't make all the features you want, because you're running out of time/money or because they didn't turn out to be as good as you expected. This is known as feature creep. But there's a flip side to this; you will also find features that you didn't think you needed, but as the project takes shape their need ...


3

Expanding on Stormwind's lead, I'd be curious whether your application needs a windowed average with equal weights per unit of time, or if an exponential moving average may suffice. The latter is very simple to implement, and can be adapted to a variable framerate like so: float weight = 1 - pow(1 - responsiveness, dT * referenceFPS); smoothedValue += (...


3

Plan to use a fraction of your available pre-production time for base feature set. Base featureset should be low-risk, high-reward features, so you don't have creep on those Base featureset is minimal and non-negotiable - they must be present - otherwise no solid basis to work from and you will be riddled with self-doubt / "should I replace this" syndrome ...


2

Depends on development methodology the fast answer is "When you have enough information to begin writing code". My thinking on what "enough" should be is something like ... I wont be rewriting large portions later. What i'm writing is a small enough chunk that i can handle it as a "task". I see so many people taking on tasks like "build the terrain" ... ...


2

Doing a prototype could be a good idea in your case. Do it as small as possible, like a single room with one NPC, a little bit a dialogue and/or combat. This will let you: Try out the underlying technology and learn Spot some issues you may not have thought of Get an idea of the amount of work involved After this you can scope your full game based on what ...


2

Two options: 1. Arithmetic average (worse) Have a 2-column table that has sufficiently many rows to be able to store all values for your chosen time (0.1 s in your question) at the potentially highest possible, supported frame rate - say 300 fps (unless you limit it to for example 60). 300 fps would mean 30 rows, in order to store all values for the last 0....


2

I would say yes, go for it. But plan some common features / classes ahead of time to have some cohesion between each new component. Unity is known for its component approach to game development, and would allow this form of development easily. If you aren't using Unity, you could replicate a semi-component approach. I'm unfamiliar with other game ...


1

Yes, you can create a character from multiple animated parts and layer them over each other at runtime. This is a very common technique. Changing the color tint at runtime is usually not that difficulty either with most graphic frameworks. If you have any issues with this, feel free to post a new question where you tell us what technology stack you are using,...


1

Your server can keep time. The first thing you will need is to have the server start a turn. You would then notify the client that his turn has started and how much time they have to complete their move (this can be used to present a countdown in UI). Afterwards, one of the following will happen: The time is over, the server must be able to advance to the ...


1

Brief: most of the time you cannot have a single design step followed of a single coding step. You will have to alternate them. As a general rule, try to respect what is already designed (not what is already coded). About not having an initial design (just a sketch or a mental image): if you do not have a design you do not have a design. You must do ...


Only top voted, non community-wiki answers of a minimum length are eligible