Jump to content
  • Advertisement

Kitt3n

Member
  • Content count

    620
  • Joined

  • Last visited

Community Reputation

468 Neutral

About Kitt3n

  • Rank
    Advanced Member

Personal Information

  1. Kitt3n

    Continuous Integration. The good, the bad and the ugly.

    Completely agree that you need some way of automated builds (idependent wether CI or nightly). It does force you to not hardcode paths, if makes sure the QA has a 'fresh build' on a regular basis and you don't get developers trying to manually put together a build copying files from whatever network locations (it does go wrong at one point). I would even go one step further and say that the build should result in not only an executable - but in an installer for a complete product (including all assets, sounds, scripts, .... ). >Build machines can be virtual machines, or separate physical boxes somewhere. It only really matters if your build takes an age to complete. If a full build takes "ages" to complete - then you have a serious problem anyway which needs to be addressed. It means in effect that your development team is waiting out a (big) part of the day doing "nothing". Be pro-active and look for options like incredibuild or optimize your #include-strategy ( [url="http://kitt3n.homeftp.net/wiki/dev/index.php/Buildtimes"]http://kitt3n.homeft....php/Buildtimes[/url] ). >The major gripe I have here is that the code itself has to be both testable Write tests for where it makes sense, math-code or in general code which is 'easily' tested - usually lower-level code. Keep it simple - it's no use to test a "big" system automatically this way because imo that does take too much time - that's the job of your QA department. >If a chunk of code [i]really[/i] takes a full week to write you've got some serious problems with your design. Agreed, however I've been in situations where you want the trunk to remain stable but need to do a compatibility breaking change. In this case you can decide to make a feature-branch. This gives you the possibility to do non-atomic commits (without disturbing anyone) and merge it back the moment you are done. >But you suggest that you would need to submit incomplete modules. I disagree. You certainly should check in atomic changes, not incomplete modules. imo make a seperate commit for every 'feature' (no matter how small). Then at least you have a chunk of code which is related when you track back in history. Which is way better then having 10 features pushed into one big commit.
  2. I suggest the Panasonic Vierra series (got a 42" plasma myself, 100% satisfied), they are affordable for qood quality. Even though I'm dutch, my opinion is that (in general) philips sucks (don't have any personal experience with that TV, though). Also good (or so I've heard) are the pioneer's - but they are expensive... /R
  3. Kitt3n

    Annoying Things in Gaming

    >Sacred, one of my favorite hack-and-slash-games, become an entirely >different game solely because of its post-release patches Nice to hear that people actually remember the game - it's pretty long since it was released.. And just in case you didn't hear it yet, we are working hard on sacred 2 right now (tight deadline, as usual :)
  4. Kitt3n

    First Map of MiniMORPG

    Quote:Original post by Emmanuel Deloget Quote:Original post by jwalsh Quote:Original post by HopeDagger Just one hunk of landmass? It would probably be a lot more interesting and varied if there were rivers/islands/mountains/etc. This is just to show size & scale. =) Topographic map is yet to come. It varies from about 800 ft to about 5,000 ft above sea level. There's red, brown, and tan terrain, along with frozen caps at the peak of the highest mountain. This of course must melt off and leads to a river. Don't worry, I gotcha covered. =) Usual constructive criticism: Do you plan to put something at these 5000 ft? because if it's not the case, what would be the interest (from a gameplay point of view)? Of course, putting something (temple? castle? forgotten tower? sacred grave?)here means that you have to provide a way for people to actually visit the mountain. But that would be pretty cool :) Maybe it has no point from a gameplay point of view, but if you really use the full heightrange, your world looks just so much more cool, then if you would keep everything 'flat' around one "base" height (...yes, I'm talking from experience here :)
  5. Kitt3n

    Elevation Map for MiniMORPG

    I was browsing a bit through your posts, so no Idea if this was mentioned before, but since you are a one-man-"team", I would suggest to go the "generate as much as possible" approach (from world, to quests to dialogs between npc's). Take your heightmap, create some polygonal representation of it - either simple (which would suffice for your goal) or complex (with alpha maps and blending between "tiles" and all the other gimmicks) Take another 'overlay picture" to show where you want vegetation on your map, maybe one for enemies or weather, quests and so on. You could have another "overlay" map to show where your algorithm should place towns (maybe depending on a pixelcolor or sth, how big a town should be). Then in a final process, put all of these 'layers' into a world-generator. Concerning quests - I you give it some thought, you wil come to the conclusion there is only a pretty basic set of possible questtypes (with lots of tweakable parameters, obviously)... It should be possible to largely generate pretty good quests just by providing a few basic input parameters (and if you go really fancy, interactions between quests).
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!