Jump to content
  • Advertisement

slayemin

Member
  • Content Count

    1781
  • Joined

  • Last visited

Community Reputation

6243 Excellent

About slayemin

  • Rank
    Contributor

Personal Information

  • Role
    Programmer
  • Interests
    Business
    Design
    DevOps
    Production
    Programming

Social

  • Twitter
    @slayemin

Recent Profile Visitors

43025 profile views
  1. slayemin

    Shipped a pilot

    (Warning: Rambling ahead!) I met a new client in the beginning of November through a friend. The client asked my friend if he knew how to use Leap Motion. He said, "No, I don't, but I know the just guy who does! Eric is probably one of the best Leap Motion developers in the country.", and a referral was sent my way! I need to remember to buy my friend a nice dinner as a show of thanks. Anyways, this project was interesting for a variety of reasons. First off, the bulk of development was being outsourced to Ukraine. The outsourcing of work meant that the project owner needed to work late into the night to coordinate efforts with his Ukraine team. They were having some problems with the wrist joint causing the mesh to twist (candy wrapper effect) and nobody was making much headway. So, I was brought into the project. I downloaded the full project, tried it out to see where they were at, saw the problems, and then I started looking at the implementation. Pardon my unprofessional trash talk here, but the implementation looked like it was being held together with bubblegum and duct tape. I told them that I was going to redo the project. It was such a simple project that it took me about two days to rebuild. I was able to simplify, condense and cut about 75% of whatever those Ukrainian guys did, and it was a "correct" implementation which was maintainable. It was valuable as a throw away prototype, but for production work, it needed to be redone. I told them, "If you can't tell the difference between what I did and the original, it means I did my job right." This is always a tough sell for non-technical people, but you see the real value as the project progresses. When everything is done right from the very beginning, you skip over lots of problems you would have otherwise had (which costs time, energy and money). As far as project implementation goes, this was a super easy project (for me) because I had already done several similar projects and had built out a template library to use. The hardest problem was actually dealing with the wrist and elbow joints with leap motion. So, I'll describe some of that pain here: The initial problem was that when you rotate your wrist (roll along arm axis), the wrist bone rotates but you start to get some pretty bad deformation of the arm mesh, to the point where the wrist gets pinched to look like a candy wrapper. The problem was a combination of technical implementation, incorrect rigging, incorrect mesh weighting, and a bit of fighting the leap motion plugin. Fixing the problem can be sort of described as trying to straighten wet spaghetti noodles, because so many different factors contributed to the problem. There was no single silver bullet fix that magically fixed it all. My greatest secret weapon was my strong debugging skills and approach to debugging. Although my client liked to call other experts with industry experience, they could only do vague hand waving and guess work at the causes of the problem. The true, best way to figure out what's going on is to dig into the problem, get deep into the weeds, add a ton of debug scaffolding code and visualization helpers, and really spend the time and effort to look at what's going on. A slow, methodological, scientific approach is tried and true for me and far more illuminating than the guesswork of experts unfamiliar with the project. As far as skeletal rigging goes, I ended up downloading a freely available Paragon character with exposed arms with rotating animations. I looked at the bone setup. To fix the candy wrapper effect, you need two twist joints in the arm, parented off of the elbow joint. The wrist twist joint needs to be about 1cm away from the wrist. You also need a forearm twist joint in the middle of the arm. When you apply roll rotation to the wrist, you only apply roll to the wrist twist joint but yaw and pitch are handled at the wrist joint itself. You also need to take about 50% of the wrist roll and apply that to the forearm twist joint as well. Otherwise, you start to get bad mesh deformation and loss of volume. You also need to be very robust with your mesh weighting on each of the bones. It's good to use a working reference model to get an approximation on the best vertex weights. There were also some challenges with the out of the box leap motion plugin as well. The problem is that you get the wrist transform, but the rotation values are for the wrist joint itself, not for arm twist joint roll values. I discovered that I needed to derive my own arm aligned wrist rotation, relative to the elbow position. The rotational value needs to be independent of wrist pitch and yaw. Anyways, I won't get into the vector math required to do that, but I ended up having to derive these rotational values myself. It's important to note that the wrist joint is being driven by the user (via IK) and the elbow is an intermediate joint, with transforms being set by the IK solver. The user can put their arm into any position and contortion, and the virtual arm you present needs to match as closely as possible with the physical arm location. This is really hard to get right because the animations need to support *anything* the user does -- any popping or glitches are obvious and break immersion. Doing good elbow placement with limited data has been one of the harder challenges facing most VR developers, so it hasn't been a well solved problem. Most VR developers will skip it all together and just show people a pair of disembodied hands at the motion controller locations, but if you are trying to use a full body avatar for the player character, it's a problem you eventually need to solve. I think I did a pretty good job on the elbows. I also made a discovery about the hardware capabilities of leap motion: Though this shouldn't be a surprise, the leap motion has great trouble finding elbow placement when people are wearing coats or sleeves. If you want reliable elbow tracking, you need to take off your coat and roll up your sleeves. You also need to be very aware of bright light sources in your environment because those light sources will interfere with leap motion. Keep in mind, the leap motion uses an IR camera to to track hand gestures, and the HTC Vive uses two laser base stations which emit IR lasers, so there is a slim chance that you can get laser base station interference, depending on placement and what direction you're looking. And... if it's not obvious, sunlight causes bad tracking environments for leap motion. Anyways, I nailed it on this project. You can pretty much do anything with your arms and the digital avatar will do the same thing. I'd show a video of the result, but I think the NDA restricts me from showing that. I don't think I'm the "best" leap motion developer in the country, but I'm firmly in the top 10%. My bigger worry about Leap Motion right now is the health of the company and what that might mean for their product. Are they going to be in business two years from now? Who knows. But, the library of content built for their hardware platform is slowly growing. On a VR production side note, I made an amazing discovery in this project. If you setup an Oculus to work from your chair, you can develop in VR using the built-in desktop virtualization app. As long as you can type without looking at the keyboard, you can develop in VR. Instead of having a 17 inch monitor, you can have a 5 foot screen in VR. And if you want, you can drag out windows and surround yourself with as many screens as you want. This taxes the GPU a little bit, but who cares? The beauty about this is that if you're developing VR content, you don't have to keep on putting the headset on and off between development iterations. Since you're already in VR, switching between your IDE and your VR app is reduced to a single button press. I worked like this for several days to see how I liked it and if it was feasible. I thought I'd get sweaty face, eye strain, or have some other related draw back issue. Aside from not being able to see my keyboard, it was pretty solid! There are small preference issues I'd like to change. I prefer to listen to music on youtube while I work, and when I work in VR, I am stuck with the ambient music in the oculus home environment, and switching between IDE and project switches the audio (this should be a preference). What's extra magical about working in VR is that it has a pair of headphones and a microphone embedded into the hardware, so if you wanted to do a VoIP call over Google Chat and do screen sharing, you can do it all in VR without taking off the headset! I truly believe this is going to eventually become the future of how people work and interact with computers and each other. I feel like I'm on the bleeding edge here and I saw a glimpse of the future, and damn, it looks awesome! In closing, this project was relatively small and simple. I was instrumental in shipping it. I feel that I have a fantastic relationship with my client, they are extremely happy and impressed with the work I did, and I will be their go to guy for future VR work. This is how you get repeat business and build a financially self sustained company. Now, if only I knew how to market myself... There's another potential upcoming VR project with a much bigger budget that I am extremely excited about. I can't go into details, but I will say... if we get this and pull it off, it's going to create a new industry and there will be lots of magazine articles written about what we did. My experimental research work in AI will not be wasted. Spellbound: As far as Spellbound work is concerned, I still work on it on the side, between projects. Since this is going to be mostly a story driven VR game, I've been focusing a lot on the story writing. It feels weird to open up a google doc for my game story and say I'm going "game development". It's creative story writing, not code writing. And... it's just as hard. I've gone through probably 10 different iterations of the story so far and scrapped most of them. I'm finding that the story writing for VR is extra hard and takes a LOT of time. You need to write it like a movie manuscript, but you also need to think about presentation and the fact that the story is not consumed linearly. If you're an indie on a budget (like me), then you need to consider that every word costs money and player patience, so if you're excessively verbose, it's going to be expensive and nobody wants to sit through long, boring performances. You also have to consider the localization angle: If your scripts have lots of sophisticated word play and language based puns, you are going to hate yourself when you need to localize for different audiences. Short, simple, sweet, to the point, well worded. A story isn't about how flowery and eloquently you can write your sentences, it's about retelling a sequence of emotional events which leaves an impact on your audience... I recently realized that the story writing doesn't need to be done from an omniscient point of view where you tell every important detail, it can be done from the point of view of the story writer (an in-game historians perspective, if you will) who has a limited point of view. This let's me skip details up front, hide them a bit, and do a big reveal later on in the plot as a twist in the story. With this style, you can experience the story twice and see the plot structure and make new sense of various setup clues (similiar to how you can watch the movie "The Sixth Sense" twice and get two completely different viewing experiences). Here is the dressed down storybook intro for Episode 1 in Spellbound: [This is the story book intro. It is presented as a series of illustrated pages in a book and is read by a narrator. We have accompanying voice over lines and sound effects to go along with the story, so that it feels almost like a cinematic.] Page 1: Thousands of years ago, evil wizards and witches opened the gates to hell. Swarms of demon spawn entered into the mortal realms, lead by the arch demon Asmodeus. Page 2: No army could stand against the demon spawn. Cities were reduced to rubble and ash, tens of thousands of people fell to their blades like wheat to a scythe... Page 3: When all seemed hopelessly lost to darkness, the eastern horizon erupted in a blinding glow of shimmering light. Asmodeus was no more, and his leaderless demon spawn retreated to hell. Page 4: Nobody quite knew what happened or how they won, but one thing the remaining kings agreed upon was the outlaw of magic and the execution of all its practitioners. Page 5: People were finally safe again... all but for wizards and witches. For thousands of years, those who even *looked* like they could be magical, were hunted down and killed in every kingdom. (Short pause / transition break for establishing shot) Page 6: On the edge of the Blackwood Forest, in a small hamlet named Halfordshire, a humble pair of farmers welcomed a new boy into the world. After seeing his fire red hair, Father named him "Rupert". Page 7: Rupert grew up, as all young boys do, and trouble followed naturally, as it does with all young boys. Page 8: But the natural troubles of boyhood soon turned into supernatural troubles which seemed to haunt Rupert everywhere he went. In a freak magical accident, his home was utterly incinerated. Only Rupert survived. Page 9: As he stumbled out of the smouldering cinders of his former home, the villagers could see that not even one red hair on Rupert was burned. Was it a miracle? Page 10: As the initial shock wore off, villagers began to shout that he was a witch. Fearing for his life, Rupert ran, and he ran, and he ran, deep into the Black Forest. As day turned to dusk, the village hunters abandoned the hunt. Page 11: Rupert survived through the night, wandering through the forest for days, getting hungrier and hungrier. He stumbled upon an old tower of crumbling stone, and made it his new home and lived off of whatever edible bark, berries and mushrooms he could find in the forest. Page 12: Rupert lived in the crumbling stone tower for years, completely alone. Whatever was haunting him, seemed to follow him everywhere he went. What he didn't realize is that the next morning, his life would be changed forever...
  2. slayemin

    How to get out of the mass? HELP ME !

    Take some of the money you've already made from your game sales and invest in marketing and advertising on google and facebook. You often need to spend money on marketing to get any real value out of it. Just making a bunch of social media posts isn't going to help you. Also, think very carefully about your marketing message and sales pitch. You might want to get some advice from people who are experts at marketing to help you do it right. Otherwise, you might be wasting your money or not being as effective as you could be. Keep in mind you might be an expert at making good games, but that doesn't make you an expert at marketing and sales Lastly, you're going to need to treat your marketing efforts like a science experiment: Make a hypothesis, conduct an experiment, measure the results, and see if the hypothesis/assumption was correct or not. You're going to waste some time and money chasing dead ends, but some paths will be fruitful.
  3. slayemin

    Kissing rock bottom

    Thanks, I'm doing much better now and eating better, but it was some unnecessarily hard times for me for a week or two. I think I'll be okay in the coming months.
  4. slayemin

    Kissing rock bottom

    This may be one of the harder, more difficult entries to write. I am almost tempted to not even write it, but I've convinced myself that every step of the journey is important. Almost exactly a month ago, I hit rock bottom. I was completely broke. I had nineteen cents in my bank account. My credit cards were maxed. I had next to no food in the cupboards. No gas in the car. My bus pass for community transit was empty. I was so poor that I couldn't afford the $2.75 to take a one way bus trip to my office. And if I did, I also couldn't afford to spend $8.65 for a lunch burrito. If I wanted to take the bus to the office, I would have to sneak onto the bus and keep a wary eye out for fare enforcement officers and hop off the moment they get on (happened a couple times). The only food I had for days was dried quaker oatmeal. Put a bit of it into a bowl with water, microwave it for 2.5 minutes, and then take it out, sprinkle some dried oats on it and try to mix in a pinch of brown sugar. I ate just that for days. Have you ever felt like your stomach is full but you're still starving? That's what eating the same food every day feels like. Trust me when I say this, there is no #*@!ing glory in being a starving artist. I was down hard. I was literally starving, eating oatmeal twice a day to conserve food. I needed to hatch a plan to make money. Whatever I've been doing, it wasn't working out. I need a new plan. Normally, I'd lean on my girlfriend for help, but she's down hard too. The best she could do was loan me $50. I went straight to safeway and I very carefully wandered the aisles looking at how much food costed and what I got for my money. What gives me the most nutritious energy for the least amount of money? Canned soups cost $2.30 each, there was a 2 for 1 deal on loaves of bread, a dozen eggs are ridiculously cheap, a quart of milk is a little over $3, etc. If I cook my own foods, it's a lot cheaper than anything else. Cheap eggs, milk and bread? It's time to feast on french toast! I made that $50 stretch really far and bought over a weeks worth of food supplies. But what happens when the food is all gone? Then I'm back to square one, back to starving. So, the $50 of food is a loan, not a grant or gift. I need a better plan. I decided I would go to the Sunday farmers market and setup a table and sell my girlfriends wine openers to people. I got some stock. I got a folding table and an old tent, a metal folding chair, and a demo stand. All of the previous booth props were stolen by my girlfriends former business partner. No signs, no props, no table cloths -- nothing! I had to do everything from scratch and start over. The booth fee costed $60, and by the grace of god, one of my credit cards was just barely not maxed that morning. I could pay the booth fee. Then, I didn't have a bottle of wine to demonstrate with either. And the table I had was covered in various paint splatters and looked like it had obviously been pulled out of a storage closet (it was). I almost couldn't even run the booth! I bought the cheapest bottle of wine I could find. 10am rolls around and the street fair begins. Throngs of pedestrians show up. I don't have a table cloth to cover the hideous table I brought. I spend 45 minutes walking all over town looking for a place that could sell me *anything* to cover my table with. Meanwhile, I'm beating myself up for being so stupid and short sighted as to not bring one from home. It was costing me 45 minutes and whatever the cost of a table cloth would be! I finally found a lady at the street fair who could sell me some sort of cloth for $25. One credit card swipe later, I'm in business. Without a doubt, I have the shittiest booth in the whole event. It was so miserable, people would want to look away and at something else more interesting. I'm just one random scruffy looking dude standing behind a forgettable table with a forgettable product. I borrowed a total of $100 from my credit card for the privilege to stand there. I had not eaten that morning because I had no food. My credit card was surely maxed, I couldn't even buy a black coffee if I wanted one. I had $0.19 in my bank account. I was starving. The reality was, if I wanted to eat, I would have to #*@!ing *sell* product. There is no standing around waiting for people to maybe stop by my shitty booth. It's shitty, nobody is going to be curious to stop by and window shop when there's an ugly window and nothing appealing. If I wanted to eat today, I had to actively pull people in and sell. Nothing else but me was going to bring in sales. I took that on as a challenge. I told myself, "Eric, it's time to see what you're made of. Can you really sell, or do you rely on crutches like a pretty booth?" Fortunately, I've had a smidgen of direct sales experience. I've given the same demo thousands of times. I knew the pitch by heart. I knew all the jokes. I could put on a performance. I knew how to work a crowd and draw people in... sort of. People are not going to buy from me because they like my product or like my booth, they're going to buy from me because they like my demo and I entertained and wowed them. Or... so I believed. An hour went by. Dozens of demos, but not a single sale. My stomach is grumbling. Another hour went by. Still, more demos but no sales. Two hours, and not a single dollar?! Did I just waste $100 of food money to make nothing?! I was starting to wonder if there was something wrong. Were people truly not buying from me because my booth presentation sucked? No way, I can't believe that. I was giving dozens of demos and people were amazed by the product and laughing at my jokes. It's just a matter of time and patience, and someone will open up their wallet. Finally, my first sale happened. It was a credit card purchase for $30. Damn, no cash -- that means I can't eat. But hey, I got a sale! It was validating! People would #*@!ing buy because of me! my shitty booth didn't matter! My waning confidence was restored! I could do this! And gradually, the sales started coming in, one by one. Finally, someone paid cash. I had no change, so they had to pay exact price. The moment they gave me money, I let them leave and then made a beeline to the nearest food truck and bought some sort of Hawaiian food. It was greasy and disgusting, but hey, it was food. I ended the day with a total of $260 in sales, $60 of which was cash and enough to buy another weeks worth of groceries at Safeway. I could survive for another week at least. And if nothing happened, I could do the fair event again the next weekend. And maybe upgrade my booth with a nicer table cloth? It was going to be desperate times and pure survival mode. My office rent got processed a few days later. My bank account was now $400 in the hole plus a $25 NSF fee. Rent was late. Things were starting to look grim again. Then, something amazing happened. A friend had met someone who was looking for someone that knew how to work with Leap Motion for their project, so he referred them to me. He told them that I was one of the best people in the country (I sort of am). I told my friend that if this goes through, I'll buy him dinner. So, I talk to the client and figure out what's going on. They're an established VR / film company based out of LA and they're having trouble with twisting at the wrist with leap motion and their character model (candy wrapper problem). I told them I'm a freelancer and could help them with their project. So, contracts are quickly signed and I take an initial down payment of $500 (yay, food and bus fare!). The client asks me how my VR work is going, and I reply, "Well, it's a bit of feast and famine cycle..." and he said he knew exactly what I meant. He had no idea how hungry I was. But, what an opportunity! The key thing to realize about freelancing is that it is ALL about building a solid reputation for making happy customers. Be an excellent professional. Work hard, work fast, work smart, get along with everyone, and bring value to your client. If you can do that, you will get a good reputation and have an established, healthy working relationship. That means repeat customers, more business, and good referrals -- which mean even more customers. The same principle of actively selling product behind a shitty booth applies to selling yourself and your services -- delight your customers and present them with something of value greater than their money. This is so key and fundamental to business, you must learn it. If an MBA degree doesn't teach you this, you need to ask for your money back. It turns out that this arm twisting problem was much more difficult than anyone had expected. You have to have two twist bones parented to the elbow, the mesh needs to be weighted correctly, and then you need to read the leap motion bone transform values and apply them to your skeletal rig in real time. The problem is, the only constraints people have on their arms are their physical limitations. An arm and wrist can be oriented in all sorts of funky directions, and if your approach can't handle them all, you get deformed arms, it looks bad, and it breaks the immersion of virtual reality. It's much harder to get perfect than I anticipated. The project itself was relatively simple. This guy had hired a Ukrainian development team to build his app. I looked at it and it looked like it was something barely held together with duct tape and glue. I rebuilt the whole thing in two days using the old work as a prototype, but this time I "did it right". I told my client that if he can't see a difference, I did my job right. He couldn't. Now, some dumber business people might say, "It looks exactly the same! What am I paying you for?!". This guy was smart and technical enough to see how much everything changed under the hood and how much more elegantly simple it was. It's maintainable! And it can change to meet new requirements without falling apart and costing lots of extra time and money to fix! Anyways, to take one step forward, sometimes you have to take two steps back. I ended up taking over development for the project. Sorry ukrainian devs! I ended up finishing the project much faster than they had scheduled. As of today, it's done! The client is ecstatic. Everything works perfectly and it looks amazing! The project is a pilot project for a VR film series, so if my clients client gets funded to produce the series, I think I'll have a lot more work in my future. The total pay for this project was $4,500 and took me about 10-14 days. That will be enough to pay my late rent and buy enough groceries. Whew! No more eating oatmeal for the near future. The extra good news is that this was a "small" project and there are much bigger ones on the horizon. There's a sliver of a small chance that I might actually be able to build a financially sustainable business out of this VR stuff. I must be extremely careful though: If you only rely on one client for your bread and butter (literally), if they go away, you starve. So, I must be sure to diversify and broaden my client list so that losing one doesn't cause me to starve. And, if I'm going to be thinking ten steps ahead here, I should eventually take on an apprentice and train them to become highly proficient VR developers. This would allow me to take on bigger future projects and offload some work to my team. Also, I learned a very, very important lesson about money management: Never, ever repay a debt to anyone if it means you're going to go hungry. They can wait, hungry bellies can't. This is the crucial mistake I made which made me go hungry for a week. I thought it was important to not owe anyone anything. As an ideal, it feels great to be debt free, but a hungry stomach doesn't give a flying #*@! about lofty ideals (A hungry belly also doesn't care about any pathetic excuses for why you won't sell). The other super important, crucial thing to remember is that a business is ultimately about making money. Whether you're an indie game developer, working for a AAA game company, or working in any other industry, your job/company must make more money than it spends or else it will starve and go out of business (and you'll be jobless and starve too). Think very carefully about whether you're adding value to your company, whether other people are adding value or not, and what needs to be changed in order to stay profitable. The size of your company doesn't really matter. In fact, bigger companies can be dangerous too because people get comfortable, and comfort breeds complacency, and complacency kills, especially when it becomes a cultural norm at the company. Sometimes, having a lot of money is a curse too because it shields you from facing harsh realities and changing course when things aren't working. If you look back to my very first blog post, you'll remember I started my adventure as an indie game developer with $500,000 in my personal bank account. Today, although I'm still very poor, I feel I am better armed, wiser and better poised to become successful and profitable than the day I started. The adventurous journey towards financial sustainability (and eventually profits) in a tough industry continues onwards! The future looks brighter now than it did a month ago, though I can't rest and get complacent. (Warning: don't read further if you want to have a pleasant day) Also, on a side note, it's been a bit of a tough last week. I parked my car in an alley behind my office (in a homeless mecca) and worked until 4am, and came back and discovered someone had smashed my window and grabbed $400 in VR equipment. My girlfriends ancient cat also went into really bad health. He wouldn't eat, could barely drink, was almost blind, couldn't even stand, and was constantly meowing in pain. It was dying. I took it to the "value" vet for confirmation. I had to pay $22 to confirm the poor thing was dying and no amount of money could save him. They wanted to charge me $178 to put the cat to sleep, tried to upsell me on cremation services, a few inked paw prints, etc. I declined. The vet then went down on price and offered to inject the cat with a narcotic for $48 to help him die faster and ease his pain. I declined that too. I took the dying cat home, brought him to the backyard and let him see his last morning sunshine and hear the birds and squirrels one last time. I grabbed a shovel and dug a small little grave for the little guy. He was meowing weakly in pain, laying helplessly next to his final resting place. He was suffering. It was time to go. I put him into his little grave and killed him quickly with the shovel blade pressed to his neck followed by a hard stomp. For a brief moment, he had an unforgettable look of shock and betrayal on his face and his legs splayed out in reflex, and then he died and never moved again... I thought I would be a bit more emotionally hard about it (being a war veteran and seeing lots of dead animals at our ranch), but killing a dying cat was not easy. I got choked up afterwards. It was an act of mercy and the ethical thing to do, but still... not easy. I realized that sometimes, to maintain the divine sanctity of life, you must provide death, because to continue living in hopeless suffering inevitably ending in death anyways, only serves to prolong suffering and corrupts the essence of living.
  5. slayemin

    Introduction to Octrees

    Formatted Article: https://www.wobblyduckstudios.com/Octrees.php Code Directory: https://www.wobblyduckstudios.com/Code/ Code Files: https://www.wobblyduckstudios.com/Code/IntersectionRecord.cs https://www.wobblyduckstudios.com/Code/OctTree.cs https://www.wobblyduckstudios.com/Code/Physical.cs
  6. slayemin

    Artificial Intelligence Work in Progress

    Yeah, I'm in the middle of programming it now. I'm about 60% complete and the models I describe above in my post are also computable. It's incredibly important that these kinds of conceptual models can be turned into math & logic models, because that gives them some practical applicability and also means that you can test your conceptual models for correctness in a more real environment. The simulation testing will reveal any gaps in the model which few people could spot. I didn't want to write this blog post without anything of substance to back it up (otherwise its just more wishy washy guess work clouding the knowledge domain). I'm sure there's still some gaps / errors I've overlooked, so when I am at 100% complete, I'll probably do a follow up article (and blog post) which goes far more in depth on each section and its relationship to everything else, and how the supporting data model is built and implemented. But, this post is a "This is my working frame work going forward. Where am I wrong? What am I missing?". As far as actual implementation goes, I've got a zombie which runs this AI and can make decisions on what behaviors to do (Spawn, Idle, Search, Eat). It's very simplistic in terms of behavior, but it makes decisions on what behavior to do based on its internal motives state and there is no explicit code scripting out what behaviors to do and the conditions for making those behaviors. It's essentially a model free system which uses abstraction and knowledge to drive behavior choice, and since the zombie behavior patterns are so simplistic, it's a good testing ground to validate framework accuracy.
  7. I've got a broad production level puzzle I've been trying to figure out and I've never been sure if I've been working with all of the pieces. I'll try to explain the problem and my considerations. 1) I need to create AI for all of my characters and it needs to be good enough that it's convincing. 2) My approach has been to quickly write Finite State Machine scripts in C++. It has worked well enough. 3) During development, I change stuff in my game and I will be adding in new mechanics. 4) Every time I change something important, I need to refactor my FSM AI to account for it. This becomes a "tax" I need to pay, and when I just have a few relatively simple characters, it's not intolerable. Now, I put on my magical hat of farseeing +3, and I see a future where my game has dozens of characters, each with FSM scripts. The overhead tax I need to pay increases proportionately, and it gets to the point where I need to spend equal amounts of time maintaining AI scripts as I do with building out game systems, which ultimately slows down the pace of development. Here's where I get a bit conflicted. One side of me says, "Premature optimization! YAGNI! Solving problems you don't have!" The other side of me says, "But these are real problems you're going to have if you don't head them off early and it's just going to be more expensive to fix them later. This has a compounding cost in terms of refactoring effort. Nip it in the bud now. Work smarter, not harder." And the business side of me says, "Will this help me sell more copies today? What's urgent? If this costs me X months and I don't sell Y copies to sustain development work, then my effort is misdirected. I should be focused exclusively on building what sells!" I think all are sage, prudent voices of reason to listen to and have merit behind them. My creative engineering side has been quietly asking, "How can I avoid paying that increasing maintenance tax as development goes forward?" and the answer I've been recircling back to over and over again is "Design an AI system that doesn't need maintenance. It'll have a bit of a steeper upfront cost, but the investment will pay off in saved time over the course of development." Easier said than done, and to build such a system is a tall order which teams of other, much smarter people have tried to do with limited success. My engineering approach has been to dig into current research and development in machine learning, particularly the work being done by Google owned DeepMind. They've been able to create model free AI systems which can learn how to play any game with no instructions on how to play it. Their AI systems have beaten world champions at the game "Go". A year ago I said, "That sounds like something I need for my game!" (cue: ridiculous groans). The reality is that I don't have a long history and deep background in machine learning AI systems. I didn't know anything about artificial neural networks, reinforcement learning, CNN's, or any other acronym super smart AI people mention off the cuff. I fumbled in the dark trying to understand these various AI systems to see if they could help me build an AI system for my game. I explored quite a few dead ends over the months. It's hard to recognize a dead end when you're in the middle of development, and it's also important not to get mentally entrenched on one track. I have to take a step back and look at the bigger picture to recognize these tracks and traps. One track/trap is to think, "I need to have an artificial neural network! That's the only way to make this work" Another one is, "I need to have machine learning, and my implementation for machine learning needs to match the AI industries definition! It's not machine learning if its not an implementation of back propagation!" Another trap: "My machine learning type of AI should convince AI professionals it's real!" All of that is obviously nonsense and nobody is saying this -- its an invented internal narrative, which creates unnecessary constraints, which creates traps. Russel (Magforce7) has helped me see these traps and stay focused on what matters, but I'm still fumbling my way in the dark within a maze. I'm just taking inspiration from the ideas proposed by these other AI systems, but creating my own and trying to keep it as simple as possible while trying to minimize the amount of future work I need to do to maintain the system. So, here are my design goals for the AI system: 1) It shouldn't require a lot of maintenance and upkeep after it has been deployed 2) It should ideally be flexible: Updates to the game mechanics shouldn't cause AI system code updates 3) The AI controlled characters should appear reasonably intelligent and perform plausibly intelligent behaviors. 4) There should be support for variation in behavior between characters of the same class, and between characters of different classes. 5) I don't want to write any special case code. If I start writing FSM code, I'm doing it wrong. 6) Complex behavior should be emergent rather than designed. 7) It should be relatively simple. Integrating things into the AI system should be fast, easy and non-technical. Designing a system to meet these broad goals has been very challenging, but I think I've done it. I have spent several months thinking about how people and animals think and trying to create a model for intelligence which is consistent with biological intelligence. It's taken a lot of internal reflection on my own mind and thought processes, and doing a bit of external research. One important distinction with proposing broad intelligence models is that at the end of the day, it must be computable. If you can't reduce an intelligence model into computable systems, then it is no good for AI, and probably isn't a well defined model and gets lumped in with all of the other guesswork other people have proposed. I've come up with a few of these myself and haven't been able to reduce them into data structures or algorithms, so I had to throw them out. Anyways, on to my model! I've decided that I would structure my model to work as sets of loosely coupled systems. If one particular module is flawed and needs to be refactored, it shouldn't mean the whole system is flawed and needs to be refactored. Here are each of the modules: A picture or class diagram would be helpful in understanding this better. But let me describe the general workflow here for AI characters. Each character has a mind. The mind has memory, knowledge, motivators, and a list of possible behaviors to choose from. The mind is very similar to the finite state machine. Each character has sensory inputs (eye sight, hearing, smell, etc). The only way an AI character can know about the environment around it is through its sensory inputs. The sensory inputs are just a bunch of data feeds which go directly into memory. Memory is where we contain transient state about the environment around us. Memory can be persistent even after a sensory feed is cut -- closing your eyes doesn't cause objects to disappear, so we have object permanence. Objects stored in memory have "importance value" filters applied to them and they also have expiration times. Ultimately, the memory in a mind contains all relevant state information! Our mind has a list of all possible behaviors it can perform, so there needs to be a way to choose the most optimal behavior from the behavior list, given the current memory state. This means there needs to be some sort of internal decision making process which quickly evaluates optimal behavior. How do we build this without creating a bunch of FSM scripts? Because if that's what we end up doing, then we failed and are just creating overly complicated FSM's and are creating scripted behavior models which need to be maintained and updated. Here's the trick where it gets interesting... When we get objects through our sensory inputs, we don't store references to those instanced objects in memory. Instead, we store a set of descriptive tags for those objects. We don't choose our behavior based on objects in memory, but the memories abstract representation of those objects. Our brain also has a knowledge repository of behaviors, tag sets, and its effects on motivators. Our goal is to choose behaviors which create the most reward for our character, and reward is determined by the sum of motivators satisfied (more on this below). Our agent doesn't intrinsically know how much reward certain behavior and tag sets generate, so it needs to query its internal knowledge repo. The knowledge repo is where abstract reasoning happens. Since we're not working with instanced objects directly, but rather abstract representations of those objects, we can look at the tag sets which define our objects in memory and do pattern matching against tag sets in knowledge, find which sets of knowledge are relevant to the object, and then look at historical motivation satisfaction (not historical rewards). Essentially, we're looking at objects and querying our knowledge banks for similarly related objects and asking about our past experiences, and then projecting the best matched experience onto the current object. We're trying to match the best motivationally satisfying behavior to the object, and that becomes our most optimal behavior towards that particular object. We repeat this process for all objects in transient memory, keep a high score of the most rewarding behavior, and then choose that as our most optimal behavior. What's interesting is that this applies abstraction to objects and doesn't require thousands of training cycles. Imagine an AI character reaches out and touches a burning candle flame. That creates a negative reward for that action. The AI looks at the set of properties which define that candle flame and stores it in knowledge and associates the negative motivational experience. Let's define this by the property set {A,B,C,X,Y}. Now, some time passes, and the AI is looking at a campfire, which has the property set {C,G,H,J,X,Y}. It queries its knowledge base and sees that there is a set intersection between {A,B,C,X,Y} and {C,G,H,J,X,Y} which is {C,X,Y}. It can then say that there is a relationship between the campfire and the candle flame and based on its experience with the candle flame, it can project a predicted outcome to what would happen to its motivations if it touches the campfire, without ever actually having touched the campfire. In other words, we can make generalizations and apply those generalizations to related objects. I was initially making the mistake of defining how much reward each tag was worth. This is wrong, don't do this. Let's talk about reward calculation and how it's related to motive satisfaction, and how this can vary by character class, and character instance. Here is a general set of motives every character will have: Existence / Self Preservation Pain avoidance Hunger Sex Love / Affection Comfort Greed Morality Justice Fear Power Curiosity This is not a complete set of motives, you can add more as you think of them, but the central idea here is that our underlying motives/goals are what truly drive our actions and behaviors. It's the undercurrent to everything we do as humans and animals. The general equation for evaluating reward is going to be defined as: We're essentially calculating the sum of all F(a,b,w) for all changes in motivation factors. Let's look specifically at hunger to illustrate how this works: In our knowledge repo, we have the following: which describes the effects on your motivations when you eat a loaf of bread: It satisfies hunger and creates a little bit of pleasure (the bread is tasty!). We have a few different character actors which have an eating behavior: 1) Humans 2) Zombies 3) Cows 4) Termites For reference, humans like to eat breads and meats, as long as the meat is not human flesh. Zombies are exclusively carnivores who eat any kind of meat and have no qualms about eating human flesh. Cows are herbivores who only eat grass and nothing else. Termites are a type of insect which only eats wood and nothing else. We 100% definitely do not want to write a state machine describing these behaviors and conditions! Let the characters learn for themselves through trial and error and abstraction! So, our token human is hungry and we represent this by setting his initial hunger motivation value to 0.5. In front of him is a loaf of bread and he has prior experience/knowledge with that bread, as described above in the quote. Using our equation, how much reward would he get for performing the "eat" behavior on the bread multiple times? As our human continues to eat bread, it satisfies his hunger and it becomes decreasingly rewarding to continue eating bread, to the point that it becomes a disincentivized behavior when he can't eat anymore (represented by the F(X)=X^3 graph). Let's place zombies and humans and put a chunk of human flesh in front of them both. The knowledge looks like this: It satisfies hunger, but generates a moral crisis! Here's where weights come into play. Internally within the zombie character, we have a constant, fixed weight on the influence of morality on their reward modifier. Zombies have no morality, so they are completely unaffected. Our particular human has a strong moral conscience, so eating human flesh would be deeply objectionable. We *could* adjust the humans morality weighting to 0.8 or something, and if they eventually get hungry enough, the morality consequence could get overridden by the motivation to eat, and we'd have a cannibal. Notice that no extra code would need to be written to create these special behavior cases? These numbers can be adjusted in a spreadsheet to change behavior patterns. We also don't want to go through the process of describing what behaviors can be performed with particular objects. That would add extra work. Let's say we have a wooden door. It's entirely possible and allowable for the human and the zombie to eat the door (or anything for that matter). But how do we prevent them from doing so? If they attempt to eat something they aren't supposed to eat, we simply don't change a single motivating value. They will both learn that eating wood doors does not help them satisfy their driving motives, so when it comes to choosing rewarding behaviors, this would score a big fat zero. If we have an idle behavior which scores a minimum reward of 1, then the characters would prefer to idle around doing nothing before they'd go around eating wooden doors. It's a bit hilarious that the threshold between idling and eating wooden doors is so small though. Taking a few steps back, I think I've got all of the working pieces together now and it's mostly going to be a matter of implementing this. One section that's still missing from this future planning and look ahead. If you are hungry and standing outside of a house, look in through the window and see a ham sandwich, and want to eat it, then there is an intermediate step of moving to a door and opening it. This series of chained actions has a cost which needs to be factored into the reward calculation, and it would also need to be capable of working towards goals which don't exist (such as deciding to plant crops to get food to eat -- the food doesn't exist in present time). For the last week or so, I've been building this AI system out and I've got a rough working prototype. I'm still implementing the underlying framework and discovering design oversights and errors, but I think once this is working, I'll have a pretty unique type of AI capable of abstract reasoning, learning, planning, and optimized behaviors. I suspect that lots of different characters with slight variations in weights, could generate an interesting system of interactions and an economic system of competing interests could be an emergent property of these underlying systems of motivation satisfaction driven behavior. I think this is also reflective of real life? It's been making me look at people very differently for the last few days and it's been blowing my mind a bit.
  8. Me: solo indie dev with ~20 years of programming experience I don't have a formal or highly regimented process, but I also work alone so it's less necessary because I don't have to communicate with other team members. The process I use is very similar to 'agile', but I don't really even bother to follow or know exactly what the agile processes are. I just use what works for me. So, here's how I usually do it: 1. Visualize what I want to build and how it should work. 2. Write it down in notepad++ with as much detail as possible. 3. Think about it really hard. 4. Plan out how I'm going to attack the problem. What data structures will I use? What classes will I create? How will they relate to each other? 4a: I *don't* spend any time drawing class diagrams or any sort of schematics. My philosophy is that if I have to do that, then the problem I'm working on is too big and I need to attack it in smaller chunks. 5. Implement it in code, but cycle between coding and QA very rapidly. 6. QA pass. Does it work? Does it fit the vision? Does it fit the design intent? Is the design good? Is it fun? 7. Completion. Lots of play testing. The play testing will generally reveal some areas to polish, fix or add onto. That returns us to step #1. These usually happen in relatively short, focused sprint cycles. I think game development is a highly iterative process where you're finding your way through a maze. You can do "big design up front" (BDUF) but it generally doesn't work as well for games? Maybe it does for other more experienced designers and bigger games, but for the smaller indie games, it is hard to design 'fun' and get it right the first time. With larger teams though, you'll need to have a much more focused design effort up front because it is the way you coordinate efforts and communication between team members.
  9. A few points that come to mind: 1) To my understanding, the lounge is meant to be sort of a catch-all for posts which don't necessarily fit into any of the other forum categories, and this generally includes politics. 2) Being heavy handed on the enforcement of policies in regards to politics or any other controversial topic can have a broader chilling effect on off topic conversations. I would probably close/delete posts which are trollish in nature and have no substance to contribute towards a broader discussion (political or not). 3) Encouraging diverse perspectives is important. I know I've read some forum posts here over a decade ago about athiesm vs christianity, and at the time I was a christian and laughed at the ridiculousness of athiest arguments, but they made good arguments and eventually I came to see and understand their point of view and gradually became an athiest myself. Just because we don't always agree with a perspective doesn't mean its wrong or not valuable, especially if its well argued and supported. 4) I think of politics and policies as a "proposition of a system", and being a game programmer with some systems engineering background, I see value in examining other systems even if they aren't directly related to games or programming. At the end of the day, we make virtual worlds which have their own systems and rule sets, possibly with their own internal politics (ie, skyrim has Stormcloaks vs Empire). I think art can be a commentary on life, and politics can be a part of our life and culture, so there is a place for political discussion in a game development forum. 5) With the systems engineering & politics thing in mind, sometimes I have ideas for different systems of governance and how it could work. I want to test those ideas and find blind spots by proposing them to other people to get feedback. What are its strengths and weaknesses? If I put it into a game / story, could I use the weaknesses of the system to create conflict in my game/story? Could that act as a form of social commentary? I mean, you can look at Cyberpunk 2077 for examples of this type of commentary and exposition on values, culture, politics and policies. 6) Sometimes, there may not be a clear cause and effect from the discussion of ideas, but they can have influences which show up years later...sometimes in game content and how its presented to audiences. 7) There are political things that happen all over the world, all the time, which directly and indirectly impact the gaming industry (check out gamepolitics.com). A mass shooting at a school? People often blame FPS games. China's internal politics doesn't allow games with mentions about Taiwan, tibet, etc. Lawyers (such as the disbarred Jack Thomson) can make ridiculous claims about games being 'murder simulators' and trying to pass legislation against our industry.
  10. slayemin

    Possible Use of Octree, Please

    I think what you’re really looking for is an LOD system for terrain which would apply a bit of a mesh simplification system based on screen space. An octree could be used to do that, among other options/alternatives. If you’re building your own game engine, be prepared to spend weeks to a month getting it right. If you’re using an existing engine like Unity or UE4, it should already do this for you out of the box and cost you nothing.
  11. slayemin

    How common are non competes?

    Also keep in mind that some non-competes can have terms which extend out months after you leave the job. These are designed to prevent you from taking your knowledge and immediately getting hired on with a competitor to build a competing product. Companies will want to put in a term which makes it so you cannot work in the industry for a set amount of time! This means, you are legally blocked from employment in your industry after you leave the company! Financially, you are making no money, so you would need to be double sure that you are being appropriately compensated so that you can live without wages for that amount of time. In other words, if there is a non-compete clause in your employment contract, you had better be getting paid more than just the base market rate for your skills.
  12. Sorry, I read this and my mind immediately went to a small indie startup which I knew. It was started by a bunch of graduate students from a game school. One of the kids had a rich dad who let his son use a few million dollars to start his own company, so he hired on about 15-20 class mates to make... yet another platformer... and it took them about 3 years. I visited their apartment office a few times to hang out and do play testing on their game. I was a bit shocked. They were NOT running a tight ship. At any given time, about 3-5 of the employees were out on the back patio smoking pot. A few others were watching youtube videos of starcraft 2 games. There was a lot of slacking going on. I kept thinking to myself, "If I was running this company and this is what my employees were doing, I would be busting balls, cracking the whip, and firing the unfixables. I'm not paying people to sit around doing nothing!" That's totally what this company needed. To their credit, they actually finished the game and launched it on Steam. It was well polished, felt good, looked beautiful, etc. But, the game sales flopped completely because nobody thought to do any marketing or market research. The company closed its doors and the rich kid burned a couple million dollars. Whoops!
  13. slayemin

    Begginer at writting for video games.

    From what I understand, world building for a story is pre-production work done before story writing happens. Sometimes, it is an activity that happens alongside story writing (world building -> story writing -> world building -> story writing, etc). I think this applies to all writing, not just writing for games. Writing for games is really just a subset of writing. I'm working on writing the story for my own game. It's a LOT of hard work and planning. The hard part is figuring out what story I want to tell. My current approach is to write the whole story as a novel using discovery writing, then rewrite the story a few times. I figure that between all of the rewrites, each successive story will gravitate towards common plot points that are most interesting to focus on. Once I have the story plot structure and characters well established and have well explored the story space, I'll be ready to adapt it into a game with interactive story telling. When it comes to writing for games, I think the writing format changes. It'll be structured more similar to a screen play than a novel, and you may have branching plot lines which can be filled out based on your explored story space and alternate endings. Sometimes, the story branches are more cosmetic than plot structural, and generally tend to follow a main story arc -- I actually don't know of any games which have drastic changes in plot structure based on player choice. I would say that if you want to write, you should spend a majority of your time writing. You're going to suck. You'll produce garbage you aren't happy with. But those are stepping stones towards better work. When you get more experienced as a writer, you'll also get more experienced at world building and have a better idea on what matters and what doesn't matter. You'll always want to focus on your audience experience first as well! You may like inventing new languages which are functional, but will your audience understand, know, or care about it? What's their user experience like? At the end of the day, whether you're writing books, creating movies, a playwright, making games, etc, we're in the entertainment industry and it is our job to entertain our audiences. Never lose sight of that.
  14. I also use a notepad++ text file for all of my tasks. It's super simple to setup, super simple to manage, and you can instantly change the task organization to exactly suit your needs. If you need to share tasks with team members, just take the plain text and put it onto a google docs file and share it with team members. For small teams of 2-5 people, this will work great and not cost anything. If you have a bigger team, you'll want to use something a bit more structured. Even Todolist might be sufficient for 2-10 people?
  15. Yup, I agree with jbadams. To add, I generally think that the person who started the project is going to also wear the producer hat, among many other hats. If the number of team members increases to the point where the current producer is spending a large amount of time doing 'producer' things while also trying to juggle many other roles, then it's time to delegate that to someone who can do it part time or full time. The general goal is to always be working yourself out of a job by either eliminating it through increased efficiency or delegating it to a specialist.
  • Advertisement
×

Important Information

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

GameDev.net 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!