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
@mrchrisallen The trouble is that AS3 does not seem to support UDP directly, and RTMFP may not work easily with a central C# server.
14hours 22mins ago
@mrchrisallen My original plan was to use AS3 for the client, C# for the server, and UDP for networking.
14hours 30mins ago
@mrchrisallen Write a multiplayer action game with a browser-based client and a central server.
14hours 31mins ago
@Seantron Thank you very much!
14hours 58mins ago
15hours 0mins ago
@Seantron Ok, thank you for the help. I'll wrestle with AS3+TCP(with delay unfortunately) for now.
15hours 1min ago
15hours 4mins ago
@Seantron The client will be browser-based AS3, the central server will be C#.
15hours 6mins ago
@Seantron The server will be written in C#, but it looks like this was designed to connect flash clients only. Will this be an issue?
15hours 6mins ago