Areum will be a 2D top-down medieval fantasy MMORPG. We want the game to be like playing a multiplayer version of classic RPGs such as Lufia, Chrono Trigger, Secret of Mana, etc. Movement will be tiled based, but everything will be real-time rather than turn based. This includes battles, so there won't be a separate battle screen.
That's about as much as we know at the moment :) We are currently at the start of pre-production, so there are infinite possibilities at the moment; a lot of different ideas are being prototyped. We occasionally livestream as we work on the game. When we're live, drop on in and say "hi" :)
Watch live video from InvisibleMan6 on Twitch TV
We have official forums over here: Ifthensoftware.net
I have a Twitter account which I keep updated as I work through the day: Twitter.com
You can also find us on Facebook at Facebook.com
This morning while tinkering around with the Amazon EC2 instance that we use for our website and game server, I noticed that they had a new instance type available. What shocked me was that it was better... And cheaper!
We have been using their "T1 Micro" instance for a while, which has worked well enough. It has occasionally had its performance issues though. A performance issue this morning is actually what made me ultimately discover the new instance type: "T2 Micro".
T2 Micro has a better CPU than its T1 cousin, almost twice the amount of RAM, and a better network connection all for a slightly cheaper price! The only downside appears to be that you have to move over to their new "VPC" otherwise you get a rather ambiguous error message. I was stuck on this issue until a blog post on Sam Rueby's Findings helped me out of it.
My brother and I spent the rest of the day working out how long different features of the game will take to complete. We livestreamed the process and recorded it, so you can see exactly how we approached the problem if you are interested (video available above).
I've drastically reduced the scope of the features; they are now estimated in ideal work hours rather than ideal work days. This allows for easier scheduling since more features can be fit into one iteration (one work week), although they are smaller.
When estimating, I'm also listing out all of the tasks that would be needed to complete that feature. Each task is then given an estimate in ideal work hours no less than 1/4 of an hour, and no more than 1 hour. As before, estimates are powers of two, in order to combat increasing uncertainty as estimates become longer.
A feature's estimate is calculated by adding up the estimates of each of its tasks. This sum is then rounded up to the nearest power of two. If a feature takes longer than 2 hours, there is a good chance that it needs to be split up unto smaller features.
Latest tweets from @its_invisible
1hour 14mins ago
1hour 33mins ago
3hours 36mins ago
4hours 4mins ago
@_GNRadio I look forward to listening to it :)
5hours 23mins ago
@_GNRadio That would be cool! I actually just subscribed to your podcast and will be adding it to my normal rotation
5hours 30mins ago
@_GNRadio Anytime! Thanks for your interest :)
5hours 40mins ago
6hours 1min ago
@_DracoWyrm Cool :) Areum is going well! Released a demo of it for Feedback Friday earlier
7hours 19mins ago