• Content count

  • Joined

  • Last visited

Community Reputation

100 Neutral

About ronkfist

  • Rank
  1. Quote:Original post by ViLiO Quote:Original post by ronkfist hmm i guess our interpretation of "decent" kinda differs :p I'm impressed, you managed to play them all and give us your expert opinion in such a short period of time. How very "decent" of you [rolleyes] Considering all but one of them are being made by indies, they are VERY decent and a few are at commercial level. Also, that is a only a small list that the Z-Man has compiled and are really only meant to be Managed DirectX games (although Arena wars is Managed OpenGL) so there are almost definitely a lot more out there (even a few have been made for contests on this very site). Your right. I just didnt find what I was looking for. Quote:Original post by smitty1276 Of course, ronkfist misses the point. C#'s lack of use in the game industry to date is not at all relevant to this conversation. This conversation regards speculation that XNA may be a catalyst for a large increase in the use of C# for games. Since XNA has not yet even released, any discussion of C#'s history is largely off topic, and is meant to shift the conversation to a more flame-bait oriented topic. It has never before been possible to write games in C# and execute them on the XB360. Period. Let go of the past. Well I'm not sure, you might wanna read the OP his questions again. By reading his 2 questions I assume he is aiming for a job in the game industry and is afraid to miss the boat if he doesnt learn C# and XNA asap. This had led me to try and find out why the game industry is still mainly using C/C++ after roughly 15 years of managed environments (lets not forget .NET is not the only managed framework) and why they would suddenly change their mind coz of this XNA framework. I suggest you(OP) take a look at the job page of different game companies and check out what they are looking for.
  2. Database vs. Files ?

    You can write different implementations as stated before and pick one at startup. You can use the same interface in different applications, the game, website, editors and so on. It's easier to maintain... Lets say you write a function "Player getPlayer(unsigned id)" and use it 100 times throughout your game code its much easier than writing the explicit sql statement and having to handle the query results each time. What if you have to change the way you execute a query or handle query results differently for whatever reason? Without an interface youd have to change your code 100 times instead of one change in the interface implementation and nothing in the "business" logic. As long as you have a small game its not such a big issue, but when it becomes big it will become a problem.
  3. hmm i guess our interpretation of "decent" kinda differs :p btw, managed languages have taken over business applications industry a long time ago, theres a reason why it hasnt happened to the game industry yet, despite all MS their efforts.
  4. Don't let them crack your game!!

    Quote:Original post by Anonymous Poster The 'spotchecks' would do CRC on random subranges of the EXEs code (so not to be too big a CPU pig and to force the hacker to maintain a full set of the original EXE). The subrange would be sent as params of the 'event'. The 'spotchecks' also modify the CRC code itself (like skip patterns, xor masks etc..) and would also frequently include the CRC code as part of whats being checked -- forcing the hackers emulator to have to run exactly the same logic sequence for the CRC scan to return the correct value. How about having the exe image in a seperate memory block. Everytime you send a spotcheck event, it checks the fake image. If the spotcheck algorithm changes it is also changed in the fake image. Whatever you do, the result of a spotcheck will be there up for grabs when its ready to be send and thats when you can manipulate it. Quote:Original post by Anonymous Poster The 'time' limit to do this (to mod code and run CRC immediately) placed in a linear msgs stream (multiple msgs aggregated in packets) would then detect the delay that the hackers emulator would incur. The only thing you can measure is a full RTT. There would be no way telling wether the delay is caused by network latency, emulator latency or a slow pc. Quote:Original post by Anonymous Poster The emulator is forced to be slower in executing this than the valid EXE would be (cross process memory access, packet interception, running the patched CRC logic and stuffing the result into packets (which then have to be encrypted using patched encryption code). Who says they would need or be running an emulator? If you base your anti cheat solutions on certain cheating methods you make the same mistake as the current anti cheating solutions being used today. Quote:Original post by Anonymous Poster Other cute things like substituting packet encryption XOR masks and soing simultaneous 'spotchecks' on client threads (if it has multiple threads) to increase the diffuculty for an emulator, shell game of patched jump addresses to force more complex emulator logic.... Don't forget if you change the packet encryption you have to do it serverside too, else client and server wont be able to communicate anymore. And then again it would be a matter of getting the algo from the packet, placing it in the fake image and execute it when needed. Quote:Original post by Anonymous Poster Ontop of that recompile major sections of the client exe frequently (daily patches) to force the hacker to have to manually rebuild his emulator. Which would in turn render all previously written patches useless, not only that but your patch writers would have to start from scratch everyday. To achieve your solutions you would need an enormous team of patch writers to write huge blocks of machine code everyday(maybe even 1 patch writer per player playing the game). All these patches would need to be tested because they are written manually... So in the end I don't think its a realistic solution.
  5. Quote:Original post by smitty1276 Quote:Original post by ronkfist .NET has been out for what 4-5 years now? Can anybody point me to a decent game created in .NET? I think you may be a bit confused. The XNA framework--which we are talking about here--hasn't even been publically released in beta yet. The XNA framework is based off of the .NET framework, hence my question.
  6. .NET has been out for what 4-5 years now? Can anybody point me to a decent game created in .NET?
  7. Beginning cross platform development

    I'm pretty much on the same boat, at the moment developping my engine for windows but planning to port it to other platforms. Its using OpenGL and I'm gonna use preprocessor tags for porting. Its probably gonna take some time cause I know almost nothing about linux programming.
  8. Database vs. Files ?

    Dont forget the point of having these interfaces is to be able to have different storage implementations or even different database implementations coz each dbms has its own sql dialect and features. Like Hplus said, you could go with a file implementation and if that doesnt do it anymore write a database implementation for your interfaces. btw I've used MySQL++ with MySQL obviously, I didnt like it all that much but it's pretty straightforward. Check out something like the DAO model to get an idea of how to interface between a storage and your game logic.
  9. Don't let them crack your game!!

    What would stop someone from sending back fake CRC checks?
  10. Sony has recently obtained a license for the Unreal3 engine which they will most probably use in their next games. As long as the big commercial engines don't switch to managed languages I dont think it will have much success for game development and I don't see that happen any time soon, if ever.
  11. Game Design OOP

    hmm why do you put CSystem in CWorldmanager? Id suggest make CSystem a static class (after all your only gonna have 1 main loop). CSystem would have all kinds of static functionality, a time function, a sleep function and so on. Don't try to inherit too much, its a mistake many ppl make when starting OOP. Here are some old but still interesting aricles Object Mentor, take a look at the "Patterns" and "Object Oriented Design" sections.
  12. Don't let them crack your game!!

    Quote:Original post by rck Quote:Original post by ronkfistSo? The database of an online game is also on a server machine and after a while it becomes more valuable than the games source code. What would be most devastating, WoW losing its client source(the graphics engine could be a separate module which is precompiled) or losing its database with 5 million+ subscribers? It doesnt neccesarily have to be on the game server, youd have separate servers just to compile.A database has backups, once client code is out there, it's out there. Chances are those are somewhere in the server hiearchy. My point was, if you dont know how to secure a server you shouldnt host games. Game server software is on the machine you connect to, if someone gets that they can start hosting illegal servers...
  13. The connection or kind of server your game is gonna run on is unimportant in development time. Your game will probably start with a few players and will slowly expand, once your server is not capable to handle it anymore you will need consider a stronger server or connection. And if 1 server doesnt do it anymore you will need several machines to host your maps. The question is hard to answer, it all depends how big your maps are going to be. If your maps grow really big you will probably want some space partitioning like a quadtree or oldstyle with a raster. They are not only interesting for deciding what info to send to which players but also for collision detection, texture loading and more.
  14. game network architecture

    hmm its not really clear to me what kind of help you want. Try taking a look at raknet, on the main page there is a doxygen manual which makes it easier to view the overall structure of it.
  15. Don't let them crack your game!!

    Quote:Original post by caesar4 or another idea: each time the user comp downloads the game dll, your download server could change a couple bytes in the dll, say the value of some const int somewhere in the code, then the client sends that value along with a CRC of the changed game file to the server for authentication That would be easy to crack :) I don't really see how DLL's can offer benefits. First of all only windows uses DLL's so ud have to create different protection methods for other systems. You need to load your DLL somewhere which makes it possible to hook the exported functions. The DLL loader in the article constructs a DLL structure in memory, so its just a matter of dumping that memory to disk and you have the DLL. Then you replace the part where it constructs the DLL with LoadLibrary() and load the DLL you saved to disk. If the DLL exports functions like "encrypt(char *data, ....)" you don't even need to do all that. You can add code to the exe as you wish and call the encrypt function wherever you want.