I did upgrade to django 1.0 Alpha. No real problems yet, but we'll see.
I've also added a list of things to be done on the side of the page. Right now it's views for the Stone Age release. I've decided to work on things in the order which the user will see them, so first connecting User registration to Avatar creation, and User sign-in to Avatar selection. Then the map and some interface stuff.
Thought you'd like to know.
Friday, July 25, 2008
Milestone, and moving on
User sign up is done thanks to some good django documentation, and no thanks to some bad django documentation.
Since user registration is almost-universal to web applications, there are plenty of resources on how to do it. Most of the programming is copy-paste-edit from my Avatar creation forms and views.
The only problem was creating a user profile model. This model saves extra data about a user that isn't in Django's included User model. I haven't thought of anything to add, but I'm sure I will, so I worked on it anyway. The problem came when connecting the models together with a foreign key. The main docs don't indicate that this foreign needs to be called 'user' to work correctly (I named mine 'djangoUser'). The Django book correctly notes this. I created a ticket about this, so we'll see what happens.
And with that, at 5:33PM, on Friday, July 25, I officially close main development on the back-end models for my initial release (hereon codenamed 'Stone Age') and move up a level to start writing views.
Since user registration is almost-universal to web applications, there are plenty of resources on how to do it. Most of the programming is copy-paste-edit from my Avatar creation forms and views.
The only problem was creating a user profile model. This model saves extra data about a user that isn't in Django's included User model. I haven't thought of anything to add, but I'm sure I will, so I worked on it anyway. The problem came when connecting the models together with a foreign key. The main docs don't indicate that this foreign needs to be called 'user' to work correctly (I named mine 'djangoUser'). The Django book correctly notes this. I created a ticket about this, so we'll see what happens.
And with that, at 5:33PM, on Friday, July 25, I officially close main development on the back-end models for my initial release (hereon codenamed 'Stone Age') and move up a level to start writing views.
Friday, July 18, 2008
Auto-monster
Ever since I came up with the idea of V, the problem of monster movement and generation chewed on the back of my head. Somehow, no matter what programming language or platform, things had to happen on their own. I would always sooth the teeth marks with "Somehow I'll use threads, or maybe crontabs if I have too." A few weeks ago, with very little left on the menu, I finally tamed the beast, and following what is becoming a V standard, I created an independent system for handling background tasks.
MinLis, or Minute Listener, runs saved events at a scheduled time. It works as a background thread that wakes up every 60 seconds. It checks the database for any events scheduled to run, fires those events, and goes back to sleep. The events are django models saved to the database. They store the scheduled time to run and how often to repeat (if at all). So far there are two type of events, events that can run a method on a model (using generics) and events that run a string through python's eval(). This way, to schedule something to run, all you have to do is save an Event to the database. One problem the eval creates is that modules must be included somehow, so I still need to create a separate include file. I created MinLis as a separate django application and have also created a google code project for it. I haven't done anything to the project yet, but once she's polished I will open her up to the world.
With MinLis working in the background, I started moving monsters around. I added a preferred map type field to the monster type model and an aggression level to monsters (these were always planned, but not necessary until now). The code for wandering monsters moves any monsters with a low enough aggression to a random surrounding map cell of the preferred type. A MinLis scheduled event runs the code every 5 minutes.
Finally, I finished monster generation. Another new field in MonsterType tracks the average number of monsters of that type that should exist. The generation code checks if the current count of existing (or waiting to exist) monsters is under this average. It then creates a random number more, but schedules them to be created every minute so that they don't all pop into existence at once. This is scheduled to run every couple of minutes.
Many of these timings will eventually be randomized. I don't want users to anticipate that every 5 minutes monsters move. But for now it's fun to kill a couple of Trolls, wait for new ones to pop out, and then watch them walk around (okay, all of this is still through text logs, but it's still cool anyways).
Amazingly, there is only 1 item left before I start moving forward with views: User sign-up. Today is django sprint and they are apparently going to merge the newforms admin into the trunk. I'm going to wait a little while, see if there are any problems, then update and see what (if anything) breaks.
Plus, there's a new beast lurking: Quest system.
MinLis, or Minute Listener, runs saved events at a scheduled time. It works as a background thread that wakes up every 60 seconds. It checks the database for any events scheduled to run, fires those events, and goes back to sleep. The events are django models saved to the database. They store the scheduled time to run and how often to repeat (if at all). So far there are two type of events, events that can run a method on a model (using generics) and events that run a string through python's eval(). This way, to schedule something to run, all you have to do is save an Event to the database. One problem the eval creates is that modules must be included somehow, so I still need to create a separate include file. I created MinLis as a separate django application and have also created a google code project for it. I haven't done anything to the project yet, but once she's polished I will open her up to the world.
With MinLis working in the background, I started moving monsters around. I added a preferred map type field to the monster type model and an aggression level to monsters (these were always planned, but not necessary until now). The code for wandering monsters moves any monsters with a low enough aggression to a random surrounding map cell of the preferred type. A MinLis scheduled event runs the code every 5 minutes.
Finally, I finished monster generation. Another new field in MonsterType tracks the average number of monsters of that type that should exist. The generation code checks if the current count of existing (or waiting to exist) monsters is under this average. It then creates a random number more, but schedules them to be created every minute so that they don't all pop into existence at once. This is scheduled to run every couple of minutes.
Many of these timings will eventually be randomized. I don't want users to anticipate that every 5 minutes monsters move. But for now it's fun to kill a couple of Trolls, wait for new ones to pop out, and then watch them walk around (okay, all of this is still through text logs, but it's still cool anyways).
Amazingly, there is only 1 item left before I start moving forward with views: User sign-up. Today is django sprint and they are apparently going to merge the newforms admin into the trunk. I'm going to wait a little while, see if there are any problems, then update and see what (if anything) breaks.
Plus, there's a new beast lurking: Quest system.
Subscribe to:
Posts (Atom)