Some update...

[Mycal]

Ok, I have a full saved draft of this topic but don't feel like finishing typing it up so I'll make this short and sweet. I will post the full topic later on whenever I feel like finishing it..

I have started working on things again. I have continued the conversion to vb/c# .NET (2008 for now 2010 after xna 4.0 is released). Currently all graphics has been totally removed but I am ready to start working on it whenever I/we decide to move to Managed DirectX (now unsupported), DX8 (almost instant conversion from the old vb6 source), SlimDX (only supports up to DX10 and not DX11 for win7), OpenGL (though haven't researched usage under .NET yet), or XNA (supports xbox, zune, windows phone 7 [with xna 4.0], and windows xp+). Currently I am leaning towards SlimDX for the full power of DirectX, but am also seriously considering XNA simply because of the portability to xbox 360, though a developers license would be needed for that (and I am willing to lay down the money for it as soon as the windows version is finished).

During this conversion I have made some major changes to the structure of the game. For one, I have ported the mapformat library into a full 2D game library (though easily extendable to 3D) dubbed BSGame for now. It is still under works but I have had so many ideas to improve it and they are pretty game changing so I will list the major ones right now.

• Layers have been eliminated from tiles. Only 1 graphic per tile is allowed now. The reasoning is explained below.
• Maps are now on the XYZ plane instead of the XY plane. The Z plane now acts as the layers and ARE dynamic. There can be as many "layers" as the developer wants, but you should always consider that not many are needed to make a great map.
• Tile attributes have been totally removed. They have simply been made layer properties for the most part.
• Any warping/doors/sounds/etc that used to be attributes have been removed. Use scripts to accomplish this task.
• Scripting will take a huge roll in this library and works on a map by map/tile by tile/plane by plane basis. Though scripting languages are currently still being considered, currently I'm considering just using LUA since its very easy to implement.
• Maps are saved in two different ways. Binary and XML. To extend this further, there are also two types of formats for maps, compressed and full maps. Compressed maps are optimized versions of maps for rendering on the client. Basically this means each z plane is made into a linked list for more efficient drawing. Tiles that have no graphics/etc will not be included in the list and no loops will be wasted on them.
• Map width/height is now dynamic.
• Though the z-plane functions as layering, there is an option on each tile to specify that the image appears above or below the player. Though I can't think of any reason at the moment why this would be useful, I'm sure there might arise a need.
• Animations function on a tile by tile basis and have a dynamic number of frames used. Nuff said.
• Though not currently implemented, multiple surfaces will still be used for rendering. See old vb6 source code (for devs) or tutorial posted by myself on MirageSource for more details.

I think that covers the major changes. Some of these changes are obvious and should have been done long ago (especially dynamic crap). Some are things I never thought of but are obvious solutions to persistent problems like XYZ plane and the classic Over/Under Bridge example. By the way, if anyone has any better insight into that concept, I would love to hear it, my idea to solve it isn't that brilliant, but should work though. It basically involves either classifying certain tiles as transition tiles or making particular graphics into transitions (staircases should always change a player's depth), but right now, I'm leaning more torwards a tile property. This way the graphic transitions are not hardcoded.

Any comments/etc just post them here, not sure that anyone checks the forum anymore though..

 

[steven]

Sounds great man.

 

[Mycal]

Still no major post yet, just another small update post.

Ok, I've been working on this for far too long, but I finally finished porting the bitmap utilities (made by ron zuber [verrigan] from Mirage Source) to pure .net code. It is actually a lot simpler than verrigan's version since it has no external API, but took forever to find a working zlib wrapper for .net. I tried very hard not to break the old images from the vb6 version, but unfortunately, I can't get the encryption code to work the same as it did using API calls. It DOES work, just not the same, so all old packed images are now dead. Since this is true, I also dumped my old pack code and went with a much better format. It is now very, very fast (I'm truly amazed at the speed increase from vb6), and everything dealing with loading/adding/crypting/compression/etc is all done in memory preventing any exposure of images unwillingly. Meaning, there's no possibility of simply monitoring a folder for the unpacked image files while the game is loading. There is a possibility of extracting them from memory, but very unlikely. If they can get it using that method, fine, they are welcome to use those images however they see fit, IMO.

Anyway, as I said, I spent too much time on these two components, but they are now done. I haven't started on any of the graphics routines yet, but that is next after what I am currently working on.

Right now, I am making an easier to use worldeditor. The old one was getting very bloated with all the changes near the end of the vb6 code and became so un-userfriendly, I still can't make sense of any of it. So I'm just completely rewriting it. The worldeditor doesn't truly need any fancy graphic library, so I'll just stick to using pure GDI calls. If the FPS is really low when everything is said and done (meaning we have a working demo to test these new map features out), I'll just copy the library over from the demo.

Finally after both of those are in working order, I'll move straight onto the server & client. Note that the client should be fairly simple as it's just adding sockets to the demo.

 

[krum]

I am still reading the rest of the post, I just wanted you to know I will have a TON of free time, school is done!! out of college and nothing to do!

I need something to program!

my VB.net skills have increased tremendously.

back to reading...

 

[krum]

First off, I want to start by saying I am excited for this awesomeness!!! Secondly, if you want to see a VERY easy to use editor that we can model our scripting off of. Check out this: http://www.adventuregamestudio.co.uk it is VERY easy to use. The game type is a bit different, BUT all of the coding is super easy. Install it and try it out OR just check-out the videos: http://www.youtube.com/view_play_list?p=21DB402CB4DAEAEF I strongly recommend using a similar style, it is just SOO easy.


moving on...

I think the bridge should be done with tiles (when possible), but sometimes it isn't possible, for example, if we had a grass "hill" and no defined grass sprite for transitions, we want to be able to make the player lower via script as well.


Tiles/Features absolutely needed:
Tiles:

• Wall Block (with optional directional "walling", it would suck to script walls)
• Script Block
• - It should look different depending on what triggers it (player steps on it etc...

Script Types:

• Server Script (if something happens on the server)
• Region Script (for multiple maps, possibly a large dungeon or town)
• Map Script (if something happens on the map)
• Default Sprite Script (for NPC's/Fishing on water sprites/Chopping Trees..etc) This will save a lot of redundant coding!
• Local Sprite Script - this will override the Global Sprite Script, this will be a per map/region basis

Predefined Functions:

• Player.Transport(map, X, Y, Z, [Action])
• Player.WalkX(2) - Will move the player horizontally
• Player.WalkY(3) - Will move the player vertically (if used like shown with x and y he would walk to X location 2, then Y location 3.
• Player.WalkTo(2,3) - Same as above but will choose the path as best fit (aka no custom path).
• Player.RunX...
• Player.RunY...
• Player.RunTo...
• Player.HealthChange(-10%)
• Player.HealthChange(10%)
• NPCName.FollowPlayer() - of course NPCName would be the NAME of the npc that will follow the player
• Map.Shop.Open() - will open the Shop assigned to the current map
• Map.Effects.Shake() - For an earthquake or something

Other Stuff I think of:

• All scripts for a map should be together
• All scripts for the server should be together
• [st]Any size maps[/st]
• Add Map Shading Dynamically
• Fast-Scripting Techniques (for transporting and such between maps) for example, right-click on the starting position and click "Start Transport", then go to the map to be transported to and right-click "End Transport", it would simply generate the code and insert it into the script on the start map.

it seems as though you have addressed some of what I have said (after re-reading), Other stuff still stands!

ok, you get the idea!
Just thought I would throw some out there, if you have all of this planned (in general) then ignore me, I am just brainstorming right now.

 

[Mycal]

Ok, I haven't read your full post, just want to give a small update, I've uploaded the source to a free svn server that has restricted access, only those I invite, but I think it only allows one account on the free version, I'm probably going to upgrade our webhost package to the next level just for the ssh access so I can install svn, python, etc with no problems.

Two, I am out of school for the semester but do start back up on June 7. I am really swamped at work this week and haven't worked on anything, but otherwise I've been working on things nearly everyday. I keep trying to go for more than just functional on the world editor and I really need to stop doing that for the first release. I've cut so many things I've planned for it for a future release, and again am just trying to make it functional for now.

On a side note, I am in the process of converting a company fully to windows 7 from windows xp. They are running windows server 2003 as well and man, this project is kicking my butt. There apparently is no compatibility with windows server 2003 in "upgrading" a pc running windows xp to windows 7 (upgrading meaning just installing win7 on a new harddrive in the machine) and office 2010 is giving so many file permission errors on the server. So, yeah, it's been a fun few days working the kinks out of the process, especially when one machine works perfect then every one thereafter gives problems. Anyway, I'll be done either tomorrow or thursday and should have a solid week to get back to the project.

I will warn, I saw that you have learned VB.NET, I am currently programming in VS2010 Ultimate. If your university subscribes to MS Dreamspark, you can get it for free, but the project solution is NOT compatible with older versions of VS. However, to keep things as backwards compatible with most machines as possible (WinXP SP2 and up), the entire solution is using .NET Framework 2.0. Support of anything before WinXP SP2 is completely incompatible with .NET Framework so that is not really an issue, but I have at least one machine at home that .NET Framework 3.0 will not install on (not sure why, maybe I should revisit this issue and see if I can't fix it, the XML features would be nice), and have no idea if Framework 4.0 works on XP.

Finally, I haven't fully finished the switch to SlimDX. I suspect that my code will work, but it is completely untested. The world editor simply uses GDI+ which works well enough. So SlimDX runtimes and SDK will need to be downloaded as well.

So short story:
- SVN is available...kind of, it will be fully very soon
- VS2010 is required, unless you want to manually get the project solution to work under an older version
- Only .NET Framework 2.0 is required (though 4.0 should be installed if you are on VS2010).
- SlimDX (SDK for developers, runtime for everyone) needs to be downloaded.
- I'll pick work back up on Thursday at the earliest, Friday at the latest.

 

[Mycal]

Now as a reply to your post krum:

I haven't looked at it much, but I have it marked and will definitely take a look soon.

The bridge thing, I'm thinking we'll go with the tiles as you said. We'll make it possible to change the bridge transition tiles in the world editor and also add a script method to do it for the special cases.

Wall block is the only "attribute" remaining on tiles. I felt the same way as you did. I believe I also already added a special block, which is scriptable, but I'll check later.

Not sure how the engine you mentioned does theirs yet, but scripting callbacks will be checked on the server and if they don't exist, they don't run. But don't worry, there will be a huge amount of callbacks, just in case.

Sprites/NPCs, I actually have a huge file somewhere detailing what I plan to do with them, and I've been working on getting that all loaded into the BSGame wiki. Oh yea, did I mention we have a wiki now? It's nowhere near finished, and missing A TON of data, but it's a work in progress, anytime I get tired of programming I work on that for awhile. Anyway the abruptly ending NPC wiki is here. But I just noticed I left out the core part of that page...oh well. Anywho, I'm going to set this up so that NPCs are either loaded from a script or simply created on the fly when a map loads. There is no limit to the amount of NPCs on any given map (but I would suggest keeping it low). And though NPCs are loaded by a specific map, there is no reason they need to be limited to that map alone. It should all be scriptable later on.

Most of those scripting methods are a given, but we do need to start building a list of methods and callbacks, I've been meaning to do that, but never got around to it. I'll add a new wiki page later on for that.

All scripts for a specific map on the world editor should and will be saved inside the specific map (all maps are saved in XML on the world editor). All scripts for a specific map on the server side will be stored in the database. All server side scripts on both sides will be stored in the database, though they can be edited and saved offline.

Fast scripting techniques, I like that idea. But better than that, I'll make a few default ones, then later on I'll add scripting support to the world editor so you can create/share your own script macros.

Perhaps I need more clarification on what you mean by map shading.

Feel free to brainstorm all you want, and anything we definitely need to add or really should add, we should post into the wiki....eventually

 

[krum]

I have ways of getting programs I need ;-)

I will have to get a PM for the SVN, I will gladly dive into the code and learn it. I want to study it for a while and mess with it so I know how everything is being done.

Right now I will look up slimeDX and 2010 differences (although .net 2.0 is basically the same as 3.0)

Take your time, we have never been in a rush before, don't start now.

 

[krum]

I will start by helping with functions, I am going to brainstorm my brains out...

I will work on creating a smart OOP setup, I will create it in VB.net Class format, then you can convert it if needed.

I will work on all of the private/public/methods/functions...etc all of that good ol' oop stuff.

I should be able to finish this in a couple of hours just to make sure I am not missing anything I will be doing:

• Server
• Map
• Player
• Guild
• NPC
• Monster

Missing anything?

Also I will work on a set of triggers for the script as well:

I envision a map script to look like this...

//Map Script File

function Map_BeforeLeave()
{
    //Prevent the player from leaving the map if a quest isn't completed
    //A number can be used as well, but a name is great for ease of use
    if(!Player.Quest["Dungeon Keeper"].Completed)
    {
         Map.Transport.Stop();
         Map.Message("The road is closed!", Red);
    }
}

function Map_BeforeEnter()
{
    //do things when the player enters to ONLY that player
}

function Map_AfterEnter()...
function Map_AfterLeave()...
function ScriptBlockName_OnStep()...

it would be nice to have it setup like VB.net does and generate the code automatically... what do you think?

 

[Mycal]

The BSGame core code actually is OO. Though it only contains, Map stuff (there's quite a bit), Character stuff (which relates to Player and NPC), and other useful utilities.

I'll get you SVN access tonight after I get home from work. I also need to remember to update the latest changes to SVN too, I've neglected doing so for awhile now, actually since I upgraded to VS2010...