Jump to content
  • Advertisement

Dan DAMAN

Member
  • Content Count

    55
  • Joined

  • Last visited

Community Reputation

126 Neutral

About Dan DAMAN

  • Rank
    Member

Personal Information

  • Role
    Programmer
    Quality Assurance
  • Interests
    Design
    Programming
    QA

Social

  • Twitter
    @ds2001man

Recent Profile Visitors

1861 profile views
  1. Dan DAMAN

    How to avoid bugs

    I find the best way to prevent bugs is to write code that's easy to understand. Do what you can to make your intentions obvious through your code. Whatever you can't make obvious document via comments. Short term this helps prevent bugs since you can "gut check" your code to see if it's doing the right thing more easily. In team situations it makes the code easier to review as well. Most bugs IME are due to simple oversights when writing up code. The harder you have to work to "get" the code the more likely you are to miss a detail which leads to a bug. Longer term when you go back to revisit old code simple code helps even more. The more easily you can figure out what you were trying to do the less likely you are to add new bugs or bring back old bugs. A few suggestions Code small features one at a time, don't do too much at once. Work out how you want your small feature to work before you write it. Source control gives you a nice way to undo your changes and start over if you're completely stumped. Keep your functions short with few arguments. Keep your functions independent of each other whenever possible. Functions calling each other is fine but having something like prepareFoo then doFoo is more likely to lead to bugs since you could forget to call prepareFoo or make other mistakes. Avoid having widely shared data that can be modified in many places (e.g. global variables, singletons etc.) Avoid duplication of code. Fixing a bug once is enough work. Fixing lots of the same bug is an exercise in frustration. Fail hard and loud on unacceptable program data. The quicker a bug leads to a catastrophic event the easier it is to find and fix. This is what can go wrong if you don't throw up huge error messages or outright crash on bad input: https://arstechnica.com/gaming/2018/07/a-years-old-one-letter-typo-led-to-aliens-colonial-marines-awful-ai/ As other posters have said, you will get bugs still, but simpler code should make them easier to find and fix.
  2. Instead of wrapping in one piece the GDNet+ tag is being broken up into individual letters. I'm assuming that would only happen if it's jammed right up against the far right of the panel. I'm using Pale Moon Version: 27.9.4 (32 bit)
  3. Dan DAMAN

    AI vs AI playtests for game balance

    That's pretty much what I'm aiming for. What I'm hoping to get out of the data is indications of things being really out of whack, like a part combination with an extreme win/loss ratio in either direction and/or matchups with extreme win/loss ratios. I'd then have real players try those and a random selection of "balanced" matchups as a control. I've found a few papers of interest such as https://www.cc.gatech.edu/~riedl/pubs/zook-fdg14.pdf and https://www.researchgate.net/publication/323296721_Automated_Playtesting_with_Procedural_Personas_with_Evolved_Heuristics Are there some other good ones you can think of? Less formal articles are also good. Thanks for the info so far
  4. Dan DAMAN

    MoLoGa Jam

    Development progress images from the K-W Month Long Game Jam
  5. As you may have noticed it's not February anymore. It is, in fact, many many months after February. I've not abandoned the jam, the project is, as far as the jam is concerned, finished. The final week was dedicated entirely to game content and pretty visuals. First step for that was UV mapping. I hate UV mapping, but this one didn't go too badly. At least in Blender it tends to go more painlessly if you unwrap small portions of a model at a time. The default unwrapping behavior tends to produce awful maps when working with non organic models like, well, everything in this game. Here's the result; you can also see the final explosion artwork here. In order to keep the amount of effort necessary to a minimum I tried to keep the art using a very simple style with big blocks of simple colors. By having the object be relatively shiny the models appear less flat. You can also see the arena is partially textured here. The most important part of any bullet hell game! (well, besides cool patterns and good mechanics) High score table! Input is arcade-style. Select a letter, push it, and it's added to the name. The final pieces of work to complete were UI polishing and getting the enemies to look nice. Since the enemies were deliberately made of simple cubes put together this simply meant making some decent looking materials and assigning them to the enemy models. Since I forgot to take screenshots of the final jam build I'll put up a couple shots from shortly after the jam. And the title screen. In the original build this was against a plain black background. Overall both me and my partner in crime were pretty satisfied with this one. Though we didn't win any "prizes" during demo day I feel this project was a pretty solid success since we managed to throw together a pretty solid FPS. The game's not been released yet due to a lack of content and some unpolished aspects. I'd like us to have a full set of six levels before release. It's also still too easy to get killed in an unfair way which I'd like to reduce. I've already got some simple additions to put into the game to make things fairer but they'll be for later devlogs. Some Guesstimated Stats Days in development - About 25 days Hours per day - About 2 - 4 hours of work a day Total development time - About 80 hours
  6. I've been working solo on a robot combat game inspired by Robot Wars, Battlebots and such. I attached a clip from an older build of the game since showing is better than telling for describing stuff Players can choose a chassis, drivetrain and weapon for their robots before duking it out in the arena. This is where my problem comes in. I'd like to have a decently wide selection of parts with different appearances and different stats. I intend to allow players to use any combination of parts they choose. Since I'm working solo that's way, way more playtesting than I can reasonably achieve on my own or with the group of friends I could scrape together for such a thing. I've already implemented a basic AI for the game so I'm considering using it to autonomously test out every possible pairing of designs against each other so I can see if any are especially good or bad. The game would collect stats like who won, damage taken, damage done etc. for each match and dump it all into a giant CSV for processing. What I'm wondering is if anyone else has done something like this? And what sort of pitfalls I should be aware of before getting too deeply into AI vs AI playtesting? If anyone has any postmortems on this sort of automation I'd love to see them.
  7. I have that book floating around my collection somewhere. It's good as far as the absolute basics of software rendering goes. The main problem with is now is that it's built around a positively ancient version of DirectX. I want to say DX7 but it's been around 10 years since I've looked at the book last. Edit: Nevermind, I have a different Andre "Tricks of the..." book. My bad. You should be able to do software rendering using GDI by generating a bitmap in memory then presenting it using BitBlt or something similar. That would let you do the vast majority of your work by directly mucking about with pixels in memory.
  8. Dan DAMAN

    problem with a coroutine

    Assuming the method you're asking about is called by something like Update or OnColliderEnter then you can't have it delay until the co-routine finishes without nasty consequences. Unless I'm mistaken Update and such block the game's main thread until they complete execution. The worst case is that you create a deadlock between the co-routine and the method waiting on it. The simplest solution I can see to get the behavior you want is to move the loop into the co-routine. [Edit: IMO this would also be the cleaner solution to your problem] //a timer used for timed pick ups public IEnumerator PowerUpTimer (float delay) { Debug.Log("PowerUpTimer"); int shotsLeft = 6; while(AmmoRemaining > 0 && shotsLeft > 0) { yield return new WaitForSeconds (delay); mainBallVector = mainBall.GetComponent<Rigidbody2D>().velocity; //grab mainBall's direction and speed before making it a destroyable ball SpecialShot(); AmmoRemaining--; shotsLeft--; } } A quick and dirty way of blocking execution on a co-routine would be to have a boolean set to true at the start of the co-routine with a while loop that executes until the boolean is set to false at the end of the co-routine. I suspect doing this will hard-lock the game but I've not tried it. Even if it doesn't I would recommend against it since tight loops like that are an inefficient way of waiting. //a timer used for timed pick ups public IEnumerator PowerUpTimer (float delay) { coroutineRunning = true; Debug.Log("PowerUpTimer"); yield return new WaitForSeconds (delay); mainBallVector = mainBall.GetComponent<Rigidbody2D>().velocity; //grab mainBall's direction and speed before making it a destroyable ball SpecialShot(); coroutineRunning = false; } // I'm pretty sure this will lock up public void ThingThatWaitsForCoroutine() { // other code while(coroutineRunning) {} // stuff after coroutine is done }
  9. Another week of development has come and gone with a bit less overt productivity but a much more game-like product. So far the game is coming together decently and has a "has potential" feel in my opinion. I've not spent much time on getting the pacing right and, without music, the game is lacking in atmosphere. However shooting feels good and I feel that the scoring mechanic gives just enough impetus for the player to be aggressive to keep the pace up. What we did last week Day 1 was finishing up what was started at the end of last week. When the player is hit the screen shakes and fades out. If the player is out of lives the game ends, if not the player respawns after a brief delay. Also set up a proper model for the player's gun. Day 2 was unable to work due to personal commitments Day 3 created models for different shots and a model for the player character. Day 4 added scoring mechanics and got the status bar working completely. Day 5 rigged the player character and got some really minimal inverse kinematics going. Looks janky but it's a start. Day 6 not visibly productive. Animated the player character then ran into tons of issues with importing the animations causing, among other issues, the player model to embed itself in the floor. Day 7 resolved the import issues by moving the player model in Blender so its median is at the origin. This stopped the model from jumping around so I could place it accurately. I suspect it's due to parenting issues which are discussed in the final paragraphs of this article
  10. In Ontario the Toronto indie scene gets most of the attention with megahits like Cuphead. Though most of the attention is on the biggest city in the country smaller communities also have burgeoning development scenes of their own. If you're in the Kitchener/Waterloo & Cambridge area there's a month long game jam, called MoLoGa jam, going on for the duration of February. Anybody that's interested can participate. Since the jam is more sedately paced I'm going to try to post weekly updates about what me and my friend are doing as a project. What is the project? For MoLoGa we're building a manic arena shooter in the vein of Serious Sam. The twist is that instead of dealing with hordes of enemies mixing ranged, melee and kamikaze attackers for challenge this game will pit the player against enemies that spew tons of bullets. The intention is to have the challenge be based on navigation and positioning so that you kill enemies in a way that gives the highest score. In short, it's meant to combine scoring and movement mechanics common to bullet hell shooters with first person gunplay. Some design details The biggest potential pitfall in the game concept that we anticipated is the player being unfairly shot from behind. In order to mitigate this the game is going to have a few assists. The biggest one is the creation of the jumbotron. The jumbotron is a big screen showing a birds eye view of a large portion of the map. It's meant to provide a way for the player to quickly check the entire area around them without having to spin around. The jumbotron is also a deciding factor in the visual theme of the game. Since I wanted the presence of huge TVs in highly visible locations to actually make sense I decided the game will take place in a literal arena. While I'm not going to include any explicit narrative the game will hopefully evoke some kind of fantastic sport or TV show. The game will also have a few other assists to make it feel fairer. They are going to be more subtle. Bullets that are approaching from behind in a way that could hit the player will have an aura showing vaguely where they are. Nearby bullets will produce a noise. What did we do last week? MoLoGa jam kicked off with a brief presentation at the UW Games Institute (formerly known as RIM 1 for some of us :p) last Tuesday. Day 1 was dedicated entirely to hammering out the game concept and what needed to be done by each of us. Day 2 I built a model for the arena the game takes place in. Not much to look at but it does the job. In order to save time I didn't model the full arena. Instead I made a model of the northwest corner then duplicated it in Unity to create the full arena. Day 3 was dedicated to setting up some of the game's infrastructure and getting basic movement working. Day 4 basic shooting controls. In theory the player has both a primary and secondary fire but only the main weapon is functional since I haven't decided whether the secondary fire will be a big laser or a rocket launcher. Day 5 enemy spawning and killing. With this the game finally resembles a game Day 6 I got together with my teammate and we put some work into getting the music he'd been working on sounding good. I gave enemies the ability to shoot their own bullets. Day 7 set up some in game UI bits and got player death detection working. This was not a productive day unfortunately. Stay tuned... next devlog will be coming, hopefully, next Tuesday/Wednesday
  11. The Toronto Game Jam is opening for registration later this year. I'm hoping to participate again since it's been a great experience every time. As of last year myself and a friend have participated in the Toronto Game Jam three times. The event, also known as TOJam, has developers come together at George Brown College for three days of manic development of crazy game ideas. Participating in a jam can be overwhelming but also rewarding and fun as hell. Over the last few events I've had things go right and things go wrong. Here are some tips to help avoid some of the worse pitfalls that you can hit during a jam. Tip 1: Know what you're going to make in advance At TOJam you have from Friday at 10:00AM until Sunday at 6:00PM to create your game. While you don't need things to be set in stone you should know that you're making a puzzle game and if will be based on sliding tiles or stacking blocks. If you don't know what you want to make then you'll be using up your time figuring out what to do instead of doing it. The week before the game jam we take our one or two paragraph "elevator pitch" and write a simple list of what needs to exist to fulfill that pitch. We then refine that list into a detailed set of tasks we want to complete on each day of the jam. With the list we can grab work as it's ready and keep dead time minimal. Tip 2: Know what features you can drop Murphy's law always strikes. Something goes wrong and suddenly the deadline is looming. When figuring out what to do for the game you should have some idea of what features you can drop without ruining it. Generally this list will be very short but it's always handy to have if you fall behind schedule. Making a list of optional features is also a good gut-check on whether you've got a realistic schedule. If the list is long then your project is probably too large. A schedule that feels like it has too little work on each day is better than one with too much. You can always add work and scope to a project while you're working on it. It's much harder to cut scope down when you're running out of time. Tip 3: Balance your workload between team members If you're jamming solo you don't have to worry about this. If not it's critical that everyone has something to do. One trick is to have broad but shallow task trees. If C depends on B which depends on A then they can only be done by one person. Sure you could work on A then your partner can work on B but you can't work on C while your partner works on B. A way of fixing this is adjusting your design so B and C depend on A but not on each other. From a coding perspective using interfaces and loose coupling helps a lot. In our latest jam, TOJam 12, we had a number of lethal hazards which could be activated by a button. In the bad case character death would depend on development of some arbitrary hazard which would depend on implementing the button to activate it. To avoid this we set up the button with two observable events, OnPressed and OnReleased and gave the player character a "Killed" method. By having a simple interface everything that was activated by the button could be developed independently. By having the "Killed" method player death could be written independently from any specific way of killing the player. Another trick is to group your tasks into distinct streams. During the start of TOJam 12 I developed the base skeleton of the game while my team mate whiteboxed levels. The only dependency here was that I needed at least one level to load to start the game which was done well before I needed it. Later on I worked on handling player death while my teammate composed the title theme song for the game. Tip 4: Have a library of game creation tools in advance When jamming it's important to always be working on the game you want to make. The last thing you should be doing during a game jam is building a tile map editor. In TOJam 11 we lost about four hours to writing input handling code for a twin stick shooter. That took away time from more important tasks like generating bullet patterns, spawning enemies and so on. Tip 5: Minimize the number of variables the game's design I'm not a professional game designer so I'm not sure if "variable" is the right word. What I refer to is a thing that can be changed to alter the feel and balance of a game. The speed of a character, enemy hit points, number of enemies, how often they shoot, how often you shoot and so on. All of these variables add complexity to the process of making a game "feel" the way it should. Having lots of low hitpoint enemies could make you feel powerful. Having a few high hitpoint enemies would feel quite different. Having lots of high hitpoint enemies could make the game feel dangerous, scary or simply unfair. In all these cases I'm only changing two variables, the number of enemies and their hitpoints. At TOJam 11 we produced a twin stick shooter called MANT: The Man Ant. The twist is that the bullet patterns would be generated procedurally. This also was the biggest headache. Pattern generation worked but it was extremely unbalanced. Sometimes patterns would be pathetically easy. Sometimes the game would produce enormous unavoidable walls of gigantic bullets. We burned up at least half a day trying to get a consistent and fun difficulty curve but still had huge differences between sessions. The game was a "finished" working product but it wasn't very fun. Our next project was a puzzle platformer built around using dead bodies left behind when your character dies to reach different goals. Variables are generally level specific and mostly independent. Things like how quickly a door should close or how often a gun should fire. Tweaking still took around half a day but we stopped tweaking because we were done rather than being out of time. ToJam Specific Extra If you're driving from another city don't forget to take traffic into account. The 401 and Gardiner Expressway are infamous for a reason. Related Links Toronto Game Jam website Our TOJam 11 project (not a great game in my opinion) Our TOJam 12 project (you can find more details on how the jam went in the development log)
  12. Reviving my account after nearly ten years since my last post. Feels odd to no longer be lurking.

  13. Dan DAMAN

    3D Sound

    I know both FMOD and XNA's Audio class library support positional audio (attunation, doppler shift etc. IIRC FMOD has a larger selection of effects). I remember Half Life (at least the version I played, forget the exact one but it came bundled with Of-For, Blue Shift, Counterstrike and TFC) made heavy use of EAX effects. I can't really think of any games now that have such a "wet" sound mix now though. Perhaps heavy reverb is a little out of fashion currently. Like Kylotan said 3D audio, reverb (and lots of other DSP effects) have been supported by existing middleware for a long time. Lots of games just don't seem to take advantage of the hardware or software that's out there.
  14. I believe mysql_query is deprecated in favour of mysql_real_query (due to potential issues in dealing with NULL characters in the query, for example when dealing with BLOBs IIRC) Converting back and fourth between strings and doubles will have a definate performance penalty though it might not be an issue in your case. It depends on how often you're hitting the database. I did the same thing as you for a MySQL project in school but it was a user application and not a game, queries would only occur once every few seconds and the database was trivially small (maybe a few hundred to a few thousand records)
  15. Dan DAMAN

    C#.net

    If you do use C# (or pretty much any other .NET language) you can take advantage of Microsoft's XNA Game Studio which lets you write games for the X-Box 360 as well as Windows without having to get the X-Box dev kit. Still, you have to pay for the XNA Creator's Club Premium membership to load stuff on the 360, it costs about $100 unless I'm mistaken. You can also get a trial membership for free if you're a student via DreamSpark.
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!