Ilkor: Character Creation close to completion
Character Creation Screenshot
Here's the first screenshot of the Character Creation page. It is still far from finished in terms of the information, content and detail that you see, however you can get a pretty good idea of what we are trying to achieve.
This screen is reached from completing the signup information on the homepage (email, race, class, gender).
The panel on the left is used to change various aspects of your character. The changes are immediately reflected on the underlying canvas below. There is still alot of information that still needs to be added to the canvas, but the actual panel functionality is almost fully developed now.
The 3 text boxes at the bottom of the panel is used to enter your password, password repeat and gatekey. The gatekey gets emailed to you upon reaching this page.
The avatar to the top right of the canvas is dynamically created based on a combination of email, race and gender. Later on in the game you'll be able to customize your avatar.
You can see from the menu on the panel that you are able to configure your character in areas such as gender, race, class, name [family | House | Clan | Folkname], Starting Settlement, Class Feat and Minor and Major Racial Feats. Each of these animated sub panels that slide out to the right give you additional information where you can make the change.
In a few weeks, we hope to release an alpha version of this character creation process so you will be able to play around and experience it for yourself.
Ilkor: Design Session
Well another week has gone by in the blink of an eye. I can't believe we are almost 1 third of the way through the year!!
The Cape Town based development team (wow all 3 of us! - myself, Chris and Mark) had a very productive design session last Wednesday evening. You guys might not know our setup, but all three of us are developing Ilkor in our spare-time, trying to find the odd hour here and therefore during the day and spending what time our families allow during the evenings and weekends on Ilkor development. It is tough going but extremely rewarding.
Mark and myself work together in the same office for our 'day job' while Chris is about 10kms down the road. Mark and I therefore manage to talk 'Ilkor' on and off throughout the day, at lunchtime and at any spare moment we find in the day when out 'day job' is a little slow. We tend to work long hours at the office so we are able to do both.
I mentioned last week we have our own VPN which all of us can access from anywhere so it doesn't matter, day or night, we can all get access to documentation, source code, etc.
We run Ilkor using a development methodology called Scrum. I'm not going to get into the details of this as it'll most likely bore you to death. However we have been working like this for many years. It basically involves splitting sizeable chunks of work up into small pieces that can be completed in a short period of time. We work on a 2 week cycle. Each cycle is called a sprint.
Our sprints start every 2nd Wednesday. Infact we start a new sprint this coming Wednesday. Part of Scrum involves having a short meeting every day to track process etc. We do this at 7am over Skype. It works very well indeed and sets us all up for the rest of the day.
Anyway...as for the design session. The agenda was to really go over a number of topics. We reviewed the database model, which as I mentioned the other week, and is really taking shape. It's not complete but a large section (specifically the metadata) is now fully designed.
We also reviewed the map engine and editor. Chris demo'ed what he has achieved to date and it is going to be completely amazing. I really want to share this with you guys but not until we have the finished tilesets, world and regional illustrated maps from Jon. To show this off before then will not do the engine justice. Anyway we thrashed out some of Chris' concerns, mostly technical around terrain transitions and the approach to both roads and rivers. We settled on a great solution which Chris is well into implementing already.
Finally I gave a presentation around the player interfaces, the pages that will be served up to the player while he plays the game. Between Simon and myself we have come up with a great navigational structure that we feel will be very intuitive, something I believe more than 90% of the text-based browser games fail to achieve. The session went well and I was happy to see that both Chris and Mark managed to understand the structure. With some feedback I'm now revising some areas before Simon will then take the brief to work on the design drafts further until we are happy. This includes the 'look and feel' or the theme of the site, which in many ways is equally as important.
All in all we've had a hugely productive week. The artists are making alot of progress, especially Jon who has taken our comments regarding the initial map snippet that was given to us. The final finished world map is expected to arrive sometime this week, we are all very excited, maybe next week we can share a small snippet of the map to you! :-)
We've now got just over 2 months to go before we intend on launching the ilkor.com website that will really just be a holding page with some info on the game and the ability to join the playtest. However this is going to be a huge milestone for us. If we can make it, it'll mean we are finally live, will have a real web presence and then have only 6 months to complete what is needed to launch the playtest at the end of 2011.
I'm really hoping that early into May we'll start to have some nice illustrations, maps and screenshots that we'll be able to give you a sneak preview of.
Cheers,
Sean.
Combining Turn-based with Real-time
This continues from my original post.
Ilkor: Dark Rising is going to have a mixed turnaround. It isn't going to follow the typical PBM's of old where a turn is processed every 1 or 2 weeks. Since it is going to be a web-based browser game and people today generally expect immediate results we have decided to try and mix turn-based with real-time.
We're still in the development phase so we haven't ironed out all the potential concerns and issues, but currently our line of thinking is to run the game with three timelines:
- Turn
- Phase
- Real-time
Turn: This is the typical PBM turn as it is known. It will be a weekly turn-around. The turn number will be incremented at midnight every Friday. A turn will represent about 2 weeks in the game world.
Phase: A turn is broken up into 3 phases. Each phase has a deadline date, midnight on Monday (phase 1), Wednesday (phase 2) and Friday (phase 3). The phase 3 deadline of midnight Friday coincides with the end of the Turn. Orders are processed in a 'batch run' at midnight of each phase.
Real-time: During a phase various Actions are permitted. They will be processed immediately and the player will receive the result of the chosen action there and then within the website. Some real-time actions will spawn off emails to players in the form of a notification.
A player is expected to log on at least once per phase. That equates to a minimum of 3 times a week. The various instructions that a player can issue per turn are expected to be spread out over the 3 phases. This is done for a number of reasons:
- Reduces the risk of a list of instructions (orders) failing due to a knock-on effect from a failed instruction;
- Reduces time required to 'submit' a turn; each phase submission could be completed in less than 10 minutes. Breaking it up into 3 smaller chunks (phases) will help new and experienced players understand what they can do, how to issue the instruction and by when;
- More in-line with current expectations of 'browser gamers', but still retaining a large degree of the PBM turn-based strengths;
- Increases traffic & on-line activity (important for player retention and possible revenue streams);
There are 3 possible ways a player will be able to interact with the game during a turn:
- Actions
- Orders
- Tasks
Actions: These are performed in real-time. The player will be able to issue these actions immediately and receive the result. Such actions will not give the player an adverse advantage should he issue them before another player. We don't want to get ourselves into a situation where players that issue such actions early on in a phase get advantages over another player who isn't on-line or chooses to only issue actions at another time. The only time an action cannot be issued will be when the phase is processing it's batch of orders (at midnight of the Mon, Tue & Fri). A player has the choice to stay on-line the entire week and issue actions as and when he pleases, or he can log on once a phase and issue actions, or even once a turn (not advisable). A player will have 'x' number of actions he can perform in a turn. Lets call that number 20 for illustration reasons. This number may increase over time as his character advances through the game. Any un-used actions within a turn do not carry over to the next turn. The player may perform all 20 actions in the first phase or spread them out over all 3 phases etc. Each action type can only be performed 'x' number of times within a single turn. For example, a player might be restricted to only 3 Buy Actions per turn. We think there is enough combinations here to really make the player think long and hard regarding which actions he is going to perform, in what order and in which phase.
Orders: These are submitted and only processed at the next phase deadline. Orders can be added, edited and deleted between the start of a phase and the end of the phase (midnight). The duration of a phase is about 48 hours (phase 1 is 72 hours due to taking place over the weekend) so the player is able to alter his set of orders as many times as he wants within this time period. All orders will be processed on the deadline of the phase. All player orders will be processed at the same time, ordered in a logical manner (to be revealed later). Examples of orders could be movement. Potentially the player's character has say 45 movement points in any given turn. He could instruct his character to move north in phase 1 until all the 45 points are exhausted. Or he could just use up 20 points by moving north 2 locations. He may issue this move morning early on in the phase or right at the end. It doesn't really matter when he does this, just so long as it is done before the phase deadline. He could even recall the move order or change it. When the phase deadline kicks in, all move orders for all characters will be processed. Combat will also be dealt with in a similar fashion. This batch approach gives a nice twist to the dynamics, is more in line with traditional PBM (turn-based) and gives every player a chance to prepare themselves, rather than being at a disadvantage to those that are either on-line continuously or early on in the phase.
Tasks: These are very similar to actions in the sense they are processed in real-time. Tasks however are instructions that can be performed as many times as you wish. Tasks also do not really have a major effect on either your character, another player or the world in general. These instructions can be seen as house-keeping instructions, such as changing player preferences, sending a message to a player or the GM, equipping your character with an item from his backpack, etc.
I'm not sure if this article has explained what we are trying to achieve. Hopefully it makes some sense. I would be very interested to hear anyone's comments.
Cheers,
Sean.
Turn-based or Real-time?
This question had been on my mind for many years. Prior to getting stuck into development of Ilkor, I had known for a long time that when the time was right I wanted to get back into Play-by-Mail (PBM) and design, develop and run a single character fantasy RPG. To keep up with the times I knew it would have to be 'online' and most likely free. I also wanted to stay true to the strengths of traditional classic RPG and PBM. For me, that meant it had to be turn-based. This in itself is going to be a huge challenge to get right.
Although Ilkor's roots are in PBM, it is going to be thrown head first into the ocean of 'text-based browser games'. In all honesty it is going to be compared to such games as 'Dark Throne' and 'Torn'. While these games lack the depth I am hoping to capture they do have a lot of features that I am after...if I am honest with myself. I think we need to learn from these games if we truly wish to succeed in the online market.
If we ignore the potential 'depth' issue of such games, they can be seen as 'modern PBM' games. I know a lot of PBM purists will disagree but they are offering a game with orders and instructions that are issued usually by the use of clicking on buttons, radio buttons, check boxes, etc. There are a few that use a turn-based approach; the majority are 'real-time'. In other words the results of the player's actions are immediate. I can buy why they are designed like this, users online today expect immediate results, that is the key advantage of being online - not so?
So turn-based PBM goes completely against the grain. What is the point of going online, issuing a handful of orders and then having to wait several days (maybe even a week or more) for the results? If you are from the PBM days you know the answer to that...anticipation.
So, what is it going to be 'turn-based' or 'real-time'? This is the question and something I have been toying with for many years. Turn-based is without a doubt the hardest to achieve successfully online. However it is core to the PBM experience.
So despite the difficulty, Ilkor is going turn-based.
But that is not the end of the problem. There are a number of different turn-based systems. In the PBM world, games either have a 'fixed turnaround' or a 'varied turnaround'. I have always wanted Ilkor to be fixed turnaround.
However this also has caused many headaches. Fixed turn-based single character RPG!! It had always been a challenged even back in the glory days of PBM. For those reading this that might not quite understand, let me explain. Turn-based PBM generally fell into 1 of 2 categories. It was either fixed or it was varied.
Varied allowed the player to submit his orders at his own speed. Maybe he played weekly, every 2 weeks or even longer. The varied turnaround meant that the company responsible for processing the orders would process orders as and when they came in. Player 'A' and player 'B' might post their orders in on the same day but the postal system delivered them 2 days apart. They would therefore be processed in the order that they arrived. It generally gives the players who play more frequently and who submit their orders quickly the advantage. Companies did attempt to put rules in place to reduce the advantage, however only to a certain degree.
Fixed turnaround on the other hand means just the opposite. A game might have a 2 weekly turnaround with deadline dates set to every second Friday. The game would process all the orders from all the players simultaneously on every second Friday and then post out the results. The players would receive their results maybe on the Saturday or Monday and then have almost 2 weeks to study their results and ponder over their next set of orders before submitting them.
Varied turnaround generally suited single character games, like RPG (just about all the hand-moderated games ran like this and even the computer moderated games like Quest, Dungeon World, etc.). Fixed turnaround was used mostly with games that involved conquest, discovery and sport management games.
I personally really enjoyed the 'fairness', structure and simplistic nature of fixed turnaround games. It enhanced diplomacy, emphasized the importance of planning, tactics & teamwork and heightened the anticipation of receiving the turn results.
Having said that, I actually preferred RPG to wargaming. I was forever searching for a decent RPG that used fixed turnaround.
Having been both a player and a GameMaster I can see the reasons why fixed worked well with wargames and varied worked with RPG, however I never really bought the story that this is the only way it can be done.
So is that the end of the story? Is Ilkor going to be a fixed turn-based single character fantasy RPG that is played online through the browser?
Well not quite. 
Why can't it be a hybrid? Why can't it be a mixture of both fixed turn-based and real-time? The strength of PBM is in the turn-based system and the strength of online is 'real-time'. The question is how can this be achieved to produce a modern online PBM?
I think I've got the answer to that, but this article is already long enough, so I think I'll leave the details to our solution to another time.
Cheers,
Sean.