why dont u shoot me a PM. we can talk there.

As many of you know, I've been working on a Star Trek game for some time. This project is not dead, just sluggish because of RL obligations.

I am starting to think about what features can be client-side, and what must be server-side, on the hub. Here are some of my ideas:

1. Have the hub itself hold ALL the data about the players on the game...their names, their positions, etc. If I can create databases with this info and have the hub handle searching for the data, then I can do something much easier with regard to sending data (see #2).

2. Instead of having the calculator have all the data for all the players on the server, which would consume a lot of memory, I can have the data on the hub, and then when you need some of the information, the hub would respond only with relevant data. For example, if you are doing a "position update" on other ships (redrawing them at their new locations), we can send a request for new positions to the hub. Now, let's assume the maximum view range of your ship is 100. The hub would only send you back the positions of players within 100x100x100, not the guys on the other side of the galaxy.

2a. The hub itself would do the cycling, not the calculators. Once a weapon is fired, the calculators never again see that. The server adds it as an entity, and handles changing its position on correct timing, and sending data on it to the calculators. Thus the server is doing all the work and all the clients are doing is rendering it.

3. Instead of having separate routines for drawing ships and drawing phasers and photons, I can actually make them all "objects" and store their position, direction, and speed data on the hub in the same fashion. That way, I can draw them all with the same routine. This would also allow for this: if you fire at a ship and you miss, the projectile keeps going until it either goes out of range or hits someone else, without any extra code, beyond a collision detection.

4. A star base will be a server-created entity that is capable of self defense. It will belong to a team (assuming I can make team play possible). Players on that team can enter the base, refuel, repair, and equip it with weapons. Players on the opposing team can attack it, and it will defend with whatever it is equipped with.

5. When the first player joins the hub, the server will create a world and generate terrain. Terrain can include basic space, stars, nebulas, and wormholes. I hope to include planets at some point, but star bases will be the only defendable thing in v1. Basic space does nothing and is the majority of the map. Stars can damage your ship if you go too close, and have gravity (not sure how I'm implementing or using gravity). Wormholes also have gravity, but more. Nebulas are there mainly for a tactical use...they disable shields, sensors, and communication. To minimize load on CALCnet and on the calculators, when you join the world, you will only be send terrain data for the area near you. As you near the edge of that, you will exchange your terrain data with new terrain data.


Here are, as I see it, the pros and cons.

Pros

• Less demand on CALCnet itself and on the client calculator.
• Able to do more, and have more realistic combat, with less coding.

Cons

• We are relying more on the hub for data than on the individual units. Thus, if the hub can't keep up, then we have a problem.
• I will need to write routines for REQUESTING data from the hub, which I wouldn't have to do otherwise.

So here is my questions:

1. Do the pro's outweight the cons? Should I adopt this new strategy?

2. Anyone willing to help out at all? I don't have all the time in the world to make this lol?

I'm not sure about speed. I do know that I disable the delay when utilizing flash, and that this game is an app. And yes, I mean a tile map.

There is no "For Zelda ill block out my entire calc if i have to" option ... !

Lol. that won't be necessary. even 3 pages is the upper end of what i really think i need. You a z80 programmer?

Honestly, Deep, I'm not too concerned. In fact the AI system that I spent all day coding is wrong, because it is based on the enemy moving one whole sprite at a time. But, that is not the case. So, it turns out I'll be needing help with this and the graphics system, because I really don't know how to do the latter. But, everything else is slowly getting done.

Ok... I have picked up progress on this, starting with a complete recode of everything. I dumped the sprite/map set as well and plan to redo them. Also, I devised two separate algorithms for AI, one for enemies that try to run into you and one for enemies that shoot at you from far away. In addition, I have designed the main menu, file save, and map save routines. I will also be doing the event triggers and event scripts. Events are divided into two classes, pre-move events and post-move events. Pre-move events are generally what should stop you from moving onto a tile. Post-move events are like entering a building, stepping on lava, or collecting an item.

AI for Collision

1. move toward player on x
    ; if enemy x = player x, goto 2
    ; if movement blocked, goto 2

2. move toward player on y
   ; if enemy y = player y, we have collision !!!
   ; if movement blocked, goto 3

3. move away from player on x
   ; if movement blocked, goto 4

4. move away from player on y
   ; if movement blocked, do nothing.

**there are some caveats with perhaps not a complete collision, since the tiles are 8x8 and AI/player movement is pixel based...

For AI where the enemy can fire at you

1. Move toward player y (more distance) (we are aiming to move in line with player, but not actually towards player)
    ; if enemy y = player y, we should try to shoot (but not all the time). If we are not shooting, goto 4.
    ; if movement blocked, goto 2

2. Move toward player x (again, moving in line with player, but not towards player).
    ; if enemy x = player x, we should try to shoot (but not all the time). If we are not shooting, goto 4
    ; if movement blocked, goto 3

3. Do nothing.

4. Move away from player on y (try to keep distance).
    ; if movement blocked, goto 5

5. Move away from player on x.
    ; if movement blocked, do nothing

-----------------------------------

Another thing I need help with. When the player moves, or the AI moves or a bullet sprite advances, I will need to replace the correct sprite underneath the sprite that has just moved. How do I do this?

-----------------------------------

Obviously, while I have made significant progress, a lot still needs to be done. So, if there are any developers out there who can code in Z80 and are willing to spare a bit of their time, I would not turn down some assistance with some of this programming. Assistance will be fully credited.

Yeah. I'm thinking 16.8 Fixed Point.

Anyway, this project is being made universal. If you are a Z80 assembly programmer with some spare time, hop over to the link below (Google Docs), check out what is needed and write a routine or two, post it into the google doc, then add your name or screen name to the very bottom of the document, along with what routines you should be credited for. I'll be working on it regularly myself as well, time providing.

Also, I seem to have lost my resources on the appropriate headers for a TI Application file, so someone can edit that in to the Doc as well.

When it is done, we can publish this as a community project, rather than a project done by a single author. That allows us to make it a large, feature-dynamic project, very quickly. This will be cross posted to cemetech as well.

Link to Google Doc:
https://docs.google.com/document/d/1R5MgUPEO1muFVD_8rArb5MsTiMA5M7KATDqquwZ3wKE/edit

For a better description, head over to http://www.cemetech.net/forum/viewtopic.php?p=196685#196685