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/AppGameKit Studio Showcase / Retro Game Fantasy Computer Framework

Author
Message
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 25th May 2020 21:27 Edited at: 2nd Jul 2020 00:40
Just wanted to make a thread for a project I have been working on for the past 11 days.

I have tried many different game dev frameworks and engines including most recently buying an ARDUBOY handheld game console and making a game for it and then purchasing the PICO-8 fantasy console and making a game for it.

I liked development on those. I really like the fantasy computers and game consoles a lot. They are incredibly well done but anyone who works with them will find their projects will grow beyong what can be done in those systems.

After some time, I thought what I really want is a way to make AppGameKit development be much closer to development on those fantasy computers & consoles. I thought one of the big differences is the fantasy machines all come with built-in sprite editor, map editor, sound fx editor and music editor. All content created with those built-in editors is readily available in your program. There is nothing you need to do except start referencing the content.

So I fired up AppGameKit and started working on a sprite editor and a system to easily work with the images produced by it.

The Sprite Editor is complete and makes a huge difference for me personally.




But I wanted to go further. I thought... I might not want to get into trying to create some self-contained fantasy machine BUT what I could do, and think would be much better, is to create a fantasy machine framework.

For the past 4 days I have been working on this.

So... let me introduce...

Retro Game Fantasy Computer Framework


The Retro Game Fantasy Computer is a fictional machine that was released(not really) at the end of the 80s taking 8-bit power to the extreme! Unfortunately, companies had brainwashed people into thinking 8-bit was dead and "the cool thing to do" was to get a 16-bit machine.


The Retro Game Fantasy Computer Framework supports two resolutions.. 256x144 and 160x90.
It has 10 different built-in palettes of 24 colors each.

Incredibly, it has 256 sprites available...
8 sprites that are 32x32 in size.
32 sprites that are 16x16 in size.
80 sprites that are 8x8 in size.
There was some space left in there so the engineer decided to make use of it.
For this reason, the system also has 136 sprites that are 1x1 in size... aka particles.


Here is a sample game I made using the Retro Game Fantasy Computer Framework system...

Here is the game in 256x144 mode...



And the same game running in 160x90 mode...





The way this all works is sprites use shared spritesheets. Each spritesheet holds up to 256 images.
When loading a spritesheet (or tilesheet) you specify the sprite size and palette (one of the internal 10 pre-defined 24 color palettes) that corresponds to the spritesheet.
Retro Game Fantasy Computer Framework will load the spritesheet and set up everything automagically.

BUT... it goes beyond this! You see Retro Game Fantasy Computer Framework doesn't limit you to just one spritesheet total.
The 8 32x32 sprites have their own 512x512 spritesheet holding up to 256 images associated with one of the 10 palettes.
The 32 16x16 sprites have their own 256x256 spritesheet holding up to 256 images associated with one of the 10 palettes.
The 80 8x8 sprites have their own 128x128 spritesheet holding up to 256 images associated with one of the 10 palettes.

As you can see this system provides a lot of power. Now you are able to have up to 768 unique sprite images available at any moment.

In addition, as you have probably realized, this also means the total number of colors displayed on screen can be increased as well.
You can use a different palette for each of the spritesheets!
24 colors (really 23 because one needs to be transparent) for the 32x32 sprites.
24 colors (really 23 because one needs to be transparent) for the 16x16 sprites.
24 colors (really 23 because one needs to be transparent) for the 8x8 sprites.

While it is recommended to choose one palette and use it for all of your sprites for cohesion you can, in fact, have a total of 69 colors displayed on screen with your sprites.

Likewise, the tilesheet also uses one of the 10 palettes providing another 24 colors.

Basically, the easy way to look at this is... use one palette for your sprites and a different palette for your tiles. Again, you may want to use the same palette for both for cohesion.

One thing you might be wondering is...
What happens if someone makes a spritesheet outside of the Retro Game Fantasy Computer Framework Sprite Editor?
The palette could be completely different from the 10 built-in Retro Game Fantasy Computer Framework palettes!

Yes that is true. So what happens is when you ask Retro Game Fantasy Computer Framework to load a spritesheet it checks the colors in the spritesheet and if they do not match the colors in the palette you specified... Retro Game Fantasy Computer Framework remaps the spritesheet colors to the specified palette.

Obviously, this is not the ideal way to work. Just use the Retro Game Fantasy Computer Framework Sprite Editor for best results. But still... Retro Game Fantasy Computer Framework does make the spritesheet compliant with its "hardware".
The images on the left are some screenshots of Public Domain Amiga games that contain up to 41 colors.
The images on the right are the same images after Retro Game Fantasy Computer Framework remapped them to palette 0.



Let's get to the heart of the Retro Game Fantasy Computer Framework system...


With these computers and consoles of the 80s, sprites do not need to be created. They already exist and are managed by the machines.
The same is true for the Retro Game Fantasy Computer Framework. The 256 sprites already exist and are managed by the system. They do not need to be created.

This and other similarities to machines from long ago all help to make the game dev process more straightforward.

Another way development is made easier & faster is the readily available editors. Currently, the Sprite Editor is done.
It has the same 10 palettes built into it and creates sprite sheets exactly the size the Retro Game Fantasy Computer Framework needs.




The Retro Game Fantasy Computer Framework system (and tile map world editor) will support tile maps of 256x144 cells.
For 8x8 tiles this is 8x8 (64) screens worth of world space in 256x144 mode and 12x12 (144) screens worth of world space in 160x90 mode.
For 16x16 tiles this is 16x16 (256) screens worth of world space in 256x144 mode 25x24 (600) screens worth of world space in 160x90 mode.
For 32x32 tiles this is 32x32 (1024) screens worth of world space in 256x144 mode and a massive 50x48 (2,400) screens worth of world space in 160x90 mode.

In addition, each of these tile maps has 4 layers. 3 layers are for display (although each can be hidden) and the 4th layer is not displayed by the Retro Game Fantasy Computer Framework.
This 4th layer is a marker layer. Sometimes called tokens and also referred to as simply the "logic" layer.
It is here where you can stamp tiles that represent enemy positions, area boundaries and so forth.

There will be a tile map world editor available in the coming weeks - THIS NOW USES THE TILED MAP EDITOR WHICH IS AVAILABLE FOR WINDOWS, MAC and LINUX..

As you can see... the Retro Game Fantasy Computer Framework provides enough tile map world space to support the most ambitious projects.

Besides... there is nothing stopping you from creating multiple sprite sheets and tile maps. After all, you are programming the Retro Game Fantasy Computer Framework system in AppGameKit using the Retro Game Fantasy Computer Framework API. This means you can have a sprite sheet and perhaps a tilemap for your title screen. You can have a sprite sheet and a tile map world for each level of your game.


The Retro Game Fantasy Computer Framework Framework is how we develop games for the fantasy machine.

Implemented in a single file, the system contains everything I need to make 2D retro game development easier and faster.

The API is very comprehensive and continues to be expanded since I will doing all of my development in the Retro Game Fantasy Computer Framework Fantasy System going forward.


Well... that's it! This is what I will be working on until I get it all completed.

This is one of the most enjoyable projects I have worked on in a long time. It is the kind of thing I have wanted for years.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 25th May 2020 21:27 Edited at: 2nd Jul 2020 00:40
The Retro Game Fantasy Computer Framework Text Grid System

Every system needs a way to display text and Retro Game Fantasy Computer Framework does as well.

Retro Game Fantasy Computer Framework can display most of the standard ascii characters...
!"#$%&'()*,-./0123456789:;<>=?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

In fact, it offers 3 text layers each handling text of a different size.

Each of these layers is a grid.

Text can be written into a grid by specifying the x,y, color and the text to write.

In addition, color can be set for any row of any grid, for any column of any grid and for each and every cell independently in the grids.

The smallest size text is on the the front most layer, the medium size text is in behind it and the large size text is behind the medium size text.


Here is what it looks like in 256x144 mode...


and 160x90 mode...


Viewing it that way is a bit of a mess so here is each text layer in each mode.

Large Text in 256x144 mode has 4 rows of 8 columns and 160x90 mode has 2 rows of 5 columns each...


Medium Text in 256x144 mode has 9 rows of 16 columns and 160x90 mode has 5 rows of 10 columns each...


Small Text in 256x144 mode has 18 rows of 32 columns and 160x90 mode has 11 rows of 20 columns each...


The font sheets can be updated as you see fit. The above just shows the default fonts that come with Retro Game Fantasy Computer Framework.

The important thing is displaying text is super easy as is making simple retro style color effects by changing the colors of entire rows, entire columns or individual cells in a sequence, etc.

I'll almost certainly add a method to set the x & y offsets for these text layers because I think it is likely at times I will want to display text only in the center of the display.


May 27th update

I implemented positioning of the rows and columns of text.

And I added the Divider Overlay.


Here is a short sample that should better illustrate the power of the text system...
Oh! I also updated the small font and made the medium and large font (shown here) just scaled up versions of the small one. It works for now anyway...


The Divider Overlay
The main thing here is that little divider overlay sitting at the right side of the screen.

Of course, it is very common in games to have some kind of status panel area. Sometimes these sit on the right side of the screen. Other times at the bottom. And occasionally you may even see one on the top or left side of the screen.

My focus is on building Retro Game Fantasy Computer Framework based on my personal experience with classic games both as a player and a developer. So the major things that were used in classic games are things I want Retro Game Fantasy Computer Framework to support.

The divider overlay is a very simple yet somewhat clever thing if I do say so myself.

In 256x144 mode (used in in the example above) the Divider Overlay is a 128x72 image. That is 1/2th the width and 1/2th the height. In 160x90 mode the Divider Overlay is an 80x45 image.

Initially this D.O. image is completely transparent and disabled.

So, what is it exactly? Well each pixel in this image represents a 4x4 pixel area of the screen. This gives us a resolution of 2x2 pixel chunks to design the Divider Overlay.
You do that by using colordiv(x as integer, y as integer, w as integer, h as integer, colorindex as integer) to color in rectangular sections.


To enable it you simply call enablediv(). And if you want to adjust it later on just call resetdiv() to reset it to a completely transparent image.

This D.O. is scaled up 4x so the 64x36 image becomes an overlay of 256x144. I will probably implement a flashing fx for the D.O that will make it toggle between half brightness and normal. I think that would be great for alerts and such.

Retro Game Fantasy Computer Framework's text all appears in front of the Divider Overlay and that is exactly what is displaying the Score and Lives using the smallest Retro Game Fantasy Computer Framework font.

The point here is that I could have easily defined an overlay around the entire screen or even split the screen up into 4 quarters. I could easily make the section appear on the left side instead of the right. Or even build it on the top or bottom.
And this is one time process. Just build the Divider Overlay and it is done always there. If the level is complete and you want to show a mini cut scene or something just call g42disablediv() if you want it to go away.

A fancier D.O can be created like this...


But again it is only one time this needs to be done and then we have the Divider Overlay. And it is enjoyable to work in the constraints of limited resolution retro style and make things appear more interesting.

Oh yeah I updated it to pass in two colors now. I am obviously passing in the same color. Had I passed in both the drawing would have alternated between the two colors.


Retro Game Fantasy Computer Framework Built-In Color Sky and Ground Shading

Back in the day colorful games was a big thing. From the humble 2600 to the Amiga copper fx... colored lines the width of the screen were used to create sunsets, skies or other simple colorful backdrops.

Retro Game Fantasy Computer Framework provides two backdrops that can be used to help add a bit more color to your games.

Each backdrop contains only 4 colors or 4 shades of a single color. There are 8 predefined backdrops for the sky and 8 for the ground. However, both sets can be used for either.

The term backdrop may be a bit misleading because these can actually be placed on the very back layer behind where tilemap graphics are displayed OR they can be placed immediately behind the default layers used by the 256 sprites.

These actually tint whatever they are placed over. So, if the backdrops are placed over a black background they will appear darker than if they were placed over a blue background and placed over a white background they would be brighter still.

Here are examples showing all 8 backdrops for the sky and the ground. The top half has a sky color backdrop and the bottom half has a simple grayscale gradient.




And this is the simple background they are over.... just too help illustrate the difference being over darker vs lighter colors makes.


Again Retro Game Fantasy Computer Framework provides these only to make it super easy to throw up a classic style gradient backdrop and it provides a way to get an extra 8 colors (or shades) out of the "hardware".
Because they interact with whatever they are placed over there are a large number of options. In its simplest placed over a single Retro Game Fantasy Computer Framework color you'll get 4 colors/shades provided the area is big enough to show that many.

These are interesting things technically. Internally, each of these backdrops is only a 1x32 pixel image and the entire set of 16 fits inside a 16x32 image that Retro Game Fantasy Computer Framework creates. When used they scale to the width of the screen and their height is controlled by you as are their starting ypos.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 25th May 2020 23:02 Edited at: 2nd Jul 2020 00:30
One thing that was fairly common in retro games was the use of lines of alternating color to simulate 3D movement into the screen.

Retro Game Fantasy Computer Framework Terrain Lines

We have control over the resolution which changes how many lines are used to create the effect. Of course, speed of the line movement is just a parameter as is the starting ypos and the height of the terrain lines area and the two colors the lines alternately use. If you don't want alternating color then just use the same color for both.

The gif conversion really butchered these but the general idea is enough to see in them.




These lines are not simply fixed height lines though... an option is to have the lines scale up in size to create a solid "3d-like" area.



As you can see from these demos the colors can be changed at any time. When the color is changed it does not instantly change all lines... it only changes the color of the "new" lines that are placed in the distance. In this way we can simulate moving seamlessly across different regions.
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: 26th May 2020 20:01
Thanks Cliff. I appreciate that.

It's definitely something I've thought about for a long time!
There's a lot more work to put into it.
Next on the list is adding support for printing, sky backdrops, fades and upgrading sprite positioning with offsets tailored specifically to the constraints of the G24.
Then I will get on to creating the tilemap world editor.
Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 27th May 2020 23:14 Edited at: 27th May 2020 23:15
You can use all the free bitmap fonts i made on itch for the project.
They are very pixelated and retro.
I updated them a few days ago.
There is 3 or 4 fonts that are ready to use in agk.
They are completely royalty free and use as you please.

Look at the old app seuck on c64 for inspiration
shotemup construction kit if your remember?
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 28th May 2020 01:32 Edited at: 28th May 2020 01:33
Thanks a lot Cliff! I just posted an update above. I actually spent some time redoing the small 8x8 font today. I appreciate your offer and will have a look at that later on. Right now I am focused more on just getting the systems all built and figured I would spend time on the "looks" later on. Definitely appreciate your offer and will be sure to check them when I get to that point though! THANKS!
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 3rd Jun 2020 04:54 Edited at: 2nd Jul 2020 00:41
GREAT NEWS! TILE MAPS ARE IN!

I've used the free Tiled map editor for many years and I really don't have any major issues with it. I thought before I created a custom map editor I'd take a look at writing a Tiled Map file loader.
This was very easy to do so I started on the Tile Map Engine for Retro Game Fantasy Computer Framework. I focused on creating a streamlined data structure for the map data testing various ways and taking the one that was the fastest for reading the map data.

Retro Game Fantasy Computer Framework allows you to define two MapViews. Think of them as viewports.

Basically you can create two separate areas on the screen up to half the screen in size and position these map views at any position on screen. Each of these areas can display a view of the tile map. This can be used for many different things from two player games to creating a dedicated area for scrolling messages or inventory or whatever. If only one map view is needed it can be full screen size.

So... using one MapView... a single full screen map display is supported. Using two MapViews... two half screen size map displays are supported.

Here is a gif showing it in action... and yes everything else is still active as well. The Divider Overlay. The Gradient sky and ground. The Terrain Lines. And the actual shmup game itself is still running fully playable.



The two viewports are defined by these two lines...
InitMapView(0, 1, 6,0, 21,8)
InitMapView(1, 1, 6,88, 21,7)

That is InitMapView(TheViewID (0 or 1), number of map layers to display in this view (1 to 3), x,y coords on the screen for the upper left hand corner of the viewport, width and height in tiles)

And to draw these views moving across the map...
DrawMapLayer(0, 0, mapview1x,0)
DrawMapLayer(1, 0, 0,mapview2y)

That is DrawMapLayer(TheViewID (0 or 1), The layer to draw (0 to 2), the pixel coordinate of the upper left corner of the map section to draw)

And here is another demo using both MapViews. This time filling the screen with each map taking up half of the screen.


It's starting to all come together. I will be glad when Retro Game Fantasy Computer Framework comes out of the factory so I can actually use it to make games!
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 6th Jun 2020 06:10 Edited at: 2nd Jul 2020 00:32
Working on the sprites to tilemap collisions now.

I think I basically have this where I want it. The goal here is just to provide a solid framework to make retro game dev simpler removing the need for a lot of the boiler plate stuff. Basically to make game dev more fun focusing on the actual gameplay and so forth.

So here is a test of the system with a two layer tile map. The second layer is just some colored sky pattern thingy and the first layer has the platforms.


The tile maps are in json format. I am not a big fan of that for production stuff because it seems kind of wasteful. So I think I will add support so the framework can save the processed Tiled map in its own binary format and load them as well.

I simplified the functions a bit and made a little better demo of the sprite to tile interaction. It's not really intended to be a physics simulation. Just illustrating the collision checking between sprites and tiles in the map.

And a larger one with faster motion...



NEXT I AM GOING TO TAKE A LITTLE BREAK FROM WORKING ON THIS FRAMEWORK SO I CAN PUT IT ALL TO A BETTER TEST BY MAKING A TINY GAME. Will probably start on that tomorrow. If I figure out what to make by then.
kaband
20
Years of Service
User Offline
Joined: 22nd May 2003
Location: Chicago
Posted: 8th Jun 2020 16:36
Gar Benjamin - I always love the stuff you do. This looks super cool!!!
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 9th Jun 2020 04:46 Edited at: 2nd Jul 2020 00:42
Thanks kaband. I appreciate that!

-----

I have started work on a little sample game just to put the Retro Game Fantasy Computer Framework framework to the test. Nothing beats "real world" stuff to identify opportunities for improvement.

So far, one big thing came out of this. Originally, I was only planning on supporting a Logic Tilemap layer for placing tile markers.
However, when I got into designing an area, I thought it would be very cool if I could use a Tiled Objects Layer.

Retro Game Fantasy Computer Framework now supports Tiled Maps with an "objects" layer.

Now this framework supports tilemap worlds with up to 4 layers (3 for rendering, 1 for logic markers, etc) and 6 different object types placed in the "objects" layer.

The way this works is in Tiled when placing objects you use the type field to specify the type of the object.

For example, here is a blue horizontal door of type "interactive".


The 6 different types supported by the Retro Game Fantasy Computer Framework framework are:
interactive
collectible
enemy
zone
trigger
general


Objects of each type are placed into distinct arrays...
interactive objects are stored in the iobjects array.
collectible objects are stored in the cobjects array
enemy objects are stored in the eobjects array
zone objects are stored in the zobjects array
trigger objects are stored in the tobjects array
general objects are stored in the gobjects array

These are global arrays and after you load your tiled map these arrays will be populated with any objects found of the corresponding type.

Of course, you don't need to use all of these different types but I like to have some structure and classifying objects into different categories is helpful.

The general type is obviously the catch all miscellaneous for those things that just don't seem to fit into the other categories.

These are arrays of the objecttype which has the following definition...


The way this works is when you name your objects you can use that single field to stick additional classification information in (if you want to).

You separate them with a colon. Like this... name:kind1:kind2

So, if you have a name like door:h:blue of type interaction it will be added to the iobjects array with the name="door", kind1="h" and kind2="blue".
The category is a bit redundant in most of these arrays and will simply be "interactive" in this door:h:blue example.

However, where it is useful is any object that does not have a Tiled object type matching interactive, collectible, enemy, zone or trigger will be stored in the gobjects array and the category will be set to whatever the type field in Tiled has.

Really these are just provided as a way to easily get the data out of the Tiled map. You can then do whatever you want with them. Set up your own proper type and arrays, etc.

The way you order your layers in Tiled is with objects as the very top layer (IF you are using objects... you do not have to use them at all). Only one layer of objects is supported and it must be the very top layer in Tiled.
After that you have 4 tile layers to use.
The first tiled layer is layer 0 in Retro Game Fantasy Computer Framework maps. The next one down is layer 1. And so on.

Here is an example from my game project which uses 2 tile layers and the objects layer.


And with objects layer support in I think this will be a huge boost for productivity. Efficient world / level building can be a big hurdle at times.

I will most likely add a function to save all of this data out as a binary data file that will have everything in the same structure as the framework converts the loaded Tiled data to.
Just makes sense I think. This kind of thing is great for development but kind of wasteful when actually releasing a game.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 10th Jun 2020 01:33 Edited at: 2nd Jul 2020 00:33
A Sample Game for the framework... rpg with robots.

So far all is going well with the test game project. The framework definitely makes development much more efficient in my opinion anyway.

I decided to make a tiny sample action rpg game but with robots and tech instead of swords, bows, magic and so forth.

Obviously, this is only just getting started but everything is going smoothly so far...

blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 10th Jun 2020 02:02
Very nice work
Are they your GUI controls (In the previous post) ?
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 10th Jun 2020 02:25 Edited at: 2nd Jul 2020 00:33
Thanks blink!

No... that is showing parts of the Tiled Map Editor. The arrows are because I had selected an object... the blue door.

Instead of writing my own map editor I have used Tiled for many years so I implemented support in the framework to load in tile maps of up to 4 tile layers and 1 objects layer.

Tiled is available for free on Windows, Mac and Linux.
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 10th Jun 2020 02:35
Ok. Very smart GB.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 11th Jun 2020 01:07 Edited at: 2nd Jul 2020 00:34
I finally got back to the Sprite Editor... there were a couple of features I wanted to get into it and now they are done.

IMAGE FLAGS - 24 FLAGS PER IMAGE
Most useful for tiles but these can be set for any images. When you save a project it saves out the normal .gse project file, the .png file containing the images and now also saves out a .gsf file with the flags data for every image in the sheet.

There are 24 flags available for each image numbered 0 to 23. That should be more than enough for the vast majority of games

Just click on a flag's rectangle to toggle it ON or OFF.

The framework has been updated to automatically check for and load the corresponding flags file whenever a spritesheet or tilesheet is loaded.

The framework has also been updated with a new set of functions to easily check a specific flag for a specific sprite and check a specific flag for a specific tile.

You can also get the full value of all flags for a given sprite or tile.

And you can check for multiple flags using flag masks for a specific sprite or tile.
There are constants defined for all 24 flags to make it easy to create the mask for checking multiple flags in one call... FLAG0, FLAG1... FLAG23.

The sprite to tile collision checking functions have also been updated to accept a flags mask.

If you don't care about the flag and just want any collision then pass in 0 for that parameter.
Otherwise, if you want to check only for collisions with tiles that have flag0 SET then pass in FLAG0.
If you want to check only for collisions with tiles that have both flag0 and flag6 SET then pass in FLAG0+FLAG6 (of course you can precalc that and stick it in a variable to be handy and less typing).

Typically these are used for things like FLAG0=The tile is "walkable". FLAG1=The tile represents a ladder and can be climbed. FLAG2=The tile represents water (maybe that means it blocks movement or maybe that means it is time to swim).

More detailed use could be FLAG0=The TOP of the tile is solid. FLAG1=The BOTTOM of the tile is solid.
You can use them however you want, of course! They are there only to make our lives as game devs easier.





SPRITESHEET / TILESHEET LOADING & SAVING

You can now specify if you want to save the project as spritesheet or a tilesheet. Same for loading.
All this does is change the name. Remember the sprite editor uses a simple naming convention for saving and loading files.

For example... a project using palette #5 and images sized 8x8 images will save and load the project file as a spritesheet project named spritesheet_pal5_size8.gse ... it will also save the corresponding image file named spritesheet_pal5_size8.png and the corresponding ImageFlags file as spritesheet_pal5_size8ImageFlags.gsf

Selecting Tilesheet will change the filenames to be... tilesheet_pal5_size8.gse ... tilesheet_pal5_size8.png ... and tilesheet_pal5_size8ImageFlags.gsf

Very important to back up this stuff. A very simple way to do this is to simply select a different palette and save. Remember G24 stores all data as indexed colors in the palettes. So you can draw using palette #5 for example switch to palette #9 save it and when you load it back in you can simply select palette #5 and everything will be remapped to palette #5 completely restoring the original images you drew.



Alright! This is enough "plumbing" work. The next time I can do some dev I will continue on with my sample game project.

EDIT: I just created a "placeholder" tilesheet of 8x8 icons that can be used with Tiled.

These won't be loaded into the game are purely for having a visual reference when working in Tiled.

This is just so we have a bunch of color coded images readily available when working in the Logic Tile Layer or when using Tiles as images on the Objects in the Objects layer. Of course anyone can edit this as they want. But it is nice I think to just have a bunch of icons ready to go.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 12th Jun 2020 05:32 Edited at: 12th Jun 2020 07:41
After spending some time populating the "dungeons" a bit... the world is starting to come to life.

I find it so enjoyable working in ultra low rez. This game is 160x90 resolution.



I am very inspired by the fantastic work done with the games on the systems I played as a kid long ago... such as the Intellivision and C-64.

It's fascinating to me the worlds & experiences they built on a 160x96 resolution screen, a few sprites, tiles and some absolutely brilliant game design and programming.

Brilliant stuff. There is a true art in taking a little and creating so much more and many of those developers back then were very good at it.

The key is focusing on capturing the essence of the experience they wanted to deliver to the player. And within the constraints of the machines the best games focus on that essence. The interaction. Exploration. Even the way the simple visuals are actually very effective in bringing the world context and atmosphere.

Many games were junk or quick cash-ins for sure. But I find inspiration in about all of them. Truly appreciate the work done.

Look at all of the game options and the fantastic design of how they made this. A beautiful example of focusing on the essence imo.


This is an awesome design for an rpg... space was very limited so each thing from the screen layout to the fx of walking down stairs are all to bring focus to the essence of what they wanted the player to experience when playing the game.
pjsmith67
8
Years of Service
User Offline
Joined: 2nd Feb 2016
Location: Nebraska, USA
Posted: 13th Jun 2020 13:59
This looks really cool. I can't wait to try it out.

Phil
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 13th Jun 2020 17:40 Edited at: 13th Jun 2020 17:42
Thanks pjsmith67!

I am looking forward to getting it to a 1.0 release state. It's getting close.

I think it's important to have at least one (and ideally a few) sample demos and micro-sized game projects immediately available. Nothing worse than a solid framework with no documentation or samples.

Working on the game / demos is also a great way to put this to a "real world" test to identify any problems or opportunities to improve it.
So as a result, I am continually updating the systems and api to simplify things, add new bits of functionality and so forth.

The next major piece of the api is audio. Hopefully I will start on that part this coming week.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 14th Jun 2020 06:15 Edited at: 14th Jun 2020 06:18
I got the basic design down for the stats. I don't want to get too carried away with this because it is just a sample game showing how to actually use the framework.
So, I decided on 3 attributes that can be upgraded... armor, weapon power and speed.

I also implemented the shaded (light on top half and dark on bottom half) text option for the smallest font so now the large and small have that. I will implement the shaded option for the medium font soonish.
I implemented a simple notification stack in the game and various touches here and there.

The way the messages int he notification system work is when they are pulled off the stack the delay for how long they are displayed is based on the length of the message being displayed.
When adding a notification text and color are the parameters.

I need to adjust the hitboxes on those collectibles right now I think they are set as being full 8x8 sprites and are really only about 4x4 pixels.

The foundation is pretty much there at this point. So I should be able to get on with actually making the game! As in game play! Some simple battles and so forth.

GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 16th Jun 2020 19:26 Edited at: 2nd Jul 2020 00:36
Not too much more to do to have this sample game project wrapped up.

I will make some other smaller simpler sample projects as well.

This one will be the main one that does a good job showing sprites, tilemaps, sprites to tilemap collisions, sprite to sprite collisions, creating the divider overlay, using the text systems as well as just general game dev with the framework and basic game dev principles such as states and tasks to manage behaviors, etc.

Anyway... a new enemy type added, player and enemy bullets added and bullet collisions and hit indicator light up fx are in.

My bot is very underpowered to take on this thing... by the time it gets here it would have received weapon, speed and armor boosts...


I'll probably make a sample platformer game and shmup game as well. Other than that maybe just some small samples for the various systems and functions.

Doing the game project was definitely a big help.

I increased the resolution of the Divider Overlay so it is now exactly 1/4th of the dimensions of the current screen mode. Also added many new functions just to simplify things such as a function to disable all 8x8 sprites so just one function call takes care of such things.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 18th Jun 2020 05:24 Edited at: 2nd Jul 2020 00:37
The first Retro Game Fantasy Computer Framework Sample Game Project is almost complete!

Great progress tonight... I actually added the sound fx too but for some odd reason the audio seems to be disabled in all of the videos after I uploaded them. ha ha

Anyway...






I hope to wrap this one up tomorrow. I am not sure if I will add audio to the framework. I was thinking about it originally but I don't think there is any need for it.
I do have a couple of more things I want to add on the graphics side though.

I will do those as I continue on with the sample game projects. Not sure if I will do the scrolling shmup or scrolling platformer next. Or maybe a single screen platformer.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 18th Jun 2020 19:48 Edited at: 18th Jun 2020 19:51
Sprite Editor has been updated again.

Now when the cursor is in the Editor Grid pressing the arrow keys will shift the image around according to the arrow key pressed: up, down, left or right.

Here are a couple of videos showing a basic overview of the Sprite Editor.




This isn't meant to be some incredible end all be all of sprite editors. It is intended to be a very easy to use sprite editor that let's us create sprite and tile images quickly.
It's definitely much better than the one I used on my C64 long ago. lol For me personally, I find working in this sprite editor to be super efficient. It handles all of the basics well and as the second video shows it takes into account those special things we as devs need. Such as we might find it easier to draw a larger image in a 16x16 or 32x32 size sprite instead of a series of smaller sprites. So we can do that and copy it. Switch to the smaller sprite size and paste the image in and we will get the series of smaller images created sequentially and pasted in the order they appear in the larger image.
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 19th Jun 2020 00:16
it really does speed up your development (by quite a bit) doesn't it?
Captain Ouais
20
Years of Service
User Offline
Joined: 12th Dec 2003
Location: France
Posted: 19th Jun 2020 10:34
Excellent
I do what i do !!!
pjsmith67
8
Years of Service
User Offline
Joined: 2nd Feb 2016
Location: Nebraska, USA
Posted: 19th Jun 2020 18:31
When do we get to play?

Phil
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 20th Jun 2020 02:45 Edited at: 2nd Jul 2020 00:38
Glad people like this project!

pjsmith67 - I am hoping to do a limited release this weekend. Thinking of you, kaband and blink.

That way maybe there will be a few more sample projects if you all don't mind and also it will help because the code is a bit of a mess I am sure. I have been working very fast on it. Although of course I always try to write solid code that performs well. But nobody and nothing is perfect so of course I expect there are some bugs in there.

The actual "game" is not a full game it is just something thrown together as an example of using the framework. You will get the project for that along with the Sprite Editor source and of course the framework itself.

It's like the "grand" sample loading a tile map for the Title Screen, another for the gameplay, showing scrolling around the level, sprite to collision detection and deactivating actors (enemies, collectibles and doors) when they leave the screen range & releasing their sprites back to the system and then waking them back up and obtaining a new sprite to use when they are entering the screen range.

There is still more to do but I thought I would just leave it where it is and people can do it themselves if they want. Such as adding collision detection and damage if the player bot is touched by an enemy bot.
The second enemy does not actually attack at all.
There is a section on the bottom of the stat panel where a map could be displayed and show the player as a dot (particle) moving through it.

Really I just made all of this because I wanted such a system for my own game dev BUT I thought surely it has to be of interest and use to other people who, like me, prefer things simple. If development is simpler and faster then it is more likely a person will finish a game. And it is more likely the person can spend their time focusing on gameplay and adding more stuff to do in the game instead of battling with technical stuff like how to load the maps, how to display the maps, scroll them, collisions, flags, or even just having an easy way to create images for the sprites and tiles.

This way is like just simple. You create your images they are saved out on a spritesheet or a tilesheet. Say you do that with spritesheet of 8x8 images and a tilesheet of 8x8 images. You just load that in and all of your 8x8 sprites use it. You just set their image to a value from 0 to 255 corresponding to one of the 256 images on the spritesheet. You can also set their frame and used in combination with the image this makes them easier too. You can set the image of a player sprite to be the first image on the spritesheet for the player for example. OR if the player is walking you can set the player image to the first image for walking. Then just change the frame #. When rendered these two (image + frame) are added together.

You load a tilemap and specify the tilesheet image to use. You create a MapView and then it's just "magic"... call DrawMapView to draw your mapview and set the x,y coords for the position to "scroll it". Or use DrawMapViewLayer to scroll multiple layers in a mapview independently.

Images and sprites are already set up for pixel perfect display and so forth. Basically just a good amount of the "set up" boilerplate type of work is automatically handled which means we can get to the more interesting bits that much faster.

Ah well it's been fun developing it!
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 21st Jun 2020 21:26 Edited at: 2nd Jul 2020 00:38
The first sample game is up on Itch.io -

BOT-G2D in the Labyrinth of DOOM
If you get prompted for a password just enter... agkg2dbot

It is a web game so obviously it is not as smooth and fast running as it would be on desktop. It averaged 42 FPS in the html build for me so I simply set it to use sync(2) which means for 60 fps refresh monitors/browsers it will run at 30 fps. Of course it uses frametime to scale everything as needed so the game runs the same as far as game speed but it will not be as smooth to the eye as true 60 fps or more that desktop gets. Actually on desktop I get hundreds of frames per second if I don't cap it in any way.
Still, doing the html build gave me a reason to do a focused optimization pass over the framework so it is quite streamlined now.
On desktop of course everything should be running at full framerate at all times unless someone has an ancient machine.
On web it will depend on the browser and the computer running it.

Trying to wrap this up for the first release!
pjsmith67
8
Years of Service
User Offline
Joined: 2nd Feb 2016
Location: Nebraska, USA
Posted: 22nd Jun 2020 02:20
Tried to run the web game and got this: "Uncaught TypeError: Cannot read property 'rangeMin' of null"

Phil


pjsmith67
8
Years of Service
User Offline
Joined: 2nd Feb 2016
Location: Nebraska, USA
Posted: 22nd Jun 2020 02:25
Never mind, I think it is the 3rd party browser I am using... obviously not quite 100% compatible with everything. I tried using Safari (on Mac) and it worked.

Phil
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 22nd Jun 2020 03:14 Edited at: 22nd Jun 2020 06:01
Excellent! Glad it worked. Yeah these web games are still an iffy thing it seems.
I use Firefox on Windows and haven't had much trouble other than sometimes games are very slow but it seems to be games made in certain ways or something that cause that.

I'm not sure if these AppGameKit web builds are using WebGL or what they are using. Does the game run decently or is it very sluggish / choppy?
I tested it and average 42 fps on the web version on itch. I set it so it should be running 30 fps or more. But of course all depends on the machine and the browser.
That's another thing I miss from the old days. Hardware was much more consistent. These days it is all across the board.

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

BINARY FILE FORMATS ARE COMING NEXT!

Having json and pngs is fine for development but I think for release it makes sense to have this stuff converted into binary file format. Especially the map data but even the spritesheet and tilesheet image files.
These will just be additional functions in the api. So the originals will still be there of course to load the TILED json file and png images, etc. Then there will be functions to save these as binary files after they have been loaded. And functions to load the binary files. So basically during development we just work with the normal file formats. When ready for release do the binary save for them then switch to the binary load functions. I will keep the function signatures the same and just add "binary" to their names.

Actually, in time it would be cool to be able to package everything up inside a single binary file. That might be a possibility sometime in the future.

And once that is done I think this will be ready for a 1.0 release so people can try it out while I switch to focusing on writing more sample games, demos and documentation.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 23rd Jun 2020 01:20 Edited at: 23rd Jun 2020 01:21
BINARY FILE FORMATS HAVE BEEN IMPLEMENTED

The good news is the functions to save and load the spritesheet, tilesheet and tilemap as binary files are implemented.

The bad news is that although it works flawlessly in the desktop build it doesn't work in the HTML5 export.
I don't know if there is some boundary constraint coming into play or what the issue is exactly.
I only know that running on desktop it all works and is very fast.
On the web it bombs out saying a short is trying to be read from a location past the end of the memblock.
Which doesn't make any sense because it is the exact same project, exact same files only built for html5 instead of Windows.

At least it will be useful for desktop and possibly it will work on mobile too.
pjsmith67
8
Years of Service
User Offline
Joined: 2nd Feb 2016
Location: Nebraska, USA
Posted: 23rd Jun 2020 02:07
Will this work on mobile platforms? I assumed it will...

Phil
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 23rd Jun 2020 02:18
The system should all work fine on mobile. Not sure about the binary file formats but those are optional.

I am still checking to see if I can figure out why the binary map will not load in the html5 build. Like to get that fixed.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 23rd Jun 2020 04:18 Edited at: 23rd Jun 2020 04:19
THE WEB VERSION AT ITCH.IO HAS BEEN UPDATED TO USE BINARY FILES.

It SEEMS that in html5 builds it is best to use integers for memblock data being sure things are aligned to 4-byte boundaries.
Originally, in the interest of reduced file size I had used a mixture of bytes, shorts and integers and the reading of the data just did not work.
I changed it to be integers and now the binary files work in the web version.

Anyway, now once loaded everything should be noticeably faster particularly the transition from Title Screen to playing the game.

Same place as before...

BOT-G2D in the Labyrinth of DOOM
If you get prompted for a password just enter... agkg2dbot
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 23rd Jun 2020 19:12 Edited at: 2nd Jul 2020 00:43
THE MAP RENDERING HAS BEEN OPTIMIZED A SIGNIFICANT AMOUNT...

Map rendering speed was increased enough that the HTML5 version of the game on Itch.io now has a framerate 22% HIGHER than it was before for my tests using Firefox on Windows.

The game on itch.io has been updated. Between the speed increase from the binary files and the optimizations on the system I think this is getting pretty solid now.

The scrolling might not be super smooth and that would be because I did not place any fps or sync caps in this build at all. Instead it is wide open to run as fast as it can.
Probably a good idea to cap these html5 builds to 30 fps which it should easily hit that on most machines I *think*. I hit 50+ fps on the html5 build. 270+ fps on Windows desktop build.
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 24th Jun 2020 01:27
Nice. It plays really well and the balance is spot on
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 24th Jun 2020 01:56 Edited at: 2nd Jul 2020 00:44
Hey thanks blink0k for trying it out!

Yeah I think that first sample game project is done. The idea was just to build a game using the sprites, tilemap and other features in framework and have the game unfinished. That way people could use it to learn the framework and maybe even expand on the game. Like the enemy that roams around that kind of looks like a jet does not actually attack. They could add that. Also I did not add collision detection between player and enemies on purpose so people could add that. It is very easy to do basically just look at the code for the player to enemy bullets collision.

I think I will start on a platformer example next.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 24th Jun 2020 03:04 Edited at: 2nd Jul 2020 00:46
Functions to help maximize performance.

I forgot to mention, another thing I added to the framework with HTML5 performance in mind (although obviously can be used for any builds) is a set of performance stat functions and a setspritelimits function.

As you know, by default, the framework supports a total of 256 sprites... 136 particles, 80 8x8 sprites, 32 16x6 sprites and 8 8x8 sprites... on-screen at any one time.

Most games will not need all of these sprites. In fact, many excellent games have been made throughout the decades with only a fraction of this number of sprites even being available.

For example, this first sample game only needs a max of 80 particles (just in case both the player and an enemy explode at the same time which is unlikely but possible), 40-8x8 sprites, 3-16x16 sprites and 0 32x32 sprites.

These four functions tell you how many of each type are active during the given frame...
activeparticlecount()
activesprite8count()
activesprite16count()
activesprite32count()


I simply call setspritelimits(80,40,3,0) before calling Init(0, 5, false, 0, 2) to reduce the sprites the system is managing to the number actually needed by the game. This means the system only needs to manage 123 sprites instead of 256 sprites.
Obviously, this is not something to focus on until needed.

And you also might know exactly the number needed without even needing to use the stat functions.
For this first sample I showed how to use the more dynamic way of asking the system to give an id of a "free" sprite and particle for each thing.

In the next sample, I am going to use the other approach of simply planning out which sprites will be used by which things. For example sprite 0 will likely be the player. Sprite 1 may be a weapon or FX. Sprites 2 to 10 may be enemies. sprites 11 to 16 may be collectibles. And so on.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 25th Jun 2020 00:48 Edited at: 2nd Jul 2020 00:46
Sample Game #2: Platformer

Today, I was thinking of what to base the second game example around. I thought I'd go with a platformer for this one.

I've had an interest in creating some "different" games for quite a while now so I am going with that for this sample.

At the moment, I am thinking of the working title...

Strawberry Warrior


So far, I am finding the framework and sprite editor to speed up development a good amount. And the more work game dev I do using the framework the more I fix tiny bugs and otherwise enhance it.
And I already updated it once so far this evening.

So, I think this is a good way to go. Makes sense to make some samples first, iron out the bulk of issues and also enhance the system for ease of use, performance. That way when I release it, people should have a good experience using it.
I would like to get a first release of it out soonish though. Ideally, by the end of the month and possibly this weekend. It just depends on how things go.

I have to say that, in my experience anyway, AppGameKit is such an excellent game development environment. It provides so much of the foundation in a very straightforward well done way and that is what makes it possible to rapidly develop something like this framework on top of it. I really enjoy developing with AppGameKit!
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 27th Jun 2020 19:56 Edited at: 2nd Jul 2020 00:47
Alright I have to keep reminding myself I am not actually making games I am simply making sample projects so when I release the framework there is some stuff for people to dig into to help them to learn it.

So... I think I will try to wrap this platformer project up very soon basically with where it is now.

I did a quick revamp on the visuals to add some more clarity and color to them. Basically making it look more like an 80s / 90s game.
I've always found it interesting that it's not so much the drawings of things but actually the colors used make such a huge difference.




I will focus on going over the code and doing a clean-up and hopefully can get this released tomorrow.

Then I can get to work on actually using it to make some games!
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 28th Jun 2020 01:25 Edited at: 2nd Jul 2020 00:48
Platformer Sample is done!

It's very basic but of course it is not meant to be a full C64/NES-like game.

It has the platforming essentials including a couple of powerups that primarily change gravity for the player.




Now, I can focus on code clean-up in these two samples. Then in the framework itself. I want to completely break out the abbreviated api into its own file. Because there is no sense in having both sets of functions inside a single file.
PSY
Developer
7
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 28th Jun 2020 19:29
Wow,

this project has gotten pretty extensive.
Very nice work!


PSY LABS Games
Coders don't die, they just gosub without return
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 29th Jun 2020 04:22
Thanks PSY.

Yeah, I kept working on it so it would have everything I need to be able to focus more on just making quality games in a retroish style.

I am going through it now being sure each function is documented in the source. Formatting, etc. Takes time... there are a little over 240 functions in the API. lol

But it is needed because basically it is doing two things... implementing a fantasy computer system and providing an api to easily work with it.

I was hoping to get this released today but I am still going through the code. Hopefully within a few days.
pjsmith67
8
Years of Service
User Offline
Joined: 2nd Feb 2016
Location: Nebraska, USA
Posted: 29th Jun 2020 15:41
240 functions??? WOW! You have put in some serious work on this. That's a lot more patience/time then I would have.

Phil
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 29th Jun 2020 21:10 Edited at: 29th Jun 2020 21:13
Ha ha. Yeah and actually that is just the public api. The inner workings are additional.

BUT... what this does is provide a basically complete framework to easily make a game. At least more so than without it for sure.

Like you can just make a map using the free Tiled Map Editor with up to 4 tile layers (3 for display... 1 for logic) and one Objects layer and with a single function load that map in and even have the objects parsed out into global arrays according to type. 1 function call to set up a MapView. 1 function call to draw that MapView or draw one of the layers within that MapView. Scrolling is dead easy just pass in the mapx, mapy everything is handled by the system.

Sprites have not only a sprite collider but also a tile collider can be added to handle collision detection between the sprites and layer in the tile map. And each tile has 24 different flags that can be set for it in the accompanying Sprite Editor. Each layer can be made opaque or to support transparency.

And just much much more. Gradients, 3 different text displays (8x8, 16x6 and 32x32), terrain lines, divider overlay, 10 24-color palettes. Even options for saving and loading the tilemap and image sheets as binary files. It does a heck of a lot of membank and renderimage work to make it all work.

It's a lot but it really basically creates a fantasy computer system and provides a Sprite Editor and api to work with that fantasy computer system.

I am really looking forward to using it.

I am almost to the point of release now.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 30th Jun 2020 00:56 Edited at: 30th Jun 2020 00:58
ANOTHER ~26% PERFORMANCE INCREASE

I've finished going over the api and being sure each function is commented. Basically, I intend to just pull those comments out as the documentation.

While doing that I noticed a couple of opportunities to increase performance and I implemented those.

This increased performance of the Sample Game #1 : BOT-G2D in the Labyrinth of Doom from 270 fps to 340 fps in the desktop version and the html 5 version is running better as well. I did not cap frame rate for this html 5 build. I uploaded the new html 5 build to itch.io ...

One final pass and compiling the comments into documentation and it will be ready to release!
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 30th Jun 2020 20:02 Edited at: 2nd Jul 2020 00:51
The first mini sample... because jumping straight into the platformer and especially the bot rpg projects is a lot to take in. Those are set up to basically be bases to make whatever kind of platformer or top down arcade adventure a person wants to make.

Starting out simple... this example shows how to load and display a Tiled map along with a player controlled complex sprite object... basically the beginning of what could be a single screen non-scrolling shmup.



GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 1st Jul 2020 01:20 Edited at: 2nd Jul 2020 00:51
Building on that AGKG2D Mini Sample Game Project 1-2 adds enemies, enemy bullets and shows how sprite to tile collisions work including letting the system return the position the sprites should be at.



GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 1st Jul 2020 04:19 Edited at: 2nd Jul 2020 00:51
Finally was able to get back to this again... added the collisions and hit fx.

I think I will add a simple hud in step 4 and then call this sample done. Thinking with 4 steps it should be an easy way to learn the framework.



Login to post a reply

Server time is: 2024-04-19 05:40:11
Your offset time is: 2024-04-19 05:40:11