Jump to content
  • Advertisement

Dovyman

Member
  • Content count

    453
  • Joined

  • Last visited

Community Reputation

277 Neutral

About Dovyman

  • Rank
    Member
  1. Dovyman

    On interesting web 2.0 research

    We have a fairly strong research team at Endeca, and as part of that we occasionally have speakers on various topics. Last week we had a PhD student from MIT (David Huynh) give a talk on reusing data on the web - it was really very interesting. I would encourage anybody interested in web 2.0 to take a look at some of the stuff the SIMILE team at MIT has been working on: Exhibit - makes it very easy for non-programmers to take data in a variety of formats and publish it to the web in useful ways Potluck - Doesn't seem to be available for use yet, but as this screencast shows how you can take any number of Exhibit applications from anywhere on the web and create a mashup on the fly Sifter - Plugin for Firefox that can add modify websites in place to add faceted browsing.
  2. Dovyman

    Ahh VMWare

    I'm working on a fairly interesting problem at work right now, so I thought I would share. Your input is, as always, quite welcome! See previous post for more overview of exactly what I'm doing, but basically we're developing a distributed test system to cut down on test turnaround. Given that we're farming this work out to developers machines when they are not around, we are using virtual machines to ensure both a) consistency of environment and b) ability to test arbitrary platforms. The issue here is that a VM isn't a small thing, the final ones that will be in use will take up space in the 10's of gigabytes, so the cost is high to transfer these around and also to store them (we currently test on something like 9-10 platforms). The criteria for where to put them are in my mind the following: a) redundancy, if one of the locations the VM is available is offline, it should be available elsewhere. b) transfer capacity, if we need to distribute multiple VM's at the same time, we shouldn't incur too much of a performance hit to do so. My initial solution to this was to have the client machines themselves store the VM's for distribution. After all, they need to have VM's anyways to actually run the tests, so they ought to be able to redistribute those same VMs. This meets the criteria, several systems will be running tests on each platform, and if we need 3 copies of the same VM, we can grab each copy from a different machine. The problem becomes the "churn" of the platform configuration. Since these are developers machines, its possible something might happen and various machines go offline at different times - how does the system reconfigure itself to handle the loss of these machines? As an example, lets suppose by chance all the machines that go offline were running platform X. Our capacity for running tests on X is now severely reduced, do we copy VM's for X to other machines that were previously running some other platform? The cost for doing this is quite high, especially if there is any kind of ripple effect. And then when the previously disabled machines come back online, how does the system revert to the old configuration? At the moment I'm letting this brew in the back of my head - I don't know exactly what the best solution is. Basically I think a good solution will end up revolving around an idea of minimum and optimal capacity - if some machines go offline we can accept running at lower capacity temporarily, but if too many are lost then it is worth the cost to transfer some VM's around. Anyhow, typing that out gave me a better handle on the issue I think.
  3. Dovyman

    On being an intern

    I haven't posted in a while, and I can pretty much say that Libertas is staying inactive for the moment - I haven't the time or the inclination (though I have picked up some other non-game projects) I started my internship at Endeca Technologies about two weeks ago, and I think I've settled in enough that I can make decent comments on my experiences so far. First of all, although you may not have heard of Endeca specifically, if you ever shopped online at Walmart, Newegg, Overstock.com, Barnes & Noble, Home Depot, and others I won't list here, you've used an Endeca powered website. Basically Endeca provides search technology that customers, like those above, can build their websites on top of. Specifically, what we call "guided navigation" is one of the key features of the Endeca software. Personally I think you can see this the best at Newegg, but essentially as you move through the page you are building up a query, and along with the actual query results, the Endeca software gives "refinements" that suggest the most promising ways to narrow your search. I could go on, and on, but suffice it to say both external facing and corporate internal sites have done some really exciting stuff with our software, and theres a lot more (secret) stuff in the works. Anyhow, my specific project actually has little to do with the search side of the business. The team I'm on is developing a grid computing system to live on a group of new high-end computers we're getting in the office. The system can run any group of commands in parallel, but the first specific need for this system is to speed up our building and testing. We support somewhere in the neighborhood of a dozen platforms, the code for which needs to be built and tested very frequently. My end of the project is to write the client application that will live on the grid machines. It's a fairly interesting project, the client is responsible for determining the state of the computer, updating anything if neccesary, and when the computer falls below a certain usage level, spawning a VM and picking up a task or tasks from the grid. To make things a little more exciting for myself, I've chose to go about this using a combination of Ruby and C/C++ when necessary. So far it's been an enlightening experience, and I'm excited for what the rest of the summer has in store. At work I switched to using solely Ubuntu on my machine, since the client I'm writing will live in a linux environment. So far I've found it very productive, and I've actually switched at home as well (though I keep a XP partition so I can play games). I've found it an interesting experience, expect another post in the near future that fully fleshes out my joys and difficulties in switching to Ubuntu from XP - for anyone interested in trying the same or with good advice for some of the issues I've confronted.
  4. Dovyman

    Generative art

    Wow those are pretty cool! I would love to have the second (zoomed out version) one as my wallpaper if you could 1600x1200-ize it for me :)
  5. Dovyman

    Pirates!

    OK so I succeeded in making something of a demo level. It's not that full featured because you have no way to know where anything is, nor do you get any kind of introduction to the level. I did however start implementing some simple AI that I've dubbed "static shooters". Basically they are guns that don't move around and will rotate to follow the player, shooting when the player gets within a specified distance. It turned out to be more difficult than I thought, because I had to add some features that would let guns fire from on top of other collidable objects without damaging them (as in the gun on top of the station in the above picture). Now when each bullet fires, the sprite object that represents the particle carries with it a) the name of its weapon b) an array of sprite names that are "safe" from it. This way the collision method never even gets executed if the particle is being checked against a "safe" object. Currently the gun platforms aren't very smart, if you fly fast enough they can't catch up. Fortunately if you have a bunch of them fairly near to the object they are meant to protect, it actually is fairly difficult to avoid them. This officially concludes the 4 weeks of my final project, and I'd say that what I have is pretty good for the time I had. I plan to continue working on it, but I may be more slow over the coming weeks because next week is the last week of classes, then the following weekend/week is final exams, and then I have to drive back to Massachusetts and get settled in my apartment in Boston.
  6. Dovyman

    Behold, a crappy HUD

    This morning I woke up, skipped both my morning classes and just studied hardcore in the library for my linear algebra test in the afternoon. I think I did OK, the computational questions were easy, but I know my answers on the proof questions weren't entirely correct. I'm hoping for the best, I did about as well as possible. After that I came home and started working on the project, which I've given the (not necessarily permanent) name Libertas. Anyhow I fixed up a bunch of dangling bugs: problems with assets not getting removed on screen transitions, exception that gets thrown when you exit, etc. I also fixed up the collygon collision a bit - due to some floating point error in the engine bouncing doesn't really work quite right. With a little finesse I've got it working, though currently it just inverts your velocity vector instead of realistically bouncing you. Thats not too hard a fix, but its lower down on the priority list. Screenshots: Control Scheme I never really intended the initial AWSD control scheme to be permanent, but I hadn't come up with any great ideas for a new control scheme. I think I want to make it mouse based, the ships heading will follow the cursor, left click will fire, and the keyboard will still control the throttle. I think this will make it easier to steer. Also I'm considering dumbing down the physics, maybe make the ship decelerate slowly anytime you aren't using your thrusters. AI? So up until now the only ship in the game was the player, but really thats boring. So I'd like to implement some kind of simple enemy ship AI soon. Realistically, it probably won't happen this week. I'm going to stick to some simple scripted stuff for the demo mission, and maybe throw in some stationary weapons platforms that will shoot at you. One of the biggest issues with the enemy AI is how to make them move, the player continues moving in the same direction once they get going, regardless of how they turn (unless they reapply thrusters). If I use this scheme with the AI ships, it could be difficult to make the ship move around accurately, but if I don't, it will seem like the ships are moving unnaturally compared to the player. Demo Level Without getting too ambitious, I've got a basic idea in my head what the demo level will consist of. You'll start out launching out of a friendly station on the map, and get some text cues that introduce you to the controls and direct you to kill some dummy satellites. Being realistic, I probably will only get about that much done, but in the future I want to evolve the mission to let you raid a small pirate base. Really the biggest obstacle is generating the art, I've managed to not do a terrible job so far, but it is time consuming. HUD I implemented a basic HUD today, the players shield and HP are displayed bottom center, and then a list of the equipped weapons is bottom right (similar to Freelancer). Right now theres nothing in the game to damage the player, and no way to change the weapons, but everything is set up so that the HUD updates itself to reflect the current player status. My next goal is to add a basic object selection system (cycle through nearby stations, nearby ships), and have it point you towards what you have selected. Without a minimap this is going to be key for a map of any size. A minimap will come eventually, but one step at a time. Bedtime!
  7. Dovyman

    Pickles

    I haven't written an update in a little while, but really theres not much to comment on - well maybe there is: School/Work This next week is the last full week of classes, then theres a week before final exams. But damnitall I've got a linear algebra exam on Monday, so I'm spending most of my weekend going through all the material so I can cross my fingers and hope for the best on Monday. On the work front, I signed/sent the lease for my apartment in Cambridge. My other 4 intern-roommates include 1 other guy from UIUC and 3 from CMU, hopefully it will be a good combo. Progress This week was particularly busy, which didn't leave much time for development. This was compounded by a string of bugs with FRB, the engine I'm using. Thankfully the guy who develops it is extremely nice and helpful, and helped me sort out my problems over AIM and sent me bug fixes. Anyhow now all the data in the game is loaded from XML. Basically theres a pre-set directory structure that contains all the data on game assets (ships, weapons, maps, players) and it is all loaded when the game starts, and then referenced when needed. Also I changed up the collision; FRB supports arbitrary bounding shapes, so I reworked things to use this. Unfortunately one of the bugs is that I can't get bounce collision with this method, at least not without some still-to-be-done messing around. Level Design? This coming week is the last week of the project (at least for grade purposes) so I want to put out something pretty cool using what I've got so far. I didn't get as far down my feature list as I had hoped, and I won't really have much time to work on it until after my exam Monday. I started making a simple level, bu then I discovered I hadn't really thought through the gameplay very much. I had no idea what kind of objects to put in the game world - or what exactly to have the player do. I modelled the mechanics originally after Cosmic Rift - but that is an online game and it isn't story-based - so I need to do some rethinking. I'd like to come up with one cool level that shows off everything that I've managed to put together thus far. I'll throw another update up this week sometime, with screenshots. If I manage to get a decent level working I might put out a demo as well; I've gotten more used to Inkscape, and even though I suck at art I've started making all the assets myself.
  8. Dovyman

    Inefficiency

    I can sympathize with Trapper Zoid. This past summer the project I was an intern on was for an embedded system; most of the code we were working on could be built with a cross-compiler and downloaded pretty quickly to the hardware. Tedious, but do-able. However we also did some work on the board firmware, testing a build of that involved this complicated flashing process where you had to arrange the jumper pins just so over a number of steps, and if you did it wrong it could be hard to fix your mistake. This lead to less testing (daily, if that much), so when it broke (and it did) it could take the better part of a day to track down the issue.
  9. Dovyman

    Status indicators!

    I didn't have as much time to work on the project today as I put off my theory of comp. homework until today, and I've still got to go to office hours to sort out some parts before I turn it in :( Anyway I did get some overlays working, you can toggle on and off a border and health/shield indicator over all the game objects. When you shoot at something, it will update the indicators accordingly. At the same time I realized my structure and ship classes were really similar, so I abstracted that functionality into a GameObject class and made Ship and Structure children. Then I moved a large portion of the initialization into those classes instead of having it sitting in my main initialization method. Also figured out that my ship looked needlessly degraded because I was scaling down a large version in-game. I went back into Inkscape and scaled the original down and its not noticeable from the screenshot, but when you move the ship around it looks a lot better. Hopefully I can do some heavy work on it this weekend, but I've got a lot of other work to do: catch up on reading my linear algebra book, do a mountain of linear algebra homework and start working on my linguistics project.
  10. I made some progress on the art, the tip about starting out tracing over another picture was helpful. I took a top-down schematic of a Raptor from Battlestar Galactica and went at it in Inkscape. What I came up with is in the screenshot below - it's not great, but for my first try I'll take it. Next up, new space station and other structures. On the coding side of things, it turns out I should have done a little more research about serialization in C#. I threw away my xml/reflection class and decided to just use the XML serialization that C# comes with. As for how to handle separating data from the engine classes - I just created an EmitterConfig class, and then derived subclasses for explosion, weapon and engine emitter configurations. This makes it easier to create specific emitter types, since you only have to specify relevant values and the rest is filled in automatically. Each class has a Construct() method that takes in some game state data, and passes you back the engine object with all the configuration data filled in. If I want another type of emitter it might become a pain in the ass, but besides the occasional special case, particles usually come in the form of bullets, explosions or engine flames. Next up is streamlining the way the XML is loaded. I want to have specific folders that weapon data, ship data, etc belong in, and then these are all loaded into a hash table with names as the key. Then all a ship needs to know is the name of the weapon it wants, and it can grab it easily. Finally I said I was going to do overlays and menu's this week - that may or may not happen depending on the next two days.
  11. This past weekend was my birthday, so I did a lot more drinking than coding. Sunday I did try and make some art for the game, since the art I'm using now isn't mine (and hence I wouldn't feel comfortable letting people download a demo until thats resolved). Unfortunately computer art isn't my thing - I'm not the greatest artist, but I could *draw* a spaceship on paper. I can't however seem to make a good one on the computer. I tried to use Inkscape - no luck. If anybody has any tips/tricks/advice on how to get the best out of my programmer art skills, please leave a comment. In the coding side, I started writing a class to let me define objects in XML. The motive behind this is so that all the game data (ships, weapons, extra map data, etc) can be created quickly and modified easily, and not live in code. For the first pass, I went with a straightforward XML to object idea. Basically some simple XML like this: Reflection Weapon 10 Becomes a GameName.Data.Weapon object with the included values. I finished this and now I'm rethinking the way I've gone about it. For example, the Weapon class contains the "name" and "damagePerHit" fields, but it also contains a field that is an Emitter from the graphics engine. I initially mixed some graphics objects in with the other data because I need to define how the weapon particles look. However initializing the Emitter object is too complex for my reflection class - its constructor takes arguments that aren't available until the game is started. So the most direct route solution is to create new classes to be twins with classes like Emitter, but these classes only contain specific data items that don't depend on the game state. Then these classes can be filled with the XML, and at the appropriate time that data will be copied to the right place in the real in-engine object. However, this doesn't seem optimal either. If I'm going to go to all that work - the result should be easier to use than simply filling in fields on an object. I'd like to find a way that makes creating these objects easier - but doesn't put any limitations on how much control I have over object creation. Not sure what that solution is going to be yet, but in the next couple days hopefully I'll bang something out.
  12. Dovyman

    Particles are fun

    Did some more work over the past couple days. Mostly I've been coding the storage classes that hold information about ships, weapons, maps, the player etc. I've also done a bunch of stuff with the FRB particle engine. The sprites are well designed so that you can attach emitters to them as children, and then attach emitters to those emitters to do things like have bullets explode. I'm still trying to think about the best way to do collision, right now I have every sprite held in a series of arrays depending on how they should collide with other objects. Bullet particles are held in one array, moving objects like the player in another, and static structures in another. The downside to this is detecting collisions involves looking at every sprite, onscreen or not - which is expensive. Screenshots (Art not mine, I need to find some more legal art to use soon): Next up is moving static data like ship information, weapon information and map information into XML files that can be parsed into storage classes when the game is loaded. Also I need to find a generic way to make large explosions using the particle engine - something fairly random that can be used for any structures or ships.
  13. Dovyman

    And they're off...

    I started today on my space shooter project, which is immediately in dire need of a good name so I can stop calling it "the space shooter project". I spent the last week or so surfing around and looking at various free graphics engines, (thanks gamedev for the nice list in the Alternative Libraries forum) and couldn't seem to quite find anything that sparked my interest. Either using it looked too difficult, it lacked a critical feature, or it didn't seem well supported. Finally, I ran across Flat Red Ball which seemed to really fit the bill. It had all the features I needed, plenty of documentation, still in active developement, had a good community behind it, and most of all, it's in C#. Friday/Saturday I spent a little bit of time fooling around with the template to see how things work, and read most of the documentation that was available. Today I started putting something together and in a couple hours I made a lot better progress than I expected. I've got a fairly data-driven application that will show a map with some collidable stationary objects, and then add in a configurable ship that the player can control. Best yet, for once it is fairly well architected and not just a shitty-on-the-fly prototype. The rest of this week: - Come up with a good collision scheme. FRB provides a lot of collision capabilities but I can't find a great way to encode each objects collision behavior in some form that can be loaded for each map. - Work on some basic polish issues. Right now you can fly off the map - need to fix that. Also the control scheme needs tweaking, I've got it so that pressing the "up" key for instance makes you accelerate forward, but turning doesn't change your direction of motion. This may be how it would actually work in space, but it makes it hard to control. I need to find a balance between the standard controls and the realistic ones I've got now. - Implement particles. FRB has some fairly powerful features that let you do a lot with sprites in general, and particle sprites in particular. One thing the game desperately needs is some graphical flair, so I want some cool particles for engines and for weapons, and for anything else I can think of. One cool idea I've had is for the level backgrounds. I've always been a big fan of cool space pictures, and it turns out Hubble images from NASA are available in super high resolution (6000x6000), and don't seem to have any prohibition on use - the perfect backgrounds for a space game. The plan going forward is for a couple journal updates every week (hopefully including screenshots from now on) and a demo at the end of every week. (I have to show a demo in the class this is for every week, so why shouldn't I post it as well - or at least a video).
  14. Dovyman

    Back from spring break

    People seem to read journals with pictures in them, so in lieu of screenshots of a cool project (since I have none - though scroll down for details on whats coming up) I'll put up my favorite pictures from spring break. I went backpacking down in Big Bend Texas for the week, definitely tiring but it was a beautiful place. Early Morning at Boot Canyon Cliffs in Mexico to the West of Santa Elena Canyon Pinnacles View off the South Rim Just before Sunset on the Southwest Rim View off Emory Peak Anyhow, in other news I'm supposed to turn in a summary and schedule for a 4-week project in my programming studio class. I'm looking at it as a good way to actually develop a game for once, even if its pretty small. I'm going to relook at the little space shooter demo I did over winter break and make it into a full fledged space shooter. Right now I'm having trouble deciding what to use for a graphics library, I don't want to have to be writing the low level functionality when I only have 4 weeks. Ideally I'd like to already have: - Basic animated sprites with collision - Simple particle engine (for explosions, weapons etc) - Sound & Music Support - Input support I think that so far SxDL looks the most promising, but I've never used it before so theres always a chance it may take more time to rampup to than I expect. I used Ravuya's Propane Injector for the original demo and I'm tempted to stick with that - we'll see. Anyway you can expect some more frequent journal entries in the near future as I'll have some game development related things to write about :)
  15. Dovyman

    GDC '07: Day whatever

    I can't help but wonder what kind of people are bouncers for Microsoft
  • 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!