Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Work in Progress / Cyber Wars: Infestation

Author
Message
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 27th Nov 2007 10:04 Edited at: 27th Nov 2007 10:14
Link
Title:

Cyber Wars: Infestation

Brief description:

Cyber Wars is an RTS game played on a simulated circuit board, where you play as an Anti-Virus team attempting to destroy the Virus team.

Story:

In the age of computers, no system is safe from virus attacks. They are feared across the globe, destroying every system in their path. They are copied to new systems, forever spreading. They must be stopped. At some point a local group of engineers developed the ultimate virus combatting program. It was a sentient AI sent out across the world, programmed to spread just as a virus does. Learning of this new form of virus protection, hardware corporations everywhere began developing newer routers and altering older ones to allow this specific program access to everything. Once the router detected the program's entry, it would then send it in all known directions, to hasten it's spread.

Upon reaching a system, the sentient program would wait, uneffecting it's host, until a virus would come aboard. Once that happened, the program would initiate and begin to "infest" the system as quickly as possible, driving out the virus threat.

This approach to virus protection was good. TOO good, as some might put it. It wasn't long before an underground group of hackers found this sentient program on their system and captured it. They altered it's logic to function AS a virus, and sent it on it's way. Since the program's signature ID was not altered, routers across the world unknowingly allowed this new threat to spread just as quickly as it's counter-part.

Now... the Infestation has begun. Anti-Virus and Virus of equal capabilities are pitted against each other on every system, battling each other for what could be an eternity.


How the game works:

You play as the Anti-Virus sentient program, spreading from system to system, in a seemingly endless battle against the Virus.

When you are placed into a new system, your virtual CPU is implanted. This is your main base of operations, controlling everything that you have corrupted in the system. It is able to compile new programs to help you eliminate the Virus. It can also Download upgrades for these programs, allowing you to compile "better" versions.

Programs are the only things that can wander around the system, they are your "units", if you will.

Components (as they are referred to in the game) are simply virtual versions of circuit components. Each of them have a different purpose and each will benefit you in different ways for corrupting them.

In order to compile a program, you must have corrupted enough memoryspace to store them.

In order to construct a new component, you need to have enough system "wattage" to power it.

Programs:

- Decompilers: These are the fighter programs. They are designed to eliminate other programs by decompiling them.
- Constructors: These programs are programmed soully for the purpose of corrupting virtual "components" as well as constructing new ones.

When a program is within an area of the system that is not being corrupted by the same influence as the program (i.e. Anti-Virus program within Virus territory) it will slowly become corrupted towards the influence in which it's located. So, if an Anti-Virus program wanders into a non-corrupted system area, it will slowly become part of the system and no longer be under your control. If a program is within an area of the OPPOSITE influence, like a Virus inside Anti-Virus territory, it will be corrupted twice as fast.

Components:

- CPU: This is your main base of operation and is one of a kind. It is able to compile and download programs onto the system.
Voltage Supplied: 10 V
Current Supplied: 10 A
Memory Available: 256 MB

- Memory Chip: Corrupting a system memory chip will allow your CPU to compile or download programs into it's available memoryspace.
Memory Available: 64 - 512 MB (Varies between memory chips)

- Capacitor: Corrupting a system capacitor will provide a certain amount of voltage to be under your control.
Voltage Supplied: 1 - 5 V (Varies between capacitors)

- Inductor: Corrupting a system inductor will provide a certain amount of current to be under your control.
Current Supplied: 1 - 5 A (Varies between inductors)

- LED: Can be corrupted or constructed. LEDs will corrupt an area of the system around them to be under your influence.
Radius of Corruption: 3 - 10 Blocks (Varies between LEDs)

- OLED: Can be corrupted or constructed. OLEDs will corrupt an area of the system around them to be under your influence.
Radius of Corruption: 3 - 10 Blocks (Varies between OLEDs)
Special: Corrupts programs within area of influence twice as fast.

- MPU: Can be corrupted or constructed. An MPU (Mini Processing Unit) acts just like your CPU, but it won't be able to handle as many processes at once, and won't be able to compile as fast, either.
Memory Available: 32 MB

- Resistor: Can be constructed. This will act as a wall, and doesn't use up very much Wattage.

- Transistor: Can be constructed or corrupted. This acts like a gate. It will allow programs of the same influence as it to pass through, but block other programs.


I'm planning on adding more program types as well as more components.

Each program can be upgraded via a download, however the upgraded versions will consume more memory to be compiled and the upgrade itself also uses up memory. But, that's the price you pay for better programs, right?


I will be posting up some screenshots here shortly.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!

Attachments

Login to view attachments
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 27th Nov 2007 10:06
Link


This is showing a compiled Decompiler and a Compiling Constructor.

The large block is the Anti-Virus CPU, and the cube is the Decompiler and the ghosted Sphere is the Constructor that is being compiled by the CPU.

ALL MODELS ARE STAND-INS!!!

I lack the artistic ability to create models and textures. So please, do not comment on my crappy looking models, lol.

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!

Attachments

Login to view attachments
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 27th Nov 2007 10:09
Link


This one is showing the CPU interface window. (Also a stand-in) In there you can view details about your influence in the system, such as how much available memory you are in control of, how much system voltage and current you are in control of, as well as how many processes your CPU is running and the total "Wattage" you have and are using.

In the pic, all three programs are being compiled, so the CPU window shows you that it's running 3 out of 4 processes.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!

Attachments

Login to view attachments
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 27th Nov 2007 10:11
Link


Here, we can see the Virus CPU on the system. As of right now he doesn't do anything, but I ran a little Decompiler over to his side and let it become corrupted, so now it's under virus control.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Butter fingers
18
Years of Service
User Offline
Joined: 20th Mar 2006
Location: Mecca
Posted: 27th Nov 2007 12:22
Link
Quote: "ALL MODELS ARE STAND-INS!!!

I lack the artistic ability to create models and textures. So please, do not comment on my crappy looking models, lol."

hmm, well, as most of the backdrop if black, and the only detail on the models are the circuits, a bloom shader would probably make this look very stylised. Because then all your circuits would glow...

I like the idea BTW, it's been done before I think, but I've never seen it as an RTS.Looking forward to seeing where you go with this!

Back to top
Profile PM Email Website
Raven
19
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 27th Nov 2007 14:52
Link
This sounds and looks a bit like that game Bolt made, forget the name though.
Still looks interesting

Back to top
Profile PM Email Website
Crazy Ninja
19
Years of Service
User Offline
Joined: 27th Aug 2005
Location: Awesometon
Posted: 27th Nov 2007 15:14
Link
Quote: "This sounds and looks a bit like that game Bolt made, forget the name though."


Firewall! Hopefully yours will be a bit different though. It looks neat, seems like you've got some good stuff planned out already.

Back to top
Profile PM
Mr Z
16
Years of Service
User Offline
Joined: 27th Oct 2007
Location:
Posted: 27th Nov 2007 17:05 Edited at: 27th Nov 2007 17:26
Link
Love the graphics of this game. It´s very nice. Even though I don´t know much about shaders and stuff, listen to Butter fingers. An glowing affect would be really awsome! And by the way, keep your models .

EDIT:

An small idea for an program to add:


Interpretors:

They can imitate other programs, but wont be as good as the program they imitate (if they imitate an decompiler, they can fight, but won´t be as good as the decompilers).

Darknes, you haunt me. If I give in, I would be an monster beyond imagining. Light, you guide me. Thanks to you, I see past the nothingness. Life, I choose to live in the light.
Back to top
Profile PM Email
MonoCoder
18
Years of Service
User Offline
Joined: 4th Dec 2005
Location: england
Posted: 27th Nov 2007 18:06
Link
Looks nice.

However, the texture on the circuits could do to be extended and/or scaled up a bit, as the repeating doesn't look that great.

EBA; FUI; Mario Land Ripoff.
Every time you post a joke in the form of code, mace yourself.
Back to top
Profile PM Email
Inspire
17
Years of Service
User Offline
Joined: 23rd Dec 2006
Location: Rochester, NY
Posted: 27th Nov 2007 22:29
Link
Nice idea! Hope that is is executed well. And I agree with Butters, through a bloom shader in there.

Back to top
Profile PM Email Website
flashing snall
18
Years of Service
User Offline
Joined: 8th Oct 2005
Location: Boston
Posted: 28th Nov 2007 00:27
Link
looking good. a bloom shader would be cool. If you scrolled the ground texture, it might give an interesting effect with the bloom. Also, a tech sort of skybox would be really cool!


"these shoes are 300 hundred dollars"-Shoes by Kelly http://smallgroupproductions.com/
Back to top
Profile PM Email Website
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 28th Nov 2007 00:32
Link
Lol, somehow I expected people to remember this idea.

I attempted this project many years ago, before Firewall came out. I lost the entire project in a HDD crash and I'm just now getting my idea back on track. Don't get me wrong, Firewall was a great strategy game, but I believe my idea for this is going to be in a different direction and not just because it'll be an RTS.

@Butters:

A bloom effect would indeed be nice for the circuits. I have never really gotten my hands dirty with such graphical implementations, perhaps someone has written a tutorial on the matter that I could rummage into?

@Mr Z:

The idea of an Interpretor program has come across my mind, but I'm still trying to think of a practical application for it. I don't believe an "imitation" ability would be very useful for the player on a number of levels. I had intially had an idea that an Interpretor could be used like a "scanning" program, where it would be able to view the details of a component or program within it's scanning range. This would allow the player to see which capacitors had higher levels of Voltage capacity and let them make better judgments as to which ones to corrupt first.

It's still in the idea department, but I'm hoping it'll go somewhere.

@Monocoder:

Yes, the circuit is very repetative, and it will eventually be recreated. I did want some kind of circuit texture that was large enough to be seen and distinguished from far away (like when you're completely zoomed out). The image is already 256x256 and is part of a much larger tiled image (2048x2048).


@Everyone:

I'm currently working on the gameplay aspects, as opposed to graphical aspects. The engine is being programmed as dynamically as possible to allow easier implementation of better graphics later on, though. This means that once I have models with animations and their OWN textures, it wouldn't take more than a few minutes to implement the new models. Special effects also have their own subroutine and functions so they won't take very long to put in either.

I'd really like to get all the functionality out of the way before going heavily into graphics. One reason for this is, I want to have a nice idea of how much processing time would be allowed for the soul purpose of having good graphics (Poly count of models, intensity of special effects, etc).

I'm glad to hear that people share an interest in my project, and I appreciate the nice words of encouragement. Thanks, guys!


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 30th Nov 2007 09:18 Edited at: 30th Nov 2007 09:20
Link
This picture shows most of the components. It's set up sorta like a stronghold, since the resistors act like walls and the transistor up front is being protected by the OLED just outside.

It was done in the level editor which can now correctly write a level file to be read by the game's engine.



Oh right, a list of what's what in the pic:

Resistors: The horizontal cylinders encompassing most of the other components.

Transistor: The huge cone up front.

Memory Chips: The flat rectangles behind the CPU... gotta keep those safe, because if they get corrupted by a virus, then EVERY PROGRAM STORED ON THEM WILL BE CORRUPTED, TOO!!! And, yeah... that's a bad thing, lol.

OLED: The large flat circle thing out in front of the Transistor. It's there so incoming viruses won't have an easy time getting through the gate.

Capacitor: The large upright cylinder outside the right corner of the "fortress".

Inductor: The large upright box outside the left corner of the "fortress".


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!

Attachments

Login to view attachments
Back to top
Profile PM Email
Bizar Guy
19
Years of Service
User Offline
Joined: 20th Apr 2005
Location: Bostonland
Posted: 30th Nov 2007 15:49
Link
Looking at this, I'd say it's considerabley different than Firewall. I like the memory chip idea a lot. That's a really good idea.


Superman wears Chuck Norris PJ's
Back to top
Profile PM Email Website
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 1st Dec 2007 00:21
Link
Thanks, Bizar Guy.

You wouldn't happen to have any constructive feedback along the lines of what ideas have been thrown out so far, would you?


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Zeus
18
Years of Service
User Offline
Joined: 8th Jul 2006
Location: Atop Mount Olympus
Posted: 1st Dec 2007 00:25
Link
Man this looks awesome, can't wait to see more.

Back to top
Profile PM Email
Bozzy
18
Years of Service
User Offline
Joined: 10th Sep 2006
Location: Birmingham, UK
Posted: 1st Dec 2007 02:15
Link
Hmmm, just a random idea... Allow the player to piece together a program for the program thingys (in a visual editor obviously) and make them pay for each component in the program... THen they can customise features and stuff

"I'm a firm believer that if a team scores one goal, then the other has to score two to win."
Back to top
Profile PM Email Website
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 1st Dec 2007 11:27
Link
Interesting thought there, Bozzy...

Hmmmm...

Well, considering it's an RTS (REAL Time Strategy) Game... then while the player was piecing together a program, couldn't the virus troops just march right up to the Anti-Virus CPU and take it out without the player being aware of it? And if the player did see it happening, then he'd be forced to abandon his work on the program to close the window and fight off the threat.

I dunno, it may be a workable concept given a little bit more thought. I'll look into it. Thank you for the suggestion.

(BTW, that does sound an awful lot like how you could "program" MegaMan in one of the Battle Network games, doesn't it? )


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 1st Dec 2007 13:16
Link
[UPDATE]

I now have Collision working in my game... although I think that was a fruitless endeavor and may be removed because I am NOW working on an intelligent pathfinding system when you want to move your units around.

That will make it so when you want to move a unit to a spot that is blocked off by structures, it'll move around it in the shortest path possible.

This is quite an endeavor for me and I think once it's working I will have not only learned a lot but I'll get a nice boost of confidence to boot.

With path finding in here, you won't need to lead your programs around corners manually (like it currently is), and save you some time to do other things while their wandering across the map in the best possible route.

ALSO!!! I'm thinking that in order to actually USE the pathfinding, I might make it so the player will have to "download" the algorithm before the units will actually use it. What do you guys think? I think it'll give the player yet another little something to work towards to make his gameplaying not only more efficient but more fun, too.


Once this pathfinding system is in place, I will begin yet ANOTHER milestone, and start working on the Virus AI... so you can actually play against something.

[/UPDATE]


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Mr Z
16
Years of Service
User Offline
Joined: 27th Oct 2007
Location:
Posted: 1st Dec 2007 13:41
Link
About that peice toughether idea: There are commercial games that use that concept. I´ve played a few myself. Lets see. Here is an list over them:

Impossible Creatures.
Earth 2150.
Earth 2160.
Warzone 2150 (or something like that).
At last one part of the Space Empires series.
Alpha Century (I think... was some time ago I played it).

You can take a look at these games, if you´d like. They could help with inspiration.


And by the way, you could expand this concept further, and how to create an multiplayer mode. I got an idea of how, and if you like, I could tell you.

Darknes, you haunt me. If I give in, I would be an monster beyond imagining. Light, you guide me. Thanks to you, I see past the nothingness. Life, I choose to live in the light.
Back to top
Profile PM Email
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 1st Dec 2007 13:51
Link
I like the idea of using resistors as walls the most. And do you get any units or is it just buildings/Components?

Back to top
Profile PM Email Website
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 1st Dec 2007 20:16
Link
Perhaps after Single Player is complete, I'll take you up on that offer Mr Z.

@kaedroho:

Thanks! Yeah, I thought the analogy would be appreciated by a few people. And yes, the "units" in this game are the programs, which are free to roam around the field. More about them is listed in the first post.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Jimpo
19
Years of Service
User Offline
Joined: 9th Apr 2005
Location:
Posted: 2nd Dec 2007 03:55
Link
Quote: "I think it'll give the player yet another little something to work towards to make his gameplaying not only more efficient but more fun"


The player shouldn't have to work to make the game fun. It would be best if pathfinding was there from the start.

Shooter - Game Finished
Back to top
Profile PM Email Website
tha_rami
18
Years of Service
User Offline
Joined: 25th Mar 2006
Location: Netherlands
Posted: 2nd Dec 2007 04:15
Link
Why can't a game without pathfinding be fun? I mean, working in itself can be fun when executed correctly.


A mod has been erased by your signature because it was larger than 600x120
Back to top
Profile PM Email Website
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 3rd Dec 2007 05:39
Link
I'm sure there are some people who would rather have it one way, but consider this:

Even your opponent (who is a computer) will need to take time to move their units individually AND around corners if you were to start without pathfinding. I would implement that, if I went that route.

However, if pathfinding were to be there from the start, I probably wouldn't put in as many Memorychips into the levels knowing that you wouldn't need the extra download space. lol


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Jimpo
19
Years of Service
User Offline
Joined: 9th Apr 2005
Location:
Posted: 3rd Dec 2007 22:34
Link
I was just giving an opinion. I'd still want to play Cyber Wars, either way.

Shooter - Game Finished
Back to top
Profile PM Email Website
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 4th Dec 2007 16:19
Link
[UPDATE]

Path Finding is now working!

I haven't done any pressure testing on it, like... sending a program to the other corner of the map, past tons of components, and winding paths. So it may or may not need to be further optimised.

I'm currently working on some collision issues that occur between programs... wherein, some programs will push others aside (the way it should work), while others simply pass through the programs they collide with.

Once that's cleared up, and the pressure testing of the pathfinding is complete, I'll begin work on a functioning AI to play against. (God, I'm so excited! )

[/UPDATE]


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 5th Dec 2007 11:41 Edited at: 5th Dec 2007 11:41
Link
Okay, since the collision bug wasn't going so well, I decided to take a little bit of time to pressure test my pathfinding algorithm.

I set up a maze-like system of resistors with an LED at the end, for a "goal". The program started at Point A in the picture, and was told to get to Point B.



You can't see it very well in the picture, but I had my algorithm clock how long it took to figure out the absolute best path to the goal. It came back as 4416 milliseconds... roughly 4.5 seconds to figure out it's way through the maze. Now, obviously that was a very stressful test and more than likely isn't very realistic for a level. But, being the perfectionist that I am, I don't like the results. In fact, I hate them. It's horrendous for a game to take that long to find a path to ANYWHERE! (IMO)

So, I'm considering taking the time to sit down and figure out even more optimising techniques I could do to make it go faster. 10x faster at LEAST.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!

Attachments

Login to view attachments
Back to top
Profile PM Email
Mr Z
16
Years of Service
User Offline
Joined: 27th Oct 2007
Location:
Posted: 5th Dec 2007 14:51
Link
Sounds like that pathfinding need some optimation. But you can do it .

Darknes, you haunt me. If I give in, I would be an monster beyond imagining. Light, you guide me. Thanks to you, I see past the nothingness. Life, I choose to live in the light.
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 6th Dec 2007 08:47 Edited at: 8th Dec 2007 15:21
Link
Official Path-Finding Optimising Update Post:

Okay, I'll be updating this post for now, to track updates on the optimizations done for the Path-Finding.

Optimization #1 Results:

What I did:
Slightly changing sorting algorithm of current paths being expanded.

PRO:
Path was found in under half a second! Took 0.384 seconds to be precise. This was an astounding result for something that I came across on accident and didn't expect the path to be found so quickly (if at all)...

CON:
It doesn't necessarily find the BEST or SHORTEST path. There were a few times where the program took an unusually wide turn around a corner, or even peaked off in another direction before going back to the correct path.


Optimization #2 Results:

What I did:
Completely redid the node system that I had going for me. This newer one is done in a hierarchical fashion, where each node will know which other nodes that it can get to from the get go. This will allow the path-finder to completely skip over checking every node for whether it can get to them or not.

PROS:
The absolute BEST path had been found.
It returned a path in slightly over a second. Around 1.2 seconds, actually. This is a step up from the last system that was used.

CONS:
There don't seem to be any Cons to speak about. One thing that annoyed me while making this was the structure of certain arrays were being built in the opposite direction as the new array that I introduced... there didn't seem to be any way around that, either, but I'll keep thinking of more ways to get it going faster.


Optimization #3 Results:

What I did:
- Went back and eliminated any "middle-man" areas of the algorithm that had resulted from the cross-over to the new node system.
- Completely eliminated any strings being carried through (that were for visual debugging purposes).
- Optimised the check for if the last node in a known path was able to reach the target coordinates or not.

PROS:
Everything... the algorithm now runs faster than ever before. It picked the best path almost every time. The only time it didn't was the very first time I told him to reach the goal. For some reason he thought he had a straight shot to it and started trying to barge through the walls. After that little shananigan, he always found the best path.

CONS:
During the maze test, the program displayed some unusual behavior when first told to find the best path. It went to two nearby nodes, then tried to run through a resistor.
The longest time the algorithm has taken to find a path to anywhere thus far is around 0.86 seconds. I still find this to be appauling, and will continue to try more optimizations....


Optimization #4 Results:

What I did:
There were many for loops in the algorithm. I happened to stumble upon a way that would allow the algorithm to escape out of these loops prematurely if it would not effect the outcome.

PROS:
The path through the maze can now be found in 96 milliseconds!!! Less than 1/10th of a second! Finding the way back to the beginning takes half that time! Also, the weird bug that caused the program to attempt to run through the walls is gone!

CONS:
There still seems to be a situation in my regular level where the algorithm will take a little longer to find the path. It's a very simple path, too, which is what's bothering me. Using the "fortress" setup in one of the pictures above, trying to find a path from the outside bottom-right area of the fortress (looks like a little cubby-hole) to the outside bottom-left area of the fortress, takes the algorithm roughly 360 milliseconds. That is not acceptable. I must find another way to optimize the algorithm that will allow it to run this path in around the same time as it does the maze. If I can get that, I'm fairly confident that the pathfinding will finally be complete.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 7th Dec 2007 13:06
Link
More optimizing techniques have been underway. I feel very optimistic about the new node system I implemented, and I'm eager to think about more ways to shorten the gap between clicking and getting results.

The program collision bug has yet to be fixed, though. I posted about it in the DBP Discussion board but it seems that no one can think of an answer to it (Or maybe the problem lies outside of the section of code that I've been looking at).
If anyone would like to try and help me out with this, here's the link to my problem post.

I really would feel good about the collision system if programs were to actually interact with each other correctly.

More updates to come.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 8th Dec 2007 13:06 Edited at: 8th Dec 2007 13:07
Link
Optimization of the path-finding algorithm has reached new heights!

After the most recent optimization, the program found his way through the maze in 232 milliseconds! That's barely over 1/5th of a second! What's even more amazing is he found his way back tot he starting point in HALF that time!



There were times, however, that the algorithm took longer... and what's unusual is that it was in a situation much simpler than this maze. I'm still trying to figure out why it took so long, and also more ways to optimise the current algorithm to get maximum results.

My goal for path-finding:

Make it so the player doesn't even know it's there. When they click, it moves. Immediately, and in the most efficient way.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!

Attachments

Login to view attachments
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 8th Dec 2007 13:08 Edited at: 8th Dec 2007 13:08
Link
[Deleted, whoops]

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Mr Z
16
Years of Service
User Offline
Joined: 27th Oct 2007
Location:
Posted: 8th Dec 2007 13:45
Link
Nice to hear you are doing progress with the path finding. Keep it up!

I´m looking forward to playing this game.

Darknes, you haunt me. If I give in, I would be an monster beyond imagining. Light, you guide me. Thanks to you, I see past the nothingness. Life, I choose to live in the light.
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 8th Dec 2007 15:13 Edited at: 8th Dec 2007 15:13
Link
The last two hours have been ever so fruitful with optimizations.

Some of you may be happy to hear that it appears as though I've wringed this sopping wet washcloth of an algorithm completely dry of all optimising techniques that I can think of.

Now, that can be a good or a bad thing. It all depends on how heavily this algorithm gets used during a real game.

I've updated the Optimization post above to include the lastest Optimizations done. I just happened to stumble upon it while spacing out and staring at a wall. For some reason the little bumps on the wall got me thinking in the right direction that lead me to it, lmao. As weird as that sounds, that's exactly what happened.

The algorithm can now find the absolute best path through the maze in under 1/10th of a second. 96 milliseconds to be precise, lol. And, just like before, it found the way back in half that time. 48 milliseconds, to the number.

Now, of course, that is not meeting my goal here. My goal would require it to find ANY path to ANYWHERE in 15 milliseconds or less. I use that figure because that's around the time that the human eye can't tell the difference if it's going faster or not, lol.




The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!

Attachments

Login to view attachments
Back to top
Profile PM Email
MonoCoder
18
Years of Service
User Offline
Joined: 4th Dec 2005
Location: england
Posted: 8th Dec 2007 15:38
Link
I've not followed what exactly is going on with your AI too closely here, so this is just a shot in the dark, but are you executing a whole pathfinding routine in one go? It might be a bit excessive to expect something to know the perfect route instantly, so perhaps try cutting it some slack: Let it take, say, 10 loops to get it's head around your maze. That's like 4.8 milliseconds a loop, no slowdown, and a more realistic pause for thought.

For your actual AI routine, though, I've nought to contribute. But your optimizations seem to be going well, so good luck.

EBA; FUI; Mario Land Ripoff.
Every time you post a joke in the form of code, mace yourself.
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 8th Dec 2007 17:01
Link
@Monocoder:

Yes, I was thinking that in order to make this at least SEEM instantaeous, I would put some calls INSIDE the algorithm that would keep all the timer based functions (and sync) consistently running.

This would make the pathfinding function actually execute slower, but to the player, everything will still be moving around and it will appear as though the pathfinding has already been completed, when it actuality it's still thinking!

Now, that would take some time to implement correctly, but once it's working, it will make it look ever so seemless. I just wanted to get the pathfinding as optimized as I could possibly get it to ensure that there would be absolutely no slow-down whatsoever.

I think that the algorithm is performing in tip-top shape as of right now, so in my next coding session, I'll be trying to get it to run in-sync with the timer operations and screen updating.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
tha_rami
18
Years of Service
User Offline
Joined: 25th Mar 2006
Location: Netherlands
Posted: 10th Dec 2007 11:36
Link
Well, it seems you're on the right track then! Congratulations .

I hope no unexpected errors pop up, and good luck. I'm interested to see what's 'next'.


A mod has been erased by your signature because it was larger than 600x120
Back to top
Profile PM Email Website
Bizar Guy
19
Years of Service
User Offline
Joined: 20th Apr 2005
Location: Bostonland
Posted: 10th Dec 2007 17:38
Link
Quote: "You wouldn't happen to have any constructive feedback along the lines of what ideas have been thrown out so far, would you?"


This isn't my genre of expertise, so not yet.

and you seem to be doing pretty well. I'll try and follow close enough to point out anything I can though.

I'm pretty impressed so far, but a lot of what you're doing is a little over my head. atm, I know next to nothing about ai, except for a large amount of paper concepts. I'll be sure to have a lot more to say once you've got a download.


Superman wears Chuck Norris PJ's
Back to top
Profile PM Email Website
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 11th Dec 2007 06:39
Link
Thanks, rami.

I hope no unexpected errors pop up either, lol. That tends to be a trend for me, but I always like to look at it as yet another challenge for me to learn from.

Everytime I hit "Compile and Run" I always think to myself "Okay, show me some errors, because I know there's gonna be some", lmao

@Bizar Guy:

Well, then I'll be hoping to hear from you soon after I get the AI and basic game concepts implemented.

And thanks again for the vote of confidence, I must say that I'm rather impressed with myself, too! I didn't expect to get this far so quickly, lol. There seem to be much less errors to get out of the way than I had initially anticipated.


Small update on the game. The "background path-finding" is implemented and working above my own expectations. Even though the return-time for getting a path has exponentially increased (To over half a second), at least the player can still do other things WHILE it's thinking.

Because of this large time interval for finding a path, I'm going to implement a "queue" for paths to be found. That is, when a program requests a path, it will be put into the queue and wait in line behind other programs waiting on a path to be found. I don't think this will be much of a problem, but I can't test it just yet because I can't tell programs to go find paths fast enough for them to get queue'd up, lol.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 12th Dec 2007 06:28 Edited at: 12th Dec 2007 06:29
Link
[UPDATE]

I've currently been working on implementing Virus AI into the game, and so far it's looking pretty good! Well, don't take my word for it, see for yourself!

I think the caption for this could be something like:

"The Red Circuits are coming! The Red Circuits are coming!" Lol



As you can see, the Virus AI can now compile and command programs. In less than a minute it unintelligently made it's way around the board infecting every component it came across.

There's still some work to be done, though. It had to make quite a few attempts at some of the components because it wouldn't stop to allow it's programs to fully come back to it's side. Lol
That is, when the Virus Constructors were corrupting a component, they would slowly start to become system programs, and the AI isn't yet aware of this. So it went through a lot of constructors that became system programs.

Eventually the AI controlled every component on the board except the AntiVirus CPU, but it couldn't even get NEAR the thing because the programs would get corrupted just outside the Anti-Virus boarder.

[/UPDATE]


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!

Attachments

Login to view attachments
Back to top
Profile PM Email
Bizar Guy
19
Years of Service
User Offline
Joined: 20th Apr 2005
Location: Bostonland
Posted: 12th Dec 2007 18:35
Link
Ha ha, cool. This has actually gotten me a bit excited about working on AI myself. Seems like a good challenge.


Superman wears Chuck Norris PJ's
Back to top
Profile PM Email Website
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 13th Dec 2007 03:30
Link
Yes, AI is a very good challenge, I like it a lot... sometimes I find myself having to lay down, close my eyes, and try to think "How would I react to that? And how can I put that into a math equation?"


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 14th Dec 2007 08:42
Link
[UPDATE]

I am adding a new program as well as a new structure!

Program Name: Driver

Description: Can "interface" with components, unleashing possible hidden component abilities or additional functions. However, Drivers are very weak programs and are easily corrupted/destroyed. Having at least a few Decompilers escort a Driver around is highly recommended.


Component Name: I/O Port

Description: Can be corrupted. Acts as an ordinary component. Just sits there. However, if a Driver program interfaces with it, it will allow the controlling player to utilise the port for downloading "Program Patches", "CPU BIOS Updates", etc. Basically, if you interface with it AND you control it, then you will be allowed to Download.


Yes, that means you can't just up and start downloading to your heart's content so long as you have available memory. You will need to locate, corrupt and interface with an I/O Port in order to download anything.

NOTE/CAUTION: Downloading will take a LOT of time if you're using a V1.0 Driver. Download Resume is NOT supported, so if the Port gets corrupted outside of your control during a download, you will need to restart that download after regaining control of the I/O Port.

Another "hidden function" I'm willing to reveal for a component is... if a Driver interfaces with a Resistor, the Driver will temporarily implement a Firewall Program into that resistor causing it to have not only increased structural integrity but also the ability to ATTACK nearby programs that are not of it's influence range. Once the Driver stops interfacing with the Resistor, it will lose the Firewall implementation and go back to being just a regular resistor.

[/UPDATE]


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 14th Dec 2007 08:55 Edited at: 14th Dec 2007 08:58
Link
Official AI Post:

I will be updating this post with any AI updates that I may have.

Update #1:

I am scrapping the current AI work I've done on the game, in favor of a "node" AI system. I'm hoping that with this system I won't have to program new AI routines for different difficulty settings.

The jist of this AI is that it will search for any available "moves" and store them all into a node list. It then calculates each move's "probability to help achieve the objective". (The goal in every match is to eliminate the opposing player's CPU, but that is still subject to change) It will then sort this node list starting at the top with "best possible move based upon current observations" and ending with "worst possible move, please don't even think about doing that".

To keep the AI from being too predictable and also too hard for players and to introduce a nice fun factor, the AI will not ALWAYS choose the move that is at the top of the list. It will have a range of moves near the middle that it will choose from. That'll keep it from choosing the "worst" move and also from choosing the "best" move. I put worst and best in quotes because the AI doesn't look past the first possible move, being that the score for each move can change at the drop of a dime (since this is a RTS, the player could at ANY moment, completely foil any moves the AI might make). It will simply keep the AI going in the game, and once the available moves start to diminish (meaning either he's about to die or he's about to win), he will start to lose nodes in this range to choose from and will start to pick nodes, or moves, outside of the designated range. What this means, is that once the game is starting to draw to a close he can either make a miraculous comeback/decimation or he will utterly fail by doing something stupid and most likely lose any ground he had.

Using this system I could simply shift the range of nodes that the AI chooses from to nearer to the top or nearer to the bottom (smarter or dumber respectively). That would provide sufficient difficulty ranges for the player to choose from. Of course, if the player chose "easiest", then upon backing the AI into a corner, it COULD mean that suddenly (when given such a low amount of choices to go off of) the AI would do something completely unexpected and fight it's way out and back into the game. (Meaning he randomly chose the best possible move in that tight situation)

--End Update #1--


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Code Ninja
20
Years of Service
User Offline
Joined: 17th Dec 2003
Location: AZ, U.S.
Posted: 14th Dec 2007 17:36
Link
Wow, this is really looking awesome. Almost like an Age of Empires: Tron Edition or something, lol. Anyway... yeah... Two thumbs up!

~Code Ninja
of Dragael Software
and Smith Comics
Back to top
Profile PM Email Website
Mr Z
16
Years of Service
User Offline
Joined: 27th Oct 2007
Location:
Posted: 14th Dec 2007 17:56
Link
Hey, this game is just becomeing better end better. I really like the idea of Drivers and I/O Ports and the way the AI would work. That node idea was just very nice.

Keep up the good work!

Darknes, you haunt me. If I give in, I would be an monster beyond imagining. Light, you guide me. Thanks to you, I see past the nothingness. Life, I choose to live in the light.
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 15th Dec 2007 00:16
Link
Heh, yeah, the node idea isn't very hard to implement at all... in fact, the pathfinding makes this look like Programming 101 all over again

The HARD part of this AI is tweaking how it should "score" moves and how big of a range in the nodes the AI should choose from.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 18th Dec 2007 03:38 Edited at: 18th Dec 2007 03:41
Link
[UPDATE]

I've just implemented "attacking". Reference screenshot, the decompilers will attack by assaulting structures or other programs with "data streams" capable of decompiling their virtual makeup.

In-game, the Constructor programs will use these streams to assault other programs but not with the intention of decompiling them. The data streams used by Constructors are capable of corrupting that program. This is a much slower process than decompiling and the constructors must have good aim. It is suggested that if you want to corrupt the enemies programs, you should instead target the memorychip that they are stored on. However, this can be difficult if the programs are stored on the enemy CPU.

Also of note here, when a structure or program is first set-up to be compiled or constructed, then it's "life" is very low and easily decompiled. While compiling/constructing, the "life" of said program/component will slowly increase to full capacity, whereupon reaching max "life", it will be completely compiled/constructed. Knowing this, it is unwise to attempt compiling programs during an assault. The same can be said about constructing components. If you are under attack and badly need some additional units, it would be wise to have an "Interpretor" program downloaded that will allow you to quickly spit out some cheap "knockoff" programs to help defend the fort. Note that Interpreted programs are not nearly as effective as a fully compiled program.

[/UPDATE]




The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!

Attachments

Login to view attachments
Back to top
Profile PM Email
Dr Parsnips
17
Years of Service
User Offline
Joined: 14th Jul 2007
Location: London
Posted: 18th Dec 2007 03:42
Link
This is looking so good! im really impressed with everything you have done here, and you seem to be making progress very fast! i hope you keep it up!

HMMMMMMM
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2024-09-30 00:26:46
Your offset time is: 2024-09-30 00:26:46