Advertisement Jump to content
  • Advertisement

Staffan E

Member
  • Content Count

    684
  • Joined

  • Last visited

Community Reputation

536 Good

About Staffan E

  • Rank
    GDNet+
  1. Staffan E

    Android Development Minipost

    Cool, I've been thinking of buying an Android phone for the exact same reason. Now I'm even more inclined towards doing so. What little experience I have with Eclipse, my impression is that I kind of like it. It has most of the important functions and is still very lightweight. Now you tell us once you have an Android game up and running, ok? [grin]
  2. Staffan E

    Hey

    [sad] Hang in there. It'll turn around for you. Best wishes.
  3. Staffan E

    It looks like a game

    I think that when starting out a substantial project like this with very little game development experience, the best thing to do is to make a grab for every third-party solution within your reach. My biggest mistake (so far) with the development of my game/engine Citizen was that I initially was very reluctant to use what others had made, and went straight to the core APIs myself. Now, close to two wall-clock-years into development I am only beginning to see some gameplay coming out the other end, and that is only because I came around and realized that if I was going to do all those cool systems myself I was looking at 5-10 years before release. Don't know if this applies to you though, but it seems to me that your project is a bit more advanced than Tetris and I understand you're doing it alone. I'm telling you because I'd love to see this kind of a game finished, and even more I'd hate to see you burn yourself out on technicalities. Cheers and good luck! /Staffan
  4. Staffan E

    Experimental Perspectives on Tilesetting

    The first thing that came to my mind was to have all overlapping walls cover only half the height of a normal character. But I guess that would probably be a strong design restriction, and not solve the problem for small critterous things. I think that the player will be forgiving of whatever method you use as long as there are no hidden enemies or objects. Something as simple as a flat-colored silhouette drawn on top of the wall could work. I know I would buy that.
  5. Staffan E

    Real world implementation of Reg Free Com (WinSxS)

    I'm listening... Manifests has been one of those (many) things that, if I pretend they're not there, I've decided they can't harm me. [looksaround] Would be nice to get some clarity. Oh, and welcome to the land of journals. Here is an r++ for passing the citizenship test.
  6. Staffan E

    Dirt Roads

    Nicely done! Throw in some soft natural lighting and those scenes could fool me for photos.
  7. Dynamic properties revealed Properties continued from here. Alright, as I promised in the last entry here is the full source for the property container I'm using. The core functionality of the prop::container is to map strings to values of any type. This is done using the templated get/set functions. The set() function either sets an existing property to a value or creates a new one. The property type is specified via the template parameter. The get() function requires that the sought property of the requested type exists or it will throw an exception. The type must match the one used with set(). To avoid having to wrap each get() call in a try-catch there is a req() function that should be called at the beginning of each scope that uses the property. If the given property exists the req() call does nothing. If it doesn't, req() creates the property and sets it to some initial value. One can think of req() as the equivalent of a variable declaration. Right now there are no functions to remove or query existence of properties but they should be simple to write. There is finally a set_callback() function that takes a existing property name and a prop::weak_callback_ptr object. This sets a callback object that should be invoked every time the given property is written to. To use this you should inherit the prop::callback class and implement the operator(). Then you should create an instance of that object somewhere using prop::callback_ptr p(new derived_cb()); This will give you a reference counted pointer object that can safely be given to the property container by set_callback("prop_name", prop::weak_callback_ptr(p)); Since callback_ptr is reference counted it will not need to be manually deleted. The pointer we give to set_callback() will not become orphaned if our callback object is destroyed. Because we send in a weak pointer the callback object will not be pinned down by the container. If the callback object is destroyed the weak pointer will become invalidated and the container safely removes it. Beyond the addition of the has() and rem() functions noted above there are a few things I'd like to add in the future. Most importantly a property should be able to have more than one callback associated so that systems can listen independently. Currently req() does not enforce that the required property has the right type which may be a design error. Also I'd like the prop::prop_value and prop::property classes to be private to prop::container to clean up the external interface. The code is contained in one C++ header file and it needs several boost classes to build. If you don't have boost, get it here. RTTI needs to be enabled when compiling. This is a requirement of boost::any. ? Check out the full implementation below, after the usage example program. Use it, abuse it, and if you find anything good or bad about it, tell me! [smile] And, yeah, funny story. GD does not allow me to upload .HPP header files. I assume they have been shown to be potentially more harmful than their .H brethren. [looksaround] There is a zip-archive containing both files though. Sample program [source] #include #include "prop_container.hpp" int main(int argc, char* argv[]) { prop::container props; // Require the new property and output its value. props.req("my_int", 0); std::cout
  8. Hah! That picture doesn't prove anything! It could be one of the few still images right before it smashes into the ground to everyone's horror. [dead]
  9. Staffan E

    More Box2D integration

    More Box2D integration Continued from here. Been busting may ass off for two days integrating Box2D into the Citizen engine. For most parts it's been successful. Although Box2D is very simple to get working, there are hundreds of small connections that need to be welded together. The biggest incision I've had to make so far is to create a logical coordinate system separate from the pixels-units I have been using. This is also what's taken most of the time. Using logical units has been one of those things I knew from the start I should do but then never got around to implement. Now, a hundred little sins later, the pixel units were so deeply rooted into the system that in weeding them out I had to review most of the graphics code and then some. *groan* At the time of typing all things render correctly but sizes are way off and need to be recalibrated in with new numbers. Box2D interactions work fine with all different object types. I mentioned before how entity hierarchies had to be scrapped in newer versions of the system. By using hinge joints I've re-enabled the option to attach one object to another, which currently is used for ship turrets, and now such attachments are physically accurate. The next big issue is that the behaviors that control movement need to be adapted to the new physics. What was done before by controlling the velocity of actors directly now have to be done using forces, so some control theory might be appropriate to avoid oscillations. I've also beaten out the last dents in the property container so the next entry will be going into all of its details, source included. I could do it now but I'm too tired to write proper documentation. Got to get up early tomorrow. See you back here soon.
  10. Staffan E

    Minor news flash

    Wow, so many projects! I hardly even have time for the one. [bawling]
  11. Staffan E

    Time's up!

    Sweet! Congrats! I checked out the video and it looks nice. Of course there are things to polish on but overall it looks done. I mean, aren't there always things to polish on. Personally I like this kind of games when there are hordes of smaller attackers. Did you experiment any with different numbers of enemies with different health levels? Again, congrats!
  12. You'll have to excuse any weird typing today. My head is completely worn down by moving all weekend. I've evacuated my apartment and will be staying with the family for a few weeks. Then it's off to Stavanger, Norway for a two-month internship position. Awesome! [grin] Integrating the properties Read about my property system here, and about the Body component here. I've shifted my efforts towards integrating the new property system together with the new Body component. It may seem dangerous to do several integrations simultaneously, and it is, see below. However the property container is a necessary part of the system the way I see it evolve so putting it off until later will only complicate things. I'm going to scrap the current way of supplying configuration data to the components by their constructor. Instead I want all such values to be properties that can be set before or after the component has been crated. The key difference here is that properties belong to the entity and the components just use them. The component must declare in its constructor which properties it will use, and give a fallback value if no such property exists. This way no props will be missing and no config data will be overwritten. This is the current prop_container interface. T get("name") void set("name", value) require_prop("name", def_value) void set_callback("name", callback_ptr) The exact operation of require_prop() is to add the property and set the default value only if it doesn't already exist. One can also specify a callback function object that is called every time a property is written to. Such an object must inherit the prop_callback interface and is held through a weak_ptr. I'd love to post the whole prop_container class source if only I had it checked in, but it's on another computer right now and in a non-functional state. I'll try to remember this later. Some people have shown interest in the property implementation. Converting test code to CppUnit format There has been a big problem with my testing code for a while. Namely, the whole test application has not failed, but crashed hard without any helpful debug output. Up until now I've been using FCTX, Fast C-Testing, xUnit, something. This is obviously a framework suited for C-programs and the main reason I picked it was it is contained in one single header and was darn easy to get running. However, since FCTX is based on C macros it does not work well with stack trace analysis, so in the end I just ignored the whole thing as the game did run (the very opposite of good conduct). Now, finally, I've taken on the problem by ditching FCTX and going over to CppUnit instead. It was a crap-load of work converting all the tests (WHY DON'T VISUAL STUDIO SUPPORT MULTILINE SEARCH AND REPLACE!?!). Just want you to know... Anyway now I can trace the crash down to something in the new property container. Apparently the deepest informative level is the string key comparer in the map that holds the property objects. It's not solved yet but at least I'm getting closer. CppUnit is nice too. Now I don't have to hack my way around testing the exception handling. And without the macro-orgy VS intellisense actually knows what's going on. The poor thing.
  13. Here is another issue of Staaf's Irregular Weekend Updates. Digest with a glass of red and some soothing music. After a discussion with my editor I agreed to try to cross-reference my posts if a subject carries over from one entry to another. So here goes nothing. Vehicle and Obstacle components merged into one Body component Previous discussion about Obstacle in this entry. Last weekend I began to tear up the Vehicle and Obstacle components and to try to combine them into one Body component. You may remember than Vehicle controls autonomous movement of entities (mostly through steering behaviors) and Obstacle does simple physics. My reason to merge them is that they were never independent anyway. Physical response affects motion too so they both relied on a single integrator. Placing the integrator in either one would cause a coupling while having two independent integrators would be very, very bad. The key point of the Body component is that it is based on the Box2D physics library instead of my own simple one. Steering behaviors are now an optional part of the Body component and they simply exert extra forces sand torques on the body when active. I've never worked with Box2D before but it was simple enough to get up and running. The hard part was and, still is, to adapt the system and design the new component, atoning for past mistakes. For example the bodies need a way to track other bodies both passively (for cohesion/separation behavior) and actively (for targeting/seeking). The passive is done by simply giving the steering behavior update a collection of all bodies. Previously the active tracking was done by storing the ID of the tracked entity and looking up its vehicle component each frame. The continual lookup was slow but I didn't want to hand out pointers between components because of the security risk. Another flaw was that the tracked entity was required to have a vehicle component even if it didn't do any auto-movement (like the mouse pointer). The new system introduces a Target component that is lightweight and only exists to flag an entity as targetable. When a body component picks a target it gets coupled with this target component and can request its location each frame. The coupling is done using a set of smart pointers, see below, so it's safe if the target is destroyed. So far so good. Right now I'm trying to figure out how to attach entities to each other in the new design. My previous concept of hierarchical structures of entities doesn't work here. I'm figuring if using joints between bodies could work but that would require a Body component on both attached entities. Hmm. Extensive use of smart pointers Previous discussion about smart pointers in this entry. I've also gone further in my studies of smart pointers and how to apply them. I recently talked about using boost::ptr_map and other collections. Now with the added requirement that my components should be safely distributable within the system such a sealed collection was not enough. Instead, by using a collection (map) of boost::shared_ptr, components flying around are reference counted to prevent premature deletion. The system distributes boost::weak_ptr objects instead of actual boost::shared_ptr objects so that if a component is distributed and then deleted the links to it will be safely inoperable. You can read more about boost::shared_ptr and boost::weak_ptr in the documentation. Briefly, boost::weak_ptr is a sealed pointer that needs to be promoted to a boost::shared_ptr through a lock() call before it can be used. This way it doesn't pin down the resource until it really needs to. Yeah, and please ignore this old lashing out on shared pointers from a year back! I overreacted to say the least. Of course you should use them only where they fit in.
  14. Staffan E

    The process of creating a game?

    Quote:Original post by DestX Well, I've been programming various games for several years, but I always had a feeling I was doing the whole process wrong, even though I improved at each game I started. If you have made a few games, complete or incomplete, then you should already have some code to go back and review. We programmers, for some reason, very easily to fall into the trap of saying "this is all wrong!" And then we hit the big shiny delete-button and say "let's begin from scratch and do it right." More than often it is better to keep using the old code, to keep improving it, because between our mistakes there are also many clever solutions. As others have suggested, try going back to your previous projects, and look for common patterns that you can factor out. Then you are well on your way already towards your next game. And you are adding to your own toolbox instead of rebuilding it each time.
  15. Staffan E

    The process of creating a game?

    I think this is what you are looking for. Tons of stuff to read about the software development process. It's not specific to game programming, but in this sense a game is just another piece of software. The same rules apply on the large scale. I myself am using a sort of blend between iterative and test-driven development. I like the freedom and robustness TDD brings when you get the hang of it. And I also like the idea from the iterative process to rapidly come back to prototypes that can be evaluated against some set of requirements. If you are a single developer I think it depends a lot on what kind of person you are. Some people like to plan out the whole structure before they begin to type the code. Others just like to wing it, make it up as they go along and go back to restructure once a clearer picture has appeared.
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!