(I'm aware I overuse that graphic, but I don't want to do any game making until the client is finished, so it's just existing graphics thrown together.)


Afar++

Afar++ is a sequel to Afar. Just a working title, and it will probably just be called Afar again, I'm just differentiating it.


What was/is Afar?

Afar is an online game played in a browser. It's made in PHP and played over the web over HTTP.

This makes it's structure quite odd for a game I guess. It's state based.

The "client" sends some data to the server, like "I just clicked the Attack button". The server acts on this and produces a web page, and sends it back, for example showing an animation of an attack.

This is simple and rubbish, but can produce a complex game, and Afar is incredibly complex, my justification for saying that being that I can't remember all the stuff I've thrown into it. Systems on top of systems all working together in... a mess. It's too complex for it's own good.

But unfortunately it's also not pretty, and not fun to play. Justification for that being player feedback.


What is Afar++?

Afar++ is essentially what Afar was meant to be. Afar was only ever a website based client working on top of Vengeance, an RPG Maker MMORPG. Afar worked out simpler to work with so I continued with it and ditched Vengeance. (Bit more complicated than that but w/e, that'll do).

Afar++ is a full RPG Maker game. It's an RPG, as expansive as any single player RPG game, graphically based and created in RPG Maker.


Online Functionality

Afar++ is based around infrequent input and output to an online server. This works in much the same way as Afar, but doesn't create the central game, just work for storage and updates.


Auto-Updater

The most important part of Afar++ will be the auto-updater. Once this is done, anything can be done.

The auto-updater downloads a small text file containing the version number of each file in the game. The game compares this with a previously downloaded list, and uses it to build a list of new files to download. It then downloads these files.

Updates

Updates will probably be done weekly. I like the idea of an update day, which was an element of a few games I've played. That you always know something new is coming, and are excited to find out what it is, etc.


Other online functions

There will be no other players walking around in Afar++, the same as in Afar. This is, for Afar++, unnecessary, resource intensive, and difficult to work around. You play the game as a single player on each map.

So what makes it a multiplayer game, and why?

Cooperatively created worlds

The very world you play in is shaped around what other players are doing. What items shops stock, what and indeed who NPCs are talking about, where you can travel and the strength of various armies and factions revolves around who is doing what, and who has done what.

This is based around world events, a concept directly lifted from Guild Wars 2.

Trading and economy

The game will have an economy based around a central online store, similar to the Grand Exchange from RuneScape. As what items you can obtain is based around what other players are doing, resources can be scarce. This will, hopefully, lead to a strong economy of resources. Players buy and sell items on an online store, setting the price themselves. They don't directly buy and sell from eachother in this system.

There will also be player to player trading, most likely handled on a website.

Chat

There will, hopefully, be a chat system, based around IRC, so that you can directly talk to other players while you're playing. This could be used to coordinate movements to manipulate the world events system for example, to do raids together and such.

Living NPCs

NPCs in the game will actually be other players, depending on what they've done and who they are. You may have just bumped into a random princess in a tower, but she happens to be Amy.

Sim PvP

Sim PvP is where you fight computer controlled representations of real players. You fight a clone of them using their equipment, stats and looks.

Guilds

Members can join and participate in guilds, which have guild houses and other in-game things. You might not be able to see other players but you can still play alongside them.



How much of this is done?

The client is reasonably in progress but none of the rest is done at all. It will be implemented in stages.

The most complex sounding part, world events, is actually quite easy to implement, I know how to do it well.

Cooperatively created worlds

I'll try and give an example for how this will work, for a part of the game.

Imagine a kingdom in the game which is at civil war. Two rival groups want control over it. They have their bases at either end of the kingdom, and in the middle is the castle that controls it, and a town around it.

The two sides battle against one another in real time. At any one time, one side can be controlling the castle and town. Or nobody can.

You might choose to side with one of the armies, fighting against the other. Your efforts strengthen or weaken either side depending on how well you do.

If the town is under control of the evil faction, none of the market traders open up. There are road blocks, and it's difficult to get around. Drawbridges are up at the castle and security is tight.

After it loses control it's left in a mess. NPCs are reluctant to let you into their homes.

The good guys take over, and suddenly there is no wood available, because the "bad guys" were working with the Guild of Woodcutters, who now won't cooperate. So weapons are now more expensive, if available at all.

I'm not sure that example's particularly well thought out, but as I said, I'm not game making at the moment, just making the client. Actual events within the game will be more thoughtful.

Cool ideas! You're always posting on everyone else's stuff, so here's a nice fat comment for you. I have a few points I want to bring up.

1. Scope
I would think very carefully about scope if I were you. Making a world that's very reactive to player actions is difficult, although you can certainly fake it with well-chosen mechanics that seem to be more complex than they are. If I were you, I would start by drawing up concrete plans for all of your ideas and then weigh difficulty of implementation versus how much they actually add to the game. Then I would prioritize features that add the most engagement for the least amount of effort.

For example, have you given much thought to how you're going to make other players into NPCs from a technical standpoint? This sounds like a cool idea, but what does it actually involve? Are the NPCs going to fill predefined roles and simply take on the name/player graphic of other players, or is it going to be more complex than that, like mimicking the actions of the player somehow? Is the payoff of seeing another player act in an NPC role worth the effort of implementing the feature, or would it be better to focus on something else to begin with?

2. Focus
I think the most compelling games are generally based around simple core mechanics. You have a lot of ideas here, but I think you should identify one or two key features to base your game around, then add other things later as a bonus. If I were you, I would spend some time rapidly prototyping a few different ideas and identifying what you expect the key elements of player interaction to be. Then make those as fun as possible before you do anything else. I took a class on game design and prototyping last semester and really learned to appreciate the value of rapid iteration in the design stages, and I can go into it in more detail if you want.

Anyway, of the ideas you've outlined here, my favorite is the idea of player-controlled territory. If you have a big enough player base to support it, you can create a lot of engagement with relatively simple mechanics. I used to play a zombie apocalypse browser game called Urban Dead that used some really simple mechanics for that. Basically, it was set in a city with a bunch of buildings that changed based on player actions. Human players could repair and barricade safehouses to keep zombies out, and zombie players could break into them to eat human players. The code is simple enough to be written in an afternoon, but it resulted in a lot of complex metagaming around scheduling attacks, defending against sieges, etc.

3. Player Base
First of all, how many players can you reasonably expect? This will affect the features you decide to base your game around. For example, territory control works better the more players you have, although you might be able to run bots to bulk up the player ranks until you have enough real people to support the game. Also, how are you going to find new players and retain them once you have them? One nice thing about PvP is that it takes some pressure off of you to constantly come out with new content, but you need users for PvP.

On that note, think about accessibility. The idea of running the game in a client is cool, but I think you can expect fewer people to play a game they have to download than one they can play in a browser. Going back to my earlier example of Urban Dead, I think one thing it did really well was be accessible. It runs in a browser, and the mechanics are simple, so it's easy for new players to pick it up and play for a few minutes every day. It's not necessarily bad for your game to have fewer players, but again, this will influence the design decisions you make. I do think it's difficult to acquire a large playerbase for a client-based MMO as an indie, though, so I would caution you against making player involvement an essential part of the game if it requires nontrivial effort (e.g. a download) for users to set the game up. PvE with some nice but not mandatory online/PvP features could work, though.

Can I ask why you decided to go back to RM after running a web-based game?

Thanks for that, and I definitely agree. The main focus will be on world events, and I think I know how to make it look and feel pretty complex while being incredibly simple in the background. If I can get that working in a small scope, then expanding it in future updates will be easy. I'll get it working for one small bit first, and continue from there, and so on.

I'm doing this in RM because I do not want to create a game engine for this; I spent much of the time I could have been making Vengeance making the engine, and it ate up any of the actual game development. I just want to make content, more and more content, so I don't want to be worrying about animating sprites and building a database etc. RPG Maker has already done those things for me. I know the compatibility is shit, and accessibility poor, but having tried browser based games and other engines, RPG Maker is just what I know best and what I know I can work with to the most potential.

I've made progress, having just finished the auto-updater, which works fully. Essentially, now that I've done login and auto updating, the client is done, as that's all that's needed for future updates to just plonk themselves onto players' computers, if that makes sense. It is fast, too, or seems to be.

I still need to encrypt passwords though, that's one thing. I'm sending them plain text at the moment which is not good. I need to come up with an encryption algorithm and implement it both ends. Simple other than finding the algorithm.

Er, what else...

Oh, as for players-as-NPCs, it wouldn't be very complex. Say a player achieves the rank of leader of the Handjobian Army and you play as a character in that army, during your quests and such you'd be lead by an NPC called, and looking like, that player. And, if you had to fight them, they'd have their skills and equipment. There'd be a bank of positions that would draw from the player database every now and then. I'm not sure how well it would work, I just remember playing BattleOn, where in the Guardian's Tower there were NPCs that were named after people on the forums - and it was interesting to meet the real people. I want something slightly more dynamic than that.

Okay, that sounds cool. I wanted to post but wasn't sure what to comment on, so I figured a sanity check was a good thing to default to. Looking forward to see where you go with this.

I think there's definitely potential for it to get out of hand, but as with afar, as everything's released when done in small chunks, it's easier to finish and release things. Once the game's online, with some interesting content, then it will be easier to release stuff, feedback comes in quicker, more buzz so more motivation, etc. If that makes sense.

I didn't think this through entirely well - just occurred to me the obvious that all switches, movement, well, everything will have to be sent and stored on the server too. Not too much of a problem, just extra work. I won't be sending player movements, I'll just send the player's X and Y any time anything else is sent, so when a switch is changed or when an item is gained. Or, on top of that, if the player's walked a significant distance, say 200 steps, because that could be annoying if your daily action was just to explore and you lost it all.

Also scripted an error scene and made a quick shitty windowskin until I edit the window scripts:



Takes a string for the message and a boolean for whether it's game killing or not; if it's not game killing it goes to the title scene after showing. String can be an error code for prewritten errors.

I'm still using Scene_Title itself, just replaced New Game / Continue / End with Existing Player / New Player / End. Will probably remove the End.

Oh yes I forgot entirely about the variables on the client-side, that could be annoying for you.

Seeing that screenshot got me pretty excited actually

Successfully turned Game_Switches into a net thing, reading a switch from the server when $game_switches[] is used.

Easier than I thought it would be. So that crisis is resolved.

(It also updates the stored x and y of the player when the switch is accessed.)

Now I need to write them, and then do the same for variables and self switches.

Safe, too, as it uses the session opened with the login sequence rather than sending a player id with the info.

Also, what is the point of the 5,000 limit coded into Game_Switches? Why are they worried you might enter a higher value?


Edit:

Switches complete! Get and set both work.

Edit2:

Variables done too.

IRC within RPG Maker is a bad idea (and takes up screen space anyway). So what about doing it the BattleOn way (how they were originally lain out) and having it in a separate window?

I'd probably commission it, rather than making it myself, having tried and failed to make IRC clients before. It'd be a simple client. An executable that would take a name and screen coordinates as parameters, so that when the game opened it would open the client next to it and sign you in as you.

Registered nicks would show as yellow/gold, non-registered as grey; there would be simple processes within the client for registering nicks and logging in, with the understanding that IRC is separate to the game itself with authentication and whatnot.

Other than that, it would just have a text box and a go button, and would just be one chat room, with no other fancy features.



If you didn't want chat you could just close the chat client when the game opens. Ideally you could resize the chat window and reposition it, too.

On opening it it would offer you four buttons:

1. Chat as a guest
2. Chat with a registered nick
3. Register a nick
4. Don't chat (would just exit)

(Afar logo is just for show and wouldn't show other than on this splash).

The separate idea is nice, but if you could figure out word-wrap, having it inside RPGMaker wouldn't be that bad. Just have options available like font size and opacity so that people can tweak it so it doesn't bother them or hide it all together, and the word-wrap will keep it from covering the entire screen. No windowskin, obviously.
Probably just shift the message window's coords to the right to compensate a little too should you make the chat to the left of the screen, too.

Alternatively, custom resolution mods are all over the place, and they work pretty well for this kind of thing; thats what I did for my chat system - increased it to 704x480 and used the blank space beside the game as the chat area.

Just throwing ideas out there :biggrin:

I keep forgetting I'm coming at this as a newbie now and that everyone's done it all before me, haha. When I started it was just three or four of us on the Netplay forums playing with it as they made it.

I think, going by what I've done before, it would be best to have it separate for performance reasons. By having the game client JUST handle the game, and nothing else, it keeps it from getting laggy. Last time I tried to get IRC working in RPG Maker I got it done, but nothing could be done alongside it, as it overpowered it. I could have multi-threaded I guess.

If I do go with the multi-window idea though I could extend it, with more windows. (More is always better, right?) - anything that has to be done via the web (or is best done via the web) - guild management, user guide (wiki), forums, possibly trading, could be done in separate windows (web browser scaled down).

So the basic mechanism, which doesn't sound that complicated, is somewhat of a defcon system. The world is split into sections and each section can at any one time be controlled by one or another faction.

In the starter scenario, a village is being attacked by raiders.

For each area there is a global variable for the map, starting at 0. Actions done by players raise or lower this variable. Negative puts it in the villagers' hands, positive puts it in the rebels' hands.

But it also depends on what's going on in the rest of the world.

If the villagers control the rebel camp, then the rebels can't control the village. They'd be out of resources and numbers. If the rebels control the village, the villagers can't control the rebel camp - they'd be too scared for their village.



The things that could be done depending on strength of each faction are as much as deciding what quests you can complete.

It would be set up in such a way that a single player online on their own could in a reasonable amount of time clear up this area. But with more players online it would switch a lot more, carefully weighted depending on how many people are doing things.

If you're already in a sub-area it won't suddenly change around you, the change will be gradual, for example if it's at peace and the rebels gain strength, in your instance scouts will start appearing that you can pick off. But if somebody else entered that sub area it would be a different world.

But this wouldn't be the world, this would be an area of the world. And each area would have sub-areas. So at any one point in the world there can be many of these world events taking place, some interacting with each other, and not always with just two sides.

Princess Amy":2u1ax1e4 said:

If you're already in a sub-area it won't suddenly change around you, the change will be gradual, for example if it's at peace and the rebels gain strength, in your instance scouts will start appearing that you can pick off. But if somebody else entered that sub area it would be a different world.

Click to expand...

Does that mean that you can farm scouts infinitely, but you can't rescue the map until you've left it and re-entered?

Also, what battle system are you going to use?

There'd be a cut off. Basically it's to make the transition between states smoother. If you stayed in an area clearing scouts but the game knew they were too strong there'd be a cut scene of some sorts and everything would change.

The battle system will be an abs, but I need to research what's around as I'm clueless at the moment.

Progress at the moment is mainly ate up by preparing stuff for the future - graphics, etc. Concept wise I thought up a better mouse system. Click the map to move to that location. If there's an event on it, then if it's still there when you get there, it tries to activate it. Right click it and you can choose to walk to it or to activate it. Enemies, click to select as a target and if you're using a close combat weapon you'll walk up to it and attack on reaching it, otherwise you walk until in range and then attack.

World events system is mapped out in my head and partially on paper, but not tested as I need to get other stuff ready first.

Am going to have to rebuild my switch system after realising having an event with a switch trigger would dos the server as it would check every frame. Instead I shall separate switches from net_switches like in netplay 1. Further I'll have to implement global switches which are net but apply to all players.

Made some progress. Implemented mouse with pathfinding. Done some mapping.

The current map I am making is the trade route in the map above. Current thoughts on its world events:

Villager hands: trade caravan roams, woodcutters work, people around
Scouts: villagers get attacked occasionally, trade caravan on guard
enemy presence: everyone flees, trade caravan under attack
Enemies overwhelm: caravan on fire, nobody around
Enemies control: enemy camps set up with tents, difficult to get around

Lots of smaller events around the place based on who controls the area.

In a finished area, each level of control would have quests to complete and multiple intertwined events. In more complex areas it would not just be five levels of control, and would not be just two groups: think back to gangs in GTA - I guess this is a similar idea.

Experimenting with Blizz ABS.



Have mouse for movement/events but not currently for attacking.

Looking fantastic so far!

The stone border within the Windows window border looks a little weird to me...Saying that, I'm more of a minimalistic kind of person

I understand and that was a complaint against the original Afar too, but theme and looks are something I want to play with to set the game apart from others. Maybe I can come about it a different way.

Hopefully the overall Hud ends up better than this... one of my first, heh. The yellow box was print screened from a Norton AV popup...



...I was young.