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
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 13th Feb 2018 09:11
Lance
20
Years of Service
User Offline
Joined: 22nd Jul 2003
Location: Third planet from Sun
Posted: 13th Feb 2018 17:32
I just tried out the latest build . It's really a lot more than I expected . All that is needed are some pickup objects and some sort of fireball/magic spell 'weapon' . Will it be easy to add some animated objects , like a sliding door/panel ?
This project should inspire

Lance
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 13th Feb 2018 19:21 Edited at: 13th Feb 2018 19:21
Mobiius and Lance thanks! And I agree enough playing around with FX and such and time to get focused on pushing things forward.

I will release current build tonight first thing and then start on some gameplay stuff. I might just do the fireball casting. Obviously is needed and I could do the enemies but be more fun (i.e. interactive) to be able to cast fireballs. Then when the enemies go in this fireball piece will already be in place.

It is easy to add anything more or less. The MapManager now has a MapUpdate function that is called from the main loop.

So yes it is a simple matter to add door tile markers and stick doors wherever they are desired in the Tiled map. Then update the area generation to create door objects based on that data. Track the state of these doors (closed, open, closing, opening) and update them as needed based on their state.

Maybe I should add working doors next instead of fireballs. And those doors would basically complete the environment. The whole idea here is I am only adding a little of each thing to show one way to implement it then others should be able to add whatever they want in the same way.

Okay, yes I will do doors in the next update. Then finally onto fireballs. But hey at least doors gets us some interaction. Initially some rooms will no longer be accessible because of course some doors should require a key.
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)
puzzler2018
User Banned
Posted: 13th Feb 2018 21:33
coming together really great..

keep going

GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 13th Feb 2018 21:55 Edited at: 13th Feb 2018 22:48
Thanks puzzler2018. I generally get burnt out when I work too much on a project for too long. But so far that hasn't happened. I've been working at a very relaxed pace and am sure that is a big reason why all is well so far.

Other than uploading current build tonight I will probably do nothing on this. Then tomorrow or next day start on the doors.

I don't know about the rest of you but I need to keep this personal game dev stuff super relaxed & enjoyable. Basically not let it become "a job" because I aready have one of those! Lol

It is enjoyable to sit with a beer and work on things occasionally in the evenings for sure!
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)
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 14th Feb 2018 03:54 Edited at: 14th Feb 2018 05:23
Here is the latest update... the main thing different this time is the updated lighting with the new animated lights.

Area #1 has some glowing lights kind of like ALERT! ALERT! or maybe on backup power...


Area #2 has some flickering lights kind of like power failure in a sci fi game or horror game or changing the light object into a torch for a dungeon crawler style game it should work.


NOTE: If you find it is too dark on your computer you can use some ambient lighting. You will find the SetAmbientLighting in the main.agc file. When I added the lights I set ambient lighting to 0,0,0 (none). Try 32,32,32 or whatever. Keep in mind that I was going for a dimly lit environment intentionally. Some areas are well lit just from having multiple lights around.

However, there are several other changes such as now using an Atlas and sub images for the various textures and a bit of code clean-up here and there. I got rid of the Print statements for the info displayed and am now using Text objects.

Because I textured most things and included the original untextured image as well and of course the Tiled.tmx for designing and so forth the project zip file is now 57 KB.

Project source is attached to this post.

I noticed a "collision with nothing" bug at one point in my testing. I will take care of that next time I work on 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)

Attachments

Login to view attachments
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 14th Feb 2018 19:31 Edited at: 14th Feb 2018 19:31
* Fixed a bug that caused a "collision with nothing" in one room
* Cleaned up the code slightly in the MapManager for activating an area
* Added a tiny amount of ambient lighting


So just use this project instead of the previous one and all should be well.

I am going to take a break from this tonight and maybe tomorrow and then will add the doors. But I wanted to get this up in case anyone is experimenting with it. Be better if you have this fixed slightly cleaner version.
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
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 17th Feb 2018 03:43 Edited at: 17th Feb 2018 03:48
Doors are in!

Started on this a bit last night and did the bulk earlier tonight.

When I added the doors the first test was the states so I had them continually opening and closing.
Taking the step toward player interaction I then made an option to turn on automatic door opening when the player is within range.

You can see the auto doors open at work in this video. At first I approach the door with the option OFF. Then again with it ON.
Press the N key to toggle this on and off. N because I was thinking automatically open when Near the door.


Then added the manual interaction to open a door by pressing E or SPACE.


The doors also check to be sure the player is out of the way before they close.

These doors are all unlocked. The next thing I will add will be collectibles so the player can get a key. Then I can lock one of these doors. Not sure if I will add it this weekend but I might!

Just another note typically I develop by just throwing stuff in and getting things done. Sometimes I spend a game dev session just doing clean-up and my typical approach is every time I am in the code adding something new I also fix any issues I noticed in the other areas and do a bit of code clean-up too.

So there are some other slight improvements here and there in the code and I discovered that when the player headed into a corner (had never done that before! lol) and turned the camera ended up pushed through the wall to see the other side. So that is now fixed.

Source is attached to this post. 64 KB now.
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
Lance
20
Years of Service
User Offline
Joined: 22nd Jul 2003
Location: Third planet from Sun
Posted: 17th Feb 2018 20:53
" and I discovered that when the player headed into a corner (had never done that before! lol) and turned the camera ended up pushed through the wall to see the other side. So that is now fixed."

What more can I say


Lance
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 17th Feb 2018 21:08
I've got some free time here for a bit so am going to start on the next update.

First thing is increasing the size of the tile sheet used for designing the game world in Tiled. I think the 64 different tiles possible in the current tile image can just squeak by enough to get the basics all in but makes more sense to quadruple the size of it now to allow 256 different tiles for designing.

This means updating the map and code as needed. But once is done is done and will have plenty of available tile markers to use.

Then I will make the collectible system and a key and locked door. Maybe not right now but at some point.
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)
hendron
8
Years of Service
User Offline
Joined: 20th Dec 2015
Location:
Posted: 18th Feb 2018 18:36
Looking great. I'm digging the lighting effects, adds a lot of atmosphere. I tend to get distracted designing that kind of stuff in too much detail too early, haha.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 18th Feb 2018 19:35 Edited at: 18th Feb 2018 19:37
@hendron Thanks and trust me I get that completely. It is exactly why I end up putting people off by talking about "wasting time on graphics stuff". lol

It's because it is so easy to get focused on this kind of thing and be stuck there basically forever doing nothing but making models, textures, sprites , tiles, lighting fx, shader fx and so forth and nothing actually gets done. What I mean is sure this is doing something but when it comes right down to it all of this time spent is truly doing nothing to make progress on the game. Meaning there is no more game to play & experience after spending all of this time on this stuff than there was before spending time on it.

It is an easy trap to fall into. And I guess the reason I hate it so much is because for many years long ago I used to do this constantly just working on graphics and so forth and all I mainly had was drives full of experiments trying out graphics and fx. lol

Anyway sorry for the ramble you just hit on something that is very important to me. I still wrestle with it at times. For years I just ditched it completely and wanted to focus no time on presentation. Now I'm trying to go for more of a balance. Get some real stuff in making some progress. Then do some facelift stuff. Then do more work on the game side of things. Then do more on the looks again, 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)
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 18th Feb 2018 19:47 Edited at: 18th Feb 2018 19:49
Okay, back with another update.

I expanded the size of the tiles image as mentioned previously. Now there is plenty of room to add many different tiles for designing the game world.


I added some new tiles for blue and red doors. And I added new tiles for blue, red and yellow keys.

Then I updated the Tiled map to change one of the normal (gray) doors into a blue locked door and changed another into a red locked door.
I also added some collectibles... only keys at this time. There is one blue key, one red key and one yellow key in the first area.

I updated the MapManager to handle these new red and blue doors and to handle populating the new collectibles.

Then I updated the door system to handle doors being locked. And updated the main module so the player now has an Inventory and so far it contains only a KeyCollection.
Then I implemented the collectible manage, door manager and main to handle collecting keys and unlocking doors.

I also updated the player movement so there is now some bobbing up and down motion when moving along walls depending on the distance being covered. If moving slowly there is no bobbing.

So here I am collecting a blue key


And here I am using the blue key to unlock the blue door


NOTE: Doors do not auto-unlock if you have the Auto-Open option turned ON. You will need to manually interact with the door by pressing E or SPACE. If you have the appropriate key the door will unlock and open.
Once a door is unlocked they will automatically open if you have the Auto-Open option turned ON.

Source is attached. 74 KB now.
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
hendron
8
Years of Service
User Offline
Joined: 20th Dec 2015
Location:
Posted: 18th Feb 2018 19:56
Quote: "Anyway sorry for the ramble you just hit on something that is very important to me."


No worries, I 100% agree. I have to force myself not to get distracted by it. I guess it's just very easy to get excited by visuals. But what's the point when all you get from those visuals is some screenshots and nothing else? With the project I'm working on currently, I'm only focusing on the core mechanics and getting them to a working state before I even think about creating any kind of non-temporary media.
Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 19th Feb 2018 20:33
Looks nice gar
I use raycasting to open and a simple distance check to Close.
The same for my enemies.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 19th Feb 2018 21:03 Edited at: 24th Feb 2018 00:48
That is basically about exactly what I do. For navigating in general I use spherecastslide and for things like doors, collectibles etc I just use simple distance checks. I like to keep things simple. When I do fireball casting tonight I will use spherecast for doors and static objects. Enemies will be distance checks.

I am making this whole thing ad hoc on the fly as I do it. If I did it "proper" I would allocate a range of object ids to floor, another range of object ids to walls and so forth. And what that would do is make it so when I get the objectID from a cast I would know exactly which kind of object was hit by simple comparison of the id against the low and high ids in the various object ranges then would call the appropriate object management routine with ID-LowestIDForThatParticularSetOfObjects which would correspond directly to the index to use for that managers array.

But this tutorial project is all just for fun playing around nothing serious.

I develop very iteratively so it is possible before this is finished I will update all of the code to switch over to using object ID ranges. And I might not. Depends on when I get bored with it all I guess. 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)
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 19th Feb 2018 22:01
Looking good. Like the lighting effects, very atmospheric.
Now we need a voice over: "All prisoners should remain in their cells."
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 19th Feb 2018 23:04 Edited at: 19th Feb 2018 23:05
LOL! @Rick thanks and I agree. I personally put much more importance on sound fx than graphics for bringing a game to life. Sounds really style a game and are powerful feedback.

With the alarm / alert lights maybe "WARNING! WARNING! ... portal to alternate earth has opened"

I will focus on audio at the end.
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)
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 20th Feb 2018 03:20
Fireballs are in... or magic missiles if you prefer... I don't care what they are called but either of those sounds better than saying flying magical damage thingamabobs.

As usual I also fixed some issues I found in the last version. You should know by this point this is basically how I approach game dev. Throw some stuff in. Call it good. Next time add some new stuff and while testing the new stuff I sometimes run into issues with previous updates that I did not find when I set out to test them so I fix them as I encounter them. So basically everything progresses with new features and the whole thing gets more stable and "better" as well.

This shows the impact when the fireballs hit something.


This should better show them traveling.


As usual full source is attached. 78 KB now

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
Lance
20
Years of Service
User Offline
Joined: 22nd Jul 2003
Location: Third planet from Sun
Posted: 20th Feb 2018 16:40


Great balls of fire
I follow this thread every day ...................................
Lance
PHeMoX
6
Years of Service
User Offline
Joined: 9th Jan 2018
Location:
Posted: 20th Feb 2018 17:42
This looks pretty exciting indeed! I really dig the old school stuff. Keep up the good work, looking forward to seeing some gameplay in this soon hahah.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 20th Feb 2018 18:04 Edited at: 20th Feb 2018 18:10
Thanks Lance and PHeMoX.

I agree... normally in a game project I would have it playable by this point with everything plain un-textured simple geometric shapes and no lighting fx.

This time I am trying for more of a balance of providing both functionality and some decent amount of "looks" but nothing time consuming. It is all just very fast to implement simple visual flair.

It is inching forward to playability. In fact it already has some in the form of simple lock & key puzzles. Go here to get this key now can access this room and get another key allowing access to another room. That is a core element of these old school games.

We have finally made it to the part most of us have probably been looking forward to. Blowing stuff up. Of course it will be done incrementally and iteratively same as everything up to this point.

Next update I will add enemies. First will be just getting them to populate standing still and have collisions working between player & enemies and collisions between fireballs & enemies.

The update after that will work on basic enemy behavior of patrolling / roaming etc.

The next update will focus on reacting (perhaps fleeing when near death etc or if highly aggressive engaging as soon as they spot the player... meaning they "target" the player and moving toward player into combat range).

Then finally an update focused on their combat behaviors.

Bit by bit (incremental & iterative) is how I develop. But we are finally at this point now of adding some baddies to the game world.
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)
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 20th Feb 2018 19:03 Edited at: 20th Feb 2018 19:08
Funny: you're also using lights for effects on the walls, a trick a picked up from Jeppe Nielsen (a Danish? Blitz3d coder) who was using vertex color to accomplish this.

I was a bit disappointed at first when using AGK's CreatePointLight in vertex mode because that didn't do what I expected.
Then I tried pixel mode using SetPointLightMode and the effect was much better.

I therefore concluded that vertex mode is more suitable for explosions.
Especially when using something like CreatePointLight(explosion[expcount], expx#,expy#, expz#,200,1255,1255,1255) , which oversaturates the colors, but is faster then pixel.

I must point out though that I'm using the physics scale so all is oversized int my game world, so don't know if works the same for all situations.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 20th Feb 2018 19:10 Edited at: 20th Feb 2018 19:11
Yeah the point lights are such a super easy way to add some visual pizzazz. This is why most games in Unity, Unreal Engine, etc have some "extra" visual appeal simply due to people almost always making use of simple lighting and / or shader FX.

Any visual flair here in this WIP is very basic I mean truly it is simply point lights period. I spend just enough time to add some visual pizazz and no more. And it is all very simple stuff as can be seen in the code. It is just the 3D lighting the engine takes care of.

Of course, for things like fireballs / magic missiles and explosions one could add particles to really add to the presentation but I leave that up to anyone interested in doing so. For me this is more than enough visual flair and what is needed is some fun gameplay!
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)
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 20th Feb 2018 19:21
Looking really good, very impressive how quickly it's coming together.

There's some really nice stuff coming out in AppGameKit these days, some impressive things coming fast, and this is right up there.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 20th Feb 2018 23:12
Thanks Santman. It is all pretty simple in reality. Just a simple game world, moving around in 1st person view, shooting fireballs and so forth. I appreciate your post though!

Really AppGameKit 2 just makes game dev so simple... I mean I find it to be so logical and straightforward to work with it truly is one of, if not the, best rapid game development environments I have ever used. Reminds me a lot of AMOS and Blitz Basic.

I never spend time fighting AGK2 and everything just seems to work as I expect it to. This tutorial project has taken maybe 20 hours or so at this point.

Like adding enemies... all I need to do is create some tiles to represent an enemy or two and probably have 4 of them to indicate which way enemy faces when created. Then add an EnemyManager to define the max # enemies per area, am EnemyType and an array to store / track these enemies. Update the MapManager to process enemy creation in a given area and that is it. I mean maybe 20 minutes or so total.

Then I will implement collisions and tweak a bit.

So basically tonight I may spend 1 hour and there will be enemies standing around not "alive" yet but there and can be collided with and fireballs can hit them.
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)
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 22nd Feb 2018 03:32 Edited at: 22nd Feb 2018 03:33
I got the enemy's appearing in the game areas last night. That is all I did.

Kind of taking a break tonight so all I did was create the tile markers to define paths, added a new layer to the Tiled map to design the paths by placing node tiles and then added a skeleton PathManager file and updated the MapManager to process the path layer and define the paths accordingly.

That is all I am doing now. Time to play some Diablo 3 I think.

Next time I work on this tomorrow or Friday I will update the enemy creation function to check to see if an enemy is in a cell with a path marker in the new path layer... if so its PathID and PathNodeID will be set accordingly. Then it will be a simple matter to get them roaming around on their predefined paths. Not really sure how that will work out for a game like this and thought I would give it a try. I think as long as the behaviors are implemented well enough it might just work. Such as having them occasionally choose to stop when they reach a given waypoint and look around for a bit before continuing on, etc.

My main concern though is combat. I am used to implementing enemies as little virtual beings that scan their environment and roam around and attack and such without being locked onto set paths. But it will be a fun experiment to work on anyway. I think I might make a combat path layer that allow movement around each patrol node. But we will see. Might not be needed and I do prefer to keep things simple. It is way too easy to make things complex and simple is best IMO. Especially for a tutorial style project such as this.

Alright that is it. Once the enemies are roaming around I will post a code update. Now I am off to slay some monsters in D3.
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)
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 23rd Feb 2018 16:04 Edited at: 23rd Feb 2018 16:12
I've had a nice break. I did dabble a little adding PathID and PathNodeID to the Enemy type and the enemies now... if they are in a cell with a path node (aka waypoint tile)... have their path and current node within that path set at the time they spawn.

My brain is pretty refreshed (taking time away even if it is just messing around with other development or checking out peoples code on here such as shaders, games, helping people on the forums, etc just getting away and thinking about something else is really important IMO to prevent burnout and keep development fun). So I am looking forward to implementing enemy movement around the paths tonight.

It will probably be several hours in full for this because although conceptually very simple I have at least 3 different ways in my head to do this and will implement at least 3 different versions testing each to see which I find best for achieving the goal with ease of use and high code clarity.

So maybe expect a new update tomorrow with the outcome of my tests.
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)
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 23rd Feb 2018 17:03
really liking this project man, nice work
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.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 24th Feb 2018 20:39 Edited at: 24th Feb 2018 21:19
Thanks Ortu! I've been enjoying it. A lot of fun.

Okay, just a progress update here. I didn't spend as much time on this project as I was thinking I would so I only implemented one of a few variations I was thinking of for the enemy waypoint system.

However, the good news is the very first one turned out to be very solid.

Waypoint system is implemented and the enemies happily roam around from node to node on their path (they find their path by checking if a path node is at their starting location... so basically drop an enemy onto a path node and like a little train it will take off lol).


When they reach one of the two ends (start or finish) of their path they reverse direction.


And here is just a different view showing two enemies each patrolling on their own path. Sorry for the quality... due to the glowing "alert" light I had to shrink the image, reduce the framerate to 10 fps, reduce the colors down to only 32 and then turn on 20% optimization just to get it down to this file size (2MB+). I probably should have changed the lights to static lights would have made a big difference on the image size and I could have increased quality and maybe even size. I will do that later when I release the code.


I have not attached the updated code here yet because I might experiment with variations later. At any rate, I expect I will release this project source update tonight for sure.

Now it is time to get off the computer again. Take a break. As I am sure you know it is not just the work of development but just making video recordings, converting clips into gif animations uploading to image storage etc... well I spent a bit over 1 hour just doing that work to get the 3 gifs above! So yeah it is time to get off this thing. 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)
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 25th Feb 2018 03:12 Edited at: 25th Feb 2018 03:14
Okay, I stuck with what I had for the waypoint system. It works fine so figured why spend the time.

I am interested in experimenting with the tweening system in AGK2 at some point though. I was thinking about making a variation of the waypoint system that used that but I don't think anything would really be gained from doing so. Could be wrong. I will do some experiments another time.

Anyway, let's get on with this update. The waypoint system for the enemies is quite simple as you can imagine.


There are tiles defined to create 2 different paths. If more than 2 are needed in any one area (which certainly they would be in a real game) just create more tiles for those paths.

Defining paths is easy enough. In the Tiled WorldMapOnlyForDesigning.tmx map there is a new layer for setting waypoints. Just set the waypoints as needed. As always, any changes to the Tiled tmx map need to be copied from the WorldMapOnlyForDesigning.tmx file over to the WorldMap.txt file actually used by the program.

A new file PathManager has been added

This file declares two new types


and a new global of TPath is declared


The MapManager file has been updated to process the new layer and populate this MapAreaPaths array. So pretty simple stuff. We have a node (waypoint) type and each TPath has an array of waypoints.

The PathManager has various functions to make working with the waypoint system simple.

And of course there is now an EnemyManager file that handles updating the enemies and uses the PathManager as needed to navigate from waypoint to waypoint. Following the same pattern, the array of enemies is populated in MapManager.

And of course the DeactivateArea function in MapManager has been updated to handle deactivating paths and enemies.

I also updated various other bits in the code. Player movement is no longer under a timer. This makes movement smoother and works better at very low framerates. Turning is still under the timer because we need that coarse turning since it is via keyboard control and makes it much easier to aim the player where we want them to go.

I made a slight change to the lighting, fixed a few places in the code that did not take the FrameTimeScale into account and so forth. I also worked on improving the impact FX of the fireballs hitting objects to make it more noticeable. Overall as usual it has some new stuff and the old stuff is a bit better.

I want to have two enemies in here and did the basic work to support that. The two enemy types are slider and hopper. But only 1 (the slider) is actually implemented in this update. The other enemy will just be a different colored cube (and perhaps different dimensions). This second enemy will move by hopping instead of sliding.

That second enemy I will work on in the next session tomorrow night or Monday. I don't know exactly.

Anyway yeah so that is the update this time around.

As usual full source is attached. 90 KB now
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
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 26th Feb 2018 03:34 Edited at: 26th Feb 2018 03:36
Thought I'd do some clean-up fixing some things here and there that I noticed in my testing and improving some things a bit here and there.
Fireballs now have a lifespan and time out after 4 seconds. Other bits here and there.
Also added a hit (damaged) indicator to the enemies and then added health and applied damage to them when shot.
I didn't implement any death animation or other kind of FX but did make them deactivate when they are "dead".

So think of this as a maintenance update just to make everything a little better.

Full source is attached. 91 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
Lance
20
Years of Service
User Offline
Joined: 22nd Jul 2003
Location: Third planet from Sun
Posted: 26th Feb 2018 15:19 Edited at: 26th Feb 2018 15:20
I just tried your last 2 examples . I liked the enemy path following and getting them with the fireball , going full screen , collecting keys for the doors and the lighting . Adding enemy firing back and some sound effects along with scoring and health and of course a win zone would finish off the 'game' .

I like your coding style , very neat . It made me go back and rename a lot of my variables to full names in my map editor I'm making to something more than a few letters . Inspired me into adding pickup items and a little lighting too . My coding looks like spaghetti .........................

Keep up with the project and I hope AppGameKit would add it to their sample projects . This is a must for beginners and others that never did 3D old style games .

Lance
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 26th Feb 2018 15:45 Edited at: 26th Feb 2018 15:45
Thanks @Lance I appreciate the support!

Yeah it is getting close to being able to focus on wrapping it up. While it certainly won't be a full game ready for release of course that was never the goal.

The next dev session I will implement the enemy combat behavior. Get them evading / engaging etc.

Ha ha. Yeah on the long variable and function names I like to spell things out to make it clear what something is for. When I first moved from C64 BASIC to Assembler long ago I found it much easier simply because I could use descriptive names for variables (well memory locations storing data) instead of being limited to 2 characters (which was crazy IMO) and jmp/jsr labels instead of line numbers.

So I have stuck with that as much as I can ever since. I think programming in such strict limitations like that in those early days made it much easier to move to C/C++ etc. I mean when even Assembler offers more freedom in programming you know that old BASIC was very limited. 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)
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 26th Feb 2018 20:45
Why not just upload the video to YouTube and embed the player here?

Having the gif auto play is nice, but seems like you could save yourself some time and effort
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.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 26th Feb 2018 21:02 Edited at: 26th Feb 2018 21:03
I've thought about that Ortu. Normally I do just make dev videos of my stuff and put on YT. I don't know just thought it be nice to do something different for this one I guess.

You are right though it would be some less effort & time needed. I will probably stick with gifs on this just for consistency and then switch back to YT videos the next time I do some development thingamabob. This one is coming to an end soonish so might as well stick with gifs.
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)
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 26th Feb 2018 21:09 Edited at: 27th Feb 2018 18:14
Actually I think about all that is left for this project is...

* Enemy behavior... combat state attack and evade.
* Player health and being damaged by enemies
* Player death... nothing much probably text YOU ARE DEAD.
* Player health collectible.
* Add one more special door requiring the yellow key.
* When player opens the yellow door they teleport to the second area.
* Refactoring cleaning up code etc.

I think that is all really. I mean this kind of thing can go on forever until it is ready for an actual production release but that is not the point of it. Lol

I probably don't need to do the code refactoring because I have followed my normal patterns to a large degree but at same time I also disregarded them at times in the interest of just getting things done.

Not a major deal but some functions need to be split out because they are doing too much work. And global arrays need to have their access managed. This is done to a large degree but there are opportunities for improvement I am sure. Even though when it comes down to a choice of having to either spend time on code quality or actually getting things done I will err on side of actually getting things done about every time... I do value code quality.

There should be a PlayerManager and the player code moved out of main. Possibly a ResourceManager for the texture images etc.

So definitely some code clean-up would be nice.

Sound FX... I thought about doing that at the end but not sure I will bother. I mean that is something so straightforward I think most people can sort that out easily enough to load some sounds and play them when they want to. I *might* add an AudioManager and some very simple sound fx (i.e. sounds I make such as grunts, growls, pew pews, ouches and so forth into the mic) but not sure.
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)
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 27th Feb 2018 15:23 Edited at: 27th Feb 2018 15:24
Was going to take last night off but I ended up putting 15 mins or so in to implement a very simple evade response for an enemy being hit. Very straight forward and definitely brings them to life much more when they receive damage the switch direction turning around on their path and their movement & turning speed is boosted significantly for a few seconds. So basically player sees them get hit, they quickly turn around and zoom off back the way they came from.

Next will be to have them go into attack 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)
hoyoyo80
7
Years of Service
User Offline
Joined: 11th May 2016
Location:
Posted: 28th Feb 2018 03:06
Nice one...I love it!!!

Always dream to make an openworld rpg with pixel art, but the most challenging part is how to make the story interesting and balancing player(party) stat.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 28th Feb 2018 16:27 Edited at: 28th Feb 2018 16:28
Thanks hoyoyo80 glad you like the project.

For sure gameplay experience is the most important thing for a game... mechanics, story, feedback etc. I'm just focusing on the engine / general game dev side here for tutorial purposes.

Hopefully it can be a starting point for someone or at least help in some way on the technical implementation side of things. It is definitely not the best technical implmentation either but it is solid enough to build a game around.

Going to movies to watch Black Panther tonight so probably be tomorrow before I start on enemy combat behaviors.
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)
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 1st Mar 2018 08:39
Impressed by the lighting. Textures, especially on the ceiling, almost look like there's some normal mapping going on..

GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 1st Mar 2018 15:57 Edited at: 1st Mar 2018 16:45
Thank AGK2 / TGC for that Rick! Lol

Nothing but quickly scribbled textures and point lights here. There are multiple textures for each of floor, ceiling and walls just to allow for some variety but so the only difference between them is the brightness. Actually I might have slightly changed the scribbles from one texture to another in a set at one point. Don't remember now.
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)
puzzler2018
User Banned
Posted: 2nd Mar 2018 21:17
Happy Birthday GarBenjamin
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 2nd Mar 2018 22:54
Thanks @puzzler2018. It has been a very good day. Getting back to this project shortly.
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)
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 2nd Mar 2018 23:09
Quote: "Happy Birthday GarBenjamin"


Apparently it's your birthday so congrats!
Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 3rd Mar 2018 19:03 Edited at: 4th Mar 2018 16:23
Thanks for the birthday wishes. I had a great day. Took off work yesterday for my birthday holiday.

Alright I almost kept on working on this and thought whoah... I need to stop and get an update up. I think there is some value in updating here kind of of step-by-step. So too much doesn't go in from one update to another. Should make it easier to identify changes. But then again considering my development style of adding new stuff and then refactoring old code a bit, fixing or enhancing previous work maybe not.

Anyway... the enemies go into reactive combat now. Meaning if you should them they target you.


Originally I had the enemies fire in a straight line and this what the timer in the code for their firing was for. They would target the player, fire a shot... tiny delay, fire another shot.. tiny delay... until they fired 3 or 4 shots. That worked well. Then I implemented some random spread the trajectories of their shots and thought that was a bit more interesting. And then I just gave them a spread shot. Although they still shoot each "bullet" on a different frame.


Refactored and otherwise cleaned up the code a tiny bit here & there. Updated the "bullet" impact code for both the player's fireballs and the enemies magic shots. This was partly to fix a bug with the light fx not working in some cases. And while working on that decided to improve it a tiny bit.

Then I added a 3rd area which can be teleported to but nothing is there yet... not even a ceiling. Could it be an outside area? Anyway nothing in that area yet... like I said, I thought I should get this up.

The next step would be for the enemies to take the initiative in engaging the player in combat. It wouldn't be bad to have an enemy that leaves you alone if you leave it alone but even in that case once you attack it should pretty much stay aggressive toward you. To make it an effective obstacle that is.

Full source is attached. 99 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
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 4th Mar 2018 05:00 Edited at: 4th Mar 2018 05:02
Okay, I did another update. When I was testing the enemies' reactive combat behavior update earlier I noticed the fleeing behavior was never completed in that all it did was cause the enemy to always reverse direction when damaged.

This resulted in an enemy that was already moving away turning around and fleeing toward the player which definitely is not what should happen.

So I just made an update to correct that and also fixed one case where the enemy wasn't turning around and instead when it reached the end of a path was just reversing direction.

Now it should be at a good point to focus on finishing off (well at least the first pass) the enemy's proactive combat behavior. Meaning it engaging the player without needing to be hit first. That will be my focus the next time I work on this project.

Source is attached. 99 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
Lance
20
Years of Service
User Offline
Joined: 22nd Jul 2003
Location: Third planet from Sun
Posted: 5th Mar 2018 23:39
Late Happy Birthday

Just tried your last update . Nice to see the enemy's shoot back . Glad they couldn't kill me , yet ..

Lance
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 6th Mar 2018 00:09
Happy Birthday and great work. Very much a learning experience for me

Login to post a reply

Server time is: 2024-04-25 10:24:47
Your offset time is: 2024-04-25 10:24:47