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.

AppGameKit Classic Chat / Making a simple Old School Style FPS Game in AppGameKit 2

Author
Message
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 6th Mar 2018 04:01 Edited at: 6th Mar 2018 04:57
Link
Thanks @Lance and @blink0k. It's good motivation knowing people like this project.

I decided I might as well do a little thought on implementing the enemies LOS (line of sight) tonight. I wanted to visualize it so added indicators for the 5 rays each enemy will use to "see". I may increase that a bit depending on how it works out in practice but for now I think 5 to 7 rays will work well.



Just basic stuff nothing fancy. Enemies will do 5 ray casts to detect the player. Of course, the player does not actually exist... just a camera so I will either use the collision box I set up near the beginning to "proxy" for the player or I could just create my own line algorithm. Definitely leaning toward using the box proxy approach.

If one of the casts hits the player the enemy will enter combat mode.

Alright that's it for tonight.

Actually I was just thinking about this a bit more with the help of my bottle of beer... and I think I may just use 2 or 3 rays casts total. Because I've done game dev enough to know we usually don't need the resolution of multiple checks every single frame. Instead I could have two rays starting at the middle and moving out and back in a certain angle amount each frame. Or 3 rays with the middle one scanning back and forth 15 to 20 degrees over several frames and two more rays on the sides scanning out an additional 15 to 20 degrees on each side beyond the center ray angle limits. I will visualize that the next dev session.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
PSY
Developer
7
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 6th Mar 2018 18:55
Link
Happy Birthday

Looking good...


PSY LABS Games
Coders don't die, they just gosub without return
Back to top
Profile PM Website
PSY
Developer
7
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 6th Mar 2018 18:57 Edited at: 6th Mar 2018 19:00
Link
Happy Birthday

My last post vanished somehow during the 'upload'

EDIT: Sorry for the double post. Now it showed up....


PSY LABS Games
Coders don't die, they just gosub without return
Back to top
Profile PM Website
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 7th Mar 2018 01:04 Edited at: 7th Mar 2018 01:12
Link
No problem @PSY and thanks!


Just a quick update here (no code just describing what I did and illustrating it with a couple of gifs)...

I implemented 2 raycasts for the enemies LOS... well I implemented the visualization for it anyway. The actual implementation will be even simpler than this was considering everything is already working as far as the start points and the angles and the scanning animation etc.

So basically instead of having each enemy shooting out multiple rays every frame which seems terribly wasteful to me I thought why not have the enemy use just 1 ray or 2 rays (possibly 3 rays) that scan back and forth in front of it. This way a single ray can cover an area of distance.

I think this can work even with 1 ray assuming the object and things it is trying to detect aren't moving too fast but I decided to go with 2 rays for more accuracy.

The LOS function accepts length of the rays and speed at which they scan so in this way different enemies could have different capabilities... some could see further making them seem to be more aggressive and other enemies could scan slower and therefore not be as quick to react (theoretically anyway).

I changed the transparency to make the rays easier to see. Noticed in the other gif I posted they were hard to see.

So here is an enemy scanning with a very slow speed just to illustrate what is going on:


And here is an enemy scanning at normal speed:


So in this way as mentioned only 2 raycasts cover the full LOS in front of the enemy.

Alright this takes me to the point where I will be ready to actually implement the LOS system using raycasts so they can detect the player and enter combat mode.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 7th Mar 2018 01:19
Link
I'm wondering if you could just calculate the distance and angle relative to the enemy. If the player is say within -15degrees to 15 degrees and a certain distance the enemy see's the player
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 7th Mar 2018 01:23 Edited at: 7th Mar 2018 01:30
Link
Yes I could use math to check for the angle to the player and see if that is within the LOS angle range of the enemy but I'd just use casts because the player could be within that range BUT actually be on the other side of a wall inside a room for example where the enemy still should not see them. Math won't tell me that.

I did consider going that route and then checking the map data but decided it would just be better to use raycasts because it would map to more projects be more helpful to others.

I could do the angle check and then shoot out a ray to check for a wall but ah I find this more fun and interesting personally having them scan. lol
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 7th Mar 2018 01:30 Edited at: 7th Mar 2018 01:31
Link
Edit: Didn't see that last line
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 7th Mar 2018 01:45 Edited at: 7th Mar 2018 01:49
Link
No problem @blink0k I was updating the post to clarify at same time you were posting I think. I generally make a post then read it then update it. Read it again update it. Lol

You are right... the standard approach is exactly to do the angle check then if within the angle range do the raycast directly from the enemy to the player to check for obstacles. But since that is the standard I wanted to try something different. It is a little weird so I like it. Lol Kind of makes me think of long antennae out feeling around or if it was only one ray scanning back & forth kind of like a Cylon.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 7th Mar 2018 04:07
Link
On reflection i think it's pretty good. You could hide behind poles and statues
Back to top
Profile PM
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 7th Mar 2018 04:10
Link
The scanning is interesting, but it seems odd to have it move apart - together, like it is going wall eyed - cross eyed.
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Back to top
Profile PM Email Website
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 7th Mar 2018 04:45 Edited at: 7th Mar 2018 05:00
Link
LOL @Ortu that made me laugh thanks! Yeah for sure if it was visible like this it would be odd. I probably didn't clarify this is only for development. I will leave the code in to visualize when posting here but the idea would be the LOS indicators wouldn't actually be visible to the player. This just allows us as devs to visualize exactly what is happening so can easier tweak things as needed and so forth.

I actually just came back into this a while ago and implemented the raycasting based on the LOS scanning. It works very well. Now I just need to focus on the actual combat behavior and adjust things. Currently the enemy sees you and starts blasting and even when you move around it does a great job of turning tracking you. So they would obliterate a person in seconds. ha ha

So need to balance this out so the player has a chance. I'll add a separate timer delay on the enemies or other tasks to the Combat state such as Dodge / Relocate a bit after firing or something along those lines. I've always found this part of game dev to be one of the most interesting.

I know I have said it before but I just have to say I am so glad I found AppGameKit 2. I find it to be so incredibly easy to work with it just makes game dev a real joy. More than I have had from it in a long time. It doesn't have this huge all encompassing API but it has everything I need or at least everything I need to easily build what I need. I have developed in many different things, tested many things and honestly I find this to be unique in the way these guys have designed it. They really did an excellent job. Granted I am not doing model animations and stuff like that and maybe that is a real beast in AGK2 I don't know but what I find in many other things is they handle that kind of stuff well but they absolutely suck at the fundamentals and AGK2 just nails those fundamentals and I find it so damn refreshing.

Alright enough of me singing the praises of AGK2 I guess.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 7th Mar 2018 23:36 Edited at: 7th Mar 2018 23:38
Link
Quote: "I know I have said it before but I just have to say I am so glad I found AppGameKit 2. I find it to be so incredibly easy to work with it just makes game dev a real joy. More than I have had from it in a long time. It doesn't have this huge all encompassing API but it has everything I need or at least everything I need to easily build what I need. I have developed in many different things, tested many things and honestly I find this to be unique in the way these guys have designed it. They really did an excellent job. Granted I am not doing model animations and stuff like that and maybe that is a real beast in AGK2 I don't know but what I find in many other things is they handle that kind of stuff well but they absolutely suck at the fundamentals and AGK2 just nails those fundamentals and I find it so damn refreshing.
"


Couldn't agree with you more.
I've really found back my coding mojo (unlike in some other new languages that are trying to add just that - ex-Blitzer's know what I mean-[cough]Monkey[cough]- lol )

Also love the fact that it scales down and up pretty good and produces code that actually reads well. That's a big plus over Unity. Ever tried bug hunting in there? It's a horror.
Back to top
Profile PM Email Website
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 8th Mar 2018 04:01 Edited at: 8th Mar 2018 04:05
Link
Ha ha! Yeah I spent a good amount of time in Blitz as well on the Amiga and Windows. Also in Monkey (although when I got into it the name had changed to Monkey X).

Alright I finished up the enemy combat state. Nothing fancy but plenty enough for a game.

I added some color indicators on the enemy (in addition to them being damaged) to give some information about the state they are in. Again, this is not something I would leave in an actual game but it is good for dev purposes to help clarify things.

Here the enemy is coming down the hall and spots me. Remains in combat state tracking me and turning as needed to target me. You can easily see when it becomes aware of me... that is when it lights up.


The enemies have an awareness timer and during scanning when they spot the player their awareness timer is set. I think they remain aware / alert for about 1.5 seconds except for when they have been hit and are high on health then they remain aware for 4.5 seconds.


Here an enemy was roaming down the hall turned around to head back and got hit (it had already been damaged a few other times previously)... being low on health it turned yellar and fled.


I also improved the enemy turning while in combat mode so its turning speed is based on how far it needs to turn. The greater the amount the faster it turns and the smaller the amount the slower it turns so an enemy may start out turning quickly and slows down gradually as it nears the target point. Of course there are min and max limits on these turning speeds.

Alright that is it for tonight. Tomorrow I will need to add player health and apply damage when player is hit. Then I will post code update.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 9th Mar 2018 04:55 Edited at: 9th Mar 2018 05:55
Link
Decided to add the health bar. And then I thought really there should be a mana bar too.

Note: The black border is just something I added to make the screenshots stand out a little better here.



So that's implemented as far as the bars showing the current amount of health and mana the player has. And is all scalable as well as far as specifying the size of each unit and the gap between them.



or no gap between the units if that is your preference.


It auto centers vertically more or less but of course that can be changed. Never paid any attention to it until now looking at the screenshots but I think I kind of like the 3rd one the best. But maybe without the unit gaps.

Okay that is it for tonight. Tomorrow I will actually implement the player being damaged by enemy shots. And I will probably implement the mana bar as well because I was thinking it would be good to have it cost mana to launch fireballs and that mana will recharge. Thinking can only launch a fireball when it is full so it will recharge fairly quick but still be good for a visual cooldown indicator. And who knows maybe later (when this is done and someone else implements it) a person could find an item that increases the mana recharge rate allowing them to cast faster.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 9th Mar 2018 05:23
Link
Is the source in the first post the latest?
The movement seems a little stuttery on my machine, not at all smooth like in your video. (I have a i5 2.71ghz CPU and 16GB NVIDA Geoforce Adapter 8GB)
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 9th Mar 2018 05:28 Edited at: 9th Mar 2018 05:32
Link
The latest version is here posted 5 days ago. It is a 99 KB zip file.

I should have an update of the source up tomorrow night or Saturday. But if you mean the very first post in this thread than the one from 5 days ago will be much further along than that. Original was just code pasted in. Now it needs to be in a zip file due to textures and using tilemaps to design the game world.

No idea if it will be smoother or not for you. There is a lot more in it now than the first post with pasted code. Runs fine on my laptop though.

5 days since the last source update. I must be really slacking this week. lol
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 9th Mar 2018 15:24
Link
Slacker.

Its nice to see so much getting done and at a good pace
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Back to top
Profile PM Email Website
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 9th Mar 2018 17:09 Edited at: 9th Mar 2018 17:27
Link
@Ortu thanks. Lol. Yeah when I was younger my motto for everything was anything worth doing is worth doing right and as the years passed for some things such as game dev it changed to anything worth doing is worth doing fast. Which seems odd I suppose but means building & maintaining momentum is important to getting stuff done.

Course that has to work with my other motto what doesn't get done today can be done tomorrow or next week.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 9th Mar 2018 18:03
Link
mine tends to be:

If its good enough to start with, keep moving forward, come back to polish/clean it up later.
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Back to top
Profile PM Email Website
Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 9th Mar 2018 20:54
Link
ortu
I do the same but painfull later on
Like when tgc want to buy some source..
spending Days to Clean it up is not fun
My space on goggle play ... https://play.google.com/store/apps/developer?id=Play8Bitar+Osterlen
Play8Bitars channel ... https://www.youtube.com/channel/UC_TbzZmDzj0axBZsbfRnDCQ
Think i know it channel ... https://www.youtube.com/channel/UCEJY7tJ5_HBQxi06BGsnoQg
SlideDb space ... http://www.slidedb.com/members/play8bitars-osterlen
Back to top
Profile PM Website
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 9th Mar 2018 22:47 Edited at: 9th Mar 2018 22:48
Link
Looking good. Can't you do the recasting by casting it backward from the player? Just thinking of the speed of multiple enemies.....you need only cast back from the player to enemies within a radius of X. As you are using cubes now anyway, you just need to use the normals to figure out which side of the enemy was hit, if any, then if it was the front the enemy could see the player. Simple, but would keep you to a single recast per enemy.
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 9th Mar 2018 23:33 Edited at: 10th Mar 2018 01:26
Link
@Santman sounds reasonable. Like most "problems" there are many different solutions. Definitely think yours is another reasonable approach and agree would be better for performance. The common way of checking angle to player to see if within angle range of enemy and only then doing a cast would have better performance too.

It is a novel approach just "something different". Generally, I don't like to "cheat" and instead implement enemies to actually scan their environment as if they were "real" beings. So like they just literally "look" (well literally in this context I mean... which means casting out a ray across their range of vision) and they may see the player, they may see a wall in front of them, they may see a collectible, etc. And then they can decide what to do with that information. Here though I have not done that in the interest of keeping this simpler and knocked out a simple waypoint system for the enemies movement. But still they could use the information gathered from actively scanning their environment in other ways if a person wanted to make use of it. Originally I was thinking of having the enemies cast out multiple rays maybe 7 each frame in their range of sight to implement "true" sight for the fun of it. The 2 rays sweeping back & forth is an optimized implementation of that idea. Tonight I will work on getting the player taking damage then maybe the mana spending and regeneration cooldown on firing and post an update either tonight or tomorrow.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 10th Mar 2018 04:29 Edited at: 10th Mar 2018 04:50
Link
I implemented the mana regeneration and the mana cost for firing.

That is all I did and I just did that. It is Friday night and after the workweek of software development all day didn't feel like doing any more than that. I like tackling things in bite-size pieces too. Works well.

So tomorrow morning sometime I will implement the enemy shots damaging the player. If I stay up long enough I might do another mini dev session tonight and get that piece done. I know it is only about 10 minutes of work at most.

Well... thinking about it... it is true it will not take more than 5 to 10 minutes to do it. Okay, I will go ahead and get it done now.

--------------------------
Okay... player damage and health bar dropping is implemented. Nothing happens when the player loses all health. That will be for another time. But in all this is a pretty big update over last time. You can actually play now.

Source is attached. 108 KB
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)

Attachments

Login to view attachments
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 11th Mar 2018 06:59
Link
I didn't do anything on this today. I think this has gone far enough at this point to just wrap it up.

The next time I work on it I will focus on some code restructuring such as breaking the player control out into a new PlayerManager code file. Maybe add a proper game loop that has skeleton code for game states Title, Playing, Dead.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Lance
20
Years of Service
User Offline
Joined: 22nd Jul 2003
Location: Third planet from Sun
Posted: 11th Mar 2018 12:31
Link
Those block people ( maybe sprites needed ?) keep trying to kill me . But since I have super powers the fireball/laser shots don't faze me . " Maybe add a proper game loop that has skeleton code for game states Title, Playing, Dead " I think that should wrap up a good Old School Game . It has given me quite a few ideas for my project . 2 thumbs up to you .

Lance
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 12th Mar 2018 14:47 Edited at: 12th Mar 2018 16:30
Link
@Lance ha ha. That's a good thing! If it seems like they are trying to kill you then they are earning their room & board!

Once I add a game state structure or even player state management you will no longer be immortal being able to seamlessly transition from living to the undead and continue playing in the dead state.

There is a texture slot set up already for the enemies. In the beginning I thought about using 2D sprites for enemies and collectibles or 3D and decided to go with 3D objects. The idea is a person can replace the cube with a model they make whenever they want to.

I might make a final iteration at some point to wrap it up with some low poly models for the enemy. A lot of is just how much is needed and how much is too much? I made this just to be a larger tutorial project basically a template... something that has a little more meat to it than a very basic example. It already covers many different things. Like transitioning between areas (levels, etc) although current gameplay does not have it you can teleport to the next area at any time by pressing T.

My thinking was the developer can do the same thing any time in-game based on whatever objectives are needed. Maybe it is collecting enough items. Maybe it is unlocking a certain door etc. But there might be value in me adding it to actual gameplay and is easy to do.

So... if people think something more is needed to make it more beneficial as a tutorial style project that can be referenced and used as a template starting point let me know!

Next update will have the player code broken out, a little code clean-up as usual and the game state implemented.

I can keep adding to it. My concern is the more stuff added the more complex it becomes and the more time required to understand it all. I didn't want to overload people with too much stuff to wade through. But if it doesn't seem like a problem then adding more wouldn't be much of a risk.

Of course, I guess it is reasonable for a person to expect different types of games will have different amounts of stuff to take care of.

For example if I had made something like a basic Star Fox template it would be much less involved. So maybe I need to keep that in mind. Can always make other tutorial style projects in future that are even simpler and those would be better for a new person to start with.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Lance
20
Years of Service
User Offline
Joined: 22nd Jul 2003
Location: Third planet from Sun
Posted: 12th Mar 2018 16:41
Link
In my map editor I am working on I use cubes for walls(5,5,5) , Doors(5,5,1) start marker and end of 'game marker', and also placing .x objects . It is odd to see a cube leave an object but it does the job . I am using some scaled down FPSC .x files and their textures .
The texture selection and .x objects are selected with code from Cliff M.'s "Rolfenstein" programmed in DBP . it's basic code but it works perfectly .

If (GetRawKeyPressed(79 ) =1 // O key or any key you want to use
inc OB // Object or texture number
If OB = 14 then OB = OB-13 // 14 doesn't exist so go back to starting number
Endif

I find doing coding to be relaxing and keeps the old brain working .
Lance

Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 12th Mar 2018 17:05 Edited at: 12th Mar 2018 19:15
Link
Ha ha. Yeah cubes work for a lot of stuff. I think sometimes people get too caught up in making things "look good" when it is not necessary such as an internal world editor. If it is to be a world editor intended for players of the game to use then it makes sense. If it just something internal for development to get things done it is a waste of time to make it "look fancy" IMO.

I went with using Tiled because it is free and something many people may already have and use and if not they probably at least have experience with other 2D Tile Map Editors. And they can make the tiles look as they want them to. Oh and of course because it is my "go to" solution I use tile maps for a lot of stuff. In the end though it's just about having an easy way to get stuff done.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Green7
18
Years of Service
User Offline
Joined: 23rd Nov 2005
Location: Switzerland
Posted: 13th Mar 2018 08:09
Link
Quote: "I think sometimes people get too caught up in making things "look good" when it is not necessary such as an internal world editor..."


I know that problem... its when my artsy side breaks through and i start to fiddle with optics, getting into mr. Monk mode,, loosing focus. maybe it's like: if i can't get it run properly, then at last it looks fancy.
Back to top
Profile PM Website
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 13th Mar 2018 14:51 Edited at: 14th Mar 2018 03:42
Link
Ha ha! It is very easy to do it. I enjoy technical design and programming but... I also enjoy fiddling with visual and audio stuff. And it is something that is so easy to spend hours and hours on and even end up with little change in the end sometimes.

It is a different kind of fun. I do it periodically just as a sort of break from working on game functionality. But I am always on guard to not get sucked into spending a lot of time on it.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 13th Mar 2018 19:04
Link
I think tonight I will start wrapping this up, ramp down development time and probably start visiting the forum less. For maybe the next 6 to 7 months then be back active again. It's just that time of year where I spend more time outside & doing other stuff so don't have much time for game dev stuff. But it is only temporary and sometimes mid summer I get an urge for a week or two to do some game dev.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 14th Mar 2018 01:41 Edited at: 14th Mar 2018 01:41
Link
Dual screen

Attachments

Login to view attachments
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 14th Mar 2018 03:27
Link
Wow that is cool!
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 16th Mar 2018 03:35
Link
I have done a couple of iterations on restructuring the code. Ended up adding a few new files in the process which I hope doesn't make the project seem more complicated than it is and harder to follow.

That's the thing about breaking stuff out. It's great for studying pieces in isolation but can make the overall program / system harder to understand. Thankfully here it is nowhere close to the degree found in OOP with tons of abstraction.

I also added an X-ray vision mode to make the walls transparent just for something extra. Actually I am not sure why really it just popped in my head so I added it. It is handy though to watch the enemies. It also kind of looks like one is inside a structure with all glass walls which is a little interesting I thought.

And at another point I increased the resolution on the health and mana bars to use 20 sprites each instead of 10.




Alright that is it. I will probably get the next update up Saturday if not tomorrow night.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 17th Mar 2018 15:34
Link
Still following this.. It's like watching a good SF series and anticipating for the next episode. Has been lots of fun so far.
Back to top
Profile PM Email Website
Lance
20
Years of Service
User Offline
Joined: 22nd Jul 2003
Location: Third planet from Sun
Posted: 17th Mar 2018 17:01
Link

" Still following this.. It's like watching a good SF series and anticipating for the next episode. Has been lots of fun so far. "

Same here .

Looking forward to the next episode but not the end ..........................

Lance
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 17th Mar 2018 20:09 Edited at: 17th Mar 2018 20:22
Link
Hey @Rick and @Lance thanks for stopping by this thread!

I will put up an update sometime tonight.

Just refactoring the code. Actually be the third pass on it today. Each pass I only do just so much. Making great progress though and is needed. Clean-up the code in general and also get rid of some "bad" practices I used when throwing this thing together (like I had code in the Collectible Manager and Door Manager directly updating the player's inventory adding and removing keys). Of course, I had done it that way originally because it makes for less code, less steps which in itself is a good thing. However, I feel that any given manager's data should only be updated (i.e. managed) by that manager. So that means just adding some functions to the player manager to Add Items and Remove Items to / from the inventory as well as updating the Collectibles and Door Managers to no longer do anything but return a value saying something needs to be added or removed. This way these things get encapsulated. I am not a fanatic about it but I think it will make for a more solid foundation for people to add on. Ultimately, however a person needs / wants to do things to actually get a project done and working is the right way. A person can spend as much time on writing "better" code as they can on making "better" graphics so I try to manage the time spent on this as well.

Anyway an update on the source will be posted tonight. I actually haven't worked on the GAME STATE at all yet. So I guess that will have to wait til the next update after tonight's! But who knows I might knock it out before I post later.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 18th Mar 2018 03:05 Edited at: 18th Mar 2018 05:16
Link
Here is the latest update of the source code.

* Large amount of code refactoring to make a more "proper" structure (not perfect but "better" than it was)
* Updates on lighting
* Double resolution on the player health and mana bars
* XRay Vision mode added to see through walls and doors
* Fixed an issue with floor tiles occasionally appearing much darker than they should




On that last item... there seems to be some kind of bug with InstanceObject(sourceObjectID). Not sure what exactly. But I spent an hour or more just trying to get rid of a weird glitch where occasionally a few floor tiles would appear much darker than they should. It only effected a few tiles in any one run and they were at different locations nearly every run although generally in the same areas. I think it may have something to do with how lighting interacts with instanced objects perhaps. Not sure.

Anyway, you will see in the code that at first I thought perhaps there was some limit for instanced objects that caused the issue so I broke out the single cube into creating several different cubes. One for floor tiles, one for wall tiles, one for ceiling tiles, one for doors and one for the enemies. This did not resolve the issue but I left that in place because I liked it better. Is better to more easily allow the code to be built on.

Anyway, then I simply changed the code so floor tiles (and ONLY floor tiles) do not create an instance of a existing cube object and instead each tile creates a cube from scratch and that resolved the issue.

If anyone wants to see the issue just find that line in the MapManager and you will see the original InstanceObject(cubeFloor) code commented out on the end. Uncomment it and occasionally you should see some random floor tiles appear much darker than they should be. Or possibly this behavior only occurs on certain graphics cards such as mine.

There is always the possibility it is something I am doing in the code but I don't think that is the case. Because if I remove the point lights entirely (tested that at one point too) the glitch goes away. If I set the floor tiles to not be effected by lighting the glitch goes away. And if I replace InstanceObject with creating cubes for each tile the glitch goes away.

At any rate... it is a non issue because just creating cubes instead of instancing resolves the issue. Hence... no issue. But thought I'd share the information anyway in case someone else runs into this same thing.

Okay, that is it. Hope you like the updates. I am not done refactoring the code yet. I will make a couple more passes on that and then add the Game States.

Source is attached. 119 KB

There may be some code commented out and some gibberish in there as I was messing around sorting out that glitch with floor tiles. I will clean it up sooner or later.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)

Attachments

Login to view attachments
Back to top
Profile PM
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 18th Mar 2018 09:04
Link
I've noticed some of these oddities with lights too at times. Perhaps has to do with too many (pixel)lights hitting the same surface at once?

Quote: "
SetPointLightMode
Description
Sets the point light to vertex or pixel mode. Vertex mode is faster but pixel mode has better quality. By default lights are created in vertex mode. A mesh can be lit by up to 8 vertex lights and 4 pixel lights at a time, if you add more lights than this then the closest lights will be used by the mesh.
"
Back to top
Profile PM Email Website
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 18th Mar 2018 18:22 Edited at: 18th Mar 2018 18:45
Link
Hey @Rick. I don't think is caused by a limit on the lights. It is like these certain cubes (which are random, sometimes does not happen and when it does they are different cubes glitching and almost always spaced out at different locations) are getting anti-light. Like light is being removed from them and sometimes to an extreme degree. Sometimes they appear maybe 25% to 50% darker than they should and sometimes are maybe 75% to 90% darker.

I just changed that line creating floor cubes back to using InstanceCubeFloor and sure enough there they are. In fact, one run I got lucky and there were 4 of them 3 of them actually are adjacent. This is just a fluke thing. Usually they are spread out one here one there.

Anyway here are two screenshots to show what I am talking about. One with the lighting from the enemies shots and one without. You can see lighting does effect them still but there is something else going on like the normals are reversed maybe or something. I really don't know. All I know is if I CreateObjectBox instead of Instancing a previously CreateObjectBox the glitch goes away.

There are 3 of these dark cubes right next to each other and there is a fourth over in the corner on the left side. Each are at the same level of brightness / transparency whatever it is.


Here we see they can still be lit fine.


At one point yesterday I built a little system allowing me to modify the floor cube directly in front of me and I tried everything I could think of from setting color to full 255,255,255, with no transparency to shaowbias and other things that shouldn't even come into play... basically every command available in the AppGameKit toolbox for objects... and nothing resolved the error other than when I set them to not be effected by light at all OR deleted that cube and created a new instance of the cubeFloor object. It's like there is some weird thing where just occasionally for some reason an InstancedObject gets whacked. Like I said this behavior only happens when using Instanced objects. When I simply create a cube for each floor tile using CreateObjectBox it never happens.

Anyway, I am fine with it. As long as I can solve it just by creating cubes instead of instancing it is kind of an afterthought but I wanted to mention it because someone else will likely run into this at some point. And hopefully this will save them from time digging into it. From what I could see the solution is simple do not instanceObject there. Why it does not impact walls or ceiling or doors even though they also use InstanceObject I have no idea. This is more the kind of thing for TGC to dig into to figure out. I just look for a solution so I can move forward and then share it on here. Honestly, if I could not solve it I would just call it random generation of dark tiles to change up things visually and leave it at that. lol
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 18th Mar 2018 22:11 Edited at: 18th Mar 2018 22:13
Link
Okay, I decided to work on this again. Knocked out a title screen. I probably should change it though because Mage Quest is a game I actually want to make at some point so maybe I will rename it for this source share here.

Anyway for now (the black border was added on only for the upload here just to make it stand out better against the forum page color)....



That's all I did. I might knock out the info (i.e. how to play / instructions / story type of screen) later. And if I do then I will implement the Game State and Title/Info states to have a functional Title Screen.

More than likely it will tomorrow though.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 19th Mar 2018 00:06
Link
Hmm, that's mighty strange indeed. Perhaps a gfx memory issue or something then.
Looks cool nevertheless.

BTW: dunno if was asked before but what tool were you using for the anim gifs you posted earlier?

Back to top
Profile PM Email Website
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 19th Mar 2018 03:01
Link
Spent some more time messing around with screens. I will need to do them again because I did not notice until AFTER I had taken screenshots that when I created the new HudHide function I did not include hiding the health & mana bars. lol

Anyway... something along these lines...





Okay, well the next time I work on this I will do these "proper" and then add the title screen, etc. etc.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Lance
20
Years of Service
User Offline
Joined: 22nd Jul 2003
Location: Third planet from Sun
Posted: 19th Mar 2018 13:24
Link
I never really noticed the light effects on some of the tiles before . The title / start screen are looking good ..

Lance

Today is the first day of spring
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 21st Mar 2018 20:53 Edited at: 21st Mar 2018 20:53
Link
I did another round of refactoring on the code last night. This time focused primarily on asset creation and release. When I first set out to do this I was used to having to manage things myself and so made functions in each manager to delete models, lights and so forth.

Actually thought about creating a full featured AssetManager at one point for this reason. However, the most awesome AppGameKit 2 api has several single commands to release ALL 3d objects, images, lights, sprites, texts, etc.

So this allowed me to cut out some code!

Tonight I will implement the Title screen which means Title screen with working options to start game, access the Info screen and exit the game. The Info screen will only have the option to return to the Title screen. Start game well of course that will just take you to the gameplay same place as all along.

Shouldn't take long to do this.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 22nd Mar 2018 03:15
Link
Ah well I didn't get to spend as much time on this as I was thinking. Ended up after work getting a haircut and then coming home and sleeping for a few hours. Wasn't feeling so well. Guess maybe something I ate bad headache and stomach feeling blah.

BUT after I woke up I did start on adding the Game State management in and implemented a couple fades as well.



Tomorrow I will give it a try again. This crud should be gone by then.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 22nd Mar 2018 11:32
Link
Very slick looking fades.
Back to top
Profile PM Email Website
Golelorn
7
Years of Service
User Offline
Joined: 20th Nov 2016
Location:
Posted: 23rd Mar 2018 00:39 Edited at: 23rd Mar 2018 00:47
Link
I love this style. Reminds me of Might and Magic/Wizardy/Bards Tale/TSR Gold Box. Feel free to give us newbs some tips.

This world is missing solid games like that. I buy so many 99 cent to 5 dollars games on steam its sad. I just don't care for the realistic approach. I replayed all the Might and Magic games recently when I found them on sale on GoG. I definitely think your style is a lost art.

And, tbh, I don't think its obsolete. My 15 year old son plays the hell out of a few 2d games. He also loves BF, CoD, and Frame(??).
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 23rd Mar 2018 04:30 Edited at: 23rd Mar 2018 04:32
Link
Thanks @Rick and @Golelorn!

I also have many "budget" games in my Steam library. I like those games and supporting those developers.

This should be a solid foundation for people to build on. I am debating implementing that second enemy type. Since I was more thinking of a kind of FPS action adventure and thought it might be helpful to folks I implemented a waypoint system for the enemy.

For a more action oriented game more of a shooter the enemies should be "off the tracks" and basically move sideways back and forth as they approach the player. So I might implement that type of enemy in one of the other areas. And the player could have strafe ability as well although I never used it when I played those games.

Anyway, I worked on it tonight and we now have the working Title screen menu. But I didn't have time to actually post the update. Will do it tomorrow.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 24th Mar 2018 02:48 Edited at: 24th Mar 2018 04:35
Link
Back with an update....

6 MB gif here...


This has the logo splash screen, the working Title screen, Game State implemented and more refactoring of the code. It also has some code no longer hooked up such as a function to take a screenshot during gameplay. The media folder has been structured with more subfolders so it is much more organized now.

I am still not done with the code refactoring but it is getting better with each iteration and overall it is solid now. Just that it can be improved.

I think I might take a break from this for several weeks. Originally I was thinking of winding down on game development but I don't know... I am kind of thinking of doing a tiny 2D game. A break would be good I think because then I can return to this in 3 to 5 weeks and when I look at the code anything that is not clear will stand out more to me so I will know where more comments are needed and will add them. The only thing that is really needed is for the player to die when their health is depleted. I will add that at some point. And possible some audio. Maybe.

I have thought about implementing that second enemy that doesn't use waypoints for movement but I think it might be better to do that as a second project. Like take this project and use it for what it is intended... a foundation to make old school (90-degree walls, keyboard only controls, etc) games. But I could also add in mouse control. And I could take this project and turn it into more of a DOOM style shooter with enemies not using waypoints and release that as a separate tutorial project. And it seems to me the more base template style projects we have for AGK2 the better. So that's something I might do later this year.

Source is attached: 780 KB (sorry about the size but with these full screen images there is not much that can be done about it)

Alright enjoy! And who knows I might still work on this occasionally even if I do start on a tiny 2D game. But right now I think I won't release an update next week.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)

Attachments

Login to view attachments
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-04-19 13:14:59
Your offset time is: 2024-04-19 13:14:59