The results:

	Hahn	Grue	Place
Snowscape	1	2	1st
TaBu	3	1	2nd
Funky Fight	2	5	3rd (tie)
Lufiaesque	4	3	3rd (tie)
Text-based	5	4	4th
Card Combat!	6	6	6th

Congrats to all contestants. You rock.

And now, an apology. I'm sorry for the delay in judging, which was caused by a lack of a third judge. When I asked Miko early on to judge again, I assumed her response was an affirmative, but it wasn't and she was way too busy all week. I tried pressuring vecna into it, but he doesn't love you guys enough. For some reason, I didn't think to ask Zara until it was way too late to delay any longer (that'd be at the time of this writing). So yeah, sorry. This judging system really needs at least 3 to prevent ties like this. Bad me.

And now, the prize: The prizewinners get to design a monster for inclusion in Sully. Hahn and I get final say, but go nuts, guys. If there was any question, I'm talking about designing the name, stats, skills, and AI for this Monster. 1st place gets to make an optional kickass boss, 2nd gets an optional boss, the thirds get optional minibosses, and fourth place (which will be added to the prizes because of the unfortunate tie which was all my fault) will get to make a common enemy (which is less cool, but will be more visible!). Again, don't worry about the art, just the details of the enemy. Email your entries to me and we'll pound out a fitting final form! :)

Again, congrats to all, and thanks for being awesome!

The next HoV starts this friday

It will be a 20 17-day contest to make a short RPG. If you do not think this enough, I made the first SotS demo in 7 days by myself. So, yeah.

More details (rules, requirements, etc) will come up later. Also, I'll be securing the judges in advance and making sure everyone's on the same page this time. ;)

Note: this is not spellchecked, because I didn't spellcheck it.

Grue's schema

Gameplay - 30 pts.

Does it execute gracefully?
Is the system as complex as it's premise requires?
How much strategy does the system allow?
How much skill does the system require?
...is it fun?

Interface - 15 pts.

How elegant is the interface?
How intuitive is the interface?

Portability - 15 pts.

How mobile is the code?
Does the code have unique and uncommon function names and global variables?
Is it's use documented?
Can it be modified by a non-coder easily?

Code - 15 pts.

Was it coded well?
Is the code easy to read?
Is the code documented?

Innovation - 15 pts.

Is it completly new?
Is it an intresting spin on old themes?
Is it more cliched than Admiral Ackbar catching mice?

Discretion - 10 pts.

How much did it impress me? ;)
Random other bits that amuse or annoy me.

The Games

(Listed in no particular order)

---

Funky Fight!

by SDHawk, Salamando, Troupe

Gameplay: 18 pts.
The first few times I played this, I was completely owned. And then I realized that I was pressing the keys at the life bar, and the 'bar' in the instructions was the big red bar. Sorry, I don't play DDR. ;)
Anyway, this is overall an intriguing little system. I was definitly not expecting it.
There is some strategy implicit in the system, but not much. I've beaten the game totally by doing attacks, and ignoring healing and specials. The AI doesn't seem competant enough to get anything effectivly done if you're hitting the marks.
I would suggest some more 'brakes' on the system. There should be a penalty to healing, and a penalty to gaining your skill points. There should be effects that speed up and slow down your tracts and your opponent's tracts. Powerful moves should mean you get robbed of options for a while, or perhaps have certain commands disabled.
Frankly, this combination of DDR and RPG seems prgnant with intresting ways to play the concept.
Furthermore, the AI really does feel extranous when I play this. I keep wanting to go head to head with a real person in a bigger, badder, fleshed-out version of what's here. However, I'm strained to figure out a game that would be an RPG and still be natural with that sort of gameplay. The best I can concieve is making it completely non-traditional and try and be party-game RPG weird like Final Fantasy Crystal Chronicles, but I'll leave that ponderance for a braver man.
As the system stands, it is quite enjoyable, and very odd. I was very amused by it when I first played it, and it's fairly enjoyable. It really needs more spice to support a full game, but I'll take that into account in the Code section when I figure out the ability to extend the system as-coded.
18 points out of 30 awarded. Definitly better than the middle of the road, but the faults in gameplay balance issues here are not easily changed by tweaking numbers like in a traditional system, so I must take that into account.

Interface: 7 pts.
The interface is functional, if a little user-unfriendly. I would suggest a glyph in a corner that shows what each directional does for reference.
The background was cute, but not the amazingly spastic discogasmic cacophony of light that I've seen in every game Hahn's ever played in front of me during vergecons. I guess I just expect it with this genre. Lifting some background pattern generators from Timeless would've helped.
The use of sound effects was apt, but I found myself wanting more. Once again, if you're going to make this sort of game, subtlety and understatement is not supposed to sneak in anywhere. ;)
Overall: competant, but misfitting. half marks, erring on the rounding-down.

Portability: 3 pts.
The functions and variables are not uniquely named. The most egregious case is a struct named "Particle", although there are numerous other examples.
It would take some work to bootstrap this system into your game. filepaths and namespace checking would definitly need to be moevd, unless you like having all your vc in the base dir.
The use was not documented.
Low-level modifactions are somewhat clear. The AI struct has informative comments, and all the data is in a single vc file that you must edit.
Low points, but don't feel bad... I doubt most people actually payed heed to my desires for portability :(

Code: 11 pts
The code is formatted well, and for the most part has easily understandable functions. The commenting is sparse and mostly of the form of a coder's notes to himself, and not to a third party.
I could not readily identify the parts that control the speed of the scrolling and the such, so I am not able to determine how easily extensible the system is in those regards offhand.
The code is largely bug-free, and works well for what it was designed to do.

11 points, mostly good, some noteable omissions.

For the statsticians out there, this weighs in at:
109 ints (3229 expanded), 4 strings (46 expanded), 31 functions, 2030 total lines

Innovation: 12 pts.
While certainly unique for an RPG battle system, I see on the horizon my weariness in apply rhythm game mechanics to all possible genres. However, as I am not yet disenfranchised, I will not hold this against this entry.
I am not entirely sure how well this plays into RPG battle systems at all, as before stated, since it would ideally be best a 2-player system. The subtleties of such asystem only fully come out with two able and practiced human opponents. To pretend you could make an AI that would be enjoyable and crafty is hopeful, to put it kindly.
The concept could definitly use some more refinement, but I will grant a majority of points to innovation.

Discretion: 6 pts.
Although the tone of this judgement may initially seem harsh, I rather liked the game. If it's ever polished up later, and incorporated into a full game, I would be endlessly fascinated.

Total: 57 pts. Above average and innovative. Perhaps difficult to put into a full game.

---

Lufia-esque BS

by Gayo

Gameplay: 15 pts.
This is one of the traditional entries, and of the whole contest, this is pretty much the closest to what I imagined Sully 1's battle system would've been back in the day.
...If this was complete.
Also, being the one actually coding Sully's Battle system, my hypothetical younger self would be entirely wrong. But that's neither here nor there.
At any rate, this battle system is very functional in the things it has working, and has no noticable egregious errors.
However, There is a lack in this incarnation of anything meaningful in the way of strategem. No status conditions, no special effects that I can see. Only two flavors of damage (Physical, Magical). There is definitly a framework in place, but no such items at this time.
And what the hell is that pinwheel icon, darnit!
Overall it's a functional, if currently hollow experience. Half marks. Also, it would've been nice to have some official 'press space to start battle' deal.

Interface: 14 pts.
The interface is simple and clean. In fullscreen, it is very responsive. The icons are cute and clean, if enigmatic (What *is* the pinwheel? Party favors?!) The Menu interface is well-formed and the textboxes are pleasing.
It's a little sparse, but could pass in a pinch for a SNES game. high marks.

Portability: 10 pts.
Ahh, gayo. You documented your functions in a clear plaintalk way, which is good by me. However you made way way too many global variables and functions named in a way that would promote naming clashes. While reviewing your code, there were innumerable times I was all "oh man." about them. some examples: pc, npc, money, GetHeight(), GetWidth(), IsPresent()... things that could easily be used in graphics libs or partyhandling libs or image libs... argh! :(
Half marks as a base, since it was half good and half bad, and a few extra points for having the best documentation of the competition.

Code: 14 pts.
This code is some of the clearest vc I've yet to stumble across. Well documented. Well spaced. Comments for implementors and readers alike. It was clearly designed for expansion, and to be understood by others.
My only complaints lie in a lack of folder structure for the various pieces, or an overlying "how everything fits together" explaination. High marks, but not perfect.

Stats:
78 ints (2235 expanded), 4 strings (21 expanded), 152 functions, 3988 total lines

Innovation: 4pts.
It is a variation, albiet a very clean one, on a very familiar theme. Not a particularly exciting variation, nor one that, barring the mysterious pinwheel icon, presents anything new. Low marks.

Discretion: 7pts.
Although there's not much to do, the whole package pleased me as a user library, which was my goal for this contest. It was constructed well, and has a large amount of framework to build upon. I believe Gayo has already expanded upon this in the time since the contest ended. This catches my favor for being so very VERGEy.

Total: 64 pts. Above average, but hurt by incompleteness.

---

Snowscape

by RageCage, Troupe, Sommerlost, Toen, Zeromus

Gameplay: 13 pts.
Well, here's the most visually impressive entry, done up in a resplendant (and very unusual) 512x384. It deviates from the expected in being more of an adventure-game System, taking place with movement and aiming and skill. It introduces a little ritual-based system that is definitly a new twist on an old theme of component-based magic, at least for me. The system demonstrates the loading of rituals and their combination to great effect, but I am left wondering how best to distribute them during a game to encourage changes in gameplay (rather than just using fireballs all the time).
I was equally impressed and disappointed, impressed by the gameplay possibilities of such a system, but disappointed in the enemy AI. The whole thing had a very Secret of Mana feel to it, and when the AI gets trapped on landscape features, well... it throws it off. Whenever I played, I ended up actually waiting until I could snag the guys on some feature so I could waste them leisurely.
I understand from the docs that non-magical attacking will be implemented, which is good news, because a quicker form of attack is definitly neccesary.
As it stands this demo is a nice tech demo, but I believe it will take much more time than the Contest allowed for to get it completed and polished in a fashion to do the promise shown here justice.
Presently, strategy and skill aren't really factors. The best strategy is to charge up a kill-lots-of-things spell at let it rip, or trap the AI using it's own machinations and destroy them at your leisure.
Also, I did not notice any experience system in gameplay or during code review. This is interesting, and a valid choice, but curious to say the least.
The only noticable gameplay bugs I found was the visual glitch of having eneies pop up out of nowhere occasionally.
Overall this is another promising, yet incomplete system. Half marks: a valid tech demo, but not quite a battle system yet. The AI problem is foremost, and you guys should watch your back with balance when that time comes.

Interface: 15 pts.
The interface to Snowscape is very interesting, unique, and frankly a bit sexy. I approve of the mouse/keyboard combination, although I would suggest allowing the ritual keys to be remapped in any final game you make for personal comfort and to aid those lefties out there.
The ability to scroll the screen around but not so far that the player is off of it is nice, and classy to boot. I would suggest a bounding border of how far you can scroll this so your guy is never on the edge or corner (unless it's the edge or corner of the map). Secret of Mana does this, and it encourages not abusing how entities are activated.
The destination point's glowing raindrop-circles were a nice visual touch. The sounds used were all appropriate.
Full marks. Capital job here, boys!

Portability: 6 pts.
Hrm. There's no documentation of any kind to show use, and the comments are few and mostly of the data-qualification kind. This codebase needs a large amount of going-over before someone else could use it or modify it effectivly.
Of some consolation is the note that the names of functions and variables are pretty much specialized to a point where this library could be used in a 'drop it in and go' fashion, once it's documented to the point where someone would want to use it.
I did not examine the code long enough to determine if the resolution was hardcoded in, or if the code was flexible enough to work at any res. I won't factor this into my grading, but 512x384 is not exactly a common res, and if the system requires it, that would be bad for re-use.
6 points: mid marks with a small demerit for having by far the worst systems documentation. I do give a thumbs-up to the html readme. more readmes should be in html. :)

Code: 13 pts.
Rather impressive. Very simple and usually easy to follow. However, the afore-mentioned lack of nearly all forms of comments sometimes derail things when trying to figure out at a glance what something's doing.
There is no doubt in my mind that RageCage is a very good coder, and will probably get even better in time. However, this lack of any sort of notation is usually a sign of youth. My ASM professor used to regale us with tales of magnificent programs he'd craft in a handful of days when he was a kid, set aside, come back to it weeks later, and stare blankly at... because there were no comments. Now, vc isn't exactly as rough as ASM to wade through for meaning, but wading through is still painful in it's own right.
All data is in-code. I have no problems with this technique. Of particular amusement was the ritualCode() function in rituals.vc. It's a giant list of if's that iterates through all combinations up to three letters of the four valid elements. Why not just alpha-sort the string when it's generated? (FYI: This was not a demerit, just an observation.)
full marks for a job well done, minus two for it's near-nakedness of comments.

For the anal:
110 ints (89936 expanded), 4 strings (111 expanded), 104 functions, 3761 total lines

Innovation: 13 pts.
It's pretty darn innovative. It's got a farm of concepts ready to pluck from it. This is this contest's leader in newness. I really don't have much to praise that I haven't already mentioned. It's pretty awesome.

Discretion: 7 points.
I liked it. It has it's strengths and faults, and I can only imagine the faults will fade with time and work.

Total: 67 points. Pretty, innovative, but hurt by incompleteness.

---

Text Battle

By Ness

Gameplay: 18 pts
Another rehash of a familiar form, this is a verbose, menu-driven variant on turn-based... being that the turns seem to be not based upon personal speed, but rather roster-order, yet the command executes immediately when the command is chosen. I'm not sure I've ever seen that before.
The gameplay is rather harsh, but that's mainly due to numbers used in the battles, and easily tweaked.
Of what's implemented, it seems fairly complete, actually... excepting that XP is granted but nothing seems to be done with it.
There's attacking, defending, at least one status ailment (the old standby of poison) and several 'grey' magic abilities.
Overall, this one errs more on the side of being a complete system than most of it's peers. However, it still requires a number of features before it would be fun to have in a game.

Interface: 3 pts.
The interface on this system needs, at best, a little work.
The controls are sluggish, which is odd for something forced into fullscreen.
The text-window of battle actions which the entry is named after is a style I approve of greatly, but it really should wait for a user to press enter before scrolling. Auto-scroll can be... annoying.
The graphics and sounds are a little on the rough side, which is okay since they can easily be swapped.
I would also suggest either setting the fontwidth to variable, or using a font designed for fixed width. The interface as a whole will be bettered by it.
Low marks given, but a little work would polish it all up in a rush.

Portability: 15 pts.
Aha! Finally, someone gave some lip-service to people actually using the system. Right there in the readme.txt. I was starting to think nobody would follow through :(
The combined power of the notes in the readme.txt, light (but descriptive) function documentation, and distinct variable and function names all around mean Ness gets full marks for portability.
Not bad for a kid from Onett.

Code: 15 pts.
The code itself is pretty good. Easy to read, and with a decent level of comments explaining process within functions. It looks as though this system is easily augmented, as well. I can only hope Ness, like Gayo, continues on with the work.
The main gripe I have is that life can be negative, and to recover someone from death, you need to use healing magic. Although, in the end, this could be considered an innovation rather than a bug. So I'm just confused.
The data, as with most other contestants, was in the code. This is neither good nor bad... just a fact.
Full marks for general all-around goodness.

If you're curious:
120 ints (1647 expanded), 9 strings (116 expanded), 42 functions, 2644 total lines

Innovation: 4 pts.
Some things about the way this was handled surprised me (see above for details) but in the end it's a pretty standard battle system. Low marks.

Discretion: 7 pts.
Although some may be upset by it's lack-of-pretty, as I said when announcing the contest Pretty by and large doesn't matter to me. This is one of my favorite entries because it's a solid base to work off of (both for Ness and others) and it facilitates that mindset.
I'm confident that with a little work, someone less technically-minded can add some pretty to it, and a solid package will emerge.
All I believe this system needs to be ready for use is items (for some reason I feel this needs items most out of the whole batch), fleshing out the spells and effects, and a little play testing. And *please* put pauses in the textbox that wait for user input to continue! :)

Total: 62 points. Surprisingly strong if you go only by looks... YOU SUPERFICIAL JERKS!

---

Card Combat!

By Zip

Gameplay: ...
This game was billed as this Contest's Balls of Steel. It's got a bit too much functionality for that title, and not enough Vanilla Ice to boot.

Overall it's an interesting codebase and I hope Zip does more with it. However, I'll forego a full review and just give him an arbitrary number to show that I care. 16. There.

And a bonus point for bonus.exe! 17! ;)

PS: I read teh donotreadme. And you couldn't stop me. Mwahaha.

Total: 17 points.

---

TaBu

By Buckermann

Gameplay: 26 pts.
Although there are faults and issues I have with this game, the fact remains that I consider this the most complete Battle System experience of any presented here. The issues I have are of convenience and style... mainly consisting of the set turn order and the lack of a wait command.
Other than that, the only grevious oversight is the meaninglessness of XP at present time, made even more sad by the short campaign set up in the demo. If I'm gaining XP, let me be buffer!
So yeah... although Buckermann warns us that it is incomplete, I found it to be pretty fulfilling overall. For a full game I would expect a lot more spells, effects, and abilities to keep things interesting, but this is definitly the leader of the pack. High marks.

Interface: 3 pts.
The interface is mainly where I have my bone to pick/axe to grind/noun to verb. First off, the control loop is *slow*. The controls are unresponsive, even in fullscreen mode, and I don't really know why. It's an annoyance to have to press down a key and hold it, or to press it several times.
Furthermore, having a visual cue as to how far a character can move, and what his weapon/spell range is is an expected (and rightly so) feature of tactics systems like this. This is a large oversight and I'll chalk that up to not enough time.
The menus and such were adequate and befitting the look and feel. Occasionally text would be printed out of the area it was supposed to fit in.
Low marks, but easily fixed with some work.

Note: after observing the code, all this unexpected unresponsiveness may be due to the large amounto flog() calls n the code.

Portability: 11 pts.
This was wisely crafted. As it stands, I cannot imagine anyone ever having namespace collisions with TABU as everything is prefixed with "TB_". This is my preferred method of handling libraries in VERGE, and if you're going to make a personal public-use library, you should really consider such tactics.
The commenting as far as function-description was sparse, but acceptable. 75% marks for this entry: could've used more handholding on the non-coder user level,and an implementation guide.

Code: 13 pts
The code is well-formed, heavily commented, and fairly well diveided into seperate files.
Unlink the other entries, this one uses plaintext data files for it's weapons/spells/armors, and even has a savefile. However, it's curious to note that the enemy definitions are in code rather than in parsed datafiles.
The code is good, but cryptic at times. This is abrogated by Buckermann's thourough use of comments to describe process. Good show.
There is also an excessive amount of logging. This is good for debugging, but bad for gameplay. A simple way to turn logging off would've been preferred.

Full marks, minus a tad for leaving the logging in.

And finally:
103 ints (125726 expanded), 10 strings (11004 expanded), 85 functions, 4060 total lines

Innovation: 7 pts.
Everything old is new again? I wasn't expecting this, and although I may've been surprised, it didn't really deviate from established, if old and non-console, norms. Half marks for thinking outside of the normal VERGE paradigm.


Discretion: 10 pts.
This was my favorite for this competition. It was... unexpected. I never played Ultima, but this reminded me of my childhood on the c64, and later the Amiga in such games like The Crescent Hawk's Inception. I'd never even considered putting a system like this into a VERGE game, but now that my eyes are opened, many, many things become apparent.
Also, I promise that I like this one best for legitimate reasons and not because I got to move first of all the PCs, too. Besides, vecna was the coolest person. Damn that Firestorm spell kicks ass.

Total: 70 pts. Would've been a runaway victory if the controlling was more responsive.

Congrats to everyone who sucked less than me and managed to get an entry. :D

I've played them all, and must say that I am impressed in general... except that I never figured out how to get into the battles in the Lufiaesque one. Now that I know, I'll try that out when I get home (knowing is half the battle, after all)!

Anyway, congrats again, and good luck to everyone in the next compo, which I will enter unless I die first. :) (And my entry will not be a badly drawn map with the words "YOU ARE RPG!")

Quote:Originally posted by Gayo

Congratulations, Grue, you have saved yourself from dying in flames. That would have been awkward for both of us.

Yeah. Dying always puts me in a bad mood. And have you ever tried getting the stench of burnt flesh out of the walls? Bah!

Interesting was the fact that except for CC, no game got the same rating from both judges.

Yes, I was interested in that too. Also, the tie made me sad that I never procured judge #3. :(


Anyway, some more comments about Lufia-esque, which I have decided to call LBS because it's shorter:

So... we can call it 'Pounds' for even shorter? :D


However, a few of the vars are indented to be general system variables for broader use. I saw no reason for people to have two totally different PC struct formats when one would work fine, and the money variable is intended to be for general use, and so on. This makes "plugging in" the BS to a pre-existing framework a bit harder, but I think that it will make building a new game with the intention to use the BS a bit easier. I think I will change the "npc" struct though, because I could see that being used for totally unrelated stuff.

Incorrect. It'll not make creating the game any easier. It'll just make the source slighty 'prettier'.

Incorrect. It'll not make creating the game any easier. It'll just make the source slighty 'prettier'.

I don't really see what you mean. How is it not harder to have your own money variable, for example, and have to add an extra step at the end of battle where moeny is transferred from the battle system's money variable to yours? Similarly, if you have two PC structs, you either have to use one for stats and one for other stuff, or duplicate parameters between them, neither of which is a good option and both of which require additional translation function overhead.

I must say that I'm very happy overall with the rating for my entry (of course I would have prefered to get the maximum points from Hahn and McGrue. But then I also would like to have a few billion euros, a super-model as a girlfriend and be declared emporer of the world). The seconds place in this competition is more than I originally had hoped for. Maybe because I'm much better informed about the problems and quirks my battle system has ;)

But I can't help it, I have to answer to some points the judges made. Please don't see this as complaints, just some clarifications:
Quote:Originally posted by hahn

POLISH:14
The source material might be a speed bump here. By re-creating Ultima, the art and sound options are
somewhat limited.[...]
It is possible to run my battlesystem in higher resolutions (with a bit of work). The main reason I choosed 320x240 is because of my limited artistic abilities, and because it's simply faster to draw some 16x16 sprites than 64x64 ones. Having said that, I fully acknowledge that my entry isn't very pleasant to the eye in it's current form.


PIZAZZ: 10
I found this demo very nostalgic and endearing. I would love to see it used as part of a full game
with exploration and story.
Maybe, and just only maybe, you'll see a small Sci-Fi game for the next competition from me. And I'm quite sure it will have a higher resolution.
And it's nice to see that you enjoyed it overall, even with the problems :)

Quote:Originally posted by mcgrue
Gameplay: 26 pts.
[...]
The issues I have are of convenience and style... mainly consisting of the set turn order and the lack of a wait command.
Mainly because I didn't had the time to implement a method for the computer player to change the order of his units in a (semi) intelligent way. And without this, giving the ability to change the order only to the player, would have made it much easier for the player. But this should be implemented in the next version (yeah, the next version. It's allways the next version).

Other than that, the only grevious oversight is the meaninglessness of XP at present time, made even more sad by the short campaign set up in the demo. If I'm gaining XP, let me be buffer! But XP has a meaning! If you make a level your HP/MP (and to a lesser degreee the other statistics) will be improved. The difference between a level 5 party and a level 10 party is quite noticeable.

Interface: 3 pts.
[...]
I fully deserve that rating. Much better in the next version :)

Portability: 11 pts.
[...]
I once had the position of the Senior Chief Master Coder in a fan made, semi-persistant, Neverwinter Nights (the one from Bioware) project. In that position I had to take all the scripts from the various coder and try to implement them in the main code base.
A NIGHTMARE!
Only after I rejected continously all scripts who didn't adhered to strict naming coventions, it got better. That time I learned that it is very important to give your functions/variables unique name if you want anybody else to use them in their own project.


[...] could've used more handholding on the non-coder user level,and an implementation guide.
Next version :)

Code: 13 pts
[...]
There is also an excessive amount of logging. This is good for debugging, but bad for gameplay. A simple way to turn logging off would've been preferred.
Excessive? You should have seen the logfile before I took out most of the Log()s :) Anyway, the NEXT VERSION will have a simple debug on/off switch.

That's all. Thanks again for the time you took to judge my entry. Your comments are very helpfull to improve my battlesytem.

Quote:Originally posted by Gayo

Incorrect. It'll not make creating the game any easier. It'll just make the source slighty 'prettier'.

I don't really see what you mean. How is it not harder to have your own money variable, for example, and have to add an extra step at the end of battle where moeny is transferred from the battle system's money variable to yours? Similarly, if you have two PC structs, you either have to use one for stats and one for other stuff, or duplicate parameters between them, neither of which is a good option and both of which require additional translation function overhead.

The best way for interoperability is to have an addMoney() / takeMoney() function for all money-transactions, and coordinate through there.

if you're marrying two different systems, the coder in charge of the ceremony will just nest them for greatest ease, like so:

int party_money; //the money variable for lib1





// this is lib1's money-adding function.


//anytime lib1 wants to add money, 


// it will call this, instead of adding money to the 


// party_money variable directly


void lib1_addMoney( int bling ) {


   party_money += bling;


}





// This is the same function in lib2, 


// with lib2's hypothetical money-variable 


// commented out and the function call


// to join it with lib1 in place.


//


// This function is called anywhere in lib2 that 


// wants to add money to the party's coffers.


void lib2_addMoney( int moola ) {


  


  //lib2_cash += moola;


  


  lib1_addMoney( moola );


}

Now, in the case of joining up two seperate Character structures, well, you can either do it by 'reference' (the master-array/index trick that I should probably formally explain in a FAQ very carefully), or you can have every member of your character struct have accessors to abstract in a similar fashion to above, or you can attempt to merge the two happily. Frankly, I prefer the level of abstraction via accessors road... even though I use the index-reference method in Sully.

Quote:Originally posted by mcgrue

structures, well, you can either do it by 'reference' (the master-array/index trick that I should probably formally explain in a FAQ very carefully), or you can have every member of your character struct have accessors to abstract in a similar fashion to above, or you can attempt to merge the two happily. Frankly, I prefer the level of abstraction via accessors road... even though I use the index-reference method in Sully.
That does sound interesting, FAQ it! Currently wondering how to handle cards that are going to want to store different data depending on type, but have several base variables the same, and want to be accessed all at once from the same place.

Zip

I think I'm going to relax the rule on pre-existing public code for Battle Systems. So yes, you can use it. But even if I don't relax that rule, as long as you publically release said battle system by Friday, then it'd still be valid.

Also, I will say this: A battle system will not be a neccesary component ot the HoV, nor will the battle system be judged except in how it effects the gameplay experience. This point will be driven home to the judges beforehand.

I do, however, encourage battle systems in the entries (I mean, come on, 17 days? ;). If I'm making it optional, I might as well have a secondary award to the best battle system implementation and integration.

THERE ARE SO MANY OPTIONS.

This system also requires
documentation (I couldn't find any).

Did you try the readme? I'm not really sure if you are talking about code or gameplay systems, but I did make that lovely HTML ReadMe.

Immersive graphics and sound. Some magic animations are better than others, but they are all adequate.


Our artist didn't have time to do all the effects graphics ;_; Also, many of the effects were programmed minutes before the deadline (you can look at lightning bolt as an example). Hopefully, all the effects will recieve balancing and graphical enhancements in the next version (did I mention that in the ReadMe?)

I counted no
fewer than 20 spells available with the right combination of elements, and they all had amusing results....Some of the spells seem like rough
duplicates and it's not immediately clear when one is preferable to the other, but they are all straightforward
and fun to use.


There should be over 30 spells, if I remember correctly. Many thanks to Toen for helping me come up with all the effects. Needless to say, MP is something I am pestering RageCage about. Right now, there is really no balance present in the system, which is really bothering me. Some spells will definately need to be reworked completely, because there is really no way to balance their effects. Glad you had fun messing around with them all, it was great to play the final build and see all those effects we had designed actually work!

I would like to see more complicated enemy behavior, and more diverse challenges.

The AI is something that really bugged me for quite a while before the deadline, but for some reason or another, Rage felt that it was OK. After everyone has been commenting on how sucky it is for weeks, I think he trying to fix it. However, it's hard to get decent AI on a realtime game like this. We have discussed potential solutions, however. "more diverse challenges" are something you should look forward to in the next HoV. Expect environmental puzzles ala Golden Sun (thanks to Grue for the idea, although its so logical I'm sure it would have been brought at some point regardless), and more diverse enemy types. Also, a much, much larger map.

Many thanks for all your comments Hahn, and for the judgement that got us first place. Also, many thanks to Grue for your judgement and for finally posting the results. I will refrain from replying to you, because I am sure you've heard enough from me. Many congratulations to all the contestants, especially Buckerman. That system really brought back memories of an old favorite of mine, The Magic Candle (1989, Mindcraft). That's such a classic battle system, I'm really glad someone decided to port it to VERGE. Also, as I mentioned before, it was lovely to enact battles with VERGE developers and my best friend. I eagerly await the next compo!