ddn3

It's focus, you have the skills to execute but your not focusing on the details to see the ramifications. Create and foster an attentive pause in your programming routine where you ask and answer questions about what and how your doing something. Like how will it affect other submodules? Is there a better object model than this? Is this the fatest / easiest way to my goal? etc.. just asking questions will force you to go out of autopilot mode ur in and that will expand the depth of your understanding and hopefully catch these design issues early on. 

I use to think that scripting wasn't worth the effort for "small" project but it turns out those are probably the best project for scripting. Why?

Scripting is a work multiplier, create a domain specific language for your game making every line you write do more work than trying to do it in something like C++ / C# / Java etc.. Small projects are usually limited by manpower, the more work you can get done in fewer lines of code, over the long run results in massive increase productivity..

2nd for small projects, it's less risky to try new things. Learning what to do and what not to do when integrating and building scripting framework is the same for a small project as a big one. The only difference is the mistakes u make on a "big" project will cost u much more $$$$ and manpower to fix. Better to learn on a small project..

3rdly the more languages you learn the more out of the box thinking you will do from your dominate language giving u better insight and more rounded approach to programming in general.

Any of those engines could work but Unity 3D is the best choice. However even that said what you want will require some level of expertise, maybe more than a single person would have, so my guess is multiple developers and depending on the scope of the project maybe several months to a year..

Unity 3D has a web player which u can use to publish your Unity 3D content. Of course you will have to setup the web sever and hosting backend yourself none of those game engines do that for you.

Good Luck!

Otherwise known as comprehensive unit tests and functional tests, both of which you should have already. I hate to harp on it, but code without tests is broken code.

I think TDD has it's place, but for smaller development houses where it's just 2-3 programmers you have to make do with what time you have. Sure for larger teams where it's critical that components function to specification and teams are separated by timezones u don't want to mess around with email tag trying to get core critical systems working. For individual developers its up 2 u if you want to do TDD and to what extent. I find for individual developers code maintenance becomes a much larger problem, try looking at code you wrote 3 years ago for example..

-ddn

The core of data driven system is that objects are initialized by a data descriptor object be they data from XML, scripting, internally, etc.. This initialization chain follows all the way down to all the child objects. Objects themselves are not usually created on demand but rather by a factory due to the complexity of creation in data driven designs.

A data descriptor is just a unified data accessor class which makes it simple for data access and accounting. Imagine if u will an object definition is a tree and iteratiring down the tree to create all the components and child components, you'll need to keep track of that iteration as well as have data accessors to make sure data conforms to both read / write access.

Data driven design can be as simple or complex as you like but the drawbacks with such a system is that u have to have runtime checks for validity and data and class integrity which can increase the burden of testing and maintenance. So people usually write tools to manage this for them, when the data set becomes too large. Another common design pattern for data driven system is to use object composition vs inheritance to create complex objects but that's really just user preference and both can co-exist.

Good Luck!

-ddn

It's a question of scale, sure Python is fast enough for a subset of Dwarf Fortress.. To simulate DF in its entirety in Python? Maybe depends on alot of things, how well DF is written, the bottlenecks of DF and how well you know Python and if you can leverage optimized versions like CPython or IronPyhon. One thing is for sure, a high level languages like Python makes writing complex simulations like DF easier..

DF looks like alot of cellular automatas and control logic running in a micro threaded message passing scheme is my guess. Something like that shouldn't be too hard to code up in Python, give it a try. I love those old school sim games aka Rollercoaster Tychoon etc.. which is very similar to DF in ways..

I think it was due to speed. One of the original complaints about Civ 4 was it was too slow. Both Python and Lua are equivalent high level languages so flexibility wasn't the issue, imo. Lua in general runs about 4-5x faster than Python..

You can but it would require you to run the full rendering on the server side like Onlive does. Tweak the shaders to your hearts delight on the client side, nothing is rendered there.. However that doesn't mean u can't hack, just means those hacks are not possible.. Maybe u can do round robin, where your rendering is rendered by your neighbor etc.. so the client would have no incentive to hack their side? That's kinda crazy though..

-ddn

The C4 engine is fine, the diagram is overly confusing with the excessive use of arrows but I'm hard press to come up with anything better. Mostly your engine design will be predicated by your game design, a few things all graphical applications need in some form or another (not just games) and that will be common to all designs.. Like data persistence, loading, logic, rendering of some form, input, etc..

Usually there are 3 levels of structural breakdown in code, low level, middle and high level. These levels don't say anything about the code (these could be libraries million of lines long) it said more about the dependencies upon that code. Low level stuff have a wide dependency and narrowly defined purpose. Ie timing libraries, data persistence function, network functions, etc.. Low level stuff is used to build the next level, the middle layer. This middle layer encompasses application specific domain functionality ie. scripting engine, animation engine, rendering engine, physics engine.. Then there is the high level, controller logic and UI. This layer usually handles the dynamic or data driven aspects of the application and interfaces to external elements such as various networks (ie Xbox live, Internet, custom servers, etc..) or the user etc.. I've found this breakdown to be helpful in designing my applications, your mileage may vary good luck!

-ddn

The steps I think should be a high level scripting language (Python, Lua, ActionScript) then -> Java or C # -> (Maybe if you need the performance) C++. If your artistically inclined you would be a visual thinker and visual thinkers need to see feedback, that's how they best learn. I'm also visually inclined. There are many development tools available, Visual Studio, XCode, etc.. I think these might come be useful to you.

http://processing.org/
http://wonderfl.net/
http://jsdo.it/
http://www.microsoft.com/express
http://pygame.org/news.html

Nothing wrong with jumping right into Java / C# but I think you'll get more milage out of experimenting in a high level language and exploring programming there first. Most of these programing languages are in the same class, so experience in one will carry over to another. As you go down to a lower level programing language, you just have more restrictions and requirements and different syntax, but the nature of programming doesn't change.

-ddn

I'm seeing a couple of powerful trends in gaming which have the potential to dominate the industry. I think this is one of them.

-Unified game world with multiple game "views" (Dust 514)
-Free to play everything with tiered service model (Battlefield Heros, Free Realms, etc..)
-Procedural worlds with strong physical modeling (Drawf Fortress, Minecraft, etc..)
-Open instanced multiplayer worlds, join anytime (Minecraft, Guild Wars, etc..)
-Cloud based gaming (Onlive, Gaikai, etc..)
-Casual gaming (web, mobile, social games etc..)

Of course they all have existing precedent but as time goes on, I think these models will start to dominate the gaming scene.

-ddn

Yep they are comprable, though I like how yours gets around the base class dispatch problem, it copies the base class functions to the childs metatable, in mine it walks the inheritance tree to dispatch a base class function. I might just give that method a try.

Laters!


-ddn

Gamma Correction?


http://en.wikipedia.org/wiki/Gamma_correction

-ddn

Many good points made in this discussion, I think if the goal is to improve the current process you must have a solid grasp of the current process. I've noticed that each company has their own "way" of doing things. Some are very much are hierarchical and ideas only flow from the top down, no exceptions. Others are more egalitarianism, ideas can come from the lowest person on the ladder ( a temporary tester for instance ) and are seriously considered and evaluated without prejudice. The thing is both systems work, if you have a core of highly competent and creative individuals they really don't need external "assistance", or if you have an open environment where all share in the creation of a product this too can work.

Let's discuss the top 3 issues on why game development fails according to Petrillo..

Unreal or ambitious scope
Feature creep
Cutting features

Consider that the top 3 problems are related to "features and scope" why is that? Because the games industry is highly competitive, it forces competitors to add features to keep pace with their peers. Games which just throw out features (key features) or never adapt to the changing market, are at a competitive disadvantage.. No Coop? no Multiplayer? no DLC? no sale.. Of course each game is different so not all this applies.. I personally don't think Angry Bird needs Coop etc..

Mature and successful teams know there really isn't anything like "Unreal or ambitions scope", they have enough competence to achieve even their wildest ambitions, see Steam, see RDR2, see WOW, etc.. The issue is of course time and money. Experienced leads and project managers can estimate a features cost within a reasonable time scale.. This is the first point of failure, incorrect assessment of time and effort.

Feature Creep? This isn't really a point of failure from my experience. This comes back to the fact that games are a collection of interacting systems.. after an initial play through of a rough slice of the game, if it's no fun that's a bad sign. Ultimately it is a game and for it to sell, it has to be fun. Weight that against the schedule would you rather spend the remaining time finishing a product which is no fun or invest every effort to make it fun? Every year 100's of un-fun games are released, they don't make back their return and are forgotten. Sure the project completed but that's really no achievement if the company goes out of business afterwards or the team is laid off.. Companies which can afford to (ie Rockstar, Blizzard, Sony, Valve etc..), invest the time to make it fun and are not slave to the schedule. Those who can't press on and hope for the best. What can be done about this? I think the reason why things don't turn out to be "fun" is because lack of shared vision and creative leadership. People usually have an idea of what is "fun".. but for something to be "fun" alot of factors have to align, and without a shared vision of why or what is fun in a game, people can very often put in less than satisfactory effort in the needed aspects to make it fun..

Cutting features, i think this is needed actually. Back to the previous point games are a collection of systems, like the reverse analog of "feature creep", sometimes what it takes to make a game fun is to remove a feature. That's just the reality, after play through, after some insight, maybe you don't need a super smart horse AI? Maybe.. Even that being said, cutting the wrong feature for the wrong reasons can equally kill a game and I've seen that happen too. So how do u know what to cut? Again goes back to above you need to have a shared vision and creative leadership on what makes the game fun.

Again this comes back to the people, the team.. Good teams, more often than not they will make the right decision on what to add, what to cut, and what extent to take a feature or scope of a game within the time frame they have..

Hope this gives you some insights into the process.. Again i'll reiterate, each team is different and for some these top 3 are not their biggest stumbling blocks at all.. etc..

Good Luck!

-ddn

The biggest problem with trying to measure a discrete aspect of a game and giving it a numerical ranking is that games are rarely just the sum of their parts. Games are cohesive systems all interacting. When evaluating the relative worth of a a single piece it must be play tested through the whole, but there in lies the problem.. The "whole" is itself incomplete and so the evaluation is at best a cursory value.

So how do people get around this? Simple they copy. The copy features from other games which are complete and thus can appreciate the nuances of the feature both individually and collectively.. Yes the games industry is a hot bed of "imitation" but so are most human endeavors i would argue. The bigger the game the less "innovation" you will see, since the risk of "messing up the formula" is very high and they are very risk adverse. We'll then the question begs, how does any game introduce a new feature?

I think the way it works now is it takes a "champion" of an idea, be that a designer, programmer or producer (they are the usual ones i see championing ideas). Maybe they came up with the idea from another industry or some stroke of insight or random chance but for whatever reason they really like it. People will always resist new ideas, that's just human nature. Without a "champion" to push the idea, constantly grind it into the ear of the organization, it would never survive.

Once they've convince the management (producer and leads) on the idea ( we're not talking about small trivialities here like the color of a font, but large ideas like should we have co-op multiplayer etc.. ) It's scheduled, the tasks are broken down by the leads and producers. There really isn't much discussion after the fact once everyone is aboard.

So that's pretty much been the pattern I've seen. Hope that help ya out.

-ddn