A journeyman programmer who has been trying for years to be a game developer. Having never release anything more than several weak tech demos, the quest has a ways to go. A recent discovery of game competitions show hope of a fresh start at being less of a coder and more of a game creator.
I wanted to get back into a habit of journaling some of the hobby stuff I've been working on. Just browsing through screenshots of previous projects recently brought back a lot of pride for the projects I've already completed. Even though I never stopped working on projects over the last few years, I haven't done a good job at building up the photo album to remind me how far I've come. Hopefully this all doesn't sound too selfish. Maybe some of the snapshots I upload for my own sake will inspire someone else as many others have done for me. And if not, that's fine too.
The active project I've been working hard on recently is a programming language I'm writing from scratch in ANSI C. This month marks the one year anniversary of development so I felt this might be a good time to journal a bit before moving onto more development. The language interpreter is found here and separately a showcase of programs written in my language can be found here. I hope to upload a few screenshots soon, but this will have to do as an introduction until then.
After a bunch of recent refactor work I noticed something special while merging code into the public repository of my game engine synthpressure. Today I merged my 50th pull request into the engine which has been in public development for just over a year now. Probably doesn't mean much to anyone other than myself, but it's the little things that keep you going.
Turns out my break from game development lasted much longer that I would have hoped. Quite the collection of large life decisions all seemed to come up just as the new year started. After a lot of time and focus, I think I have them pinned down enough to start taking a new project seriously again.
So as the title might hint, I've decided to give a voxel game a try. I've enjoyed playing quite a few in the past, and there is a certain technical aspect to them that I'm excited to learn. Plus I figure I might be able to end my long streak of canceled FPS project if I try generalizing 3D in a simpler abstraction.
A world with 5 voxel chunks.
Blue chunk with a cursor hovering over one of it's voxels.
Blue chunk after a voxel has been removed by the cursor.
As usual I'm building the entire structure of the game from scratch so that I can get the most learning out of the project. I'm using my primitive game engine synthpressure for the general structure of the game, and everything else is new code.
After a short period of tinkering I think I've gotten a basic chunk game object created. The player can use a grid-locked cursor to add or remove voxels from these chunks. With the help of a simple occlusion trick, each chunk renders pretty effectively. Very basic stuff, but it seems like a good foundation to build on. Next up will be some code to add and remove chunks as the world needs.
A few weeks ago I participated in another Ludum Dare event. This was the first event where I was unable to pick a feasible idea in the first night of the event. Although I think the game I built nicely fits into the event's theme, I wish I could have done something a bit more original. At least I can say I learned a bit by coding up all of the game's typical logic from scratch in that short span of time. Oh well, I guess there is always next event :P.
Hiya! Now that the next Ludum Dare is upon us again, I figured this would be a good time for another pre-event blog. Also I can say that this last duration of silence has been FAR more productive than the one before it. I've still been busy at work since a secondary project deadline was established conveniently as soon as the first was completed. At least now I don't feel as crushed, and am happy to start getting back into game development.
I started this month trying to get back into game development by creating a turn-based RPG system from scratch. However after I started groundwork for it, I quickly realized I wasn't going to have enough time to do anything of interest before the upcoming Ludum Dare jam, so I gave up trying to make a game, and focused on engine improvements. Not super happy going so long without writing actual game code, but at least I got to spend some time improving my sprite skills by creating sprites for that started game.
Some of the sprites created for the RPG using the PICO-8 color scheme.
Binary format for PNM image loader: After trying to add 40 32by32 images to this fresh project I quickly realized how slow the text format loaded at scale. After adding support for the binary variants of the format, I noticed a reduction of load time by 4 times.
In-code synthesis of sounds: Took the time to understand the music theory around basic audio programming. Put this knowledge to the test by starting to build a framework around the creation of audio in code. Right now that includes a simple keyboard with configurable filter and oscillator support plus a basic sequencer. My hope is this is a good enough start to finally include some sound with my upcoming jam submission.
Type hints and documentation: Added a bunch of missing hints to several of the large engine packages. Modern Python IDEs like PyCharm can do wonders with these and greatly improve a programmers experience handling the code.
Ubuntu: At the very beginning of the month I decided I was going to upgrade my Ubuntu 16.04 development laptop to the latest and greatest 17.10. Besides the bit of overhead that it took to get my tools and repos setup again, I had to build Python 3.5 from source to get the interrupter version on the OS since it ships with 3.6. Combine that with the long running series of UI/UX bugs I've been having (probably due to the replacement of Unity with Gnome) and I've had it. Going to find some time to reinstall the LTS version this week.
IndieDB: Tonight I had started typing this blog entry earlier, but a failure to upload images led me to lose all of my progress. Not a major loss, but I really do wish you could save drafts in this blog editor.
Probably just going to work on either engine or process improvements until the start of the next game jam. I hope to see some of you guys and girls out there for this upcoming Ludum Dare jam. Number 40, should be quite eventful! If not, I wish everyone a joyful autumn holiday. Talk to you again soon!
If you've read my blog before, you would be aware that I do work a 9 to 5 software developer job every week. Just about a month ago I was pulled along with a handful of other software guys (3 other developers and 2 QA) at my work to create a new UI framework from scratch to be the basis of our team's UI development in the years to come.
It's been a very thrilling but challenging experience allowing me to work with the latest and greatest tech in the domain (.NET Core), while also forming new relationships with peers that I've never known. But beside all that it has been a complete blackhole on my energy to write software. With the extra long days, stressful deadlines, and a software conference thrown in the middle I'm surprised I'm standing after the pace of the last month.
To say the least I'm feeling a bit disheartened how deeply I've been side-tracked on my personal quest to become a game developer. Besides some time working on tooling, and a bit of noodling in the last FPS project, I haven't had the capacity to grow as a game developer for the time of this project. I also feel like I've lost whatever creative relationship I had with my past project, and I'm probably doomed from ever finishing it now.
On a more positive note, things are wrapping up with this project, and I hope to start rebuilding that energy for game development. In fact I would have started toying around with a new project idea tonight if I wasn't having so much trouble trying to compile a specific Python version for the newest Ubuntu. Right now I'd just like to have a computer with a proper working environment by the end of the week and a nice chunk of time this weekend to start building a game, I'd be so happy...
I apologize if this blog is too personal or not interesting enough for your taste in blog posts. I just felt like I needed to record something to help myself close that experience, and start on the next one. Thanks for tuning into this week's drama, hope to catch you next time!
Due to the barrier of entry being dropped for computers, gamers have come to expect the ability to download and run a game in just a handful of clicks. Apparently a .zip of source code is scary enough to prevent a large percentage of gamers from even trying the first room of your game. In this blog I'm going to describe a problem I've personally had with Python game development in relation to distribution, and a tool I've started to work around it.
One of the things I really liked about Java game development was how easy it was to distribute a game demo. Both game libraries I used (LWJGL and LibGDX) could be nested into a .jar file with all native dependencies. From the comfort of Eclipse on an Linux computer I could build a single .jar file that would play my game the same there as any Windows or Mac computer. This means all Windows and Mac users could play the game demos with no extra time or effort.
Python code is just as easy to write in a cross-platform fashion, but preparing a single file for "no questions asked" execution is a bit rougher. A game could be distributed as a series of scripts, but that requires the gamer to have a Python interrupter installed and enough knowledge to correctly install/run the scripts. This is way too much work and responsibility to expect any non-developer to deal with.
A package exists called PyInstaller that can take the collection of game scripts mentioned above and build a "one file" executable from them. Unfortunately the package can only prepare an executable for the platform it is being run from. So this means if I were to run PyInstaller on the same Linux computer that I've written the code, then I would get an executable that would only work on Linux. This is the tool I've been using manually to prepare a single Windows executable to go with any game I've released in the last year.
Fortunately with some modern tooling it shouldn't be too hard to build an automated pipeline that would perform this build process on many different platforms simultaneously.
While I was gone at a software conference last week for work I started building a custom tool to perform this automation. The tool takes the form of a Flask website with a simple HTML form for submitting game source code. On the server side, the source is built into an executable using PyInstaller and packaged back up with any art assets. Once built I should be able to setup multiple instances of the site; one for each of the platforms I would like to support. Then when I'm ready to release a new version of a game, I use these sites to quickly generate releases for platforms different than my development box.
Web form with package details filled out.
I hope to share some more development progress soon as I wrap up the first version of the tool. I'll release source code as usual when that first version gets developed. Leave a comment if you've ever had a difficult time packaging a game release. Were you ever able to automate that process? Or did the tooling just get better?
Just wanted to share a few animations to show off how things are going with the game. Been spending time just focusing on building some core game mechanics like level transitioning, stealth system, and sound triggers. It's been fun, and far more engaging then hard coding level data.
Player walking onto a jump pad.
Enemy template chasing the player up on a platform thanks to a jump pad.
Player picking up and dropping the same blaster.
Player dropping his gun on a jump pad.
It's actually been some time since I've posted a blog, so I felt it important to get something out here. Not that I haven't been working on anything, it's just progress of a new FPS has been slow, and I feel like I need some inspiration/direction before I'm super confident with the way things are going. I'm currently experimenting around with sci-fi/spy themes, but I really don't have much recorded to structure development.
Held blaster being fired by the player at the ground.
An indoor scene with ceilings of differing height.
A switch which opens and closes a solid door triggered by the player.
The next Ludum Dare jam is in December. My current goal is to continue working on this game until then, hopefully with a demo or two before then. That seems reasonable assuming I can hear the muse and refocus soon enough. If that doesn't happen, then I won't push it any further and see if I can find something else to work on in the meanwhile.
As always, thanks for checking in! I'll be certain to post more in the future building on this when I've got it.
Now that the latest Ludum Dare is behind us, and rating is coming to an end, I'm going to need a new game to start working on. Before the last event I was throwing around the idea of finally getting into making a 3D shooter, but after sinking a lot of time on a custom level editor I decided that was probably way too large a project to try and tackle yet. So instead I've chosen to kick things off with some major engine features. Then during this week I'm going to settle on a moderately sized project to start working on using these fresh features and ideals.
Below I will mention a few high level features that were recently added to the engine. Although they both seem pretty simple, they hold a powerful intent; shorter feedback loop. The idea for hotswapping assets definitely came from this Youtube video where Notch uses Java code hotswapping to rapidly build a custom renderer for a Ludum Dare event. If you haven't seen this, and you enjoy the game development process, I strongly recommend checking it out.
Now that I've got a half year of experience making an array of games, I went back and streamlined the graphics interface in addition to the new features. This can't be expressed in animations, but should greatly help game programming in the future.
Assets Management On The Fly
It wasn't until recently that the engine was able to create/update/delete assets in the middle of a game. Previously all assets had to be defined before the game's main loop started. Now an interface exists within the engine to safely change these items during the main loop. Assets include: textures, models, sounds, and levels.
Prior to a recent release all model coloring was stored statically along side the vertexes. Even with dynamic asset management, it was very wasteful to do any kind of effect where a model's color would change between frames. Now there is no static color stored with the model, but instead one provided through the draw methods. Each draw call can include it's own color without any performance penalty or memory overhead.
If you have any interest how an engineer attempts to write a game engine, or you just like Python packages, feel free to checkout the project on Bitbucket. All of the code is open source, so don't be afraid to poke around if you are curious.
No blogs were found matching the criteria specified. We suggest you try the blog list with no filter applied, to browse all available. Join now to share your own content, we welcome creators and consumers alike and look forward to your comments.