Today I experimented a bit with Tomcat, Servlets and Java Server Pages. I made a char-viewer which gets a character from my MongoDB and exports some of its data as a website.
I really like the technology. I wonder if I should use it for some web-based components. But on the other hand, I would prefer to avoid mixing too many technologies. So I would prefer all of my non-game web applications to run in the same server application. I would, for example, like to have a forum and I don't want to program it myself. But while I was able to find plenty of free forum software in PHP, I couldn't find anything properly mature in JSP.
Seems like I need to brush up my PHP skills soon. I don't like it very much, but there is hardly a way around it.
Friday, November 22, 2013
Thursday, November 21, 2013
About the death of Glitch
About a week ago, I read that Glitch closed down due to lack of players. I must admint I never played that game. But the game had some striking similarities to mine. It too was an MMORPG, it was web-based and it was breaking conventions. I wondered if the same would happen to my game. Could it? Let's see what their reasons were for closing down.
But I am not using Flash, I am using HTML5 which all the big tech companies support. I think I am pretty save in this regard.
I am still taking this as a warning: I have to try to keep my infrastructure as low-maintainance as possible.
It seems to me like what they made wasn't so much of a game but rather some interactive community something which threw together gimicky game elements without having anything one could consider the "core gameplay mechanic". Sure, there seemed to be an amazing amount of creativity behind the project. But unfortunately they let that creativity run lose without any sense for coherent structure.
I hope I got this covered. Sure, I can't claim that I am a professional game developer yet, but game development is my hobby for about 20 years. I also collected plenty of experience with The Mana World. I believe that I know what I am doing when it comes to game design.
The big strongpoint of browser-based games is that it is easy to start playing them. No gigabyte-sized download, just visit the website and you are good to go. But that's also their greatest weakness: It's too easy to close the browser window and forget that they exist. By making the game too hard to get into they fell prey to that weakness.
This showed to me that starting my games content development with the tutorial was definitely the right choice.
Technology choice
One reason they mentioned was that the decision to use Flash turned out to be bad. I think they are overrating this factor. Sure, they couldn't port it to the iPad, but when people really wanted to play it, they could have played it on their PC. And seriously, who has an iPad but no PC? Sure, Microsoft and Apple have both decided that Flash needs to die, but so far their attempts at killing it didn't work out so well.But I am not using Flash, I am using HTML5 which all the big tech companies support. I think I am pretty save in this regard.
Too complex infrastructure.
Their closing-faq mentions that "It takes a full-time team of competent engineers & technical operations personnel just to keep the game open. Even if there was a competent team that was willing to work on it full time for free, it would take months to train them. Even then, the cost of hosting the servers would be prohibitively expensive.". When that is true, they really have scaling issues. Less players should mean less work to do. But obviously that wasn't the case. Maybe their infrastructure was designed to scale up, but not down.I am still taking this as a warning: I have to try to keep my infrastructure as low-maintainance as possible.
They didn't know what they were doing.
There is a really interesting article on Gamasutra which mentions that the people who made it didn't really had much of a clue about game development.It seems to me like what they made wasn't so much of a game but rather some interactive community something which threw together gimicky game elements without having anything one could consider the "core gameplay mechanic". Sure, there seemed to be an amazing amount of creativity behind the project. But unfortunately they let that creativity run lose without any sense for coherent structure.
I hope I got this covered. Sure, I can't claim that I am a professional game developer yet, but game development is my hobby for about 20 years. I also collected plenty of experience with The Mana World. I believe that I know what I am doing when it comes to game design.
Not accessible enough
Another aspect the Gamasutra article mentions how hard it was to get into the game: "A lot of people were just like 'I don't know what the fuck I'm supposed to do.' Some people took 'I don't know what I'm supposed to do' as an invitation to explore and ended up loving it. Other people closed the browser. That's it."The big strongpoint of browser-based games is that it is easy to start playing them. No gigabyte-sized download, just visit the website and you are good to go. But that's also their greatest weakness: It's too easy to close the browser window and forget that they exist. By making the game too hard to get into they fell prey to that weakness.
This showed to me that starting my games content development with the tutorial was definitely the right choice.
Friday, November 1, 2013
Status indicators
During playtesting I realized that when I died it was often because I wasn't aware of how low my HP were and that my barrier was already depleted.
The reason is that the players eyes need to focus on what is happening at the center of the screen during combat, but also to the status bars at the upper right edge of the screen. It's really hard to pay attention to both at the same time.
To solve this problem I decided that these markers need to get closer to the player-character. So I added some HUD elements right below it:
The arcs are, from inner to outer, the current percent-status of MP, HP and barriers. When the character would have multiple barriers, they would appear as additional concentric arcs around it. When the player wants to know the exact numbers, they can still look at the upper-right corner. But these arcs gives the player a constant awareness of the status of their player-character.
The reason is that the players eyes need to focus on what is happening at the center of the screen during combat, but also to the status bars at the upper right edge of the screen. It's really hard to pay attention to both at the same time.
To solve this problem I decided that these markers need to get closer to the player-character. So I added some HUD elements right below it:
The arcs are, from inner to outer, the current percent-status of MP, HP and barriers. When the character would have multiple barriers, they would appear as additional concentric arcs around it. When the player wants to know the exact numbers, they can still look at the upper-right corner. But these arcs gives the player a constant awareness of the status of their player-character.
Sunday, October 27, 2013
Barrier Tutorial
I added a barrier tutorial to the tutorial map.
The player has to walk through a course without taking any non-shield damage.
This required two new scripting abilities: Map areas which trigger scripts and attacks which trigger scripts. Both of these new abilities will likely come in handy in the future.
The player has to walk through a course without taking any non-shield damage.
This required two new scripting abilities: Map areas which trigger scripts and attacks which trigger scripts. Both of these new abilities will likely come in handy in the future.
Saturday, October 26, 2013
Balancing through testing
To test my formulas I created a little program to auto-generate mobs with average stats from level 5 to 100. I want to avoid this in the final version (or do I?), but for now it is a nice balancing tool.
This really helped me to file off some edges and balance my procedural barrier generation algorithm. Next one are healing spells.
This really helped me to file off some edges and balance my procedural barrier generation algorithm. Next one are healing spells.
Tuesday, October 22, 2013
Balancing through number-crunching
After the stressful summer with the election and my sailing hours I wanted to continue development right away, but instead of that I decided to use the distance I gained from the project to take a 2nd look on some of my code, so I was doing mostly minor cleanups and refactoring.
Then I decided that it is time to start with the content. But when I wanted to do so I realized that I had no idea what I was doing. What's a good experience yield for a Level 5 monster? How much is a spell supposed to cost? How much defense should a level 10 robe have? Just making up values on the spot would not have been wise, as I would have to balance it through trial and error. So I decided to buy some Magic Chart paper (cool stuff, by the way. It clings to any surface through electrostatics. You can easily move them around without leaving a trace. You can draw on it with dry-erase marker and just wipe it away just like on a whiteboard) and summarized all the level-dependent formulas I have.
While doing this I realized some balancing errors which would have been quite bad in practice (MP increases quadratic but MP regeneration just linear - ooops). These handy charts will make it much easier for me to make up content.
Sunday, August 25, 2013
ToDo until public alpha
Content:
Technical:
- Mapping for Wenibe and surrounding
- Scripting for some quests
- Create and balance content for 20 levels:
- Equipment
- Mobs
- Instance freeze bug - find it and fix it or add an automatic monitor for instances and terminate those which seem to be caught in an infinite loop.
Technical:
- Create a website
- Find a server hoster and set up the gameserver
Target indicators
The players now see which combatants are currently targeted by spells
of which element. This should make barrier-management more easy.
Speaking of barriers: These can now be cast by players and are now scroll-based like all other spells. Just as I planned, each player-character can have only one barrier active at a time, but this barrier doesn't need to be on itself. So a party can decide to stack all their barriers on one designated tank while leaving all other members unprotected.
Still missing on the barrier front: A tutorial, scroll icons and an NPC to sell them.
Speaking of barriers: These can now be cast by players and are now scroll-based like all other spells. Just as I planned, each player-character can have only one barrier active at a time, but this barrier doesn't need to be on itself. So a party can decide to stack all their barriers on one designated tank while leaving all other members unprotected.
Still missing on the barrier front: A tutorial, scroll icons and an NPC to sell them.
Thursday, August 15, 2013
Barriers
This is a feature I first decided to take off my roadmap to alpha, but I realized that it's a too important part of my game concept, so I started implementing it.
A barrier is a buff which works like a HP buffer for a special element. When it is cast on another player, all damage with that element will eat away the HP value of the barrier before reducing the actual HP of the players. The HP buffer of the barrier decays naturally during the lifetime of the shield.
Currently there is only a provisorical implementation - every player starts out with a 100HP fire shield which loses 1 HP per second. But I am going to make barriers spells. Each player-character can have one barrier active at a time, but it doesn't need to be on oneself, so a player can make the tactical decision to protect another partymember instead of oneself.
There will be two kinds of barriers. Long-time wards which decay slowly but need a long time to cast, and quick counterspells which are cast very quickly but also decays rapidly. The first kind is used as a precaution when wandering dangerous areas, while the latter is cast when you notice someone attacks you to prevent the damage.
A barrier is a buff which works like a HP buffer for a special element. When it is cast on another player, all damage with that element will eat away the HP value of the barrier before reducing the actual HP of the players. The HP buffer of the barrier decays naturally during the lifetime of the shield.
Currently there is only a provisorical implementation - every player starts out with a 100HP fire shield which loses 1 HP per second. But I am going to make barriers spells. Each player-character can have one barrier active at a time, but it doesn't need to be on oneself, so a player can make the tactical decision to protect another partymember instead of oneself.
There will be two kinds of barriers. Long-time wards which decay slowly but need a long time to cast, and quick counterspells which are cast very quickly but also decays rapidly. The first kind is used as a precaution when wandering dangerous areas, while the latter is cast when you notice someone attacks you to prevent the damage.
Wednesday, August 7, 2013
Private chatting
Yesterday I added private chatting. The "whisper" option on the character context menu is now functional. There are still two problems, though:
1. Although the protocol allows it, there is no way to open a chat with someone not on the screen
2. There is no way to close chat tabs, except for reloading the website
1. Although the protocol allows it, there is no way to open a chat with someone not on the screen
2. There is no way to close chat tabs, except for reloading the website
Subscribe to:
Posts (Atom)


