Dungeon Rendering

Since generating dungeons in Unity seems to work just fine, I started working on rendering the dungeon.

First, I added random colored lights, so each room would have its own feeling to it:

Random colored lights

The next thing I added was a basic character controller (the model is still a placeholder), so that I could walk around and see how everything looks.

I put in some walls and rendered it from an orthographic camera in 3D:

Orthographic perspective

At this point, you would be able to look into every room, even if its not in your line of sight. This is very boring from a gameplay perspective and it looks very strange, too. So I quickly programmed a "fog of war"-like visibility system. Due to the fact that this is just a test, I currently use ray casting for this. This will be replaced by a much more efficient approach later on.

This little video shows everything I mentioned so far:

I also started adding more parameters and randomness to the level generator to make the levels more interesting. Writing code to create random dungeons is not very hard, but doing so that you get predictable and consistent yet interesting results isn't that easy.

Unity

I always wanted to try out the Unity Game Engine, but becoming acquainted with a new tool often takes a lot of time. This wasn't the case with Unity though.
I played around with Unity a little bit and I really like it. It is more suited for 3D games than it is for 2D though, but it makes things so much easier. Today I ported the dungeon generator to see how well that goes. I also made some bugfixes and did some code cleaning. So far everything seems to work pretty smoothly. The level generation seems to take some more time than on the Java implementation, but the rendering seems fast enough and should improve further as soon as I implement some optimizations.

Here is a screenshot of a generated dungeon layout in the editor (no textures yet):

Random Dungeon in Unity

I also made a very basic gameplay prototype that I will be integrating into this, so that I can try out some gameplay mechanics (I know it looks crappy :) ):

Very first gameplay testing prototype

Something

There hasn't been much progress on the game lately, mainly due to the lack of time and also because of me having to study the gameplay mechanics of Diablo III :P.
I am currently considering some changes for the direction I am heading with this, because nothing is really worked out at the moment. There is a basic dungeon layout generator and some netcode and that's about it. There is an overall idea of the feel and the theme of the game, but I have a hard time figuring out how to make it interesting gameplay-wise. I first wanted to have point&click controls like in Diablo, but now I think I want it to be much more fast paced like an action adventure.

Because nothing happend on this blog for over a month now, I made this little rendering, showing the first "axe"-weapon for the game:

\m/

And by the way...

... here is a logo:

Faster Network and a Name

I am still working on the network code, which will now run on UDP instead of TCP. The decision was not an easy one, but I wanted network play to be as smooth as possible, so I chose UDP, because it doesn't have as much overhead as TCP does.
As mentioned in an earlier post, UDP has several issues. The first is that it is a connectionless protocol, which means that it is not defined wether a client is currently connected or not. The second is that UDP is unreliable. You don't know if packets will arrive and you can't be sure they arrive in the correct order. It is very likely that most packets will arrive in the correct order, but when packets get lost, you will run into serious problems.

So how do we tackle these problems? Solving the connectivity problem is pretty easy: Whenever a player attempts to join a game, the client will send a CHALLENGE_REQUEST message to the server. If the server has a free slot, it will respond with a CHALLENGE_ACCEPT message and add that player to the playerlist.

But what happens if either the request or the accept message get lost? There is a simple solution: the client will send requests until it receives an accept message. If the server already got an accept message and added that player to the playerlist, but receives another request, it will just send an accept message back to the client. This way, if a request gets lost, the client just sends another one. And in case the accept message gets lost, the server will know that, because it will receive multiple requests from the same ip.

A similar system is employed for regular game messages. All game messages are bundled into packets. Each packet has a consecutive sequence number. In every tick (e.g. every 50ms) one of those packets is send through the network. If the packet arrives, the receiver will send that sequence number back during the next tick. This way, the sender knows which packets got through and it can resend packets that got lost. This protocol is a bit more complicated in detail. If you want to learn more about it, you can find all information on this website.

There is still a lot to do in terms of network programming. Using this kind of reliability, packets can still arrive in the wrong order which leads to inconsistencies. How I am going to solve this will be a topic for a future blog post.

We've also decided on a better name than "Dungeon" for our game. The game will be called 

Einherjar 

- Requiem for the Metal Gods -

That's it for now. I hope I get finished will all this network stuff soon, so I can work on things that are more fun and metal-esque.

Rock on! \m/

Quick Update

I didn't do a lot of programming in the last weeks, because I was busy designing the network functionality and considering different techiques of lag compensation and stuff. I finally came up with a concept that I plan on implementing. If all goes well, the system will be very easy to expand, but I am still worried about performance issues.

What else happened? Creating and joining a game, as well as disconnecting seems to work pretty well now. A basic chat system with a very simple user interface is also in place. This allows me to enter commands without having to program a sophisticated ui. This will most likely look a lot better in the final game, but it does its job for the moment.

Here is a screenshot:

Basic chat interface with join/leave game messages

That's it for now. I will post about my plans for the more advanced network stuff as soon as I verified that it will work.

Netcode

As mentioned in the last post, I started working on the netcode. It was a more difficult task than I thought initially. The problems weren't with the network itself, but how to structure the code and how to store data.

The netcode is based on the TCP/IP protocol. I did some research and there seem to be a lot of people who say that you have to use UDP, or it will be to slow to work for real-time purposes. In my opinion it really depends on the amount of data one wants to transmit and how frequently that data is sent. The reason I chose TCP is just because it is a lot easier to use. TCP makes sure that all packets will arrive and also that they arrive in the right order. To make UDP usable for such an application, you would need your own TCP-like protocol on top of UDP to make it reliable. The benefit of this approach is that you can decide which packages should be transmitted this way and which shouldn't. I just hope that TCP will be fast enough and I will try to only send data that is necessary to improve network performance.

The hard part was to program the network interface and I am still not very happy with it.
Data is being send in packets. Each packet starts with a packet identifier (e.g. 1 for the login packet), it is then followed by arbitrary data (like a name, a color, a position). The server has two threads for each client, one thread for sending packets and one for receiving. To avoid concurrency problems, the server stores every packet in a packet buffer which is processed and emptied in the server's main thread.

The next thing I am going to do is a basic login and player management system. Every player will need a unique identifier, so he can be referred to in the packet data. I am also going to start working on the class that will later represent the world. The server will modify this class using the information provided by the clients and send the resulting changes back to them. The right choice of what data is processed by the server or the clients is very important. For example if the client would send a position update and the server just takes the information as the player's new position, that would allow for all kinds of hacks like speed hacks or teleport hacks.
Though the game will allow for singleplayer, I do not plan on explicitly programming a singleplayer "mode". That means that if you start a singleplayer game, what happens essentially is that the game will start a local server and connect to that server. The benefit of that is that the code is the same and everything that will work in singleplayer will also work in multiplayer, so the experience will be the same. It is also easier to test the code.

I hope that for the next post I will have some images or videos. This one was rather dry, but I thought it was worth sharing.