Posts Tagged ‘online’

A few seconds of Ivy

Posted by (twitter: @juaxix)
Monday, August 25th, 2014 8:41 am

Here you are, directly from Vine
See Ivy Demo – Vine

Servers

Posted by (twitter: @juaxix)
Sunday, August 24th, 2014 11:09 pm

The first night,since theme annuncied, here in Spain is really late, 2:30 am approx, i spent like 8h creating a mongodb server with php api rest to realise next day that it would take another two days to be implemented.
So, I moved to appwarp server for Unity for the first time after analyze all the other options like photon cloud, smartfoxserver etc
The demo was working, i added all the assets, and did some coding all the day until now, barely sleeped, the project got corrupted in a physics online loop in the editor and i was in pain, lucky me i recovered the files this morning and now the only part left is to finish some online mechanics and scores ,etc
Hud is done, also character motor and cool rendering with mirroringimage fx.

Free Live Class on making game with Construct 2

Posted by
Saturday, March 30th, 2013 1:08 am

Hey there! o/

Kyatric and me will be holding a free online class on uReddit

We will teach the basis of construct2 by following more or less closely the making of this little demo

There will be a live session each saturday evening (GMT+1) for 4 weeks from Aprils 6th to April 27th.

If you can’t attend, don’t worry, they will be recorded and replayable on scirra’s twitch and youtube.

You’ll be able to directly interact with us during the live, and indirectly through our subreddit

 

So please, feel free to enroll and spread the word (:

The Joining – 3 Day MMO Postmortem

Posted by (twitter: @enichan)
Wednesday, August 29th, 2012 9:04 am

So, for our first Ludum Dare ever me and Regus made The Joining, a centrally hosted 2D shooter MMO. Against all expectations, including my own, we made a relatively complete game by jam’s end. Unfortunately a 3-day-mmo is kind of like 5-minute-cake, a cool idea, worth doing to be able to say it’s doable, but the end result is infinitely less satisfying than what you’d get if you put the proper amount of time in. While running around pewpewing evil robots is fun, a lack of players and general aim and finetuning makes it only playable for 5-10 minutes before boredom sets in.

What went right

  • We knew our tools. Despite the fact that XNA isn’t the best thing to use to get a lot of people to play your LD game, we decided to stick with what we knew in order to finish in time.
  • Teaming up with Regus was extremely enjoyable, we’ve known each other going on I don’t know, a decade and a half now, but we’ve never made a game together. Working together was great, we had complimenting skillsets and we didn’t step on each others toes or had to wait for the other to finish to continue working.
  • I’m mostly pleased with the pixel art I did. Pixel art is something I consider myself good at but I rarely get to do it anymore. Being able to do some again was very nice.
  • The game is pretty well feature complete and stable. Our code design was mostly to thank for that, until the last day when cleanliness kind of went out the window and some of my rendering functions turned to spaghetti.
  • We made an MMO, complete with combat, enemy AI, A* pathfinding and a neat sort of “level up” system. In three frickin’ days. How awesome is that? Worth it just to say we did it.
  • I got to remind myself that even if your art and particle effects are only 50% as awesome as you want, it’s still a more satisfying experience to have a bunch of half-awesome stuff and a more complete experience, then an incomplete number of perfect things. The perfectionist in me needed this reminder.

What went wrong

  • No music. I’m bad at music and didn’t have the tools or time to modify even an autotracker song. I subbed in ambient sounds instead and it works okay, but not the way I wanted.
  • We didn’t actually have time to add some features that would’ve given the game a goal, like a boss at the center, better tuned distribution of enemies, and a global win/lose condition like we planned.
  • The game wound up being not very fun. See my opening paragraph for thoughts about that.
  • I felt kind of sick after the third day cause I pushed myself so hard and my sleeping patterns are completely shot now.

Overall a lot of things went right, far more than went wrong. Our first LD experience was enjoyable, and taught me some valuable lessons, or rather reminded me of them. And it was a chance to do a few things I don’t normally get to do, like make an MMO and work on pixel art. I consider it a win, even if I doubt our game will be getting top ratings.

We probably won’t work on the game for a post-compo version, I think. Nobody’s asked us to, which is a pretty good sign that it’s not actually wanted. Comment if you think we should, though. I’m tagging this SuccessStory even though the end result is lackluster, because… well, 3 day frickin’ MMO man.

Eniko, signing out.

The Joining MMO – Finished!

Posted by (twitter: @enichan)
Monday, August 27th, 2012 6:43 pm

I can’t believe it, we pulled it off. Against all expectations, we pulled it off. We failed to add the win and lose scenarios, but nonetheless we made a more or less fully fledged massively multiplayer online 2D shooter in 3 days! What is this I don’t even

I present to you: The Joining! Get the zipped build from the entry page or download the handy dandy setup which includes all the required frameworks. (XNA 4.0, .NET 4.0)

The story is that a race of monogendered aliens who join with each other to exchange genetic material have become complacent and reliant on AIs, and thus weak. Now the AIs have gone rogue and you have to once again join with your fellow alien type people to become stronger and defeat the AI overlord! (note: overlord not in game)

The game boasts procedurally generated terrain with buildings, a single central server everyone connects to, chat features, point and click movement and combat, and some pretty particles. No music, but I tried to compensate with ambient war sounds.

Now I have a dreadful headache so postmortems, time lapse and gameplay video will follow later. First LD, and we made it. I can’t even believe it. I’m so happy!

European checking in

Posted by (twitter: @enichan)
Saturday, August 25th, 2012 4:54 am

So, last night me and Regus, after grumbling about the theme for 5 minutes since it fit none of our ideas brainstormed for an hour and a half and then decided to go to bed. Turns out neither of us slept all that well, ghee wiz whoda thunk! We at least bashed out an interesting idea, which implements some features of evolution and natural selection as gameplay mechanics.

Right now I’m nursing my morning (mid-day) cup of coffee trying to wake up and trying not to think of how much time sleeping took up. Then we’ll bang out design decisions and milestones, I think, and get cracking.

One thing I can already reveal; we’ll be going online. YEEEAAAAAHHHHH!

An online persistent world building game in 48 hours

Posted by
Saturday, April 28th, 2012 9:44 am

I’d been meaning to write this a lot earlier, but I’ve been way too busy to do it until today. Anyways, I made an online persistent world game in 48 hours. I wonder if it’s been done before during LD? We really need a tag system for games or something, it’d be interesting to be able to look up games with
specific elements. This post will be a bit of a combination of a making-of and a post-mortem; I’ll explain how this game came to be and comment on it.

Before Ludum Dare
This was my second Ludum Dare, so I had a decent idea of what to expect. Last time I used Unity, which had both its advantages and disadvantages. But since I’m the kind of person who wants to be able to customize everything and doesn’t want unnecessary things forced into his game, I prefer not to work with Unity. Fortunately, since February I’ve been doing an internship where I’m working on an XNA game, so I got pretty familiar with it. In making that game, I wrote a simple sprite engine which turned out to be very useful, so a week or so before LD23, I took the engine, removed some game-specific functions, added a tiny bit of documentation and released it as VBXSE. A short while ago I’d also been working on a simple netplay engine named GNI in my free time, so I decided to release that as well.

The original idea
After waking up at around 9-10 AM (competition started at 3 AM for me, but sleep is very important if you’re doing a 48-hour solo project), I checked the site to find out the theme was unexpectedly ‘Tiny World’, a theme I hadn’t even considered a possible winner in the poll. After thinking about it, I decided to make a roguelike-ish survival game similar to UnReal World where you and a couple of NPCs were stuck on a tiny island and had to get food and shelter to survive. That’s right, the original concept was nothing like what the game eventually became. I wrote down the basic game design in a text file, if you want details. So, I started working on the survival roguelike…

World and Graphics
Since roguelikes tend to be played in console windows, I decided to keep the area size small enough to fit in one. After some thinking, I decided square areas would make the most sense considering you also need room for other game information, and I ended up at a 22×22 world with each tile having 22×22 subtiles.

After a rough interface sketch, some calculations and some guesswork I decided the tiles would graphically fit best at a 32×32 size. However, I’m terrible at drawing stuff, so I decided to turn ‘lack of skill’ into ‘style’ and went for a pixel art look; I drew every tile and item in 8×8 and then resized it to 32×32 to make it look ‘retro’.

I made all of the art in GIMP because the Paint that comes with Windows 7 tries to be too hard to be a real drawing program and in doing so actually becomes worse for making pixel art…and it still doesn’t have any transparency. Brushes were surprisingly actually very useful when making tiles like grass, sand and sea. Just keep using random brushes and you have good-looking grass. Definitely something I should use more often.

Sound and music
The music for the game was made in FL Studio 9 using only soundfonts from DSK Music‘s HQ Instruments set. Although the effect is very subtle, the game actually contains dynamic music; although throughout the entire game the same track keeps playing, there’s three slightly different versions of them. They play simultaneously, and the volume adjusts depending on where you are.

Normal track
Forest track
Beach track
FLP (FL Studio Project) file

The music used the ‘Celtic Harp’, ‘Ney Flute’, ‘Percussion 1’, ‘Oboe’ (forest only) and ‘Harp’ (beach only) soundfonts. It was inspired by Paavo “Tarantula” Harkonen’s soundtrack for obscure MMORPG Dransik (now a shadow of its former self and named ‘Ashen Empires’) and a random street performer playing on a harp the day before LD23.

The sound was created by rubbing or hitting various objects around my desk against eachother in different ways, recorded with my laptop microphone and edited in Audacity (amplitude change, pitch change and echo). Like the music, it was mainly inspired by obscure MMORPG Dransik, where you would hear a simple but satisfying sound whenever you did things like cutting trees and mining.

But how did it become a persistent world game?
Development started out well. I started by making simple ‘world generation’ (filling the entire world with grass tiles). Then I made movement work, then proceeded to add sea and forests to world generation. I added the axe and item usage, so you could chop wood. Then I also needed support for dropping and picking up items, which also required a menu to let you choose between items. I also made sure you could save and load your world, so I made functions to serialize the entire world to a long string and load it again.

At that point, day 1 was already over (LD goes from Saturday 3 AM to Monday 3 AM here, so it’s 2 days instead of 3 as it is in some time zones), and there was no sign of crafting, construction, the hunger system, NPCs, wildlife, fishing and similar methods of food gathering, liquids, an age system, building recognition or pretty much anything beyond the very basics of the game. Whoops. So, what is the logical thing to do when your plans seem way to ambitious?

I went with the logical solution: I changed my game into a complete persistent world building game. Of course it’s a ridiculous decision to take halfway through development, and even more so when your project is in that state due to being way too ambitious, but all things considered, it ended up being not as unreasonable as it sounds. I had recently created a netplay library, and though network communication is always tricky and it was not tested much, it did seem to work perfectly from the small amount of testing it did get. As a game design decision it was more logical than anything; I was just a tiny bit of code away from making a game where you can build stuff, and games like Minecraft, Terraria, Active Worlds, a whole slew of BYOND building games and many more games have pointed out that just building things for other players to see can actually be fun in itself. Add to all that that I could already serialize any part of the world to a string, and the decision was made overnight to go all-or-nothing for an online persistent world game.

The first thing I did on the second day was finish the crafting and building system (otherwise even having a persistent world would be futile). Then I used my GNI library to write a server program and a client class. The client would ask the server for the serialized string representing the world map, and then for the serialized strings of each of the areas in the tiles (each tile on the 22×22 world map contains an inner area consisting of 22×22 ‘subtiles’, if you haven’t played the game). I found out the serialization had some errors, but after some bugfixing, it actually worked perfectly. Then, to make client changes affect the server and have the server keep the client up to date, instead of at the start the server would send the client the inner areas only whenever he zoomed in or walked to a different inner area, and the client would serialize the entire inner area and send it to the server whenever a tree was cut, an item was dropped or picked up and whenever something was built. It’s an inefficient approach (the reason it lags whenever you switch between areas or do something area-affecting), but it worked great for a 48-hour game. I then proceeded to add functionality for chat, player names, seeing each other, et cetera.

After the netplay features worked, I decided to add what little extra content I could still safely push in (mountains, stone, and anything that requires stone – yes, originally there was only wood) and release it.

What I like about the game
-It’s a persistent world game. That by itself is awesome.
-It’s my first succesful attempt at a non-BYOND online game. There was one other finished game were I attempted netplay, but its netplay was a horribly buggy mess that desynced for any players that were more than 2 meters apart.
-The world generation is nice. I’ve barely done any random world generation before, so the fact that I managed to get a properly shaped island with properly shaped beach and mountain areas out of it is pretty nice.

What I dislike about the game
-Lack of content. And I mean utter lack of content. There’s two kinds of walls to build, two kinds of floor plus four natural floor tiles, one tool to make and one decorative item. Ludum Dare games aren’t known for their extreme length, but it’s very minimal here; it’s a building game, but there’s hardly any variation in what you can build, so you get bored very easily. This is especially disappointing after my previous LD game, which could be played for significant lengths of time and still be interesting.
-It’s buggy and laggy. Whenever you zoom in, lag. Whenever you build something, lag. Whenever you cut a tree, lag. Whenever you move from one area to another, lag. And those 4 natural tiles I mentioned at the previous point? Good luck getting three of those without relogging a minute later, as they mess up something in the graphics (still not sure what causes it).

Things I should do again next LD
-Use VBXSE and GNI again. Especially the latter came as a surprise in how powerful it can be in just a small amount of development time. I was afraid of netplay functionality before considering the debugging hell it can cause, but now I think I’ll just plan for netplay from the start of the theme allows it.
-Use pixel art. I can’t draw, but ‘style’ turns out to work as a pretty good excuse to hide my lack of skill.
-Record random objects using my laptop microphone and edit them in Audacity for quick sound effects. I’m pretty satisfied with how they turned out; they subtly add a lot.
-Be overly amibitious. Partly because I’m just an idiot, but also because going beyond what you know you can do allows you to learn new things. It would be better for the game if I didn’t, but in the long run this is very useful.

Things to keep in mind for next LD
-I should make sure there’s enough content. LD is for games, not for tech demos.
-I should try to get the day after LD off work. Starting a week with a serious lack of sleep hurts your productivity for the entire week.
-I should update and improve VBXSE and especially GNI. They’re awesome, and therefore they must become even more awesome.
-I should make sure I’m used to the the tools and libraries I’m working with. I thought I knew XNA, but it wasn’t until halfway through the project that I realized I didn’t know even how to play multiple music tracks at the same time and change their volume. I also wasted a lot of time debugging an issue that happened because I didn’t take into account that using auto-poll GNI’s client class handles received data in a different thread.

Beyond here
I was initially considering updating the game a bit, adding some extra content and fixing some things I didn’t like, but there are so many things I’d like to change and so many things that need to be changed to make the game actually fun that it’d just take too much time. I think it would be interesting to one day make a complete game based on this, but that’s the kind of plan that will either never see the light of day at all or won’t be used until years later.

By the way, I forgot to do it initially, but I’ve slapped a Creative Commons license on the game so you have the right to mess with it in any way you want. Well then, see you all next LD!

Appendix A: Tools/libraries/etc used
C#: The language the game is written in.
XNA: Engine used for the game.
Microsoft Visual Studio 2010: The IDE I’ve used to make the game in.
VBXSE: XNA Sprite engine, used for all graphics stuff.
GNI: Netplay library, used for client-server communication
FL Studio 9: Used to make the music. I’m a fervent supporter of pattern blocks, even as Image-Line gets rid of its unique features.
DSK Music’s HQ Instruments: Set of amazing soundfonts I use for music. The music for this game was made solely using DSK HQ Instruments, using default FL Studio VSTs as effects.
Audacity: Pretty much the best audio editor around. Used for sound effects.

Appendix B: Network signals
If you’re interested in how exactly the server and client communicate, these signals are sent back and forth. Each signal has a ‘key’ denoting what the signal is about, and a ‘value’ containing other info.

Server to client
(None) – A signal with no information to check if the client is still connected.
identify – Asks the player for his appearance and location, in case some other players requests it later.
goplay – After version check and sending the necessary maps. Tells the client the player can start playing.
gspfinish – Indicates the server is finished sending inner tiles and the client can enter the subterrain the player was about to enter.
message – A chat or system message. Output the value to the displayed messages.
people – A list with the unique player numbers of all players that are currently online. If a known ID is missing, that means a player has disconnected. If there’s an unknown ID, the client sends a ‘who’ signal to ask for information on the new player.
person – Information on a player (ID, appearance, location) as a response to the ‘who’ signal. The client will then add the player to the list of known IDs.
pos|X – Where X is the unique player number of a different player. Tells the client where the specified player is right now.
subter|X|Y – Where X and Y are integers representing coordinates. Replace the inner tile at X,Y with the serialized inner tile in the value string.
subteru|X|Y – Same as above, but the change is vital, so if the player is in the area, it MUST update the inner area before letting the player continue doing whatever he’s doing.
versioncheck – Asks the client to send his version number, to make sure he isn’t using an outdated client.
versionmismatch – Tells the client he can’t play on the server because the versions don’t match. Which version the server is running is in the value.
where – Requests the client to send a ‘here’ signal, telling the server where the player is.
worldmap – Sends a serialized world map as the value. Allows the client to build the same world map client-side as the one that exists server-side.

Client to server
The server automatically sends these signals without the client saying anything to it:
Every 2 seconds – where – Ask for the player’s current location.
Every 2 seconds – pos – Tells the player where other players are.
Whenever a client connects – versioncheck – Asks the player for his client version.

The server can receive the following messages:
cmsg – Client wants to send a chat message.
getsubplus – Value contains X and Y coordinate. Client asks server for the inner area at (X,Y) as well as the 8 areas around it. Server sends them followed by a ‘gspfinish’.
here – Client tells the server where the player is.
ident – Client tells server information about the player (appearance and location). Server stores the information and sends ‘worldmap’ and ‘goplay’ signals to let the player start.
nick – Sets the player’s nickname.
usub|X|Y – Client tells server they updated the inner tile at (X, Y). Server updates world and sends a ‘subteru’ signal to all players.
version – Client tells server what version they’re using. If it matches, the server will return an ‘identify’ signal, otherwise it will return a ‘versionmismatch’ signal.
who – Client asks server for information on a player. Server sends a ‘person’ signal in response.

I probably won’t use this next weekend, but I’m posting this just in case I do want to use it.
GNI is a library to facilitate some simple, easy to use communication between a server and any number of clients.
Please note that this was coded in a relatively short time span, it was not tested extensively, network code is vulnerable to tons of unpredictable bugs, and my experience with netplay development is limited.
What I want to say is, don’t rely on it unless you’re capable of fixing bugs in it, as it might break at the worst possible moment.
The example chat program I wrote seems to work perfectly, though, so it should work. ‘Should’ being the key word here.

Features
-Simple way to send signals from server to client and vice versa, without bothering with minor technical details
-Automatically calls a function when a signal is received, a player connects, or a player disconnects

Download
Code includes a simple chat server project and chat client project as examples.

DLL download link (5 KB)
Source download link with example (19 KB) (Microsoft Visual Studio 2010 solution)

How it works
Small packages of information called GNIDatas are sent through the library. When received, it’s reconstructed as a GNIData struct.
GNIData consists of a key-value pair, with the keys or values being shorts (16-byte integers), strings, or nothing.

Server
-The server class must inherit from the library’s GNIServer class.
-Call StartServer(…) to start the server. You can have it check for incoming signals automatically, or choose to do so manually by calling Update().
-Override OnDataReceived(GNIData data, uint source) to interpret signals. It’s called from Update when a full GNIData has been received. ‘Source’ is the clientID of the client that sent the signal.
-Override OnClientConnected(GNIClientInformation client) if you want something to happen when a player joins. (The client is automatically added to the client list.)
-Override OnClientDisconnected(GNIClientInformation client) if you want something to happen when a player disconnects. (The client is automatically removed from the client list.)
-Use SendSignal(…) to send a GNIData to a client, or BroadcastSignal(…) to send a GNIData to every client.
-Send empty signals (datatype and valuetype ‘none’) if you want the server to automatically detect if a connection has been lost; otherwise it won’t notice until it fails to send a signal to it.

Client
-The client class must inherit from the library’s GNIClient class.
-Call StartClient(…) to start the client. It WILL NOT check for incoming signals automatically; call AutoPoll() to have it do that. Alternatively, call Update() whenever you want to check for incoming signals.
-Override OnDataReceived(GNIData data, uint source) to interpret signals. It’s called from Update when a full GNIData has been received. ‘Source’ is always 0 and meaningless in the client.
-Use SendSignal(…) to send a GNIData to the server.
-To be honest, I’m not sure what happens when the client unexpectedly loses connection to the server. It’ll probably throw an exception, so just catch that.

Documentation
Does not exist. If you can’t figure out the code, it’s best not to use it as it might still be buggy.

License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
You are free:
* to Share — to copy, distribute and transmit the work
* to Remix — to adapt the work
* to make commercial use of the work
Under the following conditions:
* Attribution — You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).

Have fun, and good luck with your games.

TOAST and Flash Online Scores tutorial reminder

Posted by
Sunday, August 22nd, 2010 4:18 am

Sunday morning at the game dev factory

TOAST

Good morning Ludum Dare. I had one bite of my toast before I snapped out of it and realized I NEED A PICTURE OF MY FOOD!

Made my coffee.  Opened the window blinds. Eating my toast.

Got 5 hours of sleep again last night and am trying to stay both calm and pumped for the next 15 hours that remain. My game will hopefully change and improve a lot over this day.

FLASH GAME HIGHSCORES TUTORIAL

One thing I wanted to post about that I remembered last night as I finished dropping in online highscores into my Flash game was that with such a large and new crop of LDers here there may be a few that use Flash and haven’t got an easy highscores option to encourage some friendly competition on their score based game.

Well have no fear! One option is to check out a tutorial I made here a year ago about how to drop MochiMedia global highscores into your game. You don’t have to use their wrapper or ads or anything–you can use just their highscore widget.

You can check out my tutorial here and feel free to ask any questions that may come up if you are using Flixel or FlashPunk I know people here have used it with those though sometimes you have to adapt my tutorial a bit I think.

Plus you can see how they work in my current LD entry here.

TurnStyle (Spawn of Cryptid Puzzle Challenge) Released

Posted by
Saturday, February 28th, 2009 8:37 am

Well after an incredible amount of work I have finally released my first Flash / ActionScript 2.0 game! You can play it here if you’d like. I hope it is cool to post here because it is relevant in that the original game play idea came from my Cryptid Puzzle Challenge entry in the Mini-Ludum Dare #7 competition back at the beginning of the month.  I also wanted to really share it all with my buds here at Ludum Dare!  :-)

Here is level 3 from my first Flash game TurnStyle.

TurnStyle is a unique visual and memory based puzzle game where each of the 15 puzzles are original illustrations that follow a complete story arc over the duration of the game.

Every puzzle is made up of individual pieces which have been randomly rotated so that they are scrambled each time. You must work quickly and efficiently to rotate the individual pieces into the proper alignment before the timer runs out.

There are easy, medium, and hard difficulty puzzles mainly guided by the amount of individual image pieces that make up each puzzle and the way that I break up the images into pieces.

Personal best records are stored locally for score and rotation count per puzzle. Global high scores may be submitted to the Mochi Leaderboards at any puzzle progress screen. You are able to retry a level if the time runs out.

I haven’t submitted it to any portals or whatnot yet so it is living at it’s mochi-ads home right now.  I’m using their encryption, version control platform, advert api, and leaderboards/facebook api.  Seems pretty easy to setup.

I will try to post more about my adventure in creating this game and learning Flash over at my personal site but for now this is finished!

[cache: storing page]