May 17 2012: ForceOrder and LastOrder
Mkay, I thought it was just that LastOrder's number of orders to hold was set too low, but really, the problem is that orders are deleted entirely when they're no longer stored for a unit by the system. So, I tried simply producing a clone of orders every time I had to reissue an order from ForceOrder, thereby making sure my orders didn't fall out of the stack. This, however, introduces the seemingly unsolvable problem that I now cannot be sure that an order enforced from some context will remain in existence and won't be replaced by a new one when it is enforced, and I have no practical means of finding a pointer to the new order object from that context. Thus, the only reasonable thing to do seems to be introducing a function to LastOrder which puts an order back on the top of the stack of orders to save. Unfortunately, this means I'll have to modify Rising_Dusk's library.
May 17 2012: Minor update for LinkedHashMap
Added getR to OrderedLinkedHashMap.
May 16 2012: ForceOrder troubles and progress
A war story for all my fellow coders out there...
For a long while, I've been battling bugs with ForceOrder. First, I thought there was something fundamentally wrong with my mechanisms, and the same order object was stored for several issued orders. Then I learned that the core mechanics seemed to work, but that a unit having received a forced order for every other regular order it was issued would bypass its forced order. I tried on several occasions over the past weeks to find the cause of the root. I looked through most of my own code in extreme details, I browsed LastOrder and studied some parts of it line by line, I added test methods to print out miscellaneous data potentially relevant to the bug, and I added debug messages everywhere, but I simply could not find any error that could've caused the bug. Ultimately I found in LastOrder, that, in the action function for the event launched on order issuing, new order objects were created but not stored. I looked into the constructor for the order struct again and realized that it is responsible for updating stored orders. Part of this maintenance concerned the deletion of old orders that were pushed out of the queue... And so I found the source of my frustrations: A little integer constant called ORDERS_TO_HOLD. This value determines how many orders LastOrders stores at a time, and the default value is only 3. Incrementing the value, I noticed the amount of orders before a bypassing of a forced order increased as well. Now I have defined the value to be 8191, and the bug has vanished. Supposedly it's technically still there, only marginalized to the degree that it is utterly insignificant, but now ForceOrder actually seems to be working exactly as intended in practice.
And that's how, after all this tedious debugging, I seem to have finally managed to make ForceOrder work. I'll do some more testing and work on my upcoming Fear library (as promised a while back), and then, hopefully, both systems should be published soon.
April 12 2012: ForceOrder
I seem to be getting close to a testable version of ForceOrder, a vJass library enforcing orders on units based on specifiable order priorities. I'll post here once it has been confirmed to be functional and published.
April 10 2012: The original Heroes revisited
Consider this a note to myself as much as a note to everybody!
After watching The Hunger Games I believe I have in idea of how to feasibly accomplish the originally intended gameplay of Heroes: rather than have the players ultimately follow a single quest-line, pit them in a scenario oriented around the players having to survive and be the last man standing. To accellerate the game, add different quests the completion of each wins the completing player the match. Or, perhaps, each quest ultimately unlocks a final challenge, perhaps to all players in a way offering each an advantage based on how far through the quests he has made it so that no still-alive player gets left behind, and everybody who is not already dead will still have a feasible chance of winning the game when the final showdown commences. Add to that a mechanism allowing the dead to make life hard for their killers, and I believe we may be looking at quite an interesting construct.
April 2 2012: Game design at the ITU
After achieving my Bachelor of Computer Science I will apply for admission to the IT University of Copenhagen as a postgraduate student in game design leading to a degree of Master of Science in Information Technology.
Semi-irrelevant fact: I just submitted my application last Friday, thereby finally rendering the above quote from my about page obsolete!
March 1 2012: Swift update for LinkedHashMap
Default secondary ordering has been changed to oldest-to-newest, and a new static method has been introduced to produce maps with a secondary order from newest-to-oldest.
The newest version can be found under Projects.
February 29 2012: LinkedHashMap, Vectors, and VUnit updated (again)
-
LinkedHashMap has reached version 3.0 with a major update
- Miscellaneous changes to architecture
- Ordered linked hash map struct introduced
- Debug mode corrected
- Vectors has reached version 5.2 and has had its debug mode corrected
- VUnit has reached version 2.1 with an extremely minor update
The newest versions can be found under Projects.
January 17 2012: LinkedHashMap, Vectors, and VUnit updated
As usual, the newest versions can be found under Projects.
January 16 2012: Back to mapping
I just passed my last exam for this period so I should be able to get back to mapping soon.
December 1 2011: What's next?
Happy 1st of December!
Although all scheduled work on LinkedHashMap has been completed, updates for Vectors and VUnit remain pending. I'll report back once I have the time to look into them.
November 14 2011: Learning from one's mistakes
From this point on, I will strive to post my vJass libraries for review elsewhere before publishing them here. Hopefully, then, noone will be unfortunate enough to build their projects around a defective creation of mine.
November 14 2011: IterableHashMap is now LinkedHashMap
IterableHashMap has been renamed to LinkedHashMap and is now out in version 2.0. As usual, it can be found under Projects.
November 13 2011: IterableHashMap
My iterable hash map library, creatively dubbed IterableHashMap, has been released and can be found under Projects.
November 6 2011: Busy!
I am it. However, when I become less so, I shall look into finishing the goddamn fear system. The skeleton is there, and my hashtable library seems to be working as intended so it shouldn't pose too much of a workload once I get to look at it.
October 31 2011: VUnit 1.1 and Vectors 4.0
VUnit has been updated to version 1.1 and now supports suite initializers and terminators.
Vectors has been updated to version 4.0 which features two major improvements.
First, the last non-static methods returning vector struct instances have been changed into mutators as was done for other such methods in version 3.0.
Second, several bugs have been fixed.
The new versions of both libraries as well as corresponding VUnit test suites can be found under Projects.
October 29 2011: Oh, I almost forgot...
Well, frankly, I did forget - otherwise I would've put this in the last post, obviously.
Until I started working on and with VUnit, I began writing a hash table library like I previously mentioned I would.
I've managed to come up with a pretty clever solution, I think, and it seems promising in terms of utility and efficiency alike.
The first version is pretty much ready for testing which was just another reason for me to commence development of a unit testing framework - and the reason I'll get back to hash tables immediately after finishing writing Vectors 3.1.
October 29 2011: Distractions
As proclaimed, I looked into Zinc, but I found it didn't really solve any of the major problems I have with vJass. Consequently, I'll make do with the latter, and honestly, with a little extra effort, it should suffice despite its unattractiveness.
In other news, after publishing a highly flawed version 3.0 of Vectors (sorry, guys!), I decided I needed some good old-fashioned unit testing to help me out. To me, being a computer science student and all, of course this meant writing a suitable framework - oh, boy.
The good news is I focused on doing just that, and now it's done! Presenting: VUnit, a vJass JUnit clone (sort of, anyway).
You'll notice that I already produced a VUnit test file for VUnit itself, that is, a vJass script file containing VUnit unit tests testing, well, VUnit. Obviously, such tests cannot be trusted entirely, but they serve as a decent immediate indication of the framework's working as intended - as well as its practical applications.
Currently, I am working on version 3.1 of Vectors in a TDD-like fashion while introducing tests for the faulty 3.0 code, that is, I'm sorting out my mistakes through systematic testing in order to generate a VUnit test script and a new version of Vectors addressing those mistakes simultaneously.
I'll write back once Vectors 3.1 has been completed and thoroughly tested. In the mean time, do youselves a favor and stick with Vectors 2.3!
September 26 2011: Zinc...?
I was recently pointed towards the Zinc language for World Editor, and I must say, so far I find it very appealing relative to vJass. I'll probably spend some time looking into it and then consider a change of language.
September 21 2011: Teaching Java, coding vJass
Wherefore art thou vJass (and not Java)!?
Honestly, vJass is an amazing language for a level design scripting tool, especially considering it being fan-made, but having to get by without generics, extending interfaces, javac, and - apparently - anonymous classes as well as the protected access control modifier is a pain in my academic idealist ass. To make matters worse, I currently teach a programming class, and I begin to realize that the freshmen I'm yelling at can do more advanced stuff with their Java code formulated in friggin BlueJ after four or five weeks of university than I can with my vJass code after eight years of scripting and two years working on a bachelor in computer science. Make no mistake, Vexorian, I'm a huge fan, but I'm really starting to look forward to implementing answers to rookie questions in my classes...
(In case any students at Aarhus University currently attending dIntProg are reading this, please note that vJass is, in my opinion, still one of the best scripting languages for video game editors out there. Also, for the record, the course seems to progress exceptionally well this year (yes, you're awesome).)
Rant over!
September 19 2011: So many libraries...
Admittedly, I am often more perfectionist than I want to be. As I grow tired of tedious repetition and unintelligible API's while coding, I find myself wanting to substitute new libraries, maybe even to an extent where most of my map-specific code is based on underlying systems I've formulated myself. Consequently, I am, again, working on miscellaneous libraries that will hopefully simplify the fear system as well as future systems. I will try to make my creations available here as they become worth sharing.
Libraries currently planned or under development:
- Improved hash tables
- Support for forced orders
- Fear system
- Taunt system
August 22 2011: Vectors
While attempting to develop a proper fear system for KTS I decided I would need a basic vector class. Being a computer science student, my first response was, obviously, to start putting together the most extensive vJass vector library ever devised. This library, which did actually grow quite comprehensive, was named Vectors and is currently in version 2.3. It provides the classes Vector2D and Vector3D and covers a wide range of functionality from basic operations to advanced calculations.
July 7 2011: KTS: The Krain
The Krain is a melee/tank class. Krains are mystic, magic-wielding warriors empowering their bodies with the force of magic and exercising martial arts perfected by the touch of sorcery. Krains tend to appear quickly, deal supernatural amounts of damage with their very fists glowing with the might of magic, and then retreating from the frontlines to meditate and recover their spiritual force.
July 7 2011: KTS: The Ravager
The Ravager is a tank/melee class. Ravagers are warriors of a war cult focused on alternative spiritual combat disciplines. Specifically, Ravagers are trained to focus on their inner fury, letting them endure vast amounts of pain and unleash unfathomable strength in combat. A Ravager is taught to respect only the glory of victory and feels no remorse toward the death of his foes as he lays waste to them in a trance of channeled bloodlust.
Abilities
- Bloodlust: Passive. Regenerate mana proportional to damage done on normal attacks. Furthermore, the Ravager's defense is improved by an amount proportional to his current mana.
- Warcry: Instant. Sends nearby enemies running in fear.
- Backlash: Charged, uninterruptable. Lets the Ravager lay down his weapons for a couple of seconds, accumulating rage as his foes engage despite his lack of resistance. In a scream of rage, the Ravager lashes back at every foe whose attacks have hit him during the period of passiveness, dealing normal damage plus the sum of damage taken from incoming attacks by that foe and slowing them for a brief duration.
- Focus: Passive, cooldown. Lets the Ravager retain focus on the battle, refusing to die when slain. Whenever the Ravager falls while the ability is not on cooldown, he will rise again after a short period of restoration to engage his foes once again.
- Trance: Instant. Sends the Raveger into a trance of fury, increasing his movement speed, attack rate, and damage by amounts proportionate to his current mana. While in this state, the Ravager loses mana continuously, and the trance ends when his reserve is depleted entirely. Furthermore, Bloodlust causes the Ravager to regenerate health rather than mana while Trance is active.
July 7 2011: Technicalities of KTS
As a result of the relatively complex systems necessitated by the map's mechanics, I have decided to switch from "GUI" to vJass. I have been working with WorldEditor for years, and continuously I have decided that learning JASS was not worth the effort. Now, however, it would seem I hardly have a choice, and as I am writing a few libraries I must say that postponing the transition to vJass may very well have been a rather poor decision. Admittedly, typing is considerably more efficient, and comfortable, than dragging, dropping, and clicking.
I expect to rewrite the entirety of the map's scripts to vJass which should be somewhat time-consuming. Consequently, I do not expect to introduce any new elements to the map in the immediate future. Just how long this "immediate future" will last is, however, unclear to me, but hopefully I can resume progressive work on the project in a matter of weeks.
An update on the conceptual development should follow shortly.
June 27 2011: Details on KTS
As promised, the following is a brief summary of Krainert's Team Survival:
- The map supports between 2 and 10 players split into 2 teams
- When the game starts, each player must pick one out of 6 available hero classes
- Each team has a separate map area in which their gameplay will unfold
- Players must summon mobs from their respective summoner structures to fight within the enemy team's area while defending their own area against the mobs of the enemy
- Each area contains mob spawn zones in which summoned mobs will appear and a destination zone towards which mobs will fight
-
The map operates with 3 primary resources:
- Capital (Gold): general resource; gained through income
- Requisition (Lumber): required to summon mobs; gained through income
- Supply (Food): consumed by mobs; provided by summoning and support structures
-
Furthermore, the map encompasses 2 secondary resources:
- Authority (summoning structure mana): required to upgrade current summoning structure; gained from summoning mobs
- Influence (spellcaster structure mana): required to cast global spells; gained from slaying mobs
- A player's current summoner structure can be upgraded, and for every second upgrade the player is presented with a choice determining the available mobs after the upgrade and further upgrade options
- Each type of summoner structure makes available a number of mob types of different character and tactical role, from basic melee and ranged to flying and support or even elite units
June 24 2011: Krainert's Team Survival
Dramatic change in direction: I have suspended the original competitive RPG concept indefinitely as a result of my failing faith in the quality of a map with such gameplay. Instead, I have resumed work on a previous team hero defense map for which I will use several of the concepts for Heroes. The working title for this new production is Krainert's Team Survival (KTS) as a kudos to Enfo's Team Survival by which the basic gameplay is inspired. The development of the map has gained considerable momentum, and I expect to release more details soon.
May 23 2011
I am currently rethinking the general theme of Heroes and considering whether to go with a much more grim initial scenario then I have previously imagined. Coming up with a decent setup is quite a challenge, though; for the players to be able to complete tasks without an army to back them up, the opposing force must be the dominant one, and so if the player represents the hand of good, the world must necessarily be ruled by evil.
Hence, my previous plot concept concerning an invading force excavating for a recently discovered artefact rumoured to be highly powerful cannot function since it would imply that the players would have the entire force of good on their side, ready to aid them in their struggles - thereby eliminating any chance of the player having to explore the land and complete quests on his own or with his fellow heroes.
Consequently, I am now trying to construct a world in which evil has already prevailed, at least momentarily, and the forces of good, all but extinct, roam as underdogs in the dark realm. The player must then persevere and aid the opposition, ultimately leading a large-scale uprising against the tyrant masters and pressing on beyond the frontlines into the heart of the enemy to apprehend the final big bad boss.
May 8 2011
After some experimentation with the current map layout I have decided to rethink it and move towards a less symmetric island. My primary motivation is the tendency towards a monotone feel for symmetric maps and a desire to let the specific regions shape the overall map layout rather than vice versa as I believe doing so will let me create a more geographically natural looking scenario.
I will post again once I have decided on a map layout and begun terraining.
April 18 2011
Although work on Heroes has been slow lately, the map is still under constant development.
Have a look at the revised and possibly final world layout:
In other news, I am working on a turn-based strategy game with a friend from uni.
More details will follow once the project gains speed.
February 16 2011
I have finally finished the first scetch for a possible terrain layout for the Warcraft III: The Frozen Throne RPG map, now dubbed Heroes: terrain map.
January 27 2011
I am currently working on a semi-experimental Warcraft III: The Frozen Throne multiplayer map combining a simplified RPG basis with player-formed alliances and inherently competitive gameplay. The exact nature of the project is still uncertain.