Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

127 Neutral

About Dan DAMAN

  • Rank

Personal Information

  • Role
    Quality Assurance
  • Interests


  • Twitter

Recent Profile Visitors

2017 profile views
  1. Dan DAMAN

    Passing data with message system?

    This above could be pared down further. A barebones renderer shouldn't need to know how game assets are managed, what an asset is or even that it's being used for a game (vs any other real time rendering application.) The renderer only needs to know about data that you intend to pipe into the GPU. DrawCube(Matrix4x4 worldTransform, Material material); The worldTransform covers location, size and orientation of the object. The remaining transforms (view and projection) would be handled elsewhere since they're normally common across many draw calls. The material covers everything else pretty much. From here you could then make a more abstract function which DrawCube can use behind the scenes. DrawMesh(Mesh mesh, Matrix4x4 worldTransform, Material material) As a side note, if you're rendering objects using an API like this what you'll likely need to do behind the scenes is queue something to be rendered instead of rendering immediately. Once you start using stuff like multipass shaders, render targets and postprocessing drawing objects on screen becomes a lot more work than simply rendering a box at a position via a draw call. Even without that you'd should probably sort your actual GPU draw calls for various reasons. Finally, a warning from personal experience, if you want to make games it can be a good idea to stay away from engine code until you get a game or two under your belt. Engine code is a huge massive crazy time sink and if you're not sure what you want the engine to do there's lots of intellectual tarpits and blind alleyways to get lost in on your way to something useful. It's pretty fun if you want to do it but you're not going to be making many games very quickly. Be ready to throw away a lot of code as you learn what designs do and do not work well.
  2. Dan DAMAN

    Passing data with message system?

    I would suggest the first important piece is to decide is which systems need to communicate with each other first. Once you have that you can figure out what, when and how often your systems need to communicate. IMO systems that do infrequent, one way, communication are great candidates for message passing schemes. The sender is decoupled from the receiver and for implementations like the observer pattern the overhead for sending messages is usually lower than alternatives like polling. I also second what @erpeo93 is saying. Try not to get too attached to one solution to a problem. For many basic problems in system-system communications a bog standard function call can do the job quite nicely.
  3. Do your prefabs have Rigidbody components? Generally Unity treats an object with a collider but no Rigidbody as a piece of level geometry which cannot move but can be hit by other objects. Having overlapping colliders is pretty common when creating level geometry so static colliders cannot collide with each other. Check the "Collision Action Matrix" section of the Unity manual (link below) to see if your setup is something that will generate a response. From the Unity manual
  4. I've done a few platformers with a friend using Unity 3D now. At the time we wrote our first platformer we used raycasting to handle the work of detecting walls and slopes and have used the same code, with tweaking, ever since. The system is a bit finicky to set up but works well after the initial work is done. You shouldn't have too much trouble getting most of what you want out of either option though edge grabbing might be a bit of a challenge compared to the other features. IIRC there were a couple reasons we went with raycasting since we built the system in 2015 a lot is very much an "at the time" thing and might be incorrect or outdated thanks to updates to Unity. I don't think Rigidbody2D existed at the time but I could be misremembering We couldn't find a way of having one hitbox for detecting walls and another for different important interactions that we were happy with. Even when we constrained rotation on all axes we still got slight rotations sometimes Getting a good control feel was extremely difficult. IIRC we kept getting weird issues (sliding, getting stuck, jitter etc. etc) that would crop up randomly which raycasts didn't have The way we did things was to have three rays (top, middle, bottom) cast for horizontal movement and three rays (left, middle, right) cast for vertical movement. Any intersection that's within the character's hitbox will result in the character being pushed back/up/down to eliminate the overlap. When embedded in a floor the player is always pushed up so it's impossible to get trapped though it does open the game to a class of exploit normally called a "zip" by speedrunners. Tweaking the locations of the bottom and left/right rays is used to control what sort of slopes that player can and cannot climb. Unfortunately I don't know of any good tutorials for setting up something like our system since we only really used the Unity manual, pencil and paper and hacking to implement our platforming system. I could write some blog posts or something on how our system works if there's interest. I don't think a forum post would be the best place for going into all the details on how we made our stuff work.
  5. 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: As other posters have said, you will get bugs still, but simpler code should make them easier to find and fix.
  6. 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)
  7. 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 and Are there some other good ones you can think of? Less formal articles are also good. Thanks for the info so far
  8. Dan DAMAN

    MoLoGa Jam

    Development progress images from the K-W Month Long Game Jam
  9. 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
  10. 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.
  11. 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.
  12. 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 }
  13. 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
  14. 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
  15. 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)
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!