• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Liza Shulyayeva

Members
  • Content count

    65
  • Joined

  • Last visited

Community Reputation

624 Good

About Liza Shulyayeva

  • Rank
    Member

Personal Information

  1. A couple of weeks ago I had the genius idea to rewrite SnailLife in Go. I’ve already looked into doing this once before a couple of years ago, but wasn’t really feeling it and stuck with PHP (mostly for nostaligia reasons). Now though, SnailLife is this bloated PHP app. Most of the core functionality is in. After weeks of battling infrastructure issues, when everything was back up and running again, I took a step back and saw how big the app (or rather the 3 apps now) had become. At the same time I’d been reading in passing about Go and became curious, so I figured - why not look into learning Go by rewriting SnailLife? Not because I think Go itself will necessarily make anything better, but because a rewrite might. The features are mostly already designed, reimplementing them in another language would hopefully let me focus more on improving the overall project structure while learning the new language of choice. Of course, the “learning the new language of choice” part also increases the likelihood of my turning my messy PHP app into a messy Go app as I go, but…it’ll be fun, OK? Anyway, I’m not yet sure if I’ll stick with the Go port or if I’m just amusing myself for a while before going back to the already largely implemented PHP version. So far I haven’t coded anything snail-specific and have instead been focusing on setting up database-related packages. I’ve made the code public on GitLab for now, though not sure if that’ll change when I go into writing the more snail-specific functionality: https://gitlab.com/drakonka/gosnaillife When I started the PHP version of SnailLife, I started by building the website and the main functionality that lets users interact with their snails. As time went on this focus switched almost exclusively to the back-end, and to working on functionality that required no user interaction. I realized that this is what the core of the idea was - simulating the actual snails - the brain, organ function, etc - things that the user could eventually influence indirectly, but things that would tick away on their own even if no user was involved. So for the Go version I am not starting with a web front end but with a simple CLI, and focusing on implementing the core of the snail itself first. Eventually I can build whatever front-end I want, or even multiple front-ends if I feel like it. Heck, I could even expose some sort of API for others to make their own apps on top of the simulation (if anyone wanted to, in theory). Go notes to self Open and close DB connections as little as possible - the driver handles connection pooling for you, you should only really need to do it once. Best way of reusing constructors between tests might be to create some test utilities outside of _test files which are imported only by the tests. Example usage in my case is creating a test db and table to run my mysql and repo tests against, which are in different packages. Every directory is a package. There is no way to structure code in subdirectories without each subdirectory being a separate package. Make use of table driven tests. They allow you to run multiple test cases per test. interface{} is an empty interface and can hold values of any type…avoid passing this around too much, better to learn to structure the code so you don’t have to. Go code looks to be very easy to move around and restructure if needed, so it should be fine to experiment with different project structures as I go. Current tentative project structure drakonka/gosnaillife ├── cmd │ └── snaillifecli │ └── main.go ├── config │ ├── dev │ │ └── database.json │ └── env.conf ├── lib │ ├── domain │ │ ├── item │ │ └── snail │ │ ├── snail.go │ │ └── snailrepo.go │ ├── infrastructure │ │ ├── databases │ │ │ ├── database.go │ │ │ ├── mysql │ │ │ │ ├── delete.go │ │ │ │ ├── insert.go │ │ │ │ ├── mysql.go │ │ │ │ ├── retrieve.go │ │ │ │ ├── tests │ │ │ │ │ └── mysql_test.go │ │ │ │ └── update.go │ │ │ ├── repo │ │ │ │ ├── repo.go │ │ │ │ ├── repoutil.go │ │ │ │ └── tests │ │ │ │ ├── repo_test.go │ │ │ │ ├── testmodel_test.go │ │ │ │ └── testrepo_test.go │ │ │ └── tests │ │ │ └── testutil.go │ │ ├── env │ │ │ └── env.go │ │ ├── init.go │ │ ├── init_test.go │ │ └── util │ │ ├── collection.go │ │ └── err.go │ ├── interfaces │ └── usecases
  2.   Thanks! Hoping to not disappoint :)
  3.   Technically yes, but I have not yet made it available for people to start using (not that anyone would be clamouring to try it anyway, I think it would actually be pretty boring for anybody except me - the focus is very far from "fun"). But because I have a goal to hopefully attend the European Conference on Artificial Life this year, I'm using that as a bit of a vague deadline to have something a bit more interesting and functional to show by that time (whether that be the simulation itself or the brain visualization debugging tool I mentioned above). We'll see how it goes though; I've been working a lot lately so not sure how much time or energy I'll have to really get there in time.
  4.   I wouldn't call it a game; it is intended to be more of an amateur browser based life simulation. You find, raise, race, and breed snails and manage a snail stable :)
  5. It has been a while! SnailLife work has been moving at a snail's pace. Why? Because debugging the snail brain has turned into a highly demotivating, hellish endeavour. The snails make decisions and perform actions based on so much *crap*, that the simple log files I was using all long are just not cutting it anymore. The Laravel log for the original app has turned into 3 Laravel logs because I now have 3 independent apps (the front-end, BrainRunner, and BrainHub to coordinate all the brain runners). That then turned into individual log files per snail plus individual log files per brain task. And still making sense of why snails are choosing to behave in certain ways is nigh impossible - the brain *and* infrastructure issues I have been facing have been seemingly neverending. Logging issues aside I have added some debug settings to help me narrow down issues. The BrainRunner app now has a snail debug config file which allows me to disable the following actions that would otherwise take place on each brain check: growth life check idle action check organ impact check bodyweight check movement feelings of claustrophobia feelings of loneliness More settings will be added, such as disabling sensory/short term/long term memories, for example. The "idle action check" is where the bulk of the "magic" happens, that is the biggest black hole. Adding options to disable certain functionality has helped, but the whole thing has been demotivating to say the least. I got into this to simulate snails, not work on debugging tools. And yes, of course I realize when dealing with a convoluted system like this I should have known what to expect. I did sort of expect this...I just chose to ignore it until the last minute to work on more fun things ;) After putting in a great deal of effort to remain organized and do things right in my projects at work, I've allowed good behaviour to fly out the window at home. Anyway, I have now moved logging out of local log files and into Loggly. It's not done yet, but the main logs like Laravel logs from the BrainRunner and BrainHub, snail logs, and brain task logs are all in Loggly now (in addition to the local machine). To send the default Laravel logs to Loggly for each app I added the `configureMonologUsing` method in bootstrap/app.php: $app->configureMonologUsing(function ($monolog) use ($app){ $today = date("Y-m-d"); $logFileName = "logs/laravel-$today.log"; $monolog->pushHandler(new MonoStreamHandler(storage_path($logFileName), MonoLogger::INFO)); $monolog->pushHandler(new MonoStreamHandler(storage_path($logFileName), MonoLogger::WARNING)); $monolog->pushHandler(new MonoStreamHandler(storage_path($logFileName), MonoLogger::ERROR)); $monolog->pushHandler(new MonoStreamHandler(storage_path($logFileName), MonoLogger::CRITICAL)); if (CoreUtility::InternetOn()) { $envlabel = strtolower(env('APP_ENV')); $maintag = "brainrunner_$envlabel"; $envtag = "env_$envlabel"; $logglyString = CoreUtility::buildLogglyPushHandler(array($maintag, $envtag)); $monolog->pushHandler(new LogglyHandler($logglyString, MonoLogger::INFO)); $monolog->pushHandler(new LogglyHandler($logglyString, MonoLogger::WARNING)); $monolog->pushHandler(new LogglyHandler($logglyString, MonoLogger::ERROR)); $monolog->pushHandler(new LogglyHandler($logglyString, MonoLogger::CRITICAL)); } return $app;}); Aside from having all of my logs in a central place, Loggly lets me query the logs easily to get more relevant information. I use tags to distinguish between individual brain tasks, snails, apps, environments, etc. But that is not enough. I feel to debug the brain in its current state having a visual representation of the brain would help a great deal. What originally made me think about this was my earlier experimentation with TensorFlow and TensorBoard. TensorBoard provides a visual of your TensorFlow graph and lets you interact with said visual to see how tensors flow between operations. The brain as I have it can also be represented as a set of nodes (each node representing a neuron), and I should be able to visualize the flow of inputs between neurons in a similar way. What if I could have a graph for every brain task that runs on every BrainRunner and see exactly what path each input took and why? I think I will look into this next. As you can see I have not been doing much work on the actual *snails* here. But I think the return on investment in improved debugging tools will be worth it if I have any hope of getting any further with simulating a snail brain. On another note it looks like ECAL 2017 ticket prices are out and I'd better start saving: https://project.inria.fr/ecal2017/registration/
  6.   From what I understand (and I didn't look into this in-depth so please correct me if I'm wrong), while technically this might be true the only other option you have is to host your own servers. You are apparently not allowed to use other third party hosting options, so the options are either AWS or self-hosting. Which to me is still not sounding that bad for what you get, but there is some restriction there.   As someone who used EC2 and Amazon's deployment solutions for a while before I got sick of the maintenance aspect and having instances go down only to spin up in incorrect regions I'd be wary of hosting all of my infrastructure with AWS again. But of course this was just one personal project, where I didn't feel like doing all of the ongoing maintenance myself - if you really go all out to set up everything professionally and manage it AWS could be a great option.
  7. I've never used GitHub to gain visibility or collaborators for my projects - I've used it purely to have a remote location I trust to store my code and its history. Although I was happy paying $5 per month for a limited number of private repos, when my private repo requirement went up I switched to GitLab.
  8. I finally have two BrainRunners working on a DigitalOcean droplet, and one BrainHub on another droplet queueing and assigning tasks to the runners. It's still rough, but let's start with the BrainHub's scheduled artisan commands (Artisan is the CLI that comes with Laravel): [font='courier new']QueueIdleBrainChecks[/font] runs every minute. public function handle() { // Find snail due for brain check. $snailController = new SnailController(); $allIdleSnails = $snailController->getAllIdleSnails(); foreach ($allIdleSnails as $snail) { // Seconds since last brain check $diff = Carbon::now()->diffInSeconds (Carbon::parse($snail->brainCheckedAt)); if ($diff >= 60) { $existingQueuedBrainCheck = QueuedBrain::where('snailID', '=', $snail->snailID)->first(); // If brain check is not already queued, queue a new check if ($existingQueuedBrainCheck === null) { $queuedBrain = new QueuedBrain(); $queuedBrain->snailID = $snail->snailID; $queuedBrain->save(); } } } } This basically just gets all living idle snails from the `snail_life` db and creates a new brain check entry in the `brain_hub` db. Also every minute we run the [font='courier new']AssignBrainsToRunners[/font] artisan command: public function handle() { $brainRunnerRetriever = new BrainRunnerRetriever(); $allIdleBrainRunners = $brainRunnerRetriever->getAllIdleBrainRunners(); $taskRetriever = new TaskRetriever(); foreach ($allIdleBrainRunners as $brainRunner) { $task = $taskRetriever->GetNextQueuedTask(); if ($task !== null) { $brainRunner->assignQueuedTask ($task); } } } This finds any available (idle) brain runners and assigns the next queued tasks to them. In the `BrainRunner` model: public function assignQueuedTask($task) { // Change status of BrainRunner to 1 - Busy $this->updateStatusCode(1); $url = $this->url() . DIRECTORY_SEPARATOR . 'api/runTask'; Log::info('assignQueuedTask url: ' . $url); $postfields = 'taskID=' . $task->id . '&snailID=' . $task->snailID . '&runnerID=' . $this->id . '&hubURL=' . env('APP_URL'); $curl = curl_init(); curl_setopt_array($curl, array( CURLOPT_RETURNTRANSFER => 1, CURLOPT_URL => $url, CURLOPT_POST => 1, CURLOPT_POSTFIELDS => $postfields, CURLOPT_TIMEOUT_MS => 2500 )); $resp = curl_exec($curl); curl_close($curl); // Delete task from queue $task->delete(); } The brain runner then runs the task: public function RunTask($task) { try{ $this->taskID = $task['taskID']; $this->hubURL = $task['hubURL']; $this->runnerID = $task['runnerID']; // Get runner specific logger $utility = new Utility($this->taskID); $logger = $utility->logger; $snailController = new SnailController(); $logger->addInfo('INFO: RunTask: Initialized SnailActionController'); // The recurring event is actually not required anymore, // but we kind of hack it together because before the BrainHub // the snail brains relied on it and still do temporarily. $event = new RecurringEvent(); $event->name = 'IdleSnailAction'; $logger->addInfo('INFO: RunTask: Initialized IdleSnailAction Event'); // Find the snail $snail = $snailController->findSnail($task['snailID']); if ($snail === null) { $logger->addError('ERROR: Snail ID ' . $task['snailID'] . ' NOT FOUND.'); } else { $logger->addInfo ('INFO: RunTask: Found Snail ID: ' . $snail->snailID); $snailActionCoordinator = new SnailActionCoordinator(); $snailActionCoordinator->checkAction([$snail], 60, $event); $logger->addInfo ('INFO: RunTask: Action Checked'); } $logger->addInfo ('INFO: RunTask: Reported task as finished'); // Save log to S3 (might rip this out later as we don't need to keep that many logs anyway) $utility->saveLog($this->runnerID); } catch(\Exception $e){ $logger->addError('ERROR: RunTask: Exception Caught, cancelling task'); $logger->addError($e); } $this->reportTaskFinish(); } The BrainHub connects to both the main SnailLife database and the BrainHub database. BrainRunners can only connect to the SnailLife database. The only thing that ever reads from or modifies the BrainHub DB is the BrainHub itself. SnailLife logo and website I have been getting really sick of looking at the ugly black and white SnailLife website. So I decided to try and make it a little more exciting. It's still ugly, but at least it's colorful-ugly now! I stumbled across a bunch of open source logos over at Logodust. I felt like taking a break from the BrainHub for a while and messed around with combining two of the logos and adding an eye stalk to make something vaguely resembling a snail. The logo is also quite versatile in case I ever decide to ditch the snail idea, since I've been told it looks like a chinchilla or one of those deep water fish with the light in front of its face as well... [font='Noto Serif'] [/font][font='Noto Serif'] So now the site is, though by no means great, just a little less bland:[/font][font='Noto Serif'] [/font]
  9.   This sounds like it would make a really really interesting story. You should write it. 
  10. Note: This post may make more sense if you also check out the one I posted before Christmas on my blog (which I unfortunately forgot to also post here at the time: http://liza.io/the-brain-scope-is-growing-brainhub/ I've started this post maybe twenty times now, since before Christmas, and each time I keep putting it off, thinking "I'll just blog when I have this next bit done." But each "next bit" is followed by something else, and then something else, into infinity. So I'll just write an update. Since before the holidays I've been working on BrainHub and BrainRunner, which I've already written about. Basically - checking each brain every minute as part of the main SnailLife app was becoming unmanageable. All background processes will be moved to complementary apps away from the user-facing SnailLife application. The idea is to have a BrainHub controlling tasks sent to individual BrainRunners (which are hosted on other DigitalOcean or EC2 droplets). So, here is the first iteration of the BrainHub admin site. The BrainHub has its own database of queued tasks and BrainRunners but also connects to the main SnailLife database and imports a package called SnailLifeCore to be able to get information about brains due for a check and allow admin SnailLife users to log in/control the hub. It is sort of functional in that BrainHub runs 2 scheduled tasks: QueueIdleBrainChecks AssignBrainsToBrainRunners Both of these run every minute. The first gets a list of brains that need to be processed and puts them into the queued_brains table in the brainhub db. The second, AssignBrainsTobrainRunners, looks for any idle brain runners (brain runners with status code 0) and assigns the next brain in the queue to them. Then, the brain runner checks the brain and reports back to BrainHub with the result, which releases the runner to process the next brain in the queue. Right now there are some issues - runners don't get consistently released, for example. Should be easy enough to fix, but for now I've added an emergency release button to the admin site (you can see it above). But right right now I am working on logging. The brain runner creates a new log for each brain task it runs. These then need to be backed up to AWS S3 (as opposed to being stored on the Droplet itself), and then the admin site will display the logs by-task for each runner. There is a mountain of work to do on this but it feels like I'm sort of over the main hump of setting up the core package and the BrainHub and BrainRunner apps to sit alongside the main SnailLife app.
  11.   That's funny, I have the opposite opinion of European game companies. To work in games again I got my Australian citizenship and moved from Australia to Europe (Sweden) on a working holiday visa, then looked for work. Browsing through the job ads in Sweden was like walking through some sort of magical game development company fantasy land - there were so many games companies, and so many hiring (in comparison to where I lived in AU anyway). Of course there was also more competition, but that's expected. Depending on where you are exactly the opportunities in Europe definitely are there.   From what I gather you area already in Europe? Is your country part of the EU? This makes it so much easier to relocate, and also makes it easier for a company to hire you remotely either with relocation included or with your ability to relocate yourself, as there is far less hassle with visas and such. If you are not in a country that's part of the EU you may want to consider saving up and physically moving yourself, then looking for work - I know it's a bit scary, but in my case that seemed to be the only option to actually have a company seriously consider an application for a non-senior role.
  12. I read this a few years back and it was excellent. You're right, it really sucks you in. Does anyone have any recommendations for others like it? Jordan Mechner's Prince of Persia diaries were also great.
  13.   The simulation is online and usable, but tbh I am still afraid to let anyone else try it out simply because it is still so ugly, rough, and unintuitive with plenty of errors. I am focusing on refactoring now and then will focus on bug fixing. I'm also hoping to find a front end designer and developer to collaborate with at some stage. I'll have a few people I know try it out first and then maybe open it up publicly. 
  14.   Yup, the foot is the muscle snails use to move across the ground.   I actually go over your question re immunity in the post, sorry if it was unclear. A snail starts off with 100% of whatever its base immunity is. It _lowers_ as the snail ages, so that as the snail's immune system gets weaker with age it cannot recover from damage as easily as it would when it is young.
  15. Organs! Immune systems! Old age! Dying from old age! I'm super excited. I was thinking: "How do I implement old age and death, and health in general? Is health just energy? When the snail is out of energy, it dies? But that seems too simplistic." At this point I should have realized that 'simplistic' is a good thing. Instead I decided to try to mimic a scenario that is a little closer to real life. Again, I am no snail expert or biologist and mostly I just...guessed. I want to tweak the system when I move more into the research phase of the project vs the implementing random features and fixing bugs phase. I have a feeling this should have been done the other way around. Anyway - why does any living organism die? It seems that we die either because of some trauma or injury to our internal organs or...old age. But what is old age, really? How is it different from trauma or injury to our internal organs? From the very brief amount of reading I'd done it's partly about telomeres and how efficiently our cells can keep dividing as we get older. Telomeres protect our chromosomes. Each time a cell divides, our telomeres shorten until eventually our cells can't divide anymore. And then what? I think that's when we become more prone to age-related diseases. The immune system is apparently highly related to the length of the telomeres. And when your immune system gets worse our bodies can no longer handle various illnesses as well as they used to, which eventually results in that first thing - trauma or injury to our internal organs that we can no longer recover from. My cat Rigel has a damaged bladder. A vet "broke" him and he has been handicapped ever since. The bad news is that he may now need to be on medication for the rest of his life. The good news is that there is a chance, especially since he is so young, that his bladder will regenerate over time. The cells and nerves of his bladder may still kick themselves into shape over months or years and he may be able to take a little less medicine or maybe, if a miracle happens, eventually none at all! This is how I want the snails to work. Organ damage can be sustained, but with a high enough immune system the snail may be able to recover and at least partially heal/regenerate itself. As the immune system weakens organ damage becomes permanent and the snail is not as able to recover. Eventually the snail is just too weak, its organs start failing, and it dies. The details I've kind of done it in a really hacky way...like all the experimental features so far...which is pretty much all the features. Organs So a snail has a base organ efficiency score and an organ efficiency percentage. Eg: baseHeartEffic: 60 heartEfficPerc: 100% baseLungEffic: 45 lungEfficPerc: 90% The organs so far are: Yes, I know a snail has more organs than this. But I have sort of stayed away from organs that already are represented by sensors in the brain. These include eyes (vision is accounted for), mouth (taste is accounted for), tentacles (touch is accounted for). Theywill be added eventually, but I wanted to focus on the others for now. All snails start with 100% efficiency for each organ. At first I was thinking of not havingbaseXEffic at all and just have a 0-100 percentage for each snail, but I realized this would be boring. All snails are not created equal. Just as Secretariat had a very large heart, a snail can have a much stronger or weaker organ than average. A simple percentage standard across all snails would not allow for the amazing outliers of nature that we see in real life. Ageing Snails already have a maturity rate (the rate at which they grow after birth). I decided to reuse this for ageing. Snails age every hour. Until a snail is mature it grows each hour based on its maturity rate. Once a snail is mature it begins to age and deteriorate every hour. The amounts may be small - something like 0.05% decrease in immunity per hour. You will be able to boost immunity with supplements, medicines, etc, but for now we are just focusing on the snail's natural rate of ageing here. Each minute we check for idle snail actions. Each minute we will also check for any organ damage as a result of those actions. For example, if a snail is operating at 95-100% physical effort it may have a higher chance of heart, lung, or foot damage. Recovery I have not built recovery in yet. I want to see how long a snail might live without any recovery of the organs. Recovery is to follow! First I think a big refactoring is in order. As I look back at some of the older code I can see a lot of cleanup that needs to be done in general. I think I'll do that over this weekend and then continue.