FrankenCiv: a hypothetical

[Felch]

Yes to both kinds of cheating, and yes to the scripting. It's all been done before and it can all be done again. At least in theory. Speaking for myself, this would all be a new and invigorating experience.

[Elok]

There are certain things that I just can't envision a computer doing well, like scouting and drawing reasonable inferences from what it finds. I'm comfortable with workarounds for that, personally. If the player isn't, he has a number of options: he can turn off cheats he finds unpalatable, he can play multiplayer, or he can feel inspired to join our team and improve AI performance.

EDIT: I'm sure I've reinvented the wheel several times in this thread. My apologies if it's really annoying; I'm not exactly current on possibilities. It seems to me that, if we're doing something intended for scenario play (i.e., few random maps), we won't be as constrained by AI stupidity. Specific instructions sound much easier to teach a computer than broad general principles.

Also, would it be possible and legit for you to use your fancy game designer software for things that don't make it into the core game (the part intended to be modified)? Say, a specific modpack or scenario?

[Aeson]

An HTML5 game can generally be run locally if you want. To allow for it easily, you just use relative paths to assets, settings, and scripts and make any calls to server (pulling from a database via AJAX) optional features that will just be disabled if they aren't possible. All the game assets are downloaded to the player's computer (browser cache) even if hosted remotely. So if the player instead saves those files to their local machine, they would be able to run it from there.

In regards to AI, I think the best option is to set up so that any player can be a player or AI. Then the AI scripts can hook in if someone wants to code an AI. (I would definitely want to code one myself.) All the commands an AI can give, the player can give. All the bonuses/negatives an AI could be given, can be given to the player. Just treat them the same from an interface standpoint. (The player presses the up key which triggers a function, the AI script can call the same function. Though it doesn't have to put a button of course.) This allows maximum flexibility to modders. They can modify an AI if necessary to change how it handles a new game concept for instance. It also makes gameplay much more stable. If a player drops from a game, the AI that was selected for the game could take over.

To kinda tie the points together ... A simplified directory structure for an AI mod might be:

-game
--base
---images
---settings (data, XML or JSON most likely, but the format would be modable itself)
---scripts
----core.js
----ai.js
----etc
--mods
---modX
----images
----settings
----scripts
-----ai.js

Then what happens when the game (which in this example would essentially be in game > base > scripts > core.js) looks to load the AI class, it would first look in the modX directory (assuming modX was selected from settings), it finds ai.js there, so it loads it. If it wasn't there, it would load ai.js from the base folder. The same sort of thing would happen when loading image or settings.

This way mods are plug and play and the core game files never need to be overwritten. You just need to make sure the modX is on the platform you're playing in the mods directory, whether that's the server or local machine.

(It's more complicated than that of course, but the basic idea...)

If say the entire game directory was on Apolyton, but someone downloaded it (which they have to do to play, at least the applicable files for the mod they are playing), they could play offline. Though there are some features that might not work without a connection to the server. Say if we have an AJAX call to a database to save or display high scores. That would require access to the server. So would a pitboss game hosted on the server. But those types of features should be optional to allow offline play.

[Aeson]

What kind of cheating? "AI gets absurd production and research advantages" cheating, or "AI has units magically teleport into boats" cheating? Either way, a cheating rat bastard AI is better than none at all IMO. Could you compensate by including scripting tools, so the scenario designer can include hand-holding instructions for a specific map, game and power? I'm thinking of the way old CivII designers used to spam MoveUnit commands to overcome the AI's tactical glue-sniffing proclivities. I also thought it'd be nice to include something like a macro (don't know if that's the right term); you know how a lot of players say, "at point X, I typically go for impact rovers while building up production in my three best bases" or whatever? It sounds feasible to give the AI limited instructions that way.

We could allow for scripting. Things like build queues and research paths. These could even be mod specific.

We should also allow for weighting. Rather than exact build queues, builds have weights which when combined with other weighting factors would be used to determine order of build. Personalities would have different weightings for different categories of actions. Situational "awareness" functions could adjust weightings.

Then the game could first look for "hard" scripting, if it's not there, it falls back to weighting. If that's not there, it rolls dice.

Leave it up to the modder which path to take.

[Elok]

This does sound pretty boss. At what point should we sit down and hammer out the basic features to include by default (culture, espionage points, great people, promotions, specific combat models, etc.)?

[Elok]

(apologies if my enthusiasm gets annoying, as well--this could be an awesome opportunity for me to simultaneously build up job skills, help the forum and have hella fun)

I can definitely see what you mean about not coding in what a unit can't do. Just took a peek at the unit xmls for some BTS mods. Some of these mods, almost every unit has about a billion tags, mostly to say [someability]DOESN'THAVEIT[/someability]. It's like, geez, couldn't you just say that units can't build fortresses, spy, or survive nuclear strikes unless told explicitly otherwise? The clutter is aggravating, makes it hard to sift through, and when you add it up over dozens of xml files accessed constantly it seems like it's got to degrade performance at least a little bit. Especially when all those extra tags eat bandwidth.

[Felch]

I think the first step is to figure out basics, like working with melonJS and the other development tools. Figure out how to make something simple, and then add things to it.

[Aeson]

It's good to have lots of discussions about what should be done and when. We can build a list of features ordered on priority then start working our way down. It may be that some are mutually exclusive or different variations, that's ok. Then we just work our way down the list of features to add and whatever we get to defines the "base" at that point.

The first "base" game is going to be a tiled map with a unit you can move around.

melonJS (or whatever library we end up going with) should get us very close to that point right from the start.

For my part any extended coding is going to have to wait until August most likely. Probably can get something simple together (like the aforementioned first "base") sooner though just to test melonJS and see if it's something we could build off of. The basic mod functionality would be one of the first things to build, to make sure everything else we add in will work with it.

[Elok]

Well, in the meantime my course is pretty clear: make time to finish learning the requisite languages, and get comfortable with them. I suppose I can just play around with MelonJS and do my own builds off your basic construct; if I wind up building some abominations, hey, it's a learning experience.

Incidentally, how do you pronounce your username? Eye-sawn? Ay-sun? Ee-sone? Just tried to give my wife an idea of where we were, and I wound up referring to "the admin dude in the Philippines."

[Felch]

It's good to have lots of discussions about what should be done and when. We can build a list of features ordered on priority then start working our way down. It may be that some are mutually exclusive or different variations, that's ok. Then we just work our way down the list of features to add and whatever we get to defines the "base" at that point.

The first "base" game is going to be a tiled map with a unit you can move around.

melonJS (or whatever library we end up going with) should get us very close to that point right from the start.

I agree. No harm in making a wish list, but I think we've got an idea of what the game will look like in the end (Civ 4/5 with Civ 2 graphics). Learning the tools is going to take time.

Well, in the meantime my course is pretty clear: make time to finish learning the requisite languages, and get comfortable with them.

Have you been doing anything on Codecademy? I did the Python course and I'm plugging away at the HTML/CSS, but Javascript is what we'd need to learn to do this job. I think that'd be a good place to start (for both of us).

[onodera]

Well, in the meantime my course is pretty clear: make time to finish learning the requisite languages, and get comfortable with them. I suppose I can just play around with MelonJS and do my own builds off your basic construct; if I wind up building some abominations, hey, it's a learning experience.

Incidentally, how do you pronounce your username? Eye-sawn? Ay-sun? Ee-sone? Just tried to give my wife an idea of where we were, and I wound up referring to "the admin dude in the Philippines."

The list of basic constructs that should be your stepping stones:
1) render a hardcoded isometric map
2) load and render a map from a hardcoded file, recenter it by middle-clicking
3) add the main menu game state to load and render different maps from various files
4) spawn a unit by right clicking a tile
5) select a unit by left clicking a tile
6) add a "teleport" command to the unit (no pathfinding yet)
7) add a "die" command to the unit
8) add units to the save file format
9) make the game save units together with the map
10) tell yourself you're awesome
Now onto the next stage
11) add hardcoded unit types
12) add hardcoded terrain types
13) add a menu to change the terrain types
14) add a command to change unit types and a pop-up menu that asks for a unit type when spawning a unit
15) extract unit types and terrain types to a file that is loaded by your game
16) add a mod menu that loads different files with unit types and terrain types
17) add movement cost parameter to terrain types and movement type and movement points to unit types (each movement type should have movement costs for all terrain types it can move through)
18) add a method to your units that returns their remaining movement points and a method to the tile that returns its movement cost
19) add a method to your units that checks if they can move to the adjacent tile and a method that moves them there and reduces their remaining MPs
20) add movement points and movement methods to the interface, remove the teleportation from the menu

No time to tell you that you're awesome, sorry. You units are stuck with no moves left!

21) make sure that your units' remaining MPs are saved and loaded correctly
22) add a button and a method that resets their remaining MPs
23) add a check to the button that asks you if you want to move one of your units if they can still move
24) add a player ID to the units and a current player ID together with the list of IDs to the game, make sure both save and load correctly
25) change your replenishment method that it only replenishes MPs for the current player and switches the current player ID
26) change your interface that you can only command your own units
27) add a victory condition check to your EOT button: if only one player has units, he has won
28) add a message box that tells him that once and only once per game
29) add a "new game option" that allows you to get a map from another saved game, specify the number of players and then spawns the units randomly
30) tell yourself you're super awesome!

Now it's time to sit back and refactor your code. First of all, go through your code and separate your graphics engine from your world engine. Then, split your world engine into a Model-View-Controller setup: the world contains all the knowledge about the game in progress, the views are separate for each player and give access only to the data they're allowed to know, they are used by the graphics engine to display the game, the controllers contain all the commands available to the players, they check that the commands are valid and then translate them into the internal model commands.

At this point you should be ready to continue with the rest of the game, if you aren't burnt out.

[Aeson]

Well, in the meantime my course is pretty clear: make time to finish learning the requisite languages, and get comfortable with them. I suppose I can just play around with MelonJS and do my own builds off your basic construct; if I wind up building some abominations, hey, it's a learning experience.

Incidentally, how do you pronounce your username? Eye-sawn? Ay-sun? Ee-sone? Just tried to give my wife an idea of where we were, and I wound up referring to "the admin dude in the Philippines."

I honestly don't pronounce it. I think the Ae would be like in Aegean, since it's a Greek name. Then again, we Americans probably don't pronounce Aegean right either.

My real name is Joseph if it helps

[Elok]

I'll go with Aye-son or aye-sown. Probably closest to Greek.

I'm 56% finished with codecademy's HTML/CSS lessons right now, Felch. Javascript comes next.

[Elok]

I imagine this process will be somewhat less nightmarish when split four ways, assuming we divvy it up clearly. Incidentally, why configure the "teleport" command only to remove it later? Why not just set movement from the start?

[Elok]

Hopefully final consecutive post: if, as Aeson said earlier, the finished game could be modded with Paint and Notepad, could we each be using a different tool to develop it without conflicts? I plan to download Melon and Tiled today, using the superior bandwidth at the library.