Saturday, April 14, 2012

Map editing

So far my maps were randomly generated using three different tiles. Procedural generation of maps isn't that bad per-se. Some great indie games like Minecraft, Recettear or Dwarf Fortress generate all their maps that way. The result is a versatile game environment with great replay value.

But still, when you want to do story telling and want to be a creative game designer, you need some way to create locations and scenarios by hand. This means I need a map editor. My requirements are:

  1. Creating and editing maps by placing tiles
  2. Creating warp connections to other maps
  3. Defining monster population
  4. (later) placing NPCs and scripted events

So what options do I have?

 

1. Writing map definitions in a text editor in JSON format

Pro:
  • I don't have to program any external tools

Contra:
  • No WYSIWYG
  • Very tedious
  • Very hard to troubleshoot
Maybe I will do that as a stop-gap measure until I have a more viable tool.

 

2. Use Tiled

 Pro:
  • A very mature and powerful map editing application
Contra:
  •  I would either have to write my own plugin for Tiled which saves to the format I need or I need an XML-parser. Tiled can save JSON files, which have a schema which is quite easy for me to parse.
  • Tiled doesn't work with my overlapping tiles. It does work with them, but you have to define the amount of overlapping yourself
Although using Tiled instead of reinventing the wheel would save a lot of work,  it is still not perfectly suited for my needs. Getting tiled and my engine to work together will require some work and maybe will even mean that I need to say goodbye to some features.

3. Create my own map editor as a stand-alone application

Pro:
  • An application perfectly tailored for my needs
Contra:
  • A lot of work
Creating an own map editor as a GUI application - no matter what framework I will use to do so - will be just as much work as creating the client.

 

4. Put map editing capabilities into the client

Pro:
  • Perfect WYSIWYG 
  • Easy way to get the community involved in content creation
Contra:
  • Still a lot of work, although I can rely on the map rendering
  • Puts more code in the client than I would like to have
  • Air-tight permission management required
Using the client as a base would save a lot of work over creating a new application from scratch. But integrating the map editor would add a lot of code which would be downloaded by the average player although they will never use it. To avoid this problem I could create the map editing component as a user javascript which runs locally on my machine (or that of the mappers).

Roadmap updated

While I ported the client from Metro to HTML5 I  lost track of my roadmap. I implemented some features which were planned for much later milestones (like some steps into the direction of inventory and item management) while forgetting about things which are much more important in the intermediate future. Time to get my priorities straight again.

Milestone 5 (content):
  • Map editing
  • Map management infrastructure
  • Infrastructure for reading content from external files (JSON?)
Milestone 6 (growth):
  • Flexible GUI infrastructure
  • Character system
  • EXP gain and leveling
  • Combat mechanics
  • Mob AI
Milestone 7 (wealth):
  • Items and Inventory
  • Player trading
  • Shops
Milestone 8 (adventuring):
  • NPC interaction
  • Scripting
Milestone 9 (security):
  • Permission management
  • Database logging of
    • Logins
    • Administrative actions
    • Usage statistics
  • Logins
  • Brute force protection
 Milestone 10 (eye candy)
  • Animated sprites
  • Animated tiles
  • Particle effects

Skills


This evening I added the skill infrastructure.

A quickslot bar (usable by click or number keys) is used to switch the mouse cursor to cast mode, and a click on an enemy is used to begin the cast. The server informs all players that a cast happens and how long it will take. The clients show the progress bar of the cast, taking the latency into account.

When the casting time is over, the server does damage to the victim and sends a message to the clients informing them that the action was performed.

The basic feel of the combat mechanics is already there. But there is still a long way to go. The skill palette is fixed on the server, and there is no attribute system yet.

Friday, April 13, 2012

Prevention of duplicate character and account names

Today I tweaked the account and character creation. The database now refuses duplicate names using an unique index. The server checks this and also does some other plausibility checks (password complexity, name length, no funny characters in the name) and sends either a negative or a positive response to the client. The client reacts to these by either displaying an error or navigating to the next screen.

I also added a placeholder privacy policy and terms of use to the registration.

Thursday, April 5, 2012

Added password encryption

The server now uses salting and SHA-1 hashing for the passwords. Just to be sure that no sensitive data can be salvaged should my database ever get hacked. In the USA some website was fined $250.000 for losing plain-text passwords. Although I am living in a less insane jurisdiction than the US, it's better to be safe than sorry. Also it's a matter of responsibility.

The salt is the string representation of a randomly generated GUID, so it's very unlikely that someone has a rainbow table for it.

Porting the client part 4: Account and character creation

I redid the missing parts of the login sequence. Account creation and character creation work now. The usability has still some problems though, because the server doesn't report success or failure. That's mostly because the server doesn't even know any failure conditions - it doesn't check anything for plausibility and it is possible to create multiple accounts and characters with the same names. Securing that should be my next priority. And while I am on it I should also prevent accounts from being logged in twice.

Friday, March 23, 2012

Porting the client part 3

I added the multi-tabbed chat to the client. Now my Javascript client is almost where my Windows 8 client used to be. The only thing missing is account- and character registration. These won't be very difficult to do. Not being difficult has the advantage that it won't take long but the disadvantage that it won't be very interesting to do.

Thursday, March 22, 2012

Porting the client part 2

I began to move more features to my new HTML client. I am using this opportunity to improve a lot of stuff, because my knowledge of Javascript is now a lot better than when I started the project. My biggest mistake was the idea to use classes and instancing for everything like one would do in Java. Just creating a classless object and freely adding methods and attributes to it works just as good in most cases and leads to much simpler code.

All that is left to port is the chat functionality, account creation and character creation. Then I will be as far as I was with the Metro client.

Sunday, March 18, 2012

Porting the client to a vanilla web application

I made good progress with porting the client to a normal web application. It can now go through the login sequence and draw the map correctly. What's still missing is the gameplay netcode handling and the user input during the game.

Saturday, March 17, 2012

Added WebSocket support to the server

I added my java WebSocket implementation to my server. I now have the base class ClientConnection which handles my JSON-based protocol on the application layer, and the two specialized subclasses ClientConnectionSocket and ClientConnectionWebSocket which handle the string-based data exchange with the client using vanilla sockets and WebSockets respectively.

That way I won't have to worry (much) about making sure that any given feature works in both network stacks. It will also allow me to easily add other ways to connect to my server, like an UDP-based or flashbridge-based network stack.

Here a screenshot of a simple command-line based client executing the login sequence via WebSocket:


Now there is no excuse anymore not to port the client from WinJS to normal Javascript.