Game Dev Update

Daily Dev Feb 22 – Let there be light!

As I alluded to in my last post, yesterday I added the beginnings of lighting to my game – a simple object with a sprite (a lantern) and a point light. Unfortunately, it was not smooth sailing:

My character sprites weren’t being lit properly! They were being lit by the ambient scene lighting but the point light was about as effective as a pair of goggles in an acid tidal wave.

After a while spent experimenting, I determined that my player prefab was Proper Buggered and the only thing for it was to recreate it piece by piece, which worked a treat! Newly-working character lighting in hand, I started including torch placement as part of the dungeon generation. What could possibly go wrong?

Ah… It would appear that Unity does not take kindly to many point lights existing at once.

Simple solution: have them turn on only when the player gets close, and turn off again when they leave the area. Beauty! Here it is in action:

Best bit is, at first glance you can’t even tell it’s doing it, so here’s how it looks behind the scenes:

Until next time!

 

3 CommentsLeave a comment

Daily Dev Feb 21 – Multiplayer Maps

I noticed something troubling shortly after sitting down to work on my game – my new map generation code was working splendidly, but new players connecting to my server wouldn’t get any map data and would be stuck wandering a black void! Aside from the amusement factor of seeing other players and being able to apparently walk through walls (on the server’s end, since the client saw no walls there was no collision – one downside of a non-authoritative server) this represented a major issue.

I put off my plans for working on monster spawning and combat today and focused on fixing that particular snafu, and fix it I did! The solution didn’t come easily – at first I thought I could just attach a network view to my TileMap (a construct from the 2D Toolkit) but of course that didn’t do anything since there’s no good having something listening to you if you’re not saying anything, and I couldn’t pass along the TileMap data object to new players since as a GameObject datatype, it can’t be transmitted as an argument using remote procedure calls. RPCs will, however, accept more simple data types such as string, integer and most importantly, Vector3.

For the uninitiated, a Vector3 is three float values typically used to describe a position in 3d space; an X, a Y and a Z co-ordinate. Ultimately though they’re just a three element array and the numbers can be used for anything, which made me a very happy camper.

I created RPC versions of two methods my Dungeon Manager uses to build the map – SetTile and Build. SetTile accepts four integer arguments, X and Y co-ordinates, a layer number and a tile ID. Build is called after you’re done setting tiles with SetTile and will update the TileMap allowing you to see the results. Can you see where I’m going with this? Every time the server placed a tile it calls the SetTileRPC I created, using a buffered RPC mode. When it’s finished generating the map, it calls the Build RPC, again in buffered mode.

The important part here is making the RPC calls in buffered mode – as the name suggests, in this mode all rpc calls are recorded in a buffer, which played back to new players in the order they were received.  Essentially, the server’s Dungeon Manager records every tile it places while generating the map and tells newly connected players’ Dungeon Managers to place all the same tiles, build the map and then pop the player into existence.

Wonderful stuff, wish it didn’t take so long to figure out. Networking is hard!

I didn’t have the energy or inclination to go back to the day’s planned work so instead I played around with adding lighting to the map – it looks pretty cool! For some reason player sprites aren’t being lit properly though, so there’s something to start on tomorrow!

No commentsLeave a comment

Daily Dev Feb 20 – Dungeons!

I’m writing this at ~5am local time on Friday but I say it counts as Thursday’s Daily Dev because I started last night and, frankly, nobody’s going to argue with me.

Following on from the list of five things I wanted to do by next week, today’s Thing was dungeon map generation – having the game generate a level at random for our intrepid heroes to run around in.

Starting out was pretty simple, write a short method to build a room of a specified height and width, at specified x/y co-ordinates and wrap it in some logic to prevent it building over top of existing rooms. I even threw in some basic ‘theme’ functionality to switch out which tiles it uses for the floor and walls. The results are below, showing both the ‘flooded’ theme and the default:

Creating rooms at random

The next part was considerably more complex – coming up with logic that would allow the game to build a network of rooms connected by corridors. Approaching it in stages, I started with a method that would pick an existing room, pick one of its sides, decide on dimensions for a corridor and new room at the end of it and, if it didn’t overlap existing rooms/corridors, go ahead and build it. The logic behind the exact co-ordinate setting took the most time by far, between making sure corridors and new rooms didn’t exceed the edges of their neighbours and working around Unity’s bizarre number generator (Random.Range(x, y) will return a value between x and (y-1), not x and y. Wish I’d know that sooner).

Anyway, the end result is pretty pleasing, a nice little dungeon map just begging for slavering beasts, pots of gold and adventurers with an appetite for filthy, filthy lucre:

Cartography 101: Making your first map

1 CommentLeave a comment

Daily Dev Feb 19 – Monsters!

In keeping with my rule of trying to do one thing with my game every day, today I began experimenting on adding monsters in a multiplayer environment. The end goal is to have a spawn manager running on the server which will, in its most basic allow enemies to spawn in at a given co-ordinate set when called. The logic for this is pretty simple, I can query where on my level’s tilemap a given object (say, a player) is, then pick a spot nearby, see if it’s a sane place for a monster to spawn (there’s a ground tile, no solid wall etc) and there you go.

The fun part here is adding some extra logic to make the server spawn monsters in a fun or challenging way. Perhaps you turned your back on a dark room or maybe you’re just about to turn a corner you haven’t explored before… You get the idea.

By next week I’m hoping to have these things accomplished:

  • Functioning monster spawner (fancy logic not required, a simple button to spawn an enemy nearby will suffice)
  • Multiplayer combat (maybe even pvp combat)
  • Rudimentary dungeon generation
  • Finish porting the requisite underlying systems to multiplayer (player health,  xp/level gain)
  • Figure out multiplayer UI (just show my own health, not other players etc)

This looks like a scary amount of stuff, and it kind of is, but I want to push myself and see what I can get done in the time remaining. If all goes well I’ll basically have a workable game prototype!

No commentsLeave a comment

Daily Dev Feb 17 – Multiplayer!

Alright so ‘Daily’ may not be the right word, I’ve been busy!

The past few days have been an adventure of experimenting with what’s possible using the basic multiplayer libraries provided in Unity. Long story short, making an authoritative (read my other posts for more info on what that is) server in basic Unity is… challenging. I spent a good few hours today trying to get that working and to put it gently, I made a bollocks of it. Oh well! It’s all valuable experience.

Eventually I decided that authoritative servers aren’t really needed for my game, at least not at this stage in development, and -any- multiplayer is better than none, so I put together what you see in the video below – the new system essentially lets the clients manage their own player data (movement, stats etc) which is simpler for me as a developer, but is more vulnerable to cheating. Not a big concern right now.

What you don’t see in the video is that there’s a new character controller class in the background which acts similarly to the one Dev Vlog #1 – it handles input and moves the character around, as well as telling the animation handler (largely unchanged from the original version) what to do. The big difference is that it now works with a new class, the Client Data Manager, which takes snapshots of your character data (your position as well as other stats for the animator such as are you walking and which direction you’re facing) and sends all that up to the server, which in turn sends it to all the other connected clients. This way, when you move, you tell the server “I’m moving!” and the server tells your friends that you’re moving, which makes your friends’ copy of your character do his running animation while traipsing around your screen.

S’pretty simple on paper!

1 CommentLeave a comment

Multiplayer multi problem

Alright, so I spent a good chunk of today researching multiplayer in Unity, experimenting and following walkthroughs/articles. Some progress was made but not enough that I have a working concept. My game will need authoritative servers (the server dictates everything going on in the game) for multiplayer and I want a dedicated server executable to be distributed with the game so that players can set up their own servers locally or on dedicated hosting.

This doesn’t quite seem to be what Unity is geared towards, preferring a central master server/lobby type system where clients act as servers for a given session of a game. That would work fine for, say, a competitive game like a racer or an FPS but not so much for an open world game with random terrain generation that you want to be saved over time.

My options therefore, seem to be twofold: Either write a standalone dedicated server app (probably in c#) which would allow the unity game clients to connect to it (preferred, but very complicated) or simply have two builds of my game client, the ‘server’ with no graphics/camera.

Option two seems clunky at best but also much simpler than option 1 to implement for a beginner like me, so I think for now that’s how I’ll have to do things.

Knock on wood, I’ll figure it all out and have a working concept some time tomorrow.

No commentsLeave a comment

This may hurt a little

After doing a bit of research, it would seem that if I want my game to have a multiplayer component then the best course of action is to implement it ASAP, since anything I write prior to multiplayer will need to be rewritten. Good thing I found out early! I’m in the process of researching how to add multiplayer and will be working on that today and, well, until it’s done. This may mean I have little/nothing to show for the next few Daily Devs, but I’ll keep posting my progress.

Y’know, for posterity.

No commentsLeave a comment

Daily Dev Feb 14 – Getting Stuck In

First update on the new blog, woohoo!

Today I worked on the basic handling that all characters (players, enemies, etc) require, expanded the animation system and implemented proper melee combat. I made my first enemy using these base classes and had a play around;

Next on my list will be fleshing out  the character system to include XP values (the basic xp gain/levelling system is in place) and scaling stats according to increased level. After that, terrain! Collisions, animated tiles and non/interactive props.

Further down the road I aim to add dynamic lighting and experiment with shaders and material effects.

1 CommentLeave a comment

The Journey Begins

Well hello there!

I’m Richard, a 28 year old freelance developer currently living in Iisalmi, Finland. In my spare time I like to make music and have fantasised about making my own video games since I was knee high to a grasshopper. I’ve made a few attempts in the past, some more successful than others. I could count the number of false starts and weird game development  toolkits I’ve had on one hand, if that hand had far more than the regulation amount of digits – anybody remember DarkBasic?

I’ve recently found myself in possession of far more free time than at any point since I left university and, as one author put it, “It is a truth universally acknowledged, that a man in possession of too much free time must be in want of a distraction”. I may be paraphrasing a bit, but the point is still valid. Some blokes are best not left to their own devices, but I decided upon a much safer path to ennui relief – I would make a game!

This is obviously not the first time I’ve decided on this course of action, but for the first time ever, I’m imposing rules upon myself! I must do at least one thing to my game every day, and try to also do one game-related thing that is not directly related to making the game. This blog counts as the latter, and I hope to have little updates every day or two documenting my progress, with screenshots and other links where possible.

I’ve been going for about 5 days now and have been a good little boy and made additions to the project every day since I started, here’s where we’re at as of this post:

  • This is a 2d, top-down game built in Unity 3D
  • The game will play somewhat like an Action RPG, you can run around and slap baddies in real time, no turn-based battles
  • The goal of this particular project is to learn Unity and blow the cobwebs off my C# skills
  • There will be something recognisable as a game at the end of it, although the goal is not to produce a commercially viable product; a proof of concept demo would be acceptable

Actual game development progress:

  • Tile based map creation works, but with no collision on terrain yet (you can walk through solid objects)
  • Basic player stats and associated systems: Health, level and xp
  • Basic UI: Show player hp in top left corner as rows of full/empty hearts, pressing C will show ‘character stats’ (currently just their level and xp)
  • Generic handler classes for characters (animation handler, a data handler and a controller to bridge those two with the overall game manager)
  • Rudimentary AI (attack if player is close enough, react to damage taken)
  • Basic combat system (press key to attack, if a monster is within your melee range they will take damage)
  • Player death

It doesn’t sound like much but the majority of my work so far has been setting up the basic character handler system which will be the foundation of any and all player/non-player characters in the game and will make things much easier and quicker as the project progresses.

Game development is not an easy process and if you’d like to show your support and leave a few words of encouragement, please feel free to use the comment system on this blog or drop me an email at pixotic@pixotic.org – It really helps!

 

Peace out,

P

2 CommentsLeave a comment