Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

DevastatioN

Members
  • Content count

    165
  • Joined

  • Last visited

3 Followers

About DevastatioN

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. DevastatioN

    AI research and Doom multiplayer

    Sounds good. I can provide you with all of the games from Quakecon 2013 (between myself, Demonsphere and JKist3) in demo format to view. It's probably good to see a good player against an "average" player too, to gain a sense of how things can go wrong. I'll dig up some historic games over the years. You are stating that everything is done via pixel, are you allowed to use sound? Sound is a major component of DM... if the bot is not allowed to base anything on sound, I doubt it could ever compete properly. It will also need a way of recognizing and knowing the map, for backwards perfect movement, and timing. A good example of timing in DM is the way one moves. There is generally a tradeoff in DM movement, perfect moving (which is fastest) has the least visibility, so if you run into an opponent, you are in a bad spot. Less optimal moving may be slightly slower, but grants the best visibility to be prepared if you run into an enemy. If I know my opponents current location (thought sound or otherwise), and know that they cannot get to a specific location in a set amount of time, one would use perfect tight movement to get there as fast as possible. If a player position is unknown, one would choose the safer movement style. Some of these things may be hard to learn if an episode is an entire game. There are many pieces in a game that can promote good play or bad play. Think about yourself as a gamer. If you get a frag, you generally say "wow I did something good", and if you die you generally think "I did something wrong". Maybe an episode should be at least considered on a frag by frag level. Do more of what gets me frags and do less of what gets me killed. Going more advanced, in human terms, the outcome of many situations is actually a better or worse game state position from a given scenario, even if a frag was not achieved, such as dealing only 20% of damage but receiving 80% of damage. Below is a list of things that every good DM player should be able to do, and some thoughts of how an AI could maybe learn these: Good movement. Computer likes when it moves and does not hit a wall, computer dislikes when it moves and touches a wall. There also needs to be a way that the computer knows the level, so it can run backwards through the level without touching a wall. Fast movement (sr40 and hopefully eventually sr50). Computer detects pixels to gauge it's in game speed. Computer likes when it moves faster, dislikes when it moves slower. I assume eventually the computer would start randomly pressing enough buttons to figure out sr50. Aim. Computer likes when it fires and sees blood splats *OR* hears pain groan (sometimes you hear pain but cannot see it). Computer dislikes when it fires and does not see blood splat or hears pain groan. Computer should be weighted to liking more blood splats, it should eventually pinpoint the proper pixel to fire on for maximum damage, and hopefully understand the distance between players. Damage. As above, the computer can estimate damage based on blood splats and should like seeing more blood splats. This will weight it towards the proper weapons in various scenarios as well. It should know roughly how much damage was dealt in total over various situations, and how much health an enemy has left. Damage balance. This is difficult to describe, but it's knowing to fire at the closest range possible, just before your opponent reloads. The basic premise in doom SSG battles if that you rush in while opponent is reloading, then your shot and then back away when you're reloading. I have no idea how to help an AI learn this, but maybe the above notes on damage will just make it understand. Sounds. The computer needs to be able to pinpoint an exact location of an enemy and their *direction*, given it hears a sound (landing thud, damage, reloading shot, etc.). This requires map knowledge. Enemy timing. Given a location of an enemy against passing time, the computer should know the furthest an enemy could have gone and the likelihood that it can happen. This requires map knowledge and also how fast an enemy generally moves to get from any given location to another location. Opponent state. Computer needs to know weapons an opponent has for sure, weapons opponent likely has, the current ammo an enemy has for rockets and BFG, the enemy's current health. The computer should be varying it's play eventually based on these game states. Respawn whoring. It needs to somehow figure out what optimal place to be when an opponent has just died, it should instantly start moving towards that direction given the known spawn points of the map. It should be varying this based on current state (health, weapons). Those are the basics. If the computer could learn all of those things, it'd be about an average DM player, maybe above average given that it could probably aim perfectly. Going more advanced, it'd need to learn how to manipulate it's own sounds to confuse or trick an opponent, how to guess an opponent's future plays and actions by associating it to previously seen actions, how to vary it's play away from the "best" play at times in order to stay unpredictable, and some other stuff. Are you allowed to throw the AI into different maps for various periods of time to learn specific things? For example, D5M18 would actually teach it much of the aiming and range that it requires to SSG battle properly. You could also throw it into a map of just walls in order to get it to learn movement via not touching a wall and detecting it's speed. It would hopefully learn how to strafe properly and know it's direction and where to go by being able to detect wall vs non-wall. Also, some DM maps are simpler to learn. For example, ssl2 is much more to do with aim, good movement and weapon control and not as much about determining an opponent's position using logic like D5M1 is. Anyhow, hopefully this is of some help and gives you an idea of what you're getting into if you're trying to create a human-beating bot. It also depends on your end goal, do you want it to be an average DM/tournament player? Just be able to beat casual players? Top notch gives the world elite a run for their money?
  2. DevastatioN

    AI research and Doom multiplayer

    Hi sun_stealer, Very interesting project. I'd be interesting in assisting somehow, at the very minimum I can show you how to watch recordings (from the port.... not on Youtube!) and supply you with some great examples. Funny enough, I am a chess player as well as a DM player... and your robots have already crushed us humans in that! Once you've set an AI to learn for so many hours, I'd be interested in seeing some of the recording playbacks and give some feedback on what it has learned, and what it's still clueless on. The interesting thing about reinforcement learning and doom, as opposed to chess, is how it considers scenarios. Is it trying to adjust it's bias towards good things on a game by game basis... a frag by frag basis or a scenario by scenario basis? Are you starting from ground zero of not knowing the controls, or are you starting it on the basis that it understands the controls? Either way, I'd be interested in helping and also potentially playing in a tournament against AIs as you've stated. If you're using classic rules and maps.
  3. DevastatioN

    QuakeCon 2019

    Got a BYOC ticket just in case something good comes this year! There's a good chance I'll be going anyway. Maybe looking for a room mate even!
  4. DevastatioN

    Doom 2 Tournament at QuakeCon

    Oh I definitely want to go, and have for a few years. But it's a very busy year, so the only reason I would go is for a good DooM 2 tournament. So I mean, the announcement of this tournament just makes it so I basically have no choice but to bump every other plans I have, and go. This is why I'm waiting for the announcement. I think other people are waiting as well, as many won't bother going without knowing what the DooM 2 actually is.
  5. DevastatioN

    Doom 2 Tournament at QuakeCon

    That's unfortunate, especially people like me who need to book plane tickets and make arrangements. There's going to be a strong correlation to how late they announce information vs the strength and value of the tournament. Either way, this might not be a BYOC tournament anyway, so we should be good. But I'd rather do more than just play the tournament if I'm at QCon! I'd like to play some Quake, and in the Quake Live Open event if there is one.
  6. DevastatioN

    Doom 2 Tournament at QuakeCon

    I agree that delving into politics was a poor choice, and may end up confusing. There is definitely a lot of research that the organizers need to do in order to make an informed decision. And it's not a light task to do in such a short time. If we're listing credentials, I have played competitive doom since 2001, playing on the natural doom2.exe and learning there. I've played what I believe to be every relevant port (ZDooM, ZDaemon, prboom, Skulltag/Zandronum, Odamex, Chocolate-doom), and have played competitively on Odamex/ZDaemon primarily. I have been involved in running huge big tournaments (ZDDL, And LAN tournaments), and have attended a few internationally attended LAN's in Washington DC and Toronto. As much as I would prefer as a player to see chocolate-doom, as it mimics doom2.exe perfectly and the experience will be the same, I do agree with Ralphis. It will make it more difficult for those players not familliar with doom. Similar to this approach is simply describing how to run DOSbox and doom2.exe v1.91 over LAN. This will also cause confusion for people not familliar with doom however. The next best client/server options that are heavily populated, and would be familliar to all players based on server list, scoreboard etc. are ZDaemon, Odamex and Zandronum. I believe Zandronum should be taken out of that equation for the simple reason that if you're looking for a doom tournament, you want a port that can actually play doom as closely as possible to the original. Both Odamex and ZDaemon have features/flags that can make it true to the original gameplay, unfortunately Zandronum does not have this. Zandronum's core physics have been manipulated over time, to the point where even on it's closest settings it will be different and "off". So it comes down to Odamex and ZDaemon (remember this is my opinion!). I cannot make an informed decision on which should be used. I have not played Odamex on LAN, where I have played an older version of ZDaemon on LAN. Odamex can play doom2.exe demos perfectly, displaying the correctness of the physics/features. ZDaemon has been more heavily populated over the past 10 years, Odamex is new on the port scene. Successful competitive tournaments, with very high level play has been played on both Odamex and ZDaemon. I hope this post brings more to the table in order for Quakecon to make an informed decision on how to run their tournament. I try to not be biased in my post by politics. Good luck to Quakecon, it'll be fun, and I look forward to attending.
  7. DevastatioN

    Doom 2 Tournament at QuakeCon

    That's a great write-up by Alexmax. And a good map-pool too. As was stated by JKist and Ralphis, the platforms that mimic real classic doom to the highest level are generally Odamex and ZDaemon. They have newer features to help with playing like callvote etc, while not effecting gameplay. Chocolate-doom is another interesting option, which mimics doom2.exe perfectly, but unfortunately doesn't have good features for spectating/callvoting last I checked. I think Odamex would be a great option for a competitive LAN tournament. I must admit I am a bit concerned, if there is going to be a doom tournament with reasonable settings/gamemode etc. I will 100% be travelling there from Canada. But being so close to the tournament date, with no details announced, and the BYOC already sold-out it seems, what options are there? I see the site says that normally all walk-ins can find a seat, but is this always the case? You're running a tournament that most likely has generated more interest from top doom players than you expected, many players from around the world are now ready to travel for this tournament. It's a great thing in my eyes that you've not forgotten about DooM, and hopefully all this interest shows how serious the community is about participating in a great tournament, even though the game is 20 years old.
  8. DevastatioN

    Doom 2 Tournament at QuakeCon

    I live in Canada, and am highly considering going depending on the information that comes out. Which version, vanilla/port, which maps, is it duel etc. are some important questions to be answered. I would definitely like to book my flights as early as possible.
  9. DevastatioN

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    Hey, Thanks very much for doing so much research into this. I just tried -directx today for odamex, and do not appear to have any issue. It's clear without -directx I do have an issue though. If there's anything I can do to help you test let me know.
  10. DevastatioN

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    The interesting thing is that this is happening on multiple machines and to different people, some with Logitech drivers and some with windows drivers. So far there seems to be no coherent rhyme or reason as to why. I will check with the others, but I'm pretty sure it's the same consistent ports (Prboom, Odamex) with the issue. It'd be nice to have a whole bunch of people with MX510 and different drivers to test this as well. I have not yet tried on my 3rd or 4th machines that do not use a logitech mouse, nor have I tried under a Win98 box. It'd be interesting to see the ports that don't work, merged with the mousecode of an engine that does work just to see the results.
  11. DevastatioN

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    Nothing in the registry seems to have anything to do with mouse deceleration, and it's only on certain ports that use SDL.dll. I am testing under WindowsXP, I have this issue on two machines confirmed, and a few other people are having the same issues as well. It appears to be an issue between SDL.dll and Logitech mice specifically, however there are ports with SDL.dll that work. So I assume something in the code is getting wonky on certain points on how they render the data from SDL.dll.
  12. DevastatioN

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    I have just tried the version of Remood remood_r1093-win32_mingw32.7z from the website, and I do have the same issue. I tried using the SDL.dll which is working in chocolate doom with Remood, and I still have the same issue. I have the same issue in Prboom+.
  13. DevastatioN

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    I guess I should be clearer... I definitely do not want mouse deceleraion, as it makes no sense to have it. I actually don't even want acceleration, as I havent used that in about 2 years now. Unfortunately Odamex and Prboom are giving me this mouse deceleration, which makese these ports unplayable for me. I always play FPS capped at 35FPS, but this would be a smoothness issue not a mouse issue. The issue is, I want 5cm to do a 180 degree turn no matter how fast I move the mouse (no acceleration, no deceleration just a flat rate which is general). If I move my mouse twice as fast, I'll do half the distance. I've gotten to the point where I move the mouse my entire mousepad extremely quick, it'll do virtually no movement at all. It works in all other ports fine.
  14. So I am having an issue with mouse deceleration in Odamex and Prboom, I currently have it working under Chocolatedoom and Eternity Engine. (Mouse deceleration is the opposite of acceleration, the faster you move the mouse, the less you turn.) Since all 4 ports use SDL.dll, I'm have not many places to look for these issues. I've tried many different settings in most of these ports, and Odamex I've tried literally every combination with the staff members to fix this problem. For information, I have 3 copies of ChocolateDoom, one with an SDL.dll from February 13, 2006, the second with an SDL.dll from June 27, 2006, and a third with SDL.dll from December 10, 2008. All versions of chocolate doom work fine with the mouse now. I have some version of prboom with SDL.dll from December 10, 2008, and Prboom 2.5.0 with SDL.dll from December 30, 2007. Neither version of prboom works correctly and I get mouse deceleration. I have tried all other versions of SDL.dll from chocolatedoom and other places I could find them, and the problem still persists. I have tried Odamex with all versions of SDL.dll from chocolatedoom, prboom, and anywhere else and the problem persists. I have Eternity Engine 3.37.00 with the SDL.dll from December 27, 2009 and it works fine. I have tried a few other of the SDL.dll's and they appear to also work fine. I have a logitech mouse and Mouseware... I have a second PC with a logitech mouse and no drivers, just the normal windows drivers and it experiences the same issues. Anyone have any information on this, or has the same issue?
  15. DevastatioN

    Dylan 'Toke' McIntosh, R.I.P.

    Rest in Peace, my dear friend. I had first met Toke when I started DooMing in 2001, he was a very supportive and bright person, always willing to help in anyway he could. He is to this date, the BEST mapper I have ever known, I was always amazed at what he could do, and what he knew. More importantly, Toke was an extremely good friend, I had the honor of meeting him at a LAN in Washington DC, 2003. He was extremely friendly and supportive in person as well, and the time I spent with him was amazing. Toke will always be in the hearts of every person he touched, he should never be forgotten. Rest in Peace, my dear friend...
×