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.
ddn3Member Since 14 Apr 2002
Offline Last Active Yesterday, 07:21 PM
- Group Members
- Active Posts 1,076
- Profile Views 3,299
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
ddn3 hasn't added any contacts yet.
Posted by ddn3 on 19 November 2012 - 02:52 PM
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.
Posted by ddn3 on 29 October 2012 - 04:29 PM
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.
Posted by ddn3 on 01 October 2012 - 07:55 PM
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..
Posted by ddn3 on 01 October 2012 - 03:44 PM
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.
Posted by ddn3 on 22 August 2012 - 08:13 PM
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..
Posted by ddn3 on 27 July 2012 - 06:14 PM
Posted by ddn3 on 06 April 2012 - 06:45 PM
Posted by ddn3 on 02 April 2012 - 01:11 AM
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!
Posted by ddn3 on 20 February 2012 - 03:00 PM
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.
Posted by ddn3 on 17 January 2012 - 12:40 PM
-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.
Posted by ddn3 on 22 November 2011 - 09:36 AM
Posted by ddn3 on 20 August 2011 - 04:27 PM
Let's discuss the top 3 issues on why game development fails according to Petrillo..
Unreal or ambitious scope
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..
Posted by ddn3 on 18 August 2011 - 08:24 PM
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.