Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

162 Neutral

About DaTroof

  • Rank
  1. Galactic Front ( is back online with a few bug fixes and new features. * The server now runs as a proper daemon for better uptime. * Game scenarios include conquest and deathmatch. * Computer-controlled ships participate in games so players can always find a dogfight. User accounts are optional. Anyone can start playing immediately by going to the Flash page and clicking a button. Thanks for checking it out! Please feel free to make suggestions and report bugs.
  2. Galactic Front is a multiplayer space combat game where you conquer planets and destroy your enemies. I ran a public test a few months ago, and now I finally have it online with its own web site and a whole bunch of new features. To play the game, go to the Play page and pick a name. User accounts are optional. You can log in anonymously by leaving the password blank. Once you're in the lobby, select a game, join a team, and you're ready to go. Use the arrows to control your ship. Space bar shoots your lasers. You can conquer planets by hovering over them and pressing C. If you're orbiting a friendly planet or your team's base, you can repair your shields by pressing R. Use the quotation mark/apostrophe key to send a message to the other players. Screenshot:
  3. DaTroof

    Galactic Front: Multiplayer Flash Game

    Oops. It's running now.
  4. DaTroof

    Galactic Front: Multiplayer Flash Game

    Update: I moved the game to a better server and made some more improvements to the netcode. There are still some minor latency issues I want to resolve, but combat should be a lot smoother now.
  5. DaTroof

    Galactic Front: Multiplayer Flash Game

    Thanks, Meto. I've made a few updates over the weekend. * You can build defenses on your planets by pressing B. Planets with defenses do damage to attacking ships and take longer to conquer. * I reduced the test game's map size so the games go faster (less flying through lots of empty space to find planets to conquer). * The lobby gives you detailed information about games in progress when you select one from the list (map size, number of players, etc.). * I improved the network code to reduce lag.
  6. Galactic Front is a multiplayer space shooter where you conquer planets and blow each other up. I've been working on this game for a while, and it's finally in a playable enough state that I wanted to give it a test drive. Starting the Game 1. Go to the game page, choose a user name, and log in. You can ignore the password field. For testing, I'm not requiring players to register an account. 2. Choose a game from the select box. "Beta Test" is the only available game at the moment. 3. Join a team. The Beta Test has two teams, Rebellion (red) and Empire (blue). You'll start the game orbiting your team's station. How to Play 1. Move your ship with the arrow keys. Up to thrust, left and right to rotate. 2. Shoot missiles with the space bar. Missiles do not affect planets, stations, or friendly ships. 3. If you are near a neutral or hostile planet, press C to conquer it. 4. If you are near a friendly planet or your team's station, press R to repair your shields. 5. You can send public messages by clicking in the input box on the right side of the screen or pressing the quote key. Type your message and hit enter. Upcoming Plans I'd like to set up multiple games with different scenarios, rules, and objectives (conquer all planets, most kills within a time limit, etc.). I'll also create a few different ship types. After I enable account registration, I'll set up a way to track player stats and top scores. This is the first time I've tested the game outside of my own LAN, so any feedback would be appreciated. Screenshot (slightly reduced from actual size): [Edited by - DaTroof on September 25, 2007 8:14:18 PM]
  7. DaTroof

    POSIX Threads in C++

    Quote:Original post by NotAYakk Does this reflect your archetecture? World :: SocketServer ::* SocketClient :: GameCode :: is connection ::* is connection with many on the * side. Precisely. Quote:Original post by NotAYakk Personally, I'd have the SocketServer listen to the World. When it gets data (or maybe "enough" data), it locks the "GlobalSocketClientLock", and tosses a bunch of data into the SocketClients. Once it is done adding this data, it releases the "GlobalSocketClientLock", and then walks over the SocketClients which have new data and sets a notification that they have new data to push. Now it goes to sleep until it gets more information. The GameCode ignores the SocketClients unless it has been told that they have new data. If they have new data, it locks the "GlobalSocketClientLock", quickly copies the data into it's own space, and then unlocks the "GlobalSocketClientLock". When it wants to get rid of a SocketClient, it sends a message to the SocketServer, possibly via a Socket, or possibly via a flag on the SocketClient, that the SocketClient is no longer needed. The tricks: 1> Locks are around a tight operation. If many things are tend to be done at once, all of them are done using one lock. 2> One thread controls object lifetime. It knows what other threads have a reference to an object. When other threads want to lose their reference, it communicates to the lifetime control thread, who can make decisions. 3> Multiple channels of communication are dangerous. It might be simpler to have the GameCode talk to the SocketServer via sockets -- I think sending on a socket is cheap -- rather than building a new robust form of communication. 4> Minimal processing is done while you hold locks. The server finds the Clients, locks, shoves the data onto the clients, then unlocks. The Code is notified that clients have data for it. It locks, grabs the data, then unlocks. Excellent ideas, especially the one about performing minimal processing during locks. I've moved the data into Send and Receive queues, and the only time either mutex needs to be locked is when its queue is being swapped or new data is being appended to it. Quote:Original post by Bregma No. One thread to listen to all sockets sounds reasonable to me. Listen, accept/read+enqueue. Use select() to multiplex that single thread. That's more or less what I was doing, including using select(). All the reads were performed in one thread, but every socket had its own mutex, which I thought might be overkill. The hole in my design, I think, was enqueue. Quote:Original post by Bregma Yes. One mutex per shared resource is how to do it. Minimize your shared resources. Does a single mutex over each queue sound like a good way to minimize it? I definitely like the fact that nothing needs to get locked unless the queues themselves are being modified or swapped, both of which are relatively cheap operations. Thanks to everyone for the input.
  8. I am in the process of writing a threaded socket handler for an online game. Having little experience with threads, especially in Linux, I wanted to get some feedback on my design and ask a couple of questions. The game uses a single instance of a SocketServer class to handle all the connections. SocketServer primarily consists of a listening socket and a linked list of SocketClient objects. It starts a separate thread that performs two functions: 1) The listening socket checks for new connections and adds them to the list of SocketClients. 2) A function iterates through the list of SocketClients, looks for incoming data, and appends it to a buffer. Player objects in the game have pointers to their respective SocketClients and extract the data from their buffers once per game loop (approx. 10 times per second). There are two major points of contention that I see. The first is each SocketClient's data buffer, which is the only shared data between the SocketServer and the game. My solution was to add a mutex to the SocketClient class and lock it in the functions that read or write to the buffer. The second point of contention is removing closed connections from the SocketServer's linked list. I can't safely remove the SocketClient object if the player's object in the game still has a pointer to it. I figured the best way to avoid the problem is to have the player object set a flag in its SocketClient that marks it safe to delete. If the SocketClient is closed, it sets the flag and changes its SocketClient pointer to NULL, and the SocketServer can safely remove it on its next iteration through the linked list. Does this look like a reasonable design? Are there any points of contention I may have missed? Also, some of the references I've consulted warn against using too many mutexes for performance reasons; is one mutex per client overkill? It seems to me the only way to avoid race conditions on individual clients without locking the entire SocketServer for every read/write. Frankly, I'm a little worried that I might be misconstruing how mutexes work. Every tutorial I've seen gives a barebones example using a single mutex as a global variable. Is one mutex per shared resource the right approach?
  9. Quote:Original post by MaulingMonkey Note: EVE Online shelled out some $$$ for a "solid state storage" server. Basically, it's a huge RAMdisk for the more active parts of their database. They had a news article on the subject if you're interested in further details. If you mean the Texas Memory RamSan story that ROBERTREAD1 linked, I read it. When a game reaches 25,000+ simultaneous users, serious hardware and/or software solutions become critical. I don't know EVE's architecture or what kind of data synchronization they demand, but I'm not surprised they paid big money for a solution. There are a few things I did to keep the database from lagging my game. * The application doesn't need to query the database every time it needs to access a game object's properties. All the live game data is held in memory. * Only crucial updates are immediately written to the database; for example, when an object is killed, destroyed, or transferred into a new zone. Everything else is scheduled once per minute. * If a game object's properties haven't changed since the last time its records were updated, it gets skipped in the current update. The game also knows which of the properties have changed, and only updates the corresponding records. * The updates are staggered so they all don't have to occur in the same game tick. So far the RDBMS has performed beautifully. In order to maintain a persistent game world, I need some way to store game data to disk. Using an RDBMS seemed at least as feasible as implementing a flat file system, and offered way more features out of the box. Granted, I haven't tested the game with more than a handful of zones and a few dozen simultaneous users, but since it's running on a P4 with 256 MB RAM, I expect to run into hardware limitations way before the software stops scaling.
  10. Quote:Original post by Emmanuel Deloget Quote:Original post by kordova You mentioned MMOGs so I assume that is your target application. I was under the impression that RDMSs were too slow for MMOGs. That's not true. You can issue a lot of requests in no time if you use a correct RDBMS. That's why they were invented in the first place. Absolutely. There's also the question of how the game is using the RDBMS. Live data could be held in memory for fast access while the RDBMS handles persistent storage. That's how my game does it, anyway.
  11. A while back I announced the Webventure project and set up a web site for testing. After I lost the most current version of the source in a server glitch, the site was put on hiatus while I rewrote most of the system from scratch. It's ready to go public again, and I registered a domain name to celebrate. Webventure is a Web-based adventure game system. If you've ever played games like Zork, you'll understand how it works. If not, there's a beginner's manual to help you get started. The first game developed in Webventure, "The Silent Partner," is back online and ready to play. The site also provides a Web-based editor so you can create and publish your own games. Anyone who registers a free account can take a shot at writing one. Just log in to your account and go to your portfolio to get started. The developer's manual is available here. All game data (excluding images) is stored in an XML file. If you'd prefer to edit your game file offline, you can write your own XML and upload it to the site. You can download the source for "The Silent Partner" here. Among the features I've added since the previous version: * The online editor * Better image support * Scoring system * Resizeable game window * More scripting commands * Scripts are compiled to bytecode when the game starts * Players can save games This is the first public release of version 0.5, so I expect people will find bugs I didn't anticipate. Any feedback is appreciated. I'm especially interested in comments about the editor and suggestions for improvements.
  12. DaTroof

    Scripting game AI?

    I've found scripting to be very useful for high-level planning. My game engine uses Ruby scripts that get triggered by in-game events; for example, when a player talks to an NPC, the NPC's ontalk script determines how it reacts. It hasn't yet proven to be a bottleneck, and some of my NPCs have fairly complex behavior. One example is a miner who will go to a mine and work when he's broke, go to a refinery and sell his ore for money, go to a pub and drink beer until he's broke again, and repeat the cycle. The script looks something like this: credits = this.children.get('credits') if credits == nil # NPC is broke # Does he have ore? ore = this.children.get('ore') if ore == nil # NPC has no ore # Is he in the mine? if this.parent['name'] == 'mine' this.doCommand('mine') else this.doCommand('go to mine') end else # NPC has ore # Is he in the refinery? if this.parent['name'] == "refinery" this.doCommand('sell ore') else this.doCommand('go to refinery') end end else # NPC has money # Is he at the pub? if this.parent['name'] == 'pub' # Does he have beer? beer = this.children.get('beer') if beer == nil this.doCommand('buy beer') else this.doCommand('drink beer') end else this.doCommand('go to pub') end end The script only determines what the NPC needs to do and adds its commands to a schedule. The engine handles all the intensive stuff like pathfinding to get from one location to another.
  13. Another solution could be to make the value you want to manipulate a member variable and pass it in the constructor. class Base { public: virtual void DoSomething(); }; template <class T> class Derived : public Base { private: T MyValue; public: Derived(T init) { MyValue = init; } void DoSomething() { // Do something with MyValue here } }; Derived<int> foo(100); foo.DoSomething();
  14. DaTroof

    OOP/Modular based Game design?

    Quote:Original post by cypherx For a more relevant example, think about how much scaffolding/infrastructure something as simple as rendering requires in an OO approach to game engines. In many designs I've seen screen objects implement an IRenderable interface and possess a Draw() method. There is then a Renderer class responsible for calling all these draw methods. Another option (if you're targetting multiple backends) is to have Renderables carry high level data describing their graphical properties and then different Renderers (OpenGLRenderer, DXRenderer, SoftwareRenderer, etc...) translate these into appropriate API calls. I'm sure there are other OO approaches to rendering I'm not thinking of. There's nothing wrong in either approach, but it's easy to get caught up in "high level" design issues and spend time perfecting how classes interact instead of writing useful code. Okay, I can see your point about over-design. I just thought you were throwing the baby out with the bathwater. Why avoid encapsulation if the problem you describe is related to inheritance? An object-oriented approach doesn't mandate the use of a complicated inheritance hierarchy. Proper encapsulation remains useful on its own because it can provide a design that's just as flexible, but easier to maintain.
  15. DaTroof

    OOP/Modular based Game design?

    Quote:Original post by cypherx I'm also not a professional game developer. I do have some coding experience, including a few small games...but take my opinion with a grain of salt. That said, I don't think Object Oriented design is that great for a small hobby game. In the past, I spent way too much time on a game engine building up intricate object relationships and then untangling them when I realized I had missed an important feature. I think OOP is much better suited for development teams with explicit/semi-rigid requirements than individual hobby coders. For small games you usually don't need all that structure. Think about what you need your game to do, decompose that into functions and data structures. You'll have some organization/modularity without the rigidity of inheritance hierarchies. To recode steeg's example: *** Source Snippet Removed *** This is almost the same thing, but you're not tying your functions to any specific stateful data. This makes your code less scalable but more flexible, and in my opinion, quicker to develop. -Alex Your example isn't significantly different from steeg's other than separating the functions from the data structure. I don't see how that makes it more flexible or quicker to develop. It's just as easy to encapsulate the functions and data in the same class. I did appreciate, however, that your example encapsulated the running bool in GameState.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!