|
Maybe this is deserving of its own thread, but since it is related to game development, I thought I would start here. Preface: I'm building a wargaming utility designed to enable players to play without necessarily being face to face. Think Warhammer or Warmachine over the internet. I'm handling the unit and rules logic via scripting files so the utility is extensible when new rules supplements are available. That way a person can have access to the content of an arbitrary set of units/books. However, I'm not in the piracy business, and want to limit the access to these rules files to specifically authed clients. (Ie, those who have purchased the most recent rules supplement.) So it becomes necessary to encode these scripted files in a way that links them to a specific client. That way User A cannot give his files to User B -- User B has to own his own copy of the script files. Now, I've very little knowledge about fancy encrypting technologies. The most obvious solution to me is to zip the scripts files using a password that is unique to each client. (Maybe an MD5 of their username, or something similiar. Something the end user is unlikely to know, but is quick to determine algorithmically.) Then I can just use a zipping library to unzip the script file into memory at runtime. Anyone have any suggestions? Ideas? Also, how secure is my idea? I know that I won't be able to stop dedicated crackers using this technique, but how long would it hold of a curious nerd?
|
#
¿
Dec 28, 2007 05:47
|
|
|
|
| # ¿ Apr 27, 2024 18:49 |
|
|
Fixed my problem. Thanks!
Pfhreak fucked around with this message at 07:31 on Jan 1, 2008 |
|
#
¿
Jan 1, 2008 07:22
|
|
|
devoir posted:... vastly differing viewpoints on XNA\. Huh. I've always heard this: It's not really designed from professional production studio stuff, but for any sort of hobbyist, it can get you up and running very quickly. It's powerful enough to do some pretty cool 3d stuff, and has support for modern shaders. It's easy to develop with too!
|
|
#
¿
Jan 23, 2008 01:50
|
|
|
I believe the class is Vector2, not Vector2D. 
|
|
#
¿
Feb 6, 2008 17:34
|
|
|
Feel free to post, and we'll help you through.
|
|
#
¿
Feb 6, 2008 18:24
|
|
|
Vinlaen posted:I still need a massive 1920x1200x32bit * (amount of screens of terrain) texture though, right? (when using 1920x1200 resolution) There are a number of schemes to prevent the appearance of tiling. You can flip and rotate textures, to start, and you can also add a few 'decals' above the texture. (Like big rocks, grass blurbs, etc) that break up the visual aspect without destroying your video memory.
|
|
#
¿
Mar 3, 2008 20:58
|
|
|
So I'm working on putting together some basic AI for a 2d sidescroller a la mario. (Although it is a fair bit more complex than Mario, but it's from the same angle.) Due to the nature of the gameplay and plot, I need to have a number of enemy types that can arbitrarily respond to any other enemy type (and indeed, any unusual object in their environment.) My first thought was to follow the standard object oriented approach -- model it like it exists in the real world. But I realized that would be unbelievably complex, and way more work than needed, and I started to do some reading. One model that particularly stuck out to me was a 'smart-world' or stimulus based approach. Rather than having each AI evaluate what everything in the world meant for their situation, I would drop little 'beacons' into the world that projected a type in a certain radius. So one might be food, or enemy, or loud noise, or fear... etc. Then, the AI for a unit just polls the nearby beacons, selects which is the highest priority, and changes state appropriately. That seems straightforward enough to me. However, I'm looking into doing some pathfinding for my characters. The easiest (and most coarse) method is just to push them around until they stop moving, and then turn them, and push a different direction. That's what my first prototypes did, and I'm not satisfied. I've read about A* and nodegraphs, and I can see how I might use these to navigate with a flying agent, land based enemies don't seem to make sense. Can anyone point me to resources (or give me some pointers [HA! programming joke!]) on managing 2D navigation?
|
|
#
¿
Mar 15, 2008 22:41
|
|
|
very posted:It really depends on what kind of terrain you are talking about and how your characters move. Can you give us a better idea? Yeah. We're using a physics library, and all of the agents will be affected by it. We are defining the world using textured polygons of arbitrary size. Thus, the world isn't tiled. The agents have a bounding box that defines their collision size, and they currently move back and forth by sliding along the ground. (By altering their linear velocity.) Does that help? I'm trying to think of a similar game. Abuse is pretty close. (Actually, they make their source available, maybe I'll check that out!)
|
|
#
¿
Mar 16, 2008 03:50
|
|
|
Pixel Shader question: Much like, *ahem* Girl With Huge Tits, I'm starting to learn about doing some HLSL pixel shaders. It's pretty obvious to me how to do things like change the tone of an image, or do some distortion based on a function. I'm even thinking I'm starting to understand how to do normal maps and render to backbuffers. I'm pretty proud of even the simple shaders I've written (woo! Go Sepia!), but I want to start learning about more dynamic effects. Things like fire perturbation (ie, the heat haze) really confound me. Web resources are surprisingly slim on how to set this up (or I suck at google.) Things like explosions are a little bit more documented, and I think I could implement one if I had to. I should note that all of these effects are 2D, our game dev club has basically finished our engine, and we're looking to add some extra visual effects. Does anyone have any resources? Good suggestions for books even?
|
|
#
¿
Mar 25, 2008 16:29
|
|
|
iopred posted:FSM's can be made pretty easily in a nice OOP way, create a State interface, with methods like "Start, Run and End" and then just have a FSM class that does all the transitions by calling the right functions. Then its just an issue of making a bunch of different classes to do the things you want. To be entirely correct, you should probably make a state abstract base class rather than a state interface. (Remember, C# has an interface keyword.) There are a number of advantages to doing this, one, your states are all going to be like objects with a common type, not dissimilar objects with a common type. Two, you'll be able to create default methods for things like OnEnter, and OnExit, (heck, even Update and Draw) and it will make your concrete states that much cleaner to look at.
|
|
#
¿
Mar 30, 2008 06:35
|
|
|
Ferg posted:Alright I've got yet another licensing question. I decided to utilize the GameStateManagement example that's provided on the XNA website as a framework for my game's state management. I've basically plugged my game into the GameplayScreen object, and tweaked the hell out of every other screen (removed some, tweaked others). But lets say down the line I want to distribute my game. What obligations do I have as far as licensing for these huge chunks of code that I used from Microsoft? Can I just keep the MS branding at the top and add my licensing as well? Can I license it with my own license at all? Wasn't that put out under the Microsoft Permissive License? If so: quote:(A) Copyright Grant- Subject to the terms of this license, including the license conditions and limitations in section 3, each contributor grants you a non-exclusive, worldwide, royalty-free copyright license to reproduce its contribution, prepare derivative works of its contribution, and distribute its contribution or any derivative works that you create. But you should NOT leave any microsoft branding int there, as those are registered Microsoft trademarks, and you haven't been given permission to use them.
|
|
#
¿
Apr 8, 2008 18:45
|
|
|
Nuke Mexico posted:Ah sorry, I mis-interpreted again, then. While on the topic of Dwarf Fortress, is there anywhere he goes over his general approaches to solving certain problems? As a pet project, I was going to work on a very simple game with similar concepts. My approach to the jobs would be to have each category of job (glassmaking, masonry, etc.) have its own priority queue, to manage which job inside that category was the most important. Then, when an actor needs to get a job, he looks at all the priority queues he has access to (say, for example, he doesn't have cheesemaking, he would skip that queue) and grabs the highest priority of the bunch. That seems to work pretty well, but the stl priority queue doesn't seem to have any iterator at all, so getting a complete list of jobs available would require maintaining a separate list of pointers. Although, I'd probably have to do that anyways, because using my system wouldn't allow for 'in progress' jobs to remain in the queue. I guess I could just set their priority to 0 while they are in progress, and restore it to the previous priority if the job fails. Then I could keep it in the queue. (Although I'd have to extend the stl implementation a bit, in which case I might as well write a basic iterator for it.) Anyone know where I could get more information about writing this style of AI? I'm not trying to do anything crazy complex with it, but I am trying to build an easily maintainable, expandable code base.
|
|
#
¿
Apr 25, 2008 02:44
|
|
|
Lank posted:I think that will work well enough to make the game not come to a halt but if characters bunch up for any reason, I'm back at square one with n^2 distance checks per frame where n is the number of players and objects. There have been some good suggestions thus far. (Check out Oct-trees, and other space partitioning.) But also think about time partitioning. Do you really need to update your AI 60 times a second? If your AI only updated 30, 15, 10, or even 6 times a second, would you really be able to tell? (My guess is no.) You probably have either a factory or a manager class that is creating or handling these AIs. Basically what you want to do is create a counter in the factory or manager so that you only update each AI every n frames. Try to keep the AIs spread out so that you aren't doing all the updates in one frame. It's simple, but it will net you a nice boost in frames. It's no substitute for a proper space partitioning algorithm, but it'll buy you a little improvement. Another way to improve this is to build a system that doesn't rely on the Ai agents to perceive everything, but rather have the sensory inputs tell the AI agents about themselves. Food then tells the agents, "I am food!" and the agents can do what it will with that information. (I'd build a bit field of the possible stimuli, that way you can prevent a lot of lengthy distance calculations by eliminating things the agent can't even respond to.)
|
|
#
¿
May 3, 2008 17:12
|
|
|
Lank posted:Thanks for the great advice. I've got a few comments on it: Every entity has an Update(GameTime gameTime) function. I update their movements, and their animations, etc, as fast as possible. In that entity there is also an int representing the number of passes before I calculate their 'think' again. When this counter reaches zero, I call Think() and set the counter back to 10. (Use a const for this, so it is easy to change later.) What I did (because I had no teams in my game) was to create a static variable in my entity called 'offset', which started at 0, and went up to 9. Every time I created an entity, I added the current offset to their first thinking counter. So the first entity would wait 10, then 10, etc, then the second would wait 11 for his first think, then 10 every one after, the third would wait 12, etc... (Does this make sense?) Every frame I also did offset = offset % FRAMES_PER_THINK; This way, offset was always between 0 and 9. What did you need to know about XNA game time? It's a little confusing, but what you probably want is gametime.ElapsedGameTime.TotalSeconds (I think) that will give you the number of seconds -- full and fractional -- since the last Update(). quote:Objects holding the info: I read about this style from the very start of this project and I think I'm executing it correctly. I have my objects store their value, their danger, what they can accomplish etc so the agent says "well there's gold to my left and a huge guy with a mace on my right....I'm running towards the gold." The issue I ran into was simply the distance calculations. I needed to know whether the object was allowed to tell the agent what it was and have the agent react or not. But I think I solved that.... Are you familiar with bit fields? Or the [Flags] attribute? I don't know if this is applicable in your game, but say your character responds to food, gold, and enemies, but not beer. You can create an enum that looks like: code:Then, before you make any expensive distance calculations, you can make a quick check that is basically free on the CPU: code:quote:It was stupid of me to think that a perfect radius of awareness was necessary. I just made a "cardboard box flattened out" shape around the player with the bounding boxes of the largest square that would fit inside the circle of awareness and the smallest square that would fit on the outside of it. No distance checking, just a few inequalities. I should have thought of it from the beginning but I thought I'd throw it up to show how to save a TON of time and still have an approximate circle of awareness. I'm sure I could add a few more squares to approximate the circle even more but this was a good place to start. If you are using the distance squared approach, you are only using a few multiplies and a comparison. It really isn't that expensive. It is usually better to try and eliminate comparisons before any sort of collision algorithm is called. In the game I'm working on, in addition to the flags, I assign each stimulus a priority. Once I've found at least one stimulus in range, I'll record its priority. Then, I can use that to eliminate distance calculations. If any subsequent stimulus is lower priority than the one I've already found, don't bother checking if it is close or not. Anyways, I hope that helps you speed some things up. If you have any XNA questions, let me know. I'm no expert, but I've worked with it quite a bit.
|
|
#
¿
May 6, 2008 03:09
|
|
|
Lank posted:Wow. That definitely gives me a lot to digest for a while now and tinker with. Hey, just glad I could help. I wish someone had pointed these things out to me when I had started. (You should see my first pong... Man, what a nightmare.) Edit: I'm working on a project and I'm trying to get a handle on pathfinding. The game has a similar view to, say, Black and White. You are far above the terrain, you can place buildings, and there are little mans running all over. That's about all there is to it right now. But the mans are free to run up extreme slopes and through buildings. My goal: Stop the mans from running through buildings. Be able to paint areas of geometry as impassible. Be able to send the mans to specific points (ie, building entrances) and have them navigate around things like lakes. I'm trying to figure out the best to handle doing this. My first idea was to create a grid of A* nodes across the whole terrain, but the terrain could potentially become very, very large. (I'm using Ogre's Paging Scene Manager.) My next idea was that maybe I could just place the nodes around inaccessable areas. Does that seem like a reasonable approach? But when I place another building, I'll have to invalidate some edges, add some nodes, and add some edges. Can anyone point me to some good resources on getting started with this stuff. The book I've got has plenty of resources on how to improve an existing A* implementation. (Heck, I'm not even sure A* is what I want/need!) But it has very little information on actually building the node graph. Pfhreak fucked around with this message at 16:47 on May 8, 2008 |
|
#
¿
May 8, 2008 02:39
|
|
Thanks for taking the time to explain that stuff. I'll definitely check out flags (I've got the big old Oreilly C# bible at home) and play around with them.
|
Lank posted:Maybe I can return the favor here. Just curious, but why does every object need to be able to query every other object? Or rather, why does an object iterate over an array to find the object it needs? Perhaps you should build some sort of agent/actor/entity manager that maintains Dictionary<string, Dude>. Dictionary (like the STL map) is basically the bestest thing ever. Very fast (think constant time lookups), and wonderfully easy to use. Then, you could implement methods in the manager to get the information you need. Like, lookup by string, lookup by distance, etc. Then you only ever have to store the information once, and never need to pass it anywhere. It provides a common interface among your classes, and reduces coupling. (Not sure your level here.) Coupling is where classes are reliant on other classes. Let's say you've got DudeA, DudeB, and EnemyA. If DudeA needs to be able to call DudeB.SomeMethod, and EnemyA.OtherMethod, you can't compile without those other objects. And when you change those other objects, bad things might happen to DudeA, he may need rewriting. Coupling leads to spaghetti code. If you centralize communications between your entities, you always maintain the exact same interface between things. Now, instead of having to make queries all over the place, you have a central repo for your information. Also, you can have your manager class do things like update all the active Agents. It can also be used to ferry information between Agents. Building a messaging system into a centralized class like this makes adding new types of agents a snap, although it requires you have a pretty solid understanding of polymorphism. If you don't know what that means, let me know, it is basically the most important thing you can know. I'll check out that A* tutorial tonight, see if it helps me out.
|
|
#
¿
May 9, 2008 04:22
|
|
|
Vinlaen posted:I'm still trying to create my 2D Worms game and still having trouble... (yes, I'm stupid or something). This was discussed back on page seven but I'd like to bring it back up in case anybody has any new ideas. The suggestions given to me before I didn't quite understand (eg. using a mesh for the 2D terrain deformation, etc)... I'm going to take a stab in the dark here, because I'm not sure if this solution would work, buuuut, couldn't you build a big 2 dimensional array, 1920x1200, and store bits in it? 1 for visible/collideable and 0 for not? Then, you can break up your giant level texture into smaller pieces, and use the bit field to determine whether that section of the level should be drawn? Also, you could only send the visible pieces of the large texture to the video card. Keep them loaded and ready to go, but only draw them when they are in the frustrum of the player's camera. quote:Ok, I just read your first question again. I'm not iterating through an array just to find something, I need to know, for player A, his distance to player B, player B's perceived strength, player B's health, then the same for player C, then D etc for all the other players. The think() method for each player isn't just "Attack closest player" or anything. the whole point of the game is to experiment with a complex AI so each player needs to interact with the others a ton. Ah, I see now. Your player will respond to whatever has the highest priority, where priority is some value derived from a complex function that considers things like distance, enemy health, enemy strength, player's current status, etc? In that case, you'll just need a List<> and a foreach(Player curPlayer in PlayerList). You'll have to go through each one, and try to use inexpensive eliminations before expensive ones. (Check things like, "Are we on the same team?" first, and "How far away are you?" later. But I think you already knew that.)
|
|
#
¿
May 10, 2008 01:27
|
|
|
tyrelhill posted:I'm starting some research for a project I start in a few months and want to ask a few questions here about some good sources. By now, of course, you have the Design Patterns book by the gang of four? I've found the composite pattern to be unbelievably useful. Especially combined with the command pattern. Most of my experience is with that book, so if you had some more specific resources, I'd love to see them.
|
|
#
¿
May 15, 2008 06:10
|
|
|
MasterSlowPoke posted:I don't know of anything out-of-the-box that does that, but for an XNA networking library I've heard of a lot of people using Lidgren. Holy crap, this looks like a slick library. I'll have to play with this and possibly tear out all the networking garbage I've written.
|
|
#
¿
Jul 31, 2008 14:49
|
|
|
Here's a stumper of a procedural question: Let's say I have a texture, any texture, and I want it to have depth in my game. Nothing complicated, just a cardboard cutout-esque amount of depth. Think paper mario (actually, they were 2 d, think the background pieces in paper mario.) The first way I thought of doing it would be to use the marching squares algorithm to create a perimeter, then tesellate that, then build the polys, but that seems overkill. I'd imagine there has to be a way to do this with a shader, but my shader-fu is weak.
|
|
#
¿
Sep 6, 2008 06:01
|
|
|
To clarify: I know that a billboarded sprite has no depth, if you look at it side-on it disappears. Let's call that analogous to a sheet of paper. What I want is to have it appear like a piece of cardboard. Like the texture was simply extruded to a certain depth. So, when you look at it side on, it still has a flat face with the texture, but also a 'side'. The best way I can think of to do this is to use the output from marching squares to build a trianglestrip representing the side, then billboard the actual sprite on the top of that.
|
|
#
¿
Sep 7, 2008 18:20
|
|
|
Kimani posted:Recommending dual-core or better, it seemed to chug when I set the affinity to one core. You know this was chugging because massively threaded things are generally considered a bad idea? Remember that the processor has some overhead in switching between threads, which isn't a big deal for a small number of threads. But once you have many threads, the amount of time dedicated to context switching can increase over the time dedicated to actually running your program. Maybe some day this will become the way we do things once everyone has multicore systems, but rest assured, everyone who has ever played with threads has thought, "What if I put everything in it's own thread." One current solution is generally to thread systems, not individual entities, so rather than 1 thread per bullet, lump all the bullets into a thread. The AI into a thread, the drawing in a thread, etc.
|
|
#
¿
Sep 14, 2008 17:04
|
|
|
stromdotcom posted:I've been playing with Farseer for a couple days now and I dig it, but drat someone needs to document the thing. I believe it is a port of an old version of Box2D. We used it for our game dev project, but it turned out to have lots of trouble with the more complex things we wanted to do.
|
|
#
¿
Oct 14, 2008 02:09
|
|
|
Our game dev club tried XP. Turns out we vested ourselves highly in the Magpie paradigm. ("Oooh! Shiny! Want!") We thought we could control the flow of things as they were assembled, but it was a disaster. We had a super basic engine running. It was neat, and also totally unmaintainable. Now, we are using an iterative approach. We figured out what our big targets were, starting with sending messages over a network. We completely ignore later iterations until we finish the current one. Each iteration starts by examining what we want to do: Send messages, serialize an object, etc. Then we design the interfaces. We do several 'dry runs' to review and fix our interfaces. After they are complete, and only then, do we start thinking about pseudocode. Then we build prototypes, and if everything goes well, we refine (by discarding and rewriting) those prototypes. Starting with code is a bad idea. A really bad idea. In fact, the code should only be about 15% of the work you do, the rest should really be design, testing, and analysis. Starting with code or pseduocode WILL cause you trouble in the future.
|
|
#
¿
Nov 15, 2008 02:41
|
|
|
Mithaldu posted:You're making a logical fallacy there. Sorry, you are totally right. I wasn't clear enough. When I said don't start with code, I forgot to mention that it is perfectly acceptable to write code as part of a prototype to inform the design stage, or as a training mechanism. But I think that to jump into actual project code first is going to give you trouble later. Also, I think you are right, we were really undisciplined at first. One of our members thought he understood XP, and he was an idiot. The moral of the story, I guess, was more that you should understand the discipline required for any process before jumping in.
|
|
#
¿
Nov 15, 2008 19:08
|
|
" It however only means: "Don't try to design EVERYTHING at once up-front."
|
quote:It depends entirely and completely on your level of experience with the language and your tools, nothing else. I'd say there are other factors here too including the complexity of the program you are writing, the number of people you are working with, the span of time you plan to maintain the project. Part of my experience comes from working on projects with 8 programmers, which is probably coloring the way I do things considerably. Each programmer might have a slightly different idea of how objects send messages, or how we serialize things over the network, and it can rapidly become chaos as they implement their own solutions to the problems they are encountering. I agree that if you need to crack open UML for your personal projects, you are probably over thinking things. But if you are writing a networked game with client/server interactions, scripting, or any complex drawing, it is probably to your advantage to spend the time in Visio, critically thinking over the design. Once again, you guys are right. In projects where you can forsee the whole of the game in your head, and view the control flow in your head comfortably, producing work artifacts is something of an academic exercise. But you didn't really skip the design, you actually participated in the process, you just didn't need to write it down. I don't advocate design for design's sake, but if the design teaches you something, then it was probably a valuable exercise. If you don't learn anything you didn't already know, then yeah, it was a waste of time.
|
|
#
¿
Nov 15, 2008 22:14
|
|
|
not a dinosaur posted:Python kicks all kinds of rear end. I just started learning it last Wednesday and I am already sitting on a functional 2D game engine with continuous collision detection. I'm getting a pretty good frame rate already, and when I move the collision detection into C/C++, it's only going to get better. I just can't get into python. I grapple with the concept of significant whitespace, and something about it just irks me. Although, I come from a background of strongly typed languages, fancy IDEs, and strict OO design, so that probably explains it.
|
|
#
¿
Nov 23, 2008 09:33
|
|
|
While we are on the subject of libraries, what do you guys use? I use: SFML -- Handles Sound, Graphics, Input, and limited TCP. Very easy to set up and use. ( http://www.sfml-dev.org ) Demonstrably faster than SDl in the 2D department. Only a 2D library. RakNet -- UDP networking library that is at once easy to use, and VERY powerful. This guy knows his stuff. ( http://www.jenkinssoftware.com ) Includes support for game lobbies, object replication, auto patching, logging, and a whole bunch on top of their basic UDP handling. CEGUI -- Pretty decent GUI library. Scriptable with lua. ( http://www.cegui.org.uk ) Box2D -- 2D physics library. Never run into problems with it ( http://box2d.org ) As far as I know, it's still being actively developed. With those four libraries, you should have everything you need to write your 2D networked game, without having to worry about the particulars. Oh, and Boost. For things like shared pointers.
|
|
#
¿
Dec 1, 2008 20:51
|
|
|
Peao posted:For anyone interested in free 2D art to use in their games, the Tyrian artist has a couple of cool packages, including all the Tyrian ships. This is a wonderful resource. I'm reading through some of his other slides right now on a presentation he gave, and they are full of good information.
|
|
#
¿
Dec 6, 2008 18:35
|
|
|
Mustach posted:I wonder how Little Big Planet does synchronization. Almost every game object is a "gameplay-affecting physics object." Sometimes the online experience is awfully laggy, however. LBP is essentially a 2d game, right? I mean, the models are 3d for sure, but you don't really interact with the depth of the game. Seems like 2D physics are a whole mess more straightforward than 3D physics.
|
|
#
¿
Dec 7, 2008 19:45
|
|
|
tbradshaw posted:Fair, an alternative: http://www.youtube.com/watch?v=Z8HkbqEGSic&feature=related To be honest, this behaves as if there was no 3rd dimension.
|
|
#
¿
Dec 8, 2008 17:17
|
|
|
brian posted:The other (and in my experience easier to work with) system to use "has-a" over "is-a" as in, an entity has a pointer/reference to a renderable object that can render itself, which means it'll cut down dramatically on both code and memory redundancy when the vast majority of your entities use the same mesh/plane/textures etc. It also allows you to be a bit more black-boxy when it comes to platform implementationy stuff like graphics libraries, since all your rendering code is contained in the rendering/scenegraph files of your code. I was coming here to post exactly this. I believe that an IDrawable interface is generally a mistake. Here's a rough idea of how I usually set myself up: Every object has one or more drawable pointer objects (I usually call them Sprite). In the object's constructor, I get values for those pointers from SpriteFactory.GetSprite(name, params, etc.) My objects don't have a draw method at all, instead, when the factory fills a request for a new sprite object, it also registers that object with the drawing manager. The drawing manager maintains a list (or map, or whatever it needs) to draw its sprites in order. That way, my game objects don't have to implement Draw(). And my main game loop can just contain DrawingManager.Draw(deltaTime). It's very clean once it's up an running.
|
|
#
¿
Jan 12, 2009 17:50
|
|
|
jonus posted:I want to create a highly accurate colony simulator where the player develops a frozen world using only renewable energy as a power source. A territorial map would be used for placing mines, power plants, rail and power lines over great distances, while a rts/fps view would be used for colony construction. Rather then a series of connected buildings like most rts, each colony would be an arcology, a self-contained city built to minimize heat loss. As much as I want to avoid graphics, being able to walk through the arcology would be the primary pay-off for actually succeeding at the game. I've always wanted to make this game too, but the design overhead is staggering. Every time I sit down to write this game, I inevitably lose focus, jump iterations, and crash and burn when Ogre or XNA doesn't behave quite right. I've settled for making a much smaller game that I'll actually complete (and I'm nearly at an alpha build after only 2 weeks). What sort of game projects have you completed in the past? Because if the answer is none, or the answer is "a couple, but I can't show them off here..." then there's a strong chance this project is simply too big right now. Believe me, I want this game as much, or more than you do. I'd love to write it some day, but the amount of work that would go into it, especially if you are doing it in 3D cannot be understated.
|
|
#
¿
Feb 5, 2009 22:19
|
|
|
Morpheus posted:You're right, but what I think would be better would be for the user to 'shape' the map according to functionality...so to speak. Not just changing some numbers around. Hmmm... Tree structure whose nodes represent building types. Where some room types are composite structures containing other rooms. Each room contains a generate method describing how to set up that room. A cell might insert a bed and a toilet. A prison may insert a random number of cells (which, in turn, generate their own details.) You just work your way up from there, a bedroom contains some furniture, a home contains some bedrooms, some bathrooms, a kitchen. A block contains some homes, a suburb contains some blocks, etc. Seems like a textbook case for the composite pattern. Once the tree is constructed, layout the nodes on your grid, and do some sanity checking. Interesting problem, and absolutely solvable.
|
|
#
¿
Mar 7, 2009 01:15
|
|
|
terminatusx posted:Yeah! also, during the second pass is when you'd add in essential game objects like entrances/exits, stairs, NPCs, quest-related objects etc. That's my guess. You may be able to accomplish that in the initial generation... Good solution though! I'm such a junkie for design patterns that I'd probably build a visitor for doing those sorts of things (and even doing the initial layout.) That way, I could use the same data structure to represent the dungeon in a game agnostic way.
|
|
#
¿
Mar 7, 2009 03:15
|
|
|
A more distilled version would be to say this: The visitor pattern delegates the responsibility of acting on a data structure. Rather than have your binary tree object responsible for printing itself (or, in this case laying itself out on a grid) you create an object that peers into the data structure and does work with the data there. In a binary tree example, the visitor would be able to do a pre-, post-, or in-order traversal of the structure and print some specific piece of data to the screen. In our hypothetical game example, the visitor would traverse our tree and extract the data necessary to populate our grid with our rooms. It's a wonderful way to increase encapsulation in your programs. I'm a huge proponent of more encapsulation. Data objects (in general) are not graphics objects, or sound objects, or physics objects. They are the parameters necessary to create those objects. A 2d room isn't a list of sprites, sounds, and other heavy weight, platform dependent objects, it is a list of abstract qualities that the visitor is responsible for interpreting. Rather than have your data be responsible for presenting itself, you remove the presenting to other objects. A room shouldn't know how to draw itself, it should know what it contains. It's up to the visitor to know how to draw the room. With this, you might build a 2d graphics visitor, and a 3d graphics visitor -- one might traverse your tree to draw the minimap, another to draw the world. It also lets you basically hot swap systems in and out to render your world. It appears to add complexity to a novice coder, until you realize that without it, every node in the tree has to know how to render itself in your game engine -- essentially coupling every node to every subsystem of your game. Edit: Don't know if that was really more distilled... Edit 2: If you haven't already, buy the Gang of Four Design Patterns book. "Design Patterns: Elements of Reusable Object-Oriented Software" by Gamma, Helm, Johnson, and Vlissides. Don't ask why, just buy it. It is the most important book on my shelf. Now, if I could only get out of this current job writing business apps for power (ie, electricity) engineers, and into a game programming job. Pfhreak fucked around with this message at 08:26 on Mar 7, 2009 |
|
#
¿
Mar 7, 2009 08:23
|
|
|
terminatusx posted:But would you say you're better off never learning design patterns? Perhaps it's worthwhile to know of them as long as you can avoid overusing them. This is pretty self-pertinent because I actually know of very few design patterns. Classes I took in programming never got to that depth (Digital Media B.A. woopwoop Now, I won't get behind the singleton pattern. That's one I generally disagree with. It has a very specific niche usage and it is far too often overused. Dentist, I was more attempting to illustrate the usage of the pattern, or where it might be appropriate to use a pattern. Yes, you should always have done your spec work before your design work. But as an intellectual exercise in design, where the spec is, "Create a graph/tree based memory structure responsible for generating a dynamic dungeon where the rooms have meaning and context with one another." I really do think that the patterns here were appropriate usages. Yes that spec sucks, and absolutely you should build some prototypes. I didn't mean to suggest that any of those things aren't true. I think you are selling patterns short to call them all 'hacks'. When was the last time you wrote a real piece of software that didn't use the factory pattern? What network or gui program doesn't use a variant of the chain of responsibility pattern? Ehnus, the idea that over-engineered, under-tested, half-assed applications are somehow the result of the patterns themselves is wrong. That's a problem with the people, not the concepts. Yes, programmers are lazy fucks. That's what we do for a living, write code to make our lives easier and more automated. That design patterns are slow is potentially true in some cases, there's no disputing that. The visitor has many more method calls than just implementing the logic in the data structure, sure. But that inefficiency isn't going to be noticed unless you are writing a AAA big budget game. (Or the rest of your code sucks.) Hell, it's practically mandated that every GUI app these days uses model-view-controller, even though it may not be the most efficient code. Maintainability nearly always trumps efficiency, and good OO design principles are one way to establish clean, maintainable code. Before you flip out, yes there are programmers who over use and under understand the concepts. They construct altars to the GoF in their work places (I work with a guy who literally mumbles "Design patterns... Design patterns... Design patterns" under his breath for hours at a time. I poo poo you not.) Don't look at the book as a Way Things Are, but rather another tool in your repertoire. Just like anything else in software, you have to understand their place. Even globals and gotos have their (admittedly small) use. It's important to know when and where to use them. Edit: I'll admit I probably come from a different sector of the software industry. I write code that regulates and maintains the power grid worldwide. There is a huge emphasis for infallibility and maintainability in our code. If our apps crash, hundreds of thousands of people lose power, and millions of dollars of equipment could be damaged. Because we have a large number of software projects, and we are growing almost 20% a year for the last 10 years, we are constantly bringing new engineers into our projects. It's important that our code base be as clear as possible, because it will need to be maintained for decades. Pfhreak fucked around with this message at 19:22 on Mar 7, 2009 |
|
#
¿
Mar 7, 2009 19:16
|
|
). But one day I discovered a Singleton pattern in some code at work, and after looking it up on wiki, found it to be a pretty useful device for actionscript at least, where it's a convenient way for creating a "controller" that helps all the components communicate w/ eachother.
|
I am writing a simple tile based game using XNA, and I'm looking at improving my render path. My tiles are based off of these: Click here for the full 700x720 image. I'm storing all my tiles in a 2x2 array of Cells (where a cell has all the information about that 'column' of blocks). Right now, I've got, say 2000x2000 cells. Currently, my render path looks like: -- If my cached render is dirty, redraw all my Cells from back to front, left to right. The cells themselves draw from the bottom up. I only draw the cells currently within the viewport. I also cull any blocks that have a block on top of them and in front of them. After the block is drawn, I draw the appropriate shadow on top of the block. There are 101 different possible combinations of the 9 different shadows. For example, a tile can have both a western and eastern shadow. Rather than draw each shadow separately (resulting in up to 4 or file extra calls to Spritebatch.Draw()) I cache combinations of shadows as their own textures. All of this draw is rendered to a rendertarget, and is saved off as a texture, which is then drawn. -- If I haven't moved my camera, or selected a new tile, I just draw the saved cache. This gives me fantastic frame rates. Currently, I am only drawing the blocks, and none of the objects or characters. It's working great so far, keeping acceptable frame rates on my cruddy laptop. But I'm worried about drawing characters who move every frame. Nominally, I would just render each character when I render the cell they are standing on. However, because I do not render my cells every frame to improve performance, I cannot simply draw the character when I draw the cell. So I thought I would just draw all the tiles, then draw all the characters, but that doesn't work either, because the characters can be occluded by the world. My thought was to do a multi-pass render, but I've got very little experience doing something like this. Help me figure out if this process would work: 1.) Render all the block's color (no shadow data) to a texture the size of my viewport. (Call this BlockColor.) 2.) Render the depth of the block to a texture. Render my textures as solids with a color representing their depth. (Call this BlockDepth.) 3.) Render all of my shadows to a texture, using BlockDepth to do my occlusion of the shadows. (Call this ShadowColor.) 4.) Draw BlockColor to the screen. 5.) Draw each character to the screen, using BlockDepth to do my occlusions. (Ie, if a character is halfway behind a block, only draw his upper half.) 6.) Draw ShadowColor to the screen. Note: Steps 1-3 are only done when the camera moves, or blocks are added/removed from the scene. They are expensive, but easily cached. Can this be done? Is this easy to do? Is this the right way to do it? Can you think of any other optimizations to this algorithm? Is there something that does this sort of thing automatically? I'm reading about depth buffers, but I'm still not entirely sure what that is, how they are used,
|
|
#
¿
Apr 4, 2009 01:25
|
|
|
It's on my old rear end laptop, with no video card, and 1 gig of ram for Vista, my video card, and all my other applications. Even then, it runs it pretty solid at 40 frames per second or so when I'm drawing a 40x40 grid. On average, each cell draws ~2-3 blocks and a shadow. So that's 5600 quads roughly, and I don't know how much of a performance hit using managed code brings. I am smart about only drawing the tiles that intersect with my viewable area. (I use a division and a mod to determine this, then just count N cells to the right and down.) I've got plenty of early outs for preventing draws. My desktop runs it fine, but I'm interested in learning some new techniques and ways of organizing things in a more efficient manner. Knowing how to make XNA put a sprite on screen is one thing -- knowing what other tools I have access to is another.
|
|
#
¿
Apr 4, 2009 07:50
|
|
|
|
| # ¿ Apr 27, 2024 18:49 |
|
|
PnP Bios posted:How are you drawing your sprite batch? The biggest hit you can take is when you change textures. The standard method is deferred, which does no sorting, try using textured instead. I'm using immediate mode currently. I have a '3D' world composed of 2d blocks. It looks something like the code posted before. The problem with textured based sorting is that sometimes I'll want to draw my stone texture first, and other times I'll want to draw my dirt texture first -- even within one cell. It completely changes the way I navigate during my draw. That wouldn't be a problem, really, except I tested it with only one texture and didn't see any significant improvement. (1-2 fps.) code:
|
|
#
¿
Apr 8, 2009 05:48
|
|