Carrot Kingdom Demo .8 Changes:
- New Collision System.
- Several Fixed Collision Bugs.
- 2 Additional Levels.
- Mostly a bunch of additional under the hood optimizations/re-writes.
Download the binary.
Carrot Kingdom Demo .8 Changes:
Download the binary.
Sorry for not updating recently, but, things are still happening. I usually update the AtariAge post for convenience than the page here, but I figured now I may as well try and do it more often.
If you haven’t been keeping track there, new things have been added. First a better title screen, very nice. Has the carrot and things in there now.
Next, the entire engine has been update to allow for multiple colours on the levels and multiple enemies so we can get cool scenes like this where some carrot ghosts are trying to corner Jinny by a spooky tree.
Lastly Jinny’s portrait on the lives screen has been updated, so that it’s now colourful! Very nice right? Beautiful kitty girl in all her colourful glory.
All these changes will be in the next demo that’s coming soon. I just have to polish a few things up and we’ll be good to go!
Until then have fun!! :3
I was recently looking around, for a library to do polygon triangulation. I found some great ones, LibTess, Triangle, etc. but they were all a bit heavier than what I needed. I was just intending to do convex polygons, so I figured I could get away with less code to clutter up my folders.
I found an article on GameDev.net that struck my fancy. This article provided two simple examples, the ‘Triangle Soup’ method of making triangles from one point and then dividing them up from there. This mode is easy and simple, but as one commentor suggested, that it does not always make well formed triangles.
Following this suggestion I took a few minutes to modify the basic algorithm into the suggested method of adding a new central point to the polygon and fanning the polygons out from that as the central base. This method makes nice well formed triangles, but adds more of them than the ‘soup’ method.
Hopefully someone out there will find this useful, as I needed it for a project. I have included the simple source example for you to do what you will with.
Keep in mind the code is just quick and dirty as it was basically a test so there’s no “professional” coding scheme just basic conventions and trying to get it coded up as quickly as possible so it may be a little hackey, but hey it’s a nice learning example and maybe can help some people out as I did not see very many if any at all examples of simple Convex Polygon Triangulation. It’s not meant to do any damage, but I am not liable for any, and use at your own risk.
Many many many, moons ago back in the year 2006, I got a GBA flash cart, and started coding for the GBA. The first game I made was Wolf-Pac to honour my dad who was a Pac-Man champion back in the day.
I had forgotten about it until 2012 when I met my friend Darryl. Darryl is a huge Pac-Man enthusiast, and knew of Wolf-Pac before meeting me. He was like, “Whoa, you made that?” when he met me. That was pretty cool, though today after being reminded of it again I typed it into Youtube for whatever reason and found a longplay! Much to my surprise.
It just makes me remember how bad it is haha. It doesn’t really make use of the GBA hardware at all, because I didn’t know how to make use of the sprite or background registers yet. Everything is drawn in Mode 3 (a bitmapped mode) with software sprites and pushing pixels for every object. It uses masking to draw the sprites and only tries to clear the screen as little as possible. There are apparently some errors in this method though as you can see the player has to pause and then resume to see the dots that were inadvertently cleared.
Man, looking at is makes me think how much better I could do it now, but it’s fun to travel down and see your origins. 😀 Anyway I thought you may enjoy seeing it.
Until next time!
After a long time of wanting to tackle some netcode. I finally had the opportunity to do so.
After reading this great article by: @bshokati on the Code Project, I had a good baseline for taking the next step and making some kind of client server program. I decided to keep it simple, I’d make a chat server that spat messages back and forth. Easy enough.
After a little bit of re-reading the code and getting a feel for everything I had a simple chat server. You could connect via IP, set your chat name, and send messages back and forth. Whoo. Such fun. That program was two, separate applications as well, just for the sake of simplicity. One application for the Client and one for the server. I knew in my next step I’d want to alleviate this so I setup a common folder and separated everything into Client/Server/Common code bases and tied them all together with a Main code file.
After I had all the code organized I wanted to step it up and make a simple game, to make a good base for when I add netplay to my 3D School Maze engine. I decided, since I love to abuse the Console window, I’d dust off my old Textmode game skeleton and make a game with smileys running around. I decided to make a textmode smiley deathmatch.
It was simple, the game would be one on one with you shooting the other player with an arrow. Easy. One client, one server, that’s it. Coding the game was easy enough because I already had all the drawing stuff setup, the harder part was figuring out how and when to send the data across the way to keep the games running and the players playing against each other. First I thought, hmm…what if I send the keycodes and have a keyhandler take care of the movement. Then it’ll be like you’re playing someone with a controller right next to you.
This is a good idea in theory, but data packets on the internet sometimes get stuck in traffic and things get out of sync as I quickly learned. Bright eyed and bushey tailed, I fired up my Smiley Deathmatch and started a game 1 on 1 connected via localhost. I moved around and soon I realized, “OMG these are not in sync!” as I looked at the two different windows.
After some thinking, I was on the right track I thought. Sending the keycodes back and forth is a good start, but there needs to be a way to keep things in sync. After some reading, I read about Server Authority, where the Server has final say in everything that happens. So I thought ok, the player can use his keys, and send to the server, and vice versa, but after the server processes the keys of him and the client, he should send a sync packet and sync up all the players.
I then added the states, positions, etc. to the packet, and sent them over. “Viola!” The games were in sync. It does a good job of keeping things in sync, there is no prediciton on the part of the client like “Dead Reckoning” to interpolate where things might be, before the sync packet is sent. This doesn’t seem to be a big deal though as I don’t see things jumping around like crazy. In a 1 on 1 game, with relatively little to keep track of this is fine. Though I imagine that if you scale things up, they may get crazy. It’s a good simple test and I’d like to share with you.
Keep in mind the code is just quick and dirty as it was basically a test so there’s no “professional” coding scheme just basic conventions and trying to get it coded up as quickly as possible so it may be a little hackey, but hey it’s a nice learning example and maybe can help some people out as I did not see very many if any at all examples of simple Winsock games. It’s not meant to do any damage, but I am not liable for any, and use at your own risk.
Enjoy, and make some Cool Stuff!