Isometric controls+camera RTS/RPG The Sims

This is suited for an isometric RTS or RPG, boardgames, or any project like The Sims or Tycoon games. It's not feature complete, but it can serve as a solid head start. Consult the readme file for controls and the contents of each script file.

http://www.geocities.com/hainesrs/isometric.zip - 503KB...includes all code, resources, and demo level


Here's what you get:

1. 3D isometric cam that's controlled via the mouse, keyboard, or both
2. Mouse to level clicking complete with draggable entities. Features a redefinable grid snap and panning of entities
3. Pan/tilt of the camera via the right mouse button
4. Full customization to suit your needs. Simply change initial values of some VARs and you're ready to go
5. Very basic demo level. Load into WED and run.


Known issues: - If anyone manages to squash any of these, please PM me or post your fixes here if you wish to share.

1. Grid snap quirk.

a. If an entity is on an elevation and is restricted to movement either in the X or Y direction(by holding down ctrl and alt keys), the entity can fly right off the block and into empty space. It can be released and will hover in midair. This is directly related to the fact that the Z position can never change whenever a restriction is true. I consider this a serious issue. A workaround is to simply disable restricting.

b. When an entities' movement is restricted and it is on the main ground plane, it cannot be placed on an elevated plane. It is very easy to make it do this via editing a very small amount of code, however this leads to the entity becoming elevated if the mouse cursor passes over an elevated plane and the entity is nowhere near it. I chose to eliminate placing an entity on an elevated while it is restricted because of this. If this issue can be resolved, then letter a.will also disappear.

c. If snapping is turned off(setting the snap vars to 0), the entity will sink into geometry up to it's origin and will hang off of elevated blocks by the same distance. Not a serious issue if you are using snapping(which is recommended).

2. There's no kind of entity on entity handling or entity managment period

As is, an entity can be dragged on top of another one and released from the mouse cursor. Ideally, if this happens, the entity should not be able to be released and neither should the other be able to be clicked on while the active entity is on top of it. Also, there isn't really any other type of entity management. This is just as serious as the one above.

3. Wobble cam when smoothing is > 0 and you rotate the view

Smoothing is what makes the camera gradually move from one position to another. It works great when you move the player around, but once you start rotating the view(right mouse button), the view will start to wobble. I have no idea how to fix that and the smoothing code is near the bottom of the cam.wdl. Smoothing is always 0, as is, so it is not an issue unless you make it nonzero. I consider it a minor issue, unless you really want the smooth movement.

THANKS!!!

this is a start of a RTS camera maybe (not that i need it, but i am sure a loota people do need it..
i need to goto work, but 'll take a deeper look tonight.
as far as what i saw, thanks:D:D

regards and keep it up,

Orange Brat, this is awesome and thanks big heaps.
Definatly interested in your chase cam solutions.
Cheers.

Thanks. I've gone ahead and zipped up a demo level and included the movement code I mentioned in the initial post. I heavily modified the post and included all pertinent info and the link there.

removed for clarity

Very well done !
One problem I noticed is that sometimes when you pick up a block the camera will start orbiting around it.

looks very nice. should help anyone wanting to work in an TBS/RTS.

removed for clarity

removed for clarity

Really well done! I guess it goes without saying this would be useful for board games like chess and so on as well. I think this might also be useful for a 3D editor -I remember user Damocles had talked about that- for users to build levels using prebuilt parts. Cool.

Yes, provided I or someone else can tweak it into shape, it will have multiple uses. I'm going to try to devote some time to it today and if anything significant happens, I'll reupload and update here. I really had no plans to work on it after the initial upload, but I changed my mind.

Ok, a new version is uploaded and initial post edited.

Here's what changed:

1. Fixed the grid snap...it now works correctly no matter how far you are zoomed out or the view angle

2. Fixed the rotation bug that Marco described

3. Implemented the ability to: Grid snap in XY direction, snap into X only(by holding down ctrl key), snap into Y only(by holding down alt key), no snapping at all(i.e. smooth movement)

4. Entity can no longer be dragged up a wall if the texture scanned by the mouse_to_level trace is pre-defined as illegal

5. Optimized some code

6. Generalized some values to add flexibility

7. Added some comments to scripts

Ok, I uploaded another one. Not much different, though I altered the demo level a little bit. I also included a readme. The controls have changed a bit, so see the first post or readme for that.

Known issues for anyone wanting to improve it:

1. Grid snap quirk.

a. If an entity is on an elevation and is restricted to movement either in the X or Y direction(by holding down ctrl and alt keys), the entity can fly right off the block and into empty space. It can be released and will hover in midair. This is directly related to the fact that the Z position of the entity remains consistent whenever a restriction is true. I consider this a serious issue. A workaround is to simply disable restricting.

b. When an entities' movement is restricted and it is on the main ground plane, it cannot be placed on an elevated plane. It is very easy to make it do this, however this leads to the entity becoming elevated if the mouse cursor passes over an elevated plane and the entity is nowhere near it. I chose to eliminate placing an entity on an elevated while it is restricted because of this. If this issue can be resolved, then letter a.will also disappear.

c. If snapping is turned off(setting the snap vars to 0), the entity will sink into geometry up to it's origin and will hang off of elevated blocks by the same distance. Not a serious issue if you are using snapping(which is recommended).

2. There's no kind of entity on entity handling or entity managment period

As is, an entity can be dragged on top of another one and released from the mouse cursor. Ideally, if this happens, the entity should not be able to be released and neither should the other be able to be clicked on while the active entity is on top of it. Also, there isn't really any other type of entity management. This is just as serious as the one above.

3. Wobble cam when smoothing is > 0 and you rotate the view

Smoothing is what makes the camera gradually move from one position to another. It works great when you move the player around, but once you start rotating the view(right mouse button), the view will start to wobble. I have no idea how to fix that and the smoothing code is near the bottom of the cam.wdl. Smoothing is always 0, as is, so it is not an issue unless you make it nonzero. I consider it a minor issue, unless you really want the smooth movement.

If anyone manages to squash any of these, please PM me or post your fixes here if you wish to share.

i just thought of something...

you ever heard of the game TIM (the incredible machine), well you could make such a game with this too..

for the people that dont know that game, it's a building game where you can create youre own machine by dragging objects to places.

regards and thanks for this cool contribution,

Most definitely.

Yet another update.

http://www.geocities.com/hainesrs/isometric.zip - 503KB...includes all code, resources, and demo level

My theories concerning the grid snapping turned out to be fruitful, and I squashed the heck out of my problem. The only problem is is that it left me with a massive IF/ELSE monstrosity. Basically, all I added was an offset to the snap, but it has to be handled differently depending on what quadrant the 3dmouse_pos is located in.

I have no idea if it can be made more efficient by applying some fancy thinking or simplification, but I'll leave that up to someone else with more programming experience. What's there works, but it is a pain to look at. This will probably need to be converted to a CASE/SWITCH type block when that becomes available. I suppose one way to simplify it would to make sure that the level could only exist in only one quadrant. That way, you could only use the code that deals with that specific one and remove the rest. You'd have to take steps(set level bounds) to insure the player could never build outside of that section.

Anyway, I've updated the readme, and the "issues" sections in this thread. There's at least one more serious issue concerning snapping, but it only applies if you are restricting the movement of an entity to the X or Y direction. The simply way around it is simply to disable restricting. I threw that in for anyone who may need it. I most definitely would like to see it resolved, though..along with the no snapping issues I mentioned.

Model/entity management is probably going to be a huge undertaking and will make this an almost complete package. I have no idea if I'll attempt it, but if anyone gets that working, please keep us posted here. One thing to keep in mind when building for this system, you can't just place anything whereever you want. You have to keep the grid snap in mind or else you'll have areas where the entity should be able to go but can't because of a misaligned level.

Ideally, you want to have the entire play field constructed from models, but that gets into issues of collision detection, and it is a pain. It might be easier with the new collision and perhaps eve a completely different way of moving the entities. I would think you'd need to use ent_move or c_move on them so you could get some collision detection instead of the current way. Good luck.

I like this contribution. I especially like the camera, is it ok if we change it to our needs and use it or do want to leave it as is?

-Brayden Wilmoth

You're free to do anything you wish to it. This includes gutting it and using the camera/movement code for a normal game. It is essentially a Splinter Cell style cam adapted to work with this system. This means that if you press the forward key, the player will always move away from the screen. If you press left, it will always move left. It is completely independent of the camera pan and you can thank KeithB [Ambit] for it. The relevent code is in the Heromove and playerinput files, and the vars/defines used are mostly in global_defines. There may be some stragglers in playerinput.

I intentionally made it very generic so that all you had to do was change the values of the VARs to make it unique.

If you add some features or fix some of these issues, I'd love to know what you did and see the code IF you are willing to share. If not, no biggy. This goes for anyone else. The more the merrier.

this is very cool Orange Brat!

thanks a bunch

always~

Thanks Orange Brat, nice contribution. Hey Eagle, long time no see! What are you working on these days? Would love to see some of your recent projects. Glad your still around. I'm in Iraq, just kickin back and working on my new game. See ya later.. GS out.

There was some kind of bug with mouse_force in 6.22 and upgrading to 6.3 made the program go crazy. If you held down the right mouse button to rotate the view and then let up on the button, the view would continue to rotate. I fixed this, although I have no idea why it would do this given the way it was coded:

http://www.geocities.com/hainesrs/isometric.zip - 505KB...includes all code, resources, and demo level

Orange Brat! We don't see eye to eye on politics, but dude your code kicks butt! You roxor!

5 star salute!

OrangeBrat,

I just found this great isometric example of yours. This is wonderful. I was starting to try something similar but it would have taken me a very long time to reach the quality of what you have made.

A question for you. My intention is to make a hexmap style game with 3dgs. I like your squaremap version, but to remain true to the old tactical wargame style, I will be trying to work with this to implement a hexmap. Hexmaps are a big deal with the older SPI style boardgames, as you may know, because there is no distance difference when you move in any of the 6 directions. Have you done anything similar utilizing a hexmap, or even a diamondmap (ala Diablo)?

I will start by changing the square texture to a hex and looking very closely at how you are applying the x,y offsets when snapping the entities to the square grid.

Once again, though - excellent work - and thanks for offering this to the 3dgs community. You just made my project much easier

Ron

Well, I hope you don't run into any problems with it. It still has some issues and I've pretty much abandoned it to the community. See the readme file or first post for their description. Also, the technique used to "turn off" the mouse_to_level clicking may not be the best way...that would be this line, "if(trace(temp2, temp) > 0 && (str_cmpi(tex_name, illegal_texture1) == 0))". I never really fully fleshed out the illegal texture component or really thought of an alternative way to keep an active entity from not moving up vertical walls(which was the intention of turning it off when over an illegal texture).

Also, the part dealing with the grid snapping(in the mouse file) is a mess of an if/else block. Perhaps when we have case/switch instruction it will look better. I'm not really even sure why I had to use all that code but it doesn't work right unless I do it that way. I'm sure someone like Realspawn, Rhuarc, Locoweed, etc could fix it up and make it more efficient or come up with alternatives, but anyway this is the best I could come up with at the time.

Hi Gamesaint762, yeah I have been away for a while. I have been working on some really cool projects. The A6 engine (as you already know) has opened a lot of doors with the awesome power it offers. Makes my mind swim~
I will post some screen shots of the work I have finished over the last 6 months. I have done nothing but work on my game in hopes of getting a project worthy of sponsorship.
So keep your head down while your over there and trust no one... I'll be thinking of you Gamesaint.

always~
Eagle

Thank you for this fine contribution!

Respectfully,

Thank you, Senior Expert !

You're welcome. I got the basics working, but I was never able to successfully complete the click and drag feature. I don't require, myself, and the method I was using may or may not be the best way to do it. It does work, although it has some rough edges which I've documented.

I will try to make a small level editor out of it

That's what I was trying to do. Nothing as fancy as some of the one's that have been popping up lately, though. It was just an idea I had for a side project, and that was the beginnings of it. Keep us posted on your progress, if any.

well at the moment I finished the select of the high level:

thanks for the extrem good basic code orange brat

Looking good. Don't forget that you can restrict movement of the clicked on object by holding down the CTRL or ALT key. One work for X and the other for Y. Also, the camera can be dollied if the mouse cursor touches the edges of the screen. I can't recall if that can be turned off, but I recall that there are boundaries, so it won't dolly forever. Of course, the boundaries can be altered via a VAR tweak. Another feature is the ability to rotate the clicked on object. I can't remember the way to do it, but I'm sure it's in this thread or the readme file. I never finished that, so I don't think there's a rotate "snap" in place, yet.

yep thats very usefull brat
and no the rotage hasnt snapping and you must press the middle mouse key to rotate (I change thatbecause I havent a middle mouse key ^^)
new function added
you have the choice I you want to make the unused level transparent or invisible

great camera system,
now I must think what kind of game that I would make with this nice camera system...

how would i go about useing the left mouse button to rotate the map? i would like to use this in conjuction with a popup menu but i need the right mouse button for that.
sweet bit of code btw, i shall find untold uses for this.

In the cam.wdl is where the camera panning is handled:

Code:

---

	if(mouse_right == 1 || key_pressed(tl_key_scancode) || key_pressed(tr_key_scancode) || key_pressed(ldown_key_scancode) || key_pressed(lup_key_scancode))
	{
	    orbit_camera_pan -= (mouse_force.x * mouse_sensitivity * mouse_invert_pan) - 
	                    ((key_pressed(tr_key_scancode) - key_pressed(tl_key_scancode)) * mouse_sensitivity * mouse_invert_pan * time);
	    orbit_camera_pan = orbit_camera_pan%360;	//limit to 360 degrees

	    orbit_camera_tilt -= (mouse_force.y * mouse_sensitivity * mouse_invert_tilt) - 
	                     ((key_pressed(ldown_key_scancode) - key_pressed(lup_key_scancode)) * mouse_sensitivity * mouse_invert_tilt * time);
            orbit_camera_tilt = clamp(orbit_camera_tilt, orbit_min_tilt, orbit_max_tilt); //limit
        }

---

There are some checks in other parts of the system that check whether mouse_right and mouse_left are pressed or not. You'll have to change those if you change the above mouse_right to mouse_left. I'm guessing you'll have to switch all the rights to lefts and vice versa.

cheers mate, i got that to work, now i have run into another problem, i have a gui which will launch your code, it goes fine up until i hit the new game button, then i get a can`t find hero action error, i have deleted all the blocks from the wmb bar the grid one and the camera one, any thoughts on this please?

it`s ok i got it to work, i forgot to include the scripts into the main wdl, now all i need ot figure is a random star generator, and how a turn funvction works lmao, thanks again for this code.